KermM and critor Run First 3rd Party Code on TI-84+CSE

[DrDnar]

Community members critor and KermM have received preview units of the TI-84 Plus C Silver Edition. A review will be forthcoming soon on Cemetech, so keep your eyes on Cemetech's front page and forum for the math and programming features of the TI-84 Plus C Silver Edition, inside and out. 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 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. 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.

Editor's Note: TI-Planet has requested that we note that they replicated this article on their site to help increase publicity. We cooperated with Omnimaga on simulcasting this news.

[benryves]

That is fairly disappointing performance from the screen, but somewhat expected. What is the response time of the LCD like?

[KermMartian]

[ParkerR]

This would be an interesting test for it. http://tibasicdev.wikidot.com/sierpinski-triangle

I think it would show how well it does random drawing to the graph screen.

[CalebHansberry]

Finally information!
_________________
"If I had to answer 'why' and justify the business sense of all of my projects, I'd be stumped, but with hobby projects, 'because [I/we] can' is not only a valid but awesome answer." - Kerm Martian

[KermMartian]

[TheStorm]

The Datasheet for the LCD you linked seems to imply support for a 6-bit mode on page 42. Is there a reason we cannot use this to gain a bit more throughput?

I also wonder if and how Pat was able to get decent performance in his centipede game knowing the info we know about the display. He doesn't seem to use many colors perhaps he is using some tricks to allow him to easily only update specific regions of the screen where there was movement. How quickly can you resize the "Motion area" on the screen? Perhaps that feature can be abused to minimize screen update times. "If area less than x resize update region?"
_________________

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown

"If you've done something right no one will know that you've done anything at all" -Futurama

"Have a nice day, or not, the choice is yours." Tom Steiner

<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.

[DJ_O]

What I think is:

-BASIC games will see little impact in speed, because BASIC is so slow to interpret that this will make any speed loss even less visible, plus most drawing commands don't update big parts of the LCD at once. The largest speed loss I ever heard about was home screen scrolling (which is probably due to the entire LCD being updated by scrolling), and that was from "For(Z,1,999:Disp Z:End".

-ASM games like The Verdante Forest might slow down slightly, but due to lack of scrolling they shall be safe.

-Games with smooth scrolling, however, might no longer be possible unless something such as Z-address is available.

-Programs that requires updating the entire LCD every frame (such as Solid Frame) might be impacted signifiantly but still possible if those games did not require a fast frame rate to be playable.

Of course that's me speculating, but that's what I thought from the info we got so far and the one above.
_________________

Former 83+ coder, now doing 84+CSE stuff, Omnimaga/TIMGUL founder.

Follow me on Bandcamp|Facebook|Youtube|Twitter

[KermMartian]

[elfprince13]

Definitely some interesting news here. I wonder if anyone (read: BrandonW) will hack a 4MB Flash chip into a standard 84+SE now that we know it is supported. Also, I'll be interested to see what calc84 can do with TI-Boy SE with the new windowing support.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[KermMartian]

[Dapianokid]

Hopefully TI-Boy SE will be able to support color, but from what I hear it may not be able to because of the processor not being faster.
_________________
What if we all got together and did something ridiculous?
Well?

[KermMartian]

[GinDiamond]

The 2.55MP OS is 512KB on calc, leaving the rest of the ROM for the user and stuff. How large is the OS for the CSE?

Oh, and is the Boot Code 4.00 for the CSE basically the same as the 1.03 boot code for the regular 84+'s?
_________________
Do not muddle in the affairs of dragons, for thou art crunchy and taste good with ketchup!

[KermMartian]

[GinDiamond]

I'd expect that boot code 4.00 takes care of thepenguin77's boot code downgrader hack?
_________________
Do not muddle in the affairs of dragons, for thou art crunchy and taste good with ketchup!

[KermMartian]

[tr1p1ea]

Dang i was hoping last night that it wasnt going to be multiple writes per pixel (on all modes) but i guess that was always to be expected :S.

Has there been any information on a screen buffer (extra RAM pages?)

Going to have do some work regarding buffering for graphics to see what works best (bit expanding, palettes, double buffer comparison before writing etc). My worry at the large screen resolution has been justified .

[Travis]

So it sounds like they have essentially two planes—one for background image, and a foreground limited-color mode for the UI?

And yikes! 22KB per Pic, and I guess they didn't bother with some kind of rudimentary compression? And it sounds like Pics are required to be saved in Archive now.

How does the OS work now without a RAM graph screen buffer?

Overall, the performance sounds pretty disappointing, though I'm sure some tricks will be developed to help work around this. Does the display controller provide anything that would make reasonably smooth fullscreen scrolling possible?
_________________

[KermMartian]