DM-15CC ROM grabbing

[David Jedelsky]

Hello everybody! :)

I'm back from holidays, so I will write some information (as I promised some time ago in reply to Mark Hardman's question) how we scanned the HP1x calculator ROMs.

uhmgawa in previous thread had brave reactions how the ROM grabbing is easy :). It looks like he is very well equipped with logical analyzers and other gadgets :). I agree this way it could be very easy to grab the ROM. But I have literally no single piece of such equipment. Even access to something like this anywhere. So I decided to grab the ROMs directly with our DM-15CC calculator. It means using board with ARM cpu (LPC1114) running at 48MHz. Don't you think it is much more fun?

The DM-15CC calculator has serial link over USB. So the idea was easy. Just read few logical signals in loop (finally just two: the ISA bus and sync signal) and send read values over serial link into PC where the received data is stored into file. And as a second step write simple utility to decode signals in a of-line way from grabbed serial line data.

After few tests I have found the actual bottleneck of the whole 'system' ... the maximal usable speed of serial line. So I just used small capacitor to slow-down the calculator's clock to be able to obtain usable samples.

Then I have written the of-line decoding utility using python. It just read the grabbed serial data and decodes the address:data pairs from it. Nothing especially big ... some 160 lines in python :).

Here is the whole process:
- HW preparation -> connect ISA and SYNC signal to grabbing calc and attach slow-down capacitor
- Pressing ON+[+] on the real calc (it is infinite self-test)
- Start serial data grab into file on PC
- Run it for few minutes ...
- Offline decoding - run the python decoder and grep the output to create final ROM file

So, for all interested. Yes! We are also using the self-test trick :).

Finally, somebody could be interested how long it took to do it everything from the start to the final ROM file (if anybody want to do it by yourself). I divided it into two sessions (well, the time is precious) approx. two hours each:
- First one: the ARM code and read of serial data into PC
- Second one: decoding utility and final dump

At the end I apologize to all who hoped I will uncover some big secrets in my post :) (I hope nobody expected anything special) ... and I hope you appreciate it :)

Regards,
David

Edited: 13 Aug 2012, 7:38 a.m.

[uhmgawa]

Quote:

---

uhmgawa in previous thread had brave reactions how the ROM grabbing is easy :). It looks like he is very well equipped with logical analyzers and other gadgets :). I agree this way it could be very easy to grab the ROM..

---

Unsure how/where the notion of a logic analyzer entered the
picture.

Capturing a voyager rom image really isn't difficult given the simplifying assumptions.
Case in point the only instrumentation I'd
used was a lethargic 20MHz SH1
eval board, running code uncached out of
external 8-bit wide EPROM -- a
veritable antique.
For several reasons a logic analyzer wouldn't really be my
first choice as the most efficient tool.
A trivial SoC is more than fast enough at the
voyager NUT ISA bus 4.5us cycle time, and the flexibility
of a programmable SoC lends well to the task.
While it is possible within tolerable impedance to load the
LC tank to depress the oscillator frequency, I
found no need even with the above 20MHz SH1 clunker.

I used an alternate approach vs. capture and dump of raw
unprocessed ISA data.
Here the SoC synchronizes on the ISA T1/T2 and collects the
56-bit bus transaction in realtime. Doing so it is possible to recognize CXISA instructions and their corresponding
address allowing trigger at a specific point
in the cyclic CXISA scan. Moreover the substantial bloat of
intervening loop instructions is removed from the trace.
At this point it is trivial to simply dump the fully
processed rom image data to an async port. That's it.

It would have been a bit more cumbersome without the firmware's
repetitive self-test mode, being necessary to manually
restart the self test.
Yet this would have accomplished the same goal.

Concerning the NUT oscillator, it is possible to drive it directly
with a ttl-level pulse train. IIRC either oscillator terminal
will work however the expected 180* phase shift may make
a difference depending on your T1/T2 synchronization approach.
The only situation where I'd needed to do so was for
a 15C I had setup as a partial ICE where I needed to both
drive and capture the ISA bus data, along with in-flight
processing of the NUT instruction behaviour.
Providing for very long sequences of ISA cycles to be
dumped to an async port,
driving the NUT oscillator was preferable to an attempt at
buffering the logged cycles.

My goals were a bit more complex as KINOMI needs to accurately
drive the ISA bus, specifically to interact with the R2D2
lcd controller. There are at least a few undocumented
gremlins in the R2D2, which I was able to accommodate sans one.
I couldn't quite get the R2D2 10m timeout to function as
advertised.
I'd abandoned the task after some time as KINOMI really doesn't
need to use the R2D2 timeout and doing so consumes another i/o
pin. But it did irk me not being able to solve that mystery.

In any case some study of the HP NOMAS docs will provide
sufficient detail of the protocol to get the above job done.
While I fully applaud HP of olde for making this information
available, my discussions with the incumbents concerning
their view of the legal status of these
images and subsequent release of the same in the context
of an open KEMU/KINOMI project has gone nowhere.
And regrettably it has taken far too long
to arrive at that destination.

[David Jedelsky]

Hello Uhmgawa!

Very nice, it looks like big project. I didn't know anything about KINOMI project and now I have found few videos about it and it looks great. Is there any website or other information related this project? Could you, please, write some more information about that?

You have a lot of information about the calculator's hardware. Is that mainly from your investigations of hardware or is somewhere available at least partial documentation? (e.g. you mentioned some HP NOMAS docs).

But back to the grabbing of ROM image. Yes, I very well know that I would be able to read directly contents of ISA bus and decode it on our calc hardware if I would know more about the calculator's hardware :). But what I knew was just there is some kind of bus, so what I did was just writing small grabbing loop on ARM to guess which of the signals looks promising (and it is the place where the logic analyzer would be handy :) ). And after that, when I already had the grabbed data on PC it was apparently easier to decode it there then writing ARM code for decoding.

But I agree that was just my way (including the bus slow-down), because my goal was to decode ROM as fast as possible with very minimal knowledge at the beginning :). And I think I succeeded with doing it in four hours. Sure at the cost of that it could be done in more elegant way.

Finally, you mentioned the repetitive self-test mode. I have to say that we are very happy that the self-test is reading all the ROM, without that it would be much more difficult and from that point of view it is really easy to grab the ROM. And with the repetitive self-test mode it is
just ideal situation :).

Thank you very much for very nice reply!

David

[uhmgawa]

Quote:

---

Is there any website or other information related this project? Could you, please, write some more information about that?

---

That was my original intention and at
this point largely a weary story.
Although I'd tried earnestly, I'd been unable to get any definitive
statement from HP concerning voyager firmware legal status.
Free time has been my limitation thus far, however
I will likely release it without
rom images and leave those interested to dump their own personal
voyager roms for experimentation.

Actually one of the early use cases envisioned for a
KINOMI module
was as a generic replacement NUT cpu for a defunct voyager.
That rationale was based upon the assumption of
the NUT cpu being the most likely component to fail,
given a voyager has 13 key matrix "ESD antennas" meandering
around the pcb. So in this scenario a KINOMI module once
inserted could pull the image from the ISA roms and self
program the image into its internal flash. Also from a
personal use perspective a case could be made for
extracting the rom images for download and safe keeping.

Quote:

---

You have a lot of information about the calculator's hardware. Is that mainly from your investigations of hardware or is somewhere available at least partial documentation? (e.g. you mentioned some HP NOMAS docs).

---

The NOMAS documents describe basic timing of the ISA protocol.
The balance was discovered through experimentation. Most of
that information is now captured in the KINOMI ISA bus driver.

As I've indicated previously,
substantial credit goes to Monte Dalrymple for the
comprehensive and professional effort documenting NUT cpu
instruction semantics as part
of his NEWT project. Several times as I was writing KEMU,
the NEWT specification (and Monte personally)
were able to illuminate the numerous dark corners
of the NUT instruction semantics left by the NOMAS documents.
This appears as well to be hard won knowledge extracted from
his personal experimentation.

Quote:

---

Finally, you mentioned the repetitive self-test mode. I have to say that we are very happy that the self-test is reading all the ROM, without that it would be much more difficult..

---

That does indeed make capture easy. Although not strictly
necessary, driving the bus to access the rom isn't complex and
was a sanity check against capture using the
NUT's CXISA checksum scan. You do need to remove the
NUT CPU as there is no provision in the voyager NUT lqfp-44
bonding to tristate the bus.

Well actually there seems to be a "test" line on the die
for exactly this purpose,
but I didn't find it bonded out to a pin.
If this was available the
task would have been far easier. Removing the CPU is a bit of
a trick as unless you plan on cutting all heat stakes, desoldering
in place is frustrated by needing to minimize heat degradation
of the 30 y/o zebra conductors located
directly under the NUT cpu.

I had laid out a small probe board which functions as a compact
connector mating to the land pattern of an extracted voyager
NUT cpu. It as well allows an external SoC to drive the
balance of the voyager PCB using a far more tidy
FFC interconnect. In fact the voyager housing could be
closed normally with the FFC exiting through the upper/lower
housing seam, with the probe in place.
But before finding time to construct that tool I managed to address
the remaining loose ends (eg: ON + y^x rotate-22, etc..)
with the probe fixtures.

[David Jedelsky]

Hello uhmgawa,

Thank you for your response. You should definitely create some project site and store there your hard-labored results. I believe it could be valuable for other people even without the actual ROMs.

Regards,
David