The LCD doesn't have its own DMA on the Prizm though, I think it's set up with the processor's DMA.

Might it be possible that instead of a hook routine executed within a loop, there could be a function call to start a transfer, then execute some amount of code (which runs under the same constraints as a hook routine but is not called repeatedly), and then a function call to end transfer (if DMA is not finished by that point, loop until it is). I'd imagine this would work very well for double-buffered rendering, where the previous buffer is being DMA'd and the next buffer is being drawn simultaneously.

Note: In the Protocol 7 page in the chm, I can confirm that you can indeed send commands over USB to and from the Prizm.  It says currently that only IO was used.

Also, info on the OS update:  According to the emergency OS updater, it reports a low OS version (0.02.0200).  It may instead use this as the base OS version and could be confirmed by sending an OS with a lower version number.  Also, the OS code version for the Get Device-Info doesn't report the OS version.  For a 1.04.3200 OS it reports 1.02.0200.

Also, there is a change for the EditMBString* and DisplayMBString* commands.  The unknown variable is int start, representing the first character drawn.  This number will be used as the start of the string drawn, but the OS also does bounds adjustment. Passing 0 and the cursor set past the edge of the screen with cause start to be ignored.

What is that cable? Is it a special Casio calc cable or a standard cable under a different name?