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.

So it looks like this calc is not as good as we expected. I probably won't get one.

Great post! I hope the slow display speed isn't a burden for ASM games. Hopefully if displaying a single 16x16 sprite is much faster then it should probably be fine, but I am concerned about how slow scrolling maps might be or games with multiple bullets like CaDan...

The great thing though is that most changes seems screen-related, so hopefully porting games that don't require too much LCD updating (thus, not risking slowing down a lot) can be ported fine. I hope stuff like TI-Boy SE, Gemini or SolidFrame are still possible >.<

Yeah, the calculator is more similar to the current ones than we could have feared... which is both boon (less porting effort) and clear bane (it makes the slowest series of TI graphing calculators even slower).

Question, when a game smooth-scrolls by just shifting pixels horizontally or vertically, does it actually update the entire LCD or is there something making the process faster? I wonder if this could be a way to get around the 5-6 FPS slowdown, because on the 83+/84+, scrolling by shifting pixels then drawing the missing row of sprites/tiles is way faster than just redrawing the entire 13x9 tilemap every frame.

Also, when you goto a PRGM line, does it still scrolls all the way down to the line of code line by line or did they finally add instant Goto? Just on a 84+ the scrolling is annoying so I can't imagine how slow it must be on the 84+CSE if somehow scrolling got insanely slow.

Also, I know we have seen still screen shots of the centipede game in color, but this raises a few questions for me. Being that it's not utilizing the full screen size would it get a better frame rate? Is it possible that the graphics are scaled to 2x size, and would this impact speed? I'd really like to see a video of it in action to see what kind of speed it's operating at.

If the calculator only does 16 and 18 bits color mode, I hope that custom images loader ( 8 bit png, for example) are still possible and that decompressing images isn't too slow. I also hope that it's possible to get rid of the gray bar and battery indicator at the top in ASM games, unlike in the Centipede game AoC is mentionning.

Videos or animated screenshots would definitively be nice, although I don't think the NDA allows it (otherwise Critor would most likely have posted Youtube links of the calc in action a long while ago)

As for SolidFrame, if the game execution frame rate is only slowed down by calculations, not updating each pixel, then it should probably not be impacted too much.

But if its slow framerate is a direct result of how large of a resolution it has to update, then I think we might have to forget about rendered 3D polygons (transparent 3D models with just lines might be fine, though, like Space Dementia 1 on the 68K instead of Space Dementia II)

The LCD controller seems to support a horizontal scroll mode, much like the vertical Z-addressing on the old LCD controller. This seems like it could be incredibly useful for sidescrollers, to use a method much like DJ_O mentioned (shifting and drawing only over the columns shifted in). There doesn't seem to be an equivalent for vertical scrolling though, so 8-directional scrollers won't really benefit (unless they use a method like Super Mario Bros 2 USA where the game pauses for a moment while scrolling the entire screen up/down by a certain amount).