Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
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.
That is fairly disappointing performance from the screen, but somewhat expected. What is the response time of the LCD like?
benryves wrote:
That is fairly disappointing performance from the screen, but somewhat expected. What is the response time of the LCD like?
Well, there's a difference between what it is for the OS and what it could be. When you're typing a long line of input on the homescreen, it erases and redraws the entire line every time you type, which makes the line flicker somewhat disconcertingly. However, graphing is quite fast, comparable to a TI-84+SE. We no longer have a buffer (2*320*240 bytes is a lot of RAM!), so programs will have to write directly to the LCD. As we have been discussing in tr1p1ea's Consortium topic and my routines discussion, we'll have to find ways to make it easier for programmers to work with the LCD. The long story short is that full-screen updates are slow, but you can update just a small portion at a time, which is fast.
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.
Finally information!
ParkerR wrote:
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.
Here's the result of how the program runs. Notice that by default Pt-On( uses 2x2 points, although you can use the 3rd argument to Pt-On( to change that:



Keep those questions coming! I'm happy to test anything you want.
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?"
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.
TheStorm wrote:
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?
That's not a 6-bit color mode, that's a 6-bit transfer mode. We still need to do 3 transfers per command or data word, for 16 (1Cool total bits per word.

Quote:
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?"
You mean the window? Setting the window is microseconds.

DJ_O wrote:
What I think is:

-BASIC games will see little impact in speed (especially considering most were made to run on a regular 83+), unless they make heavy use of RecallPic/StorePic commands, since most BASIC drawing commands only updates small parts of the screen and there is so much speed lost in interpreting the language to begin with that the overall speed won't change that much.
Correct. StorePic and RecallPic both involve Archive writes and reads, and are slow. Like 1-2 seconds to store and recall, not to mention that you'll get GarbageCollect messages often, since Pics are now 22KB. For normal homescreen games and programs, speed is probably going to be about the same.

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

Quote:
-Games with smooth scrolling, however, might no longer be possible unless something such as Z-address is available.
Also agreed. I just threw together a Frogger game that shows that even "smooth" scrolling for homescreen BASIC games is dicey.

Quote:
-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.
Well, updates are no longer pseudo-instantaneous. You need to pretty much be constantly piping bytes to the LCD for a maximum frame rate, so we're going to see more games that interleave LCD writes with game logic. If you use a window, things are going to get much faster.

Quote:
Of course that's me speculating, but that's what I thought from the info we got so far and the one above.
And you're quite right.
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.
elfprince13 wrote:
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.
A 4MB Flash chip might actually work, if the OS leaves ports E and F at zero on its own. There has also been speculation about whether we could get an 8MB flash chip working with the TI-84+CSE. And calc84 will indeed by trying to get TI-Boy support working, as far as I know, but hopefully he'll tell us more about that himself.
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.
Dapianokid wrote:
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.
It sounds like a Gameboy Color emulator would indeed not really be realistic, but I've known calc84 to do a great job working magic before. We will have to think about any games that could be ported to the new calculator that would work well with its constraints. For example, I would love to get my long-delayed Civilization Simulator II going on this.
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?
GinDiamond wrote:
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?
The OS is also 512KB, give or take a bit. From the early reports, the Boot Code is a bit different, to support the new features like the LCD, but not substantially so.
I'd expect that boot code 4.00 takes care of thepenguin77's boot code downgrader hack?
GinDiamond wrote:
I'd expect that boot code 4.00 takes care of thepenguin77's boot code downgrader hack?
I have no idea, but if you think about it, that's kind of a null problem now. There are no non-MP OSes to downgrade this calculator to.
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 Sad.
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?
Travis wrote:
So it sounds like they have essentially two planes—one for background image, and a foreground limited-color mode for the UI?
That's correct. The background is 16-bit, 133x83, and the foreground is 4-bit, 265x165.

Quote:
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.
Also correct. FloppusMaximus found that screenshots are RLE'd over USB and I/O, but they are stored RAM

Quote:
How does the OS work now without a RAM graph screen buffer?
Mostly the same as ever. It always used the buffer a lot less than we did.

Quote:
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?
It can do horizontal scrolling - fun fact: it's a portrait LCD on its side. We don't know of a trick to do vertical scrolling.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement