Peculiarities in HP supplied S/SX and G/GX ROM dumps

[Jonathan Busby]

I've been dumping some ROM's lately for some code that I've written and I've noticed something strange. Some ( or all? ) of the HP supplied HP48-S/SX and HP48-G/GX ROM dumps on http://www.hpcalc.org contain what looks to be garbage starting around 0x0100h ( in nibbles ). The ROM dumper that I've written first de-configures ports 1 and 2 and IRAM and moves them to the lower 256KiB of memory. After that, the code dumps the upper 256KiB of ROM and then it re-configures the aforementioned memory controllers back to their default locations but then moves the hardware regs to the upper 256KiB and dumps the lower 256KiB of ROM starting at address 0. My guess is that whomever wrote the code to dump the ROM for the dumps that are available on http://www.hpcalc.org forgot to re-configure the hardware regs which start at 0x0100h, and subsequently "dumped" the reg contents, as, it's supposed to be all zeros there, for at least 64 nibbles.

It's just curious as the dumps are supposed to be provided by HP.

Any thoughts?

Jonathan

[Jonathan Busby]

For example, for the GX-R ROM dump on http://www.hpcalc.org, starting at address 0x0100h, in nibbles, at least the next 64 nibbles should be zero, but they're not. eg. :

Code:

$ xxd -c 1 -l 32 -s +128 ./gxrom-r.bin
00000080: e8  .
00000081: 00  .
00000082: f2  .
00000083: 6f  o
00000084: 40  @
00000085: 00  .
00000086: 69  i
00000087: 0c  .
00000088: 88  .
00000089: 33  3
0000008a: 00  .
0000008b: 3a  :
0000008c: 24  $
0000008d: 11  .
0000008e: 10  .
0000008f: 81  .
00000090: 33  3
00000091: 33  3
00000092: 33  3
00000093: 33  3
00000094: 96  .
00000095: 99  .
00000096: 99  .
00000097: 7e  ~
00000098: 33  3
00000099: 33  3
0000009a: 33  3
0000009b: 73  s
0000009c: b4  .
0000009d: eb  .
0000009e: c1  .
0000009f: 01  .

Jonathan

[Giuseppe Donnini]

You're absolutely right! Some time ago, when I wrote my own HP-48 decompiler/disassembler to study the ROM (especially the hidden parts of it), I stumbled over the same problem. At first, I believed I had found 64 nibbles of hidden ROM underneath the MMIO device. After all, the region below the bankswitcher (#7F000h-#7FFFFh) is not entirely empty either, so it was not completely unreasonable to think this was genuine ROM code. But soon enough I found out that I was wrong in my assumption and I ended up patching zeros over the area #00100h - #0013Fh to avoid getting strange results while disassembling in the vicinity of that region.

I could never make sense of it, but I think you came up with a clever explanation. At least there can be little doubt that the nibbles stem from an actual MMIO chip, because, if I remember correctly, the suspicious successions of 3's exactly correspond to the default positions of write-only hardware registers.

[Jonathan Busby]

(03-26-2019 05:32 PM)Giuseppe Donnini Wrote:  You're absolutely right! Some time ago, when I wrote my own HP-48 decompiler/disassembler to study the ROM (especially the hidden parts of it), I stumbled over the same problem. At first, I believed I had found 64 bytes of hidden ROM underneath the MMIO device. After all, the region below the bankswitcher (#7F000h-#7FFFFh) is not entirely empty either, so it was not completely unreasonable to think this was genuine ROM code. But soon enough I found out that I was wrong in my assumption and I ended up patching zeros over the area #00100h - #00139h to avoid getting strange results while disassembling in the vicinity of that region.

I could never make sense of it, but I think you came up with a clever explanation. At least there can be little doubt that the nibbles stem from an actual MMIO chip, because, if I remember correctly, the suspicious successions of 3's exactly correspond to the default positions of write-only hardware registers.

Indeed! I know from my research that the HP48 self test routines move the hardware regs out of the way before computing the ROM CRC. If one checks the ROM CRC check word which is a 4-nibble CRC at the end of IROM, then one gets :

Quote:$ xxd -c 1 -l 2 -s +524286 gxrom-r.bin
0007fffe: b1 .
0007ffff: f0 .

The above is incorrect if one doesn't zero out the 64 nibs starting at #100 . It would seem that the authors of most of the 48 emulators have known about this problem and the emulators must patch the ROM dump, or something similar, or else, during the IROM self test, one would get an error.

Regards,

Jonathan

[Giuseppe Donnini]

(03-26-2019 06:27 PM)Jonathan Busby Wrote:  It would seem that the authors of most of the 48 emulators have known about this problem and the emulators must patch the ROM dump, or something similar, or else, during the IROM self test, one would get an error.

Correct!

Emu48 uses a special byte-oriented format where each nibble is expanded to a full byte with the high-order nibble left zero (which is very convenient in C where half-bytes aren't natively supported). So, in order to work, every ROM dump must first be converted to EMU format and during the conversion, guess what? ... the region from #00100h - #0013Fh (now 64 bytes, not nibbles) is silently filled with zeros!