With the release of the TI-84+CSE looming, what sort of routines would ASM programmers like to help them out? This would be potentially applicable to Doors CS as well as pretty much any programmer, shell-using or otherwise, who didn't want to keep re-writing all the graphics routines from scratch. Some of the ideas I had:

- 4-bit, 8-bit, and 16-bit color sprite routines
- 16-bit color Bresenham line and circle routines

What do you want?

How about:
-filled/unfilled rectangles
-of course some sort of fastcopy routine (depending on how the LCD works it might be cool to replace a grayscale-style fastcopy with something that supports layers, masking should be much easier now)
-text routines with support for custom fonts
-sprite flipping seems to be another common request
-built-in decompression routines (is this already supported? An RLE routine would be simple enough)

I guess a lot really depends on how the LCD works. For example, sometimes i only care to update a portion of the LCD (say a 64x64 square) so i wrote a routine that would update a variable portion of the LCD. On the 84+C this might be trivial. It's exciting to start thinking about programming it, though.

A fastcopy routine will be complicated, I think. A full-screen 4-bit buffer would take 38.4KB. Even a 2-bit grayscale bugger at 19.2KB takes more than a full RAM page, so I think we'd have to be working with (much) smaller areas. Text routines are a great idea; I know that calc84 is hoping we can get a nice 5x7 font in place for 40 columns and 40 rows of text on a screen. Depending on what we find out about this LCD, I fully anticipate that we'll be able to do sprite-flipping vertically and/or horizontally with no software manipulation of the sprite. I also anticipate that windowing the LCD will be possible.

Can we set the palette ourselves and have GIF support?

We could presumably design such a routine, I guess! GIF support would be pretty cool; I think we need _some_ kind of compressed image format.

Well I was thinking it probably depended more on how many colors the LCD is capable of producing (presumably fewer than 2^32?), more than on our programming skills.

It looks likely that the LCD is a 16-bit (5-6-5) screen, just like the Prizm. Until we find out what sort of controller it uses, we won't know if it has native 8-bit and/or 4-bit formats, or palette support, but for now let's assume it doesn't support those.

A GIF decoder is totally do-able for 5-6-5 color. It would just need to do some color space conversion. And it would be epic to have animated GIFs on-calc.

Anyway, I want a 5x7 font routine first. After that, some more font routines, and then sprites.

Are you thinking 1-bit fonts, which could be given any sort of foreground and background color for the programmer, or something more antialised with (perhaps) 2-bit characters?

I did a quick calculation, and apparently full 16-bit sprites for 127 printable characters would be insane huge (like, 13 K). So yeah, we'll probably just compress it to 1-bit font data. Maybe later, for sophisticated pretty font routines, we could do 2-bit or 4-bit grayscale.

I'd prefer 2-bit or 4-bit transparency as opposed to grayscale; I think that would be the most versatile in terms of making them work nicely with color. Even 127 5x7 characters is 555 bytes, which is nothing to sneeze at, but isn't the end of the world (shell shell shell!).

Sorry i had to chuckle a little.

I could always port my super tiny 3x4 font set to this? .

Oh, I see, you want all of our users to go blind! Now I get it.

I was trying to port some of my Grammer routines last night and I made a code that might draw a B/W 96x64 screen using the same kind of 768-byte buffer we are used to. From my calculations, it can handle about 20FPS at 6MHz. Since I don't know really how to use the LCD ports, I was basically just guessing. I also assumed that the colors were defined as %1111111111111111 = black and %0000000000000000 = white.

Code:

And then I have no clue how grayscale is defined, so I think I probably made a routine to display a colorful (not grayscale) image. However, at least it is a start!

Code:


Aside from that, since we have 128KB of RAM, for backwards compatibility I was thinking of using one of the RAM pages to hold two 768-byte buffers (or 1536-byte buffers for grayscale). The first buffer would hold the current data, the second would hold the data from the last screen update. This way, when you update the screen, you can look for changed bytes and only update what needs to be updated.

I also came up with this routine for drawing an 8x8 sprite (full color):
(define the window size first in both cases)

Code:

And for a 16x16 sprite:

Code:

Yup, those both look good. Also, $ffff is white and $0000 is black; the colors follow a 5-6-5 format. 5 bits of red, 6 bits of blue, 5 bits of green.

Actually, that can be done trivially. Sprite routines will probably use the use the windowing function (and automatic positioning) so they never have to set the coordinates explicitly once the window is defined. Also, the controller supports moving the cursor up, down, left, or right after every pixel, and up, down, left, or right after every row or column is completed. Flipping and rotating sprites is therefore as easy as choosing a different cursor movement mode.

Quite so, which is a handy feature of our particular LCD controller. Hopefully that will help at least certain types of games. It'll also be interesting to see if anyone actually writes a side-scroller that takes advantage of the "Z-addressing"-like mode.

If? I think you underestimate the community

Well, the thing I don't want to overestimate is exactly how useful this mode will be. If you think about it, the main thing it would allow for is backgrounds. Player and enemy ships, shots (maybe not shots), and items still need to be moved every frame, plus scores and health and such.

When using Z-address on the TI-84 Plus, does it automatically updates the LCD? If it's the case, then I assume that scrolling around will cause the part of the screen that is scrolled in to temporarily show up on the other side of the screen, right? (like on the NES)