Yes, DJ_O, but the hardware and OS were different. Assembly programs like to bypass the OS and interact with the hardware directly. But since the hardware is slightly different, it won't work. Moreover, the OS was also different. The locations of all the safe RAM is different, the program format is slightly different, the program loading location is different, and the OS routines have slightly different functionality.

We're not making up a 25 MHz limit. Nobody's ever mass-produced a Z80 that runs faster than 20 MHz. The only reason we're suggesting 25 MHz is that DS staff told us long ago that the TI-83+SE was planned to support up to 25 MHz. I suppose, though, that if the eZ80 goes up to 50 MHz, it's possible TI could make a regular Z80 (based on modern fab technology) go that fast, or just use an actual eZ80.

The difference between me and Kerm is that I would add a jump table for him if he asked.

Yeah I meant implemented by default though lol. That said (off-topic): I wonder if that United-TI hosted copy of Omnicalc for MP OSes is available anywhere else? Because now that UTI merged with Cemetech, all attachments are gone...

I wrote that. Here it is again.

Here's my professional opinion: A Z80 is certainly fast enough to handle simple color graphics. The biggest bottleneck in current Z80-series games is the LCD interface. The worst feature is the need to wait several clock cycles after every write. It's just long enough to be a major bottle neck, but not long enough to do anything really useful. However, even if the new driver requires no wait states, a larger screen will still take a lot more CPU power to draw graphics for. The lack of wait states could well be completely offset by the need to compute more graphics data. We'll really need to pray for 25 MHz speed.

How the driver implements color access will have an effect on speed. If it's one nibble per pixel, then graphics access will still be slightly awkward. Unfortunately, any higher resolution precludes a fully memory-mapped solution. The Z80 can directly access up to 65536 bytes of memory, but a 320x240 display has 76800 pixels. Chances are, we'll still have to deal with an LCD driver, and we definitely won't be able to make ready use of a back-buffer for graphics. However, if the LCD driver requires no wait-states, it may actually be an advantage: the LCD driver can handle the multiplication to calculate RAM addresses for us.

We also must wonder whether there will be emulation for the old LCD driver.

Edit: Let me just clarify: If TI optimizes their code (e.g. no wait states, less LCD updating, plotting for every other x, better floating-point routines) and raises the CPU speed, they could still get a reasonable graphing speed. However, a 320x240 display has more than ten times as many pixels as the current 96x64 display, so games may have a tough time drawing full-resolution graphics in real-time.

Another point to consider is how TI will be adding more memory. TI can easily add more memory without significantly reducing profit-margins, but they can't add more flash memory in a manner that current software will be able to access without changes. There is no more room in the memory map for more flash memory, but they could easily add up to 2 MB of RAM. If they want to add more flash, perhaps they will use another set of ports to page the additional memory; or perhaps they will switch to a NAND, and we'll have to contend with reading byte-by-byte from an internal buffer on the NAND; or perhaps they'll completely break the current system.

Here's something bad to consider: as long as they're completely reworking the ASIC, they might as well remove the ability to unlock the boot code. No doubt, with great color comes great restrictions on programmer freedom. But that's why we have people like BrandonW. We are firing up our oscilloscopes! We are reading our disassemblers! Native code! will! be! ours!

But I still think it'll actually turn out to be an Nspire in disguise.

Also, SRAM uses very little power when it's not actively being read/written.

On the other hand, the Sonic 3 cart doesn't have a battery. Instead, it uses an alternative to flash/EEPROM called FRAM, so your Sonic 3 saves can last indefinitely.

Try resetting RAM. If MathPrint works right, then some software you're using is causing the problem. Try resending the OS. If MathPrint works right before running any other software, then the OS may have been corrupted by something using BrandonW's old flash unlock exploit, which is now known to corrupt one particular byte of the OS. (In older OSes, that byte did nothing important, but it does now.)