- Brandon Wilson for the LCD driver info on WikiTI, and for ti84pcse.inc

Actually, Brandon Wilson provided almost none of that information. If you check the history, you will see that I did 98% of the LCD driver write-up. The RAM, B_CALL, and flag equates of ti84pcse.inc were discovered by Benjamin Moody (Flop) and the new token equates were given by Christopher Martin (KermM). I wrote up the list of symbolic names for ports and collected the data into a unified include file, and I just posted a minor update to the file. The MicrOS post I made a while ago contains a complete text-mode driver for the color screen, and shows both writing (PutC) and reading (ReadChar). I may also soon post code for turning the LCD on and off and for controlling the backlight.

Any thoughts about doing some fancy lossy image compression? I estimated that, using JPEG-like DCT compression, you could fit a full-resolution image that's almost indistinguishable from an uncompressed image in about 20 K.

The TI-84+/C/SE uses a linear voltage regulator to drop the voltage coming out the batteries down to 3.3 V. Then, inside the ASIC, it uses a charge pump to boost the voltage back up to 5.0 V. That charge pump is not active most of the time. You'll need an assembly program to turn it on. It would be unwise (though probably harmless) to attempt to connect the calculator to a computer when the charge pump is active.

Do not attempt to wire the USB port directly to the batteries. Doing so could damage anything you connect to the USB port. If you're willing to disassemble the calculator, it would be better to cut a hole in the calculator to make your own port for the light. Though, by then, you might as well just make it a traditional backlight controlled by a switch.

ROM error suggests that the OS is corrupted. I recommend backing up all data, and then using the Reset All Memory function. Then, resend the OS. If you're really sophisticated, reflash the boot sector(s), though it's probably unnecessary. This should ensure every sector (except the certificate) is not corrupted.

The "small" letters definitely look great... But yeah, if the speed is so slow that it's becoming a pain for the user, well...

Not at all. Like I said, it feels faster than the OS, and the screen repaint time feels like it matches the key repeat rate. It doesn't, but MicrOS feels more responsive than the OS because it can queue a keypress that's registered while the screen is still painting, thanks to improved, interrupt-based keyboard routines. I also optimized some of the screen handling routines. For example PutSClrWind displays a string, and writes whitespace into any unused area; thus, when displaying a new menu, it doesn't need to clear the whole screen at once (including areas that are already blank anyway), then display the string, because PutSClrWind takes care of both, such that each pixel need only be visited once.

(Also, could you actually leave the font choice to the user, or would that be too much trouble to make ?)

It's not technically impossible, but it's definitely not something I would implement. The most you might get is support for it being a compile-time switch.

If you have questions about the internal architecture of MicrOS, I suggest looking in the source code. MicrOS is fairly modular, and the routines are actually documented, so you shouldn't have too much trouble figuring out how to add your own code. You're also free to use MicrOS code in other projects. For example, you can rip the interrupt and keyboard routines out and copy them into another project without much trouble. The convoluted logic of the keyboard debouncing code is probably the best example of well-commented code in the entire Z80 community.

As most of you probably don't know, two years ago I wrote flash editor utility for the TI-84+/SE. The TI-84+CSE has prompted me to revive the project and rewrite most of it. MicrOS now functions on the TI-84+CSE and has the three vital utilities you'd want to see in a Calcsys replacement: port monitor, hex editor, and disassembler. Additionally, MicrOS, once loaded into RAM, does not use ANY B_CALLs; MicrOS has its own set of keyboard, screen, memory, and flash routines. Thus, you can use MicrOS to edit any part of the OS without fear of crashing MicrOS.

To run MicrOS, copy both MICROS and MILO to your calculator. Make sure MICROS is archived! Unarchive MILO and run it with the Asm( command. MILO will archive itself, load MicrOS into RAM, and transfer control to MicrOS. You'll notice that, because MicrOS doesn't use the OS display routines, it feels faster than the OS.

This initial beta release of MicrOS does not feature full functionality of the hex editor. In particular, the user interface side of the flash editor has not been implemented, nor has the find feature, nor the text mode of the hex editor. Currently, I am requesting comments before continuing major development. In particular, I would like opinions on whether to keep the existing font, or move to a 5x7 font with 2x upscaling. The 5x7 font would make displaying text about 40-50% faster, reduce the size of the font data set by over 1.5 KB, and be a lot uglier.

R04 definitely does something. Here's a fun utility you can play with. It's like the Calcsys port monitor, but for the LCD.

Writing to many of those undocumented registers causes the screen to go haywire.