Background:
Most TI-80s do not have a link port, making it difficult to dump the ROM. While I have had an arbitrary code execution exploit & an emulator for a while, the original method of dumping the ROM (hand-transcribing the corresponding TI-BASIC tokens & then using constraints & a parallel dump of 3.0 & 4.0 to disambiguate the ones that are visually identical) left a lot to be desired, & the link-port-based dumper requires a (rare) ViewScreen TI-80.

As with the TI-81, that seems to suggest using OCR. However, the TI-80 has half as many pixels, poor contrast, & a 4x6 pixel font. I wrote a QR code generator, but it was impractically large & slow. But I remembered using an AM radio early on to try to determine what the calculator was doing, so here we are.

Idea:
The clock frequency & shielding are such that a suitably-tuned AM radio will make noises when you use the calculator, so I wrote a program that modulates whatever the radio is picking up (which appears to be the data bus between the ASIC & the RAM & external ROM) with the bits of the ROM. Then you can connect the radio to a computer, record the resulting audio, & extract the ROM from it.

The encoding is designed to be balanced, because a radio plus sound card would filter out any DC offset. It is also designed to not require much code be typed into the calculator, so it uses pulses (a high & a low period) of varying length. In between bytes are pulses of 3-unit-long high & low periods, while zero bits consist of a 1-unit-long low & high period (note the reversed ordering) & one bits consist of a 1-unit-long high & low period. This is Manchester encoding (thanks, whomever suggested that) with extra synchronization pulses. (The original encoding took 19 time units per byte, while this one takes 11 units per byte & has a simpler encoder & decoder.)

The encoder starts reading at byte address $8000, then eventually loops around to $0000. This dumps the external ROM ($8000-$FFFF) before the internal ROM ($0000-$3FFF), which was done because the addresses are not contiguous otherwise (with memory-mapped I/O & RAM in between). Due to the lack of interrupts & DMA & equalization of code path lengths, the timing varies only due to clock drift, which simplifies decoding. It encodes approximately 208 (rev. B) bytes per second (I need to re-measure rev. A since changing the encoding), which was chosen as a compromise between ease of decoding (especially, avoiding the need for an error-correcting code) & not taking too long (around 5 minutes, due to padding before for the radio & decoder to lock on & after to avoid needing to know the exact timing).

The decoder determines the byte period (which varies based on hardware revision & possibly also the battery level) via the correlation of the signal with delayed versions of itself. It finds the beginning of the ROM by ignoring bytes until it finds one with the high bit set, because the space just before the ROM is unconnected & reads as the high byte of the address, while both known versions of the external ROM start with $D2. It then uses matched filters to synchronize to the byte boundaries & extract the bit values, which offers some robustness to noise (unlike the previous version that looked for zero-crossings).

Usage (tentative):
Tune an AM radio until you can hear when you press buttons on the calculator, then tune it to where the calculator sounds are the loudest (& no actual station can be heard). It may help to turn the radio volume to maximum once it is connected to the computer (make sure it is not routed to the speakers at maximum volume, of course), especially if it causes clipping (since we are trying to recover a square wave anyway). Type in the ROM dumper program, then perform the exploit (both to be released when the decoder is finished). Save the sound recorded from the radio as raw 48 kHz 16-bit mono PCM (which ends up being somewhere around 27 MB in size). Finally, run the decoder program to turn it into a ROM file in the format the emulator expects.
I hope you add a function to the decoder to allow for more than one recording, for redundancy. Even if just 1 bit is off, it could crash the whole calculator, and that would be sad Sad

Edit: I mean taking the median of two or more files. I feel I wasn't clear enough before.
This is next level calculator hacking & research - truly amazing and very interesting to read.

Looking forward to the results!
Some very clever rom dumping indeed, great work! Hope you get a fairly usable version soon! Smile
Fantastic work Smile
Looking forward to the results as well.
This is amazing!
I could not get a clean dump of 3.0. I am unsure if this is due to its hardware being inherently harder to pick up than the other, or whether supplying power to the 4.0 calculator via the ViewScreen connector makes its signal stronger or its clock more regular (& I do not currently have extra CR2032s to be able to test this without having to clear both calculators' memories & re-enter everything). 3.0 runs slightly slower & thus yields more samples per pulse, so it should not be a bandwidth issue. So I tried applying Nomkid's suggestion of taking a median, but even a median of 4 runs still had 3 bit errors left (which is unsurprising, as 3.44 errors would be expected on average were they completely independent).

For one out of the 5 runs I performed, the decoder lost synchronization & ended up with thousands of bit errors, so I excluded it from the aforementioned median. The first run (in which I specifically tried not to be too precise about the tuning or placement of the calculator) had 1583 bit errors, while the best had 93 bit errors. (For comparison, the 4.0 calculator produced a perfect dump on the first try with the same encoder & decoder.)

I am considering making an error correction stage that includes pre-computed checksums for small enough portions of the ROM that they are likely to contain few enough bit errors to be correctible with a checksum of the chosen size. With linear checksums whose total size is small enough (in particular, significantly smaller than the ROM), it should be impossible to recover even a single bit of the ROM from the checksum data (so that having a calculator is necessary).

(The reason to not include error correction in the encoder itself is, once again, that it would require typing in significantly more code, & so far as anyone knows, there are only 2 possible ROMs, so supplying the ECC data is feasible.)

EDIT: Grammar fix
So what are you using as an antenna?
You might have way better luck since this is AM just wrapping a wire around the calculator a dozen or so times as the antenna.
Alternatively if you have an SDR you might be able to use that to also get some easier readings off it/Look at it in a waterfall to generate a more controlled signal representation, since that has more bandwidth/accuracy then just some demodulated am audio that's in some harmonic of the output speed.
Ultimately we try to design hardware to NOT radiate things so your also probably fighting around some form of EMI shielding or something. Which you might want to consider removing from inside if there is any left.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement