Just to reiterate, everybody is correct: display performance is vastly improved by not updating the whole screen. I'm sorry if people got the impression that we have to update the whole screen every time we want to change anything. (A controller that accepts only full frames yet operates at less than 10 fps would be extremely strange.) I gave the worst-case scenario of updating the whole screen so that people could know what sort of things are impossible, like full-screen full-motion video and Sonic-style games; and what sort of things are do-able, like Tetris, Snake, Sokoban, Blockdude, Galaxian, Pong, Pac-Man, Solitaire, &c. Also, with any luck, TI will get word of this and do something to address the speed issues. Although, that seems unlikely, since the beta testers would have already mentioned it anyway.

Also, note that the pixels are really, really tiny! If you made a 5x7 font, each character would be a little less than 1 mm wide, which may cause some slight readability issues for some people(!) So, people should not plan on using sprites smaller than 16x16. Similarly, high-resolution fonts are a pretty good idea. Unfortunately, large sprites require lots of memory, so it's a good thing we have more of it.

Community members critor and KermM have received preview units of the TI-84 Plus C Silver Edition. So, over the weekend (and all of today, for KermM), BrandonW, calc84, critor, DrDnar, and KermM been working to get simple assembly programs running on the TI-84+CSE. We made significant progress, and have discovered the following:

• The ASIC is exactly the same as the TA3 ASIC on the TI-84+/SE, where port 15h reads 45h.
• Consequently, the CPU speed is still 6/15 MHz.
• There is (again) 128 KB of RAM.
• The TA3 ASIC has always supported 4 MB of flash. It's accessed by writing to ports 0E and 0F. (There's a mystery solved.) There might be support for 8 MB chips, too, but TI seems unlikely to release a such a calculator.
• The screen controller is an ILI9325 or equivalent (http://www.adafruit.com/datasheets/ILI9325.pdf) and is permanently attached to the screen unit.
• Graph screen background images are 16-bit color, uncompressed, but are scaled up 2x for display; the actual data size is 133x83.
• The pixels are likely non-square: the old resolution is 96x64---a 3:2 ratio---and the new one is 320x240, which 4:3. So, the pixels will likely be about 9:8, or 1.125.

   The UI feels a little bit sluggish; indeed, simple calculations suggest that this is because the 15 MHz Z80 is just not fast enough to drive such a large display. Adding a faster CPU mode like 20 or 25 MHz (like the TI-83+SE was originally intended to support) would go a long way toward making the UI feel more responsive. Alternatively, a lower-resolution display, automatic 2x or 3x scaling, or a palette-based or grayscale 8- or 4-bit color mode would also do the trick, or perhaps TI could even switch to the fully-pipelined eZ80.

More technically, the controller only accepts 16- or 18-bit color, meaning 2 to 3 writes per pixel. Outputting a single pixel takes at least 29 clock cycles (for filling the screen with a single color). By contrast, the old controller needed about 100 clock cycles per write, but each write could send 8 pixels, so each pixel only averaged 12 clock cycles. So it takes three times as long to write a single pixel (if you want actual graphics), and the screen has 12.5 times as many pixels. The old controller can accept 120 96x64 frames per second (but it only displays at 60 fps); the new one, displaying only a shrunken 96x64 subsection, can only manage 60 fps. So, the maximum frame rate for full-screen display is 7 fps (0.15 sec/frame), and that's only possible if you're filling the screen with a single color. In practice, 5-6 fps (about 0.2 s/f) is the best you can possibly get for full screen graphics.

Critor ran a CPU test program that DrDnar wrote, which was the first program to produce screen output, and the first to produce troll output:
http://tiplanet.org/forum/gallery/image.php?album_id=144&image_id=2100&view=no_count

KermM is already working to add TI-84+CSE support to jsTIfied. Given that he has a head start and the only major changes are screen-related, he's likely to claim the honor of being the first to add emulator support; however, there is also word of competition from the TilEm team.

EDIT: To clarify, when I said "competition from the TilEm team", I meant that FloppusMaximus has also been in on the action, although he keeps quiet about it.

{13960 33651 33669 33686} * 451.529 = {6.30 15.19 15.20 15.21} MHz
So the CPU speeds are about the same. Here a quote from the CPU clock speed tester I put on TIcalc.org a few years ago.
Jim_E's own program revealed the following values for CPU speed:
Mode Speed
0 ~6.089 MHz
1 ~14.965 MHz
2 ~14.980 MHz
3 ~14.990 MHz
On my unit, a TI-84+SE, with this program I got:
Mode Speed
0 ~6.480 MHz
1 ~15.395 MHz
2 ~15.405 MHz
3 ~15.415 MHz
On a TI-83+SE, I got:
Mode Speed
0 6.135 MHz
1 15.185 MHz
2 15.200 MHz
3 15.210 MHz
My speed tester uses floating-point math to average the results of several speed tests for each of the four modes. The one critor posted above uses the same crystal timer technique, but it only uses the PutC B_CALL, because that's the only one we know. That's why it only posts integers, which can easily be converted to ASCII; and it doesn't average results.

I bet the OS stores a (probably compressed to 8-bit color) copy of the graph screen into the extra RAM, because when drawing to the graph screen, it remembers what you put there after switching to a different screen.
(Special thanks to critor and KermM for these pictures.)

Most likely, the image files can only be stored in the archive, and are streamed directly from the archive for display. (Doing this is relatively easy for assembly programmers; in fact, it's documented in TI's SDK for the original TI-83+.) A full-resolution, uncompressed image would be larger than 64 K; files in the archive cannot exceed 64 K for technical reasons. (Mainly that TI is lazy.)

I think what Flop is getting at is that he is still working on the plug-in API; it hasn't really be finalized. He encourages you to add hooks, which may be incorporated into the official releases.

320x240 = 76800 pixels. Variables can be sent directly to the archive (thus, you can upload files larger than available RAM), but variables in the archive cannot exceed about 65500 bytes in contiguous size.

We need to get right on making Z80 a Z80 GIF decoder.

ld hl, sp
ld ix, sp
ld iy, sp

And an indexRegister+reg8 addressing mode.

But, you know, pipe-lining like the eZ80 has would be just as nice.