Omnimaga
Omnimaga => News => Topic started by: DrDnar 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.
-
Great job, team! This news is also available on Cemetech (http://www.cemetech.net/news.php?id=566), 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 (http://84color.com).
(https://pbs.twimg.com/media/BDe8VnzCIAAdMvL.jpg)
-
So it looks like this calc is not as good as we expected. I probably won't get one.
-
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.
-
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 >.<
-
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? :/
-
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).
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.
(http://img.removedfromgame.com/imgs/polytest50.gif)
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)
-
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 (http://www.cemetech.net/forum/viewtopic.php?t=8802) and I'd be happy to help. :) Xeda: Yes, that's how windows work.
-
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).
-
Really? That might be useful then. I wonder if it supports vertical Z-addressing as well? I know on the TI-Nspire 84+ emulator (Clickpad/Touchpad models) Z-address isn't emulated so using it would have been problematic, so I am not sure if this screen has it if it happens to be a TI-Nspire CX screen.
And if it only supports horizontal scrolling, then I guess for games like Zelda you'll just have slower map transitions when moving up/down, like the NES one.
-
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(!) (http://en.wikipedia.org/wiki/Irony_punctuation) 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.
-
What about things such as:
-TI-Boy SE with higher frame skipping (so that it runs at 3-4 FPS max?
-SolidFrame ?
Also I saw games on the TI-Nspire and the computer before using 8x8 sprites I think (or at least attempts at doing so) and the result is definitively weird.
-
Article now cross-posted (and translated into French too) on TI-Planet :)
http://tiplanet.org/forum/viewtopic.php?f=10&t=11287&lang=en / http://tiplanet.org/forum/viewtopic.php?f=10&t=11287&lang=fr
-
Would you guys recommend obtaining one? It seems to me that most are pretty bummed about the lack of performance quality.
-
No; to learn more, click the banner in my sig.
TL; DR: TI is not really supporting us with its 84+CSE.
-
The horizontal scrolling feature could be quite valuable for side scrollers.
Im thinking interlacing is going to be a must for full-ish screen graphics since the timings for the LCD so far have been based on writing the same value and hasnt incorporated reading and expanding from a buffer :S.
-
Would you guys recommend obtaining one? It seems to me that most are pretty bummed about the lack of performance quality.
I guess we'll see how it turns out. :P
This is kind of what we're about - taking these underpowered, poorly-made things and doing amazing stuff with them :D
-
I am quite happy with the challenge :)
-
Here's the clock speed tester program's source code. As you can see, it's a pretty simple program, but we still know enough to get some good hacking going.
-
Guess who's not surprised. :P This is pretty much exactly what I was expecting after I heard it was still z80, although I was expecting a little more than this. They didn't even up the RAM.
-
Like tr1p1ea said, I am curious about how people will overcome the limitation. The fact that it's not locked down like the Nspire might attract coders more, since most people code for calcs to push them to their limits rather than just trying to get Crysis 2 running. According Kerm's screenshot on Cemetech, the speed is much faster than the PRIZM for TI-BASIC, although slower than the TI-83 Plus. I just hope that it won't just make games unplayably slow.
-
I'm actually quite excited for this calculator, but I'm still wondering how practical interlacing will be for upping the screen refresh speeds.
-
By interlacing, do you mean doing something like the 1st Mario in this GIF?
(http://img.removedfromgame.com/imgs/0-mariointerlace.gif)
This might be handy for some games, although some might be totally unplayable that way.
I'M getting the calculator no matter if it's slower, since it's actually a lot faster than PRIZM BASIC and even if ASM is slower, this actually means that a bunch of people will actually enjoy the calc more due to the challenge.
-
Yes, like that, DJ, but keep in mind it will never be more than 1 frame behind. That GIF is very exaggerated. Broadcast television is interlaced.
-
Yes, like that, DJ, but keep in mind it will never be more than 1 pixel behind. That GIF is very exaggerated. Broadcast television is interlaced.
Depends on the framerate we get, though.
-
Well in my case Mario runs at 8 pixels intervals, which is probably gonna be the case on the calculator, especially with scrolling. If you have Mario move by 2 pixels per frame and get 12 FPS with interlacing, this is gonna be slow O.O
-
I doubt we'll be seeing any live action games for a while. Turn based RPGs wouldn't be so terrible, though, since you can just render your effects directly.
-
Well, first of all people will most likely experiment and then write routines to make writing games easier, but early action games will most likely be simple, if there are any.
RPGs will only be in BASIC and Axe (if Axe ever comes out for this calc) because every ASM RPG seems to die. I think that the last TI-83+/84+ ASM RPG ever completed was in 2004.
-
I think that the last TI-83+/84+ ASM RPG ever completed was in 2004.
O.O Wow, that seems pretty crazy.
-
Indeed. We had E:SoR but it died because Zera vanished (Iambian lost contact with him) and he doesn't have the entire story and info D:. There were a few other RPGs starting afterward but most died early. Most other successful RPG attempts were in TI-BASIC (last being Reuben series I think) and Axe (Embers:Phoenix) I think
By the way, here is the first animated screenie of the 84+CSE. However, it runs around 25% slower than the real calc (might be a bit more):
(http://www.cemetech.net/img/news/84pcse_review7.gif)
I added it at the end of the previous news (since I can't edit this one and didn't feel like posting a news just for that, although I will move it up if I write a news about the bugs and stuff since the screenshot shows a Pt-On bug )
-
I tried to write a routine to take a 768-byte buffer of the form we currently use for B/W display and from my calculations, it can manage 20FPS at 6MHz. I was trying to get a head start on making Grammer compatible :)
-
Well at least even if speed is slower on the new calc, I have yet to see a single Grammer game where smooth scrolling is used so existing games should hopefully play at good speed. Games like an ROL3 remake (*pokes Yeong*) would be perfectly safe from unplayable speeds. In his remake, I think he even had to add slowdowns so that moving around the tile-scrolling map isn't too fast.
It would be nice to see Grammer come out on this calc :)
Also Apparently, when using Text(), it doesn't add an extra row of white before the 1st character, so basically text sprites are still possible! (Although I don't know if it will be fast enough)
-
I did some other calculations in class and I have some good news :D The current LCDs are very slow and cause a big speed bottleneck for ASM games. At 6MHz, it takes about 55 t-states between LCD writes and at 15MHz it takes about 135. On the new LCDs, in a discussion with calc84maniac, I learned that every output/input to the LCD costs an extra 3 cycles. Even so, using the new screen is faster for most sprites at 15MHz. Before I learned about the 3-cycle cost, the routine was faster for every sprite that was 89-pixels wide or less (even faster as it got smaller, compared to doing it on an 84+). I think 16x16 sprites will be pretty popular to deal with the larger screen and because it gets a pretty decent speed boost.
What does this mean? Combined with the ability to shift the screen left/right with z-addressing, we could make some pretty fast side scrollers and having enemies on the screen shouldn't be too bad.
Also, people were talking about CaDan last night on IRC and the question of bullets was brought up. However, remember that with the old LCDs, we typically copied data to a buffer in RAM (the graph buffer) and then copied to the LCD. Then for bullets, we would use another buffer to store their locations. With the new calc, we will be copying directly to the LCD and we won't need to worry about LCD delays (except the 3-cycle thingy). So we could probably easily manage an average of 100 cycles per bullet. That is less time than it would require to draw a byte to our current LCDs o.O This is great news for things like Grammer's particle engine because this means that it could handle the movement of 150000 particles per second. 150 000 ! Now I am starting to get excited :)
EDIT: Although, with each of the particles, it would probably take about 150 t-states to also compute collisions and choosing a direction to move, so that would actually be more like 60 000 particles per second. So 1000 particles could be handled at 60FPS with multiple colors :D
-
Yeah if the Z-adress is present, this will help a lot. Granted, we might not have good vertical scrolling, but at least games like Mario will be much easier to make.
Also, here is the first program to access the LCD directly: http://www.cemetech.net/programs/index.php?mode=file&id=856
(http://www.cemetech.net/img/ss/001116.gif)
I think the screenshot uses CalcCapture so it might not represent the real frame rate.
-
Looks like someone is working on a jezzball port, from that pic.
-
Also programs are still 8xp files O.O
This is strange, considering there is no backwards compatibility with older ones or vice-versa, because the 83 didn't either and the extension changed from 83p to 8xp. I was expecting 84p/84i/84k/84v or 8cp/8ci/8ck/8cv files.
-
Are you sure there's not backwards compatibility? It sounds really backwards compatible to me. The only things messed up are drawing commands. Most programs that TI cares about would work just fine.
-
I swear that I heard that some memory addresses content moved around, but I also refered to the new screen as well. By backwards compatible I meant that every monochrome program would be running on both calcs without a single modification and look identical.
-
Some existing BASIC programs will be compatible; no existing assembly programs will be (although some very simple assembly programs will simply need to be re-assembled with a new header file.) Put it this way: there was more backwards compatibility between the TI-83 and 83+ (or even, arguably, between the TI-82 and 83+) than between the 83+/84+ and 84+C.
-
Wasn't there a TI-83 shell that ran TI-82 games or vice-versa (after renaming the 82/83p extension)?
-
But the files are compatible, so why not allow them to transfer? If anything, it makes it easier for programs like tilp.
-
I looked at Kerm's code and it appears that bcalls are mostly the same, too.
-
Well, WikiTI got updated recently with newly found technical information ;)
http://wikiti.brandonw.net/index.php?title=84PCSE:OS:Include_File
-
Ah then that's good to hear. I was sure that more had changed than that. At least I'm glad that bcalls are the same.
-
Hmm maybe some are the same, but not all (most...) aren't, IIRC
at best, there's an offset ?