It goes away after a few days


Memory: 16 MB User ROM, 61 KB User RAM, 32 MB ROM total.
LCD: 216x384
Processor speed: Thought to be 29 MHz in regular mode, but can be overclocked to 116 MHz.
Processor model: I can't recall the model off of the top of my head, but it's not the faster DSP model.

I really hope that doesn't mean that you can only have 33KB apps (at most) because of that 28KB header. Are "add-ons" run from ROM like Apps?

They're stored in ROM, but it seems like they're copied to RAM memory when running - probably a section of RAM that's beyond those 61 KB.

Ah, that would be interesting to find out more about. I tried looking for some information on the Prizm Wiki, but I was disappointed to see that it doesn't have much content yet.

Er, well that's the result of my schedule's forced neglect. A good chunk of the stuff we know isn't posted yet.

But to answer your question, add-ins are written to memory at 0x00300000h and run from there.

Oh right, you already told me that, and I completely forgot. >_< Sorry about that. Does that imply that the actual RAM size is at least 3.15MB, then, or is the address space discontinuous?

Well, I'd guess that it's either discontinuous or that's the address of the virtual memory location. I think the latter is more likely though, seeing as how no one has reported two RAM chips.

Yeah, that's what I was thinking as well. I'm somewhat looking forward to getting my hands on one of these to help with the reverse-engineering effort, but I'm hoping it doesn't convince me to abandon my beloved TIs.

Update: The OS appears to be encrypted with a MD5 hash. While it's disappointing that there's anything more than a simple checksum guarding it, it's not infeasible that the code could be cracked like with the Nspire.

I think you mean *signed with an MD5 hash. Since MD5 is a one-way hashing algorithm, allowing you to calculate the checksum of a message but ideally to not be able to deduce the message from the checksum, it can be used to secure but not encrypt data.

Er, yes, thanks. It'd be kind of hard to write an OS in 128 bits

Hehe, you could try. So basically, it just hashes the OS and checks the hash in order to make sure it hasn't been corrupted, not to enforce any security? That's excellent if so.

By the way, my Casio Prizm still smells after one month of usage.

Also Casio screwed up on OS 1.02.0200 release: they re-introduced the Locate bug that was in OS 1.01.0200, even though it was fixed in the other OS 1.02.0200 that was pre-loaded on calculators available in retail stores (those found online had 1.01.0200). In fact it's a double-screw-up because they made two OSes with the exact same version number...

Those who bought their calc brand new, factory-sealed, with OS 1.02.0200 pre-loaded on it, DO NOT UPGRADE!

Well, we have no idea what the boot code is like at the moment, so I can't give you a real answer to that. All I can say for certain is that the OS updater checks the MD5 hash of the OS.

Yay resources! What about that zip that may or may not have appeared in my inbox, is that ready for public release, or is it still under wraps?

I released it on Omni. I'll post it here when I'm done later.

Sounds great. For the sake of my poor file server, may I hope that it's hosted externally?

Yep. I also eliminated the insane 12 MB prizm3064 file to avoid intellectual property laws.

Excellent, that must have roughly halved the size of that massive file. For some reason, I think the thing that impressed me most about the sample Add-In in the zip file was that the two icon states made the eye that was the icon open and close.

Some of the errors that can be generated by the AUX_DisplayErrorMessage() syscall. It takes an integer argument and generates these messages for each value. Execution of the program continues normally after EXIT is pressed.


Code: