Author Topic: KermM and critor Run First 3rd Party Code on TI-84+CSE  (Read 20438 times)

0 Members and 1 Guest are viewing this topic.

Offline DrDnar

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 546
  • Rating: +97/-1
    • View Profile
KermM and critor Run First 3rd Party Code on TI-84+CSE
« on: February 19, 2013, 12:29:21 pm »
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.
« Last Edit: February 19, 2013, 03:45:51 pm by DrDnar »
"No tools will make a man a skilled workman, or master of defense, nor be of any use to him who has not learned how to handle them, and has never bestowed any attention upon them. . . . Yes, [] the tools which would teach men their own use would be beyond price."—Plato's The Republic, circa 380 BC

Offline KermMartian

  • Editor
  • LV7 Elite (Next: 700)
  • *******
  • Posts: 500
  • Rating: +233/-20
    • View Profile
    • Cemetech
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #1 on: February 19, 2013, 12:43:08 pm »
Great job, team! This news is also available on Cemetech, where I will be posting a full review of the calculator later today. I also plan to post news about the first graphical ASM program for the calculator to directly manipulate the LCD, as well as the hinted jsTIfied upgrades to support the TI-84+CSE.




Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3821
  • Rating: +80/-8
    • View Profile
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #2 on: February 19, 2013, 12:54:25 pm »
So it looks like this calc is not as good as we expected. I probably won't get one.

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #3 on: February 19, 2013, 12:54:41 pm »
Thanks for that information, this could be painful for decent graphics, but at least we know what we are. Too bad they are still clocked at 15MHz max :/ Using an eZ80 would probably have been a better idea to at least take away the sluggish-ness. Did they at least allow key responses while updating the LCD, that way you don't have to wait for the whole screen to update to go to different menus? I mean, I type faster than 5FPS so being able to perform the computations faster than a calculator just because of a slow UI is kind of a turn-off.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #4 on: February 19, 2013, 01:04:43 pm »
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 >.<

Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #5 on: February 19, 2013, 01:06:14 pm »
This sucks that it takes so long to write to the screen. :( I wonder if there is anything we can do to make it faster? :/

Offline Lionel Debroux

  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2135
  • Rating: +290/-45
    • View Profile
    • TI-Chess Team
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #6 on: February 19, 2013, 01:07:07 pm »
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).
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.
Co-admin of TI-Planet.

Offline DrDnar

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 546
  • Rating: +97/-1
    • View Profile
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #7 on: February 19, 2013, 01:08:03 pm »
Xeda, you don't have to update the whole screen at once. For example, TI only updates the current line you're currently typing on, which is much faster, although KermM says it still flickers a little bit. In fact, the screen controller has windowing function, which allows you to confine writes to an arbitrary rectangular section of the screen. So you can just define a window and fill it, without ever having to move the write pointer. I'm reading the data sheet now and will post a WikiTI page summarizing all the features relevant to us.
"No tools will make a man a skilled workman, or master of defense, nor be of any use to him who has not learned how to handle them, and has never bestowed any attention upon them. . . . Yes, [] the tools which would teach men their own use would be beyond price."—Plato's The Republic, circa 380 BC

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #8 on: February 19, 2013, 01:10:28 pm »
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.
« Last Edit: February 19, 2013, 01:12:02 pm by DJ_O »

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #9 on: February 19, 2013, 01:14:02 pm »
Well, on the one hand, I would estimate that drawing a 16x16 sprite will probably be at minimum 30x256 (256 pixels in all for a 16x16 sprite) t-states compared to about 2000 on the current calcs which is about 3.5 times slower on the new screen. Although, since it will be at 15MHz, it will probably be more like 1.5 times slower to draw to the screen.

However, now that I think about it, a 16x16 tile is 2000 cycles, but that doesn't account for byte-boundaries. Since we don't need to worry about that anymore, it might actually turn out to be a bit faster for sprite drawing. Plus, a lot of games that use grayscale will not need to have the LCD updated constantly since the screen supports gray and we can use double-buffering to get the most out of scrolling tilemaps (so we only update what we need to update).

Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #10 on: February 19, 2013, 01:14:55 pm »
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.

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #11 on: February 19, 2013, 01:17:58 pm »
Xeda, you don't have to update the whole screen at once. For example, TI only updates the current line you're currently typing on, which is much faster, although KermM says it still flickers a little bit. In fact, the screen controller has windowing function, which allows you to confine writes to an arbitrary rectangular section of the screen. So you can just define a window and fill it, without ever having to move the write pointer. I'm reading the data sheet now and will post a WikiTI page summarizing all the features relevant to us.
Wow, so we can define a 16x16 window and just write the 48 bytes to it without updating the pointer (not even to shift the write pointer up/down or left/right to go to the next column or row?) if so, that is pretty awesome. We could also use our own palettes without a problem to draw sprites in nice grayscale.

EDIT: By 48-bytes, I mean 768 bytes for a 16x16 sprite.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #12 on: February 19, 2013, 01:18:36 pm »
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 D: (transparent 3D models with just lines might be fine, though, like Space Dementia 1 on the 68K instead of Space Dementia II)
« Last Edit: February 19, 2013, 01:30:12 pm by DJ_O »

Offline KermMartian

  • Editor
  • LV7 Elite (Next: 700)
  • *******
  • Posts: 500
  • Rating: +233/-20
    • View Profile
    • Cemetech
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #13 on: February 19, 2013, 01:38:41 pm »
Not to advertise Cemetech, but if you have any technical questions that I can answer or things you want me to test out on my new calculator, don't hesitate to post and I'd be happy to help. :) Xeda: Yes, that's how windows work.



Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: KermM and critor Run First 3rd Party Code on TI-84+CSE
« Reply #14 on: February 19, 2013, 01:38:50 pm »
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).
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman