*.ROM and *.MOD file format documentation?

[Thomas Okken]

Hi all,

I'm looking for documentation about the *.ROM and *.MOD file formats (HP-41 ROM image files). Anyone have a link to byte-by-byte explanations of these?
Thanks,

- Thomas

[Howard Owen]

The .ROM file format is documented in SDK41 over at TOS.

[Doug Wilder]

The .ROM format is very simple. It is 16 bits for each 10 bit word exactly as they appear in the rom.

The upper 6 bits are set to zero. So a 4Kword rom takes 8KB in a PC .ROM binary file. The largest 16 bit word is 03FF just as the largest 10 bit word is 3FF. Open a .ROM file in a hex editor.

To my knowledge the .MOD format has not been released. The .r41 format (found here: ftp://ftp.math.jyu.fi/pub/hpil/swap/swap09/ ) is more complex as it packs 4 words into 5 bytes.

Best

[Thomas Okken]

Thanks Doug!


I guess it's not a big problem to only be able to handle ROM files, since it's easy enough to extract the ROM file from a MOD file.


I took a peek at a couple of MOD files (Finance and Securities), and at first I couldn't make sense of what I was seeing, but given that the original ROMs have 10 bit words, now I get it. I'm wondering, though, what this means for user code. If I want to extract user code from a ROM image, is it OK to just ignore bits 8 and 9, or do they have some significance? I notice that they're not all zero, which is what I would expect (given that user code instruction words are just 8 bits).

- Thomas

[Doug Wilder]

Hi Thomas,

I don't work with user code directly in rom much, the reason being that the HP41C COPY function will pull any rom user code into ram and MLDL will write user code to romram. I just develop in ram.

Didn't look it up so this may be wrong/incomplete:

1) Each new line: the first byte has bit 8 set (so it is 1xx).

2) At the .END. bit 9 is set (2xx). I have to look this up.

3) There are two header words before each user code program to implement COPY and PRIVATE.

4) The entry point/s is at a global label.

5) Jumps/executes distances are in words. They are always precompiled (duh, guess i didn't need to say that).Programs run backwards from in ram so the direction bits are switched. The global chain is still intact as it is needed for COPY.

Best

Edited: 5 Feb 2006, 12:51 p.m.

[Thomas Okken]

I stared at a couple of ROM dumps for a couple of hours, and here's what I found. It seems pretty straightforward. I don't care about the "mystery" blocks (Doug mentioned they are for COPY and PRIVATE), and the details of GTO/XEQ offsets and the global chain are not important for what I plan to do either (when Free42 imports HP41/42 user code, it translates it to its own internal format and the specifics of offsets etc. are unceremoniously discarded).

Thanks again for your help -- looks like I'm good to go! :-)

- Thomas

0000: (1 word)  ROM number

0001: (1 word)  number of functions + 1

0002: (2 words) Offset to pac name. Points to an E0 byte, which is *preceded*

                by the pac name, with letters in reverse order. The encoding

		looks like ASCII but with the letters of the alphabet moved

		to 01-1A. The last character of the name is flagged by bit 7.

0004:           function directory, one 2-word entry per function. If the

		function is user code, bit 9 of the pointer's first word is

		set; for mcode, bit 9 is clear.

		The directory is followed by two zero words, presumably a

		sentinel.

The remaining words contain the pac's code. User code chunks are always

preceded by a two-word chunk of unknown purpose; both the user code chunks and

the mystery chunks have their final word highlighted by having its bit 9 set.

Inside user code chunks, bit 8 is used to indicate the first word of an

instruction -- to help speed up BST, no doubt.

So, to extract user code from a ROM image, the following algorithm seems like

it might be adequate:

1) Get the ROM number from word 0000 and the instruction count from word 0001.

2) Get the ROM name by dereferencing the offset at word 0002-0003 (minus one)

and moving backward until a word with bit 7 set is found. Add 0x40 to all words

in the range 00-1F.

3) Copy the table of offsets into temporary storage. Discard all mcode entries;

sort the remaining entries by address.

4) Import user code, starting from the instruction pointed to by the first

entry in the sorted offset table. Keep importing until an END instruction is

found. Then remove all offsets before this END from the offset table.

5) Repeat step 4 until the offset table is empty.

6) During the import process, keep track of the locations of global labels in

the imported code. Build a new XROM->label translation table. Mcode entries

should be set to NULL so Free42's instruction despatcher will know that it has

to display an error message rather than perform a subroutine call.

7) Display a warning when mcode entries were found in the ROM image; display an

even sterner warning if the user code from the ROM image calls these mcode

functions.

Edited: 5 Feb 2006, 2:27 p.m.

[Vieira, Luiz C. (Brazil)]

Hi, Thomas;

part of what you have already observed is described in 'HP41 MCODE For Beginners', availble with the MoHPC DVD/CD Set. And there is more in there, a lot more... It´s fairly worth reading.

Cheers.

Luiz (Brazil)

[Thomas Okken]

Thanks for the tip, Luiz -- it hadn't occurred to me to look there, but now that you mention it, machine code and ROM layout are topics that seem to go hand in hand! I don't look at those CDs enough. :-)

- Thomas

[Doug]

Yes, it looks like you have it! Keep in mind however that the first line of a program does not have to be a global.

The 2 word header for user code program, used by COPY:

0000 Number of 7 byte registers required to hold the program.

0001 Number of bytes that go into the first 7 byte register so that all the other 7 byte registers are full. Format is 2b0 (or 3b0 for priv) where 0 < b < 8.

3E0 = RTN, usually used at entry to first function (rom name). Although many times HP don't waste the word as rom name is not supposed to be executed. So it could be anything.

Edited: 5 Feb 2006, 11:19 p.m.

[Thomas Okken]

Thanks to all for helping me with this!


I have written a program that extracts the user code from *.ROM files and saves it in a *.raw file that Free42 and Emu42 can use. It still needs some tweaking, but it looks usable... In case anyone is interested, I'll post a message on this forum when it's done, and I'll put it on the Free42 web page for download. Probably by the end of this week.

- Thomas

[Howard Owen]

I wondered what you were up to with the 41C rom images. Sounds really useful!

I imagine these would be loadable into HP-42X with Hrast's RAW42.EXE. Unfortunately, at least one program with 42S specific functions does not work, and actually crashes my 48gx. How similar is the raw fromat for Emu42 and Free42 to the P41 raw format?

Regards,
Howard

[Thomas Okken]

Hmm, if you have a raw file with HP-42S code, and it crashes your 48 when you run it under HP42X, it sounds like you need to send Hrast a bug report. BTW, does it work when you load it in Free42 or Emu42?


On the other hand, the problem could be non-HP42S code, that is, XROM instructions that are not valid HP-42S instructions. I don't know how a real 42S (or a hardware-level emulator like HP-42X and Emu42) will react to that kind of thing, or to synthetic instructions. It might crash.


As far as the format is concerned: AFAIK, all raw files are memory images, that is, the same bytes as in the memory of a real calculator, nothing added, nothing removed.

- Thomas

Edited: 8 Feb 2006, 12:00 p.m.

[J-F Garnier]

I don't know how a real 42S (or a hardware-level emulator like HP-42X and Emu42) will react to that kind of thing, or to synthetic instructions. It might crash.

From what I remember from a HP42S ROM code disassembly, an unknown XROM will cause a "Machine Reset". I didn't try, although it would be easy using the built-in memory editor. It may not be the case with HP42X, as Hrast is an expert in ROM code patch :-)

J-F

[HrastProgrammer]

It may not be the case with HP42X, as Hrast is an expert in ROM code patch :-)

Thanks J-F, but it will do "Machine Reset" or something like that because I haven't patched this :-)

[Tony Duell]

I don't know if it's any use, but my LIF Utilities for Linux include programs to look at an HP41 ROM file (as saved on floppy by most MLDL boxes), and to catalogue the functions in a ROM.

I am not sure whether .ROM and .MOD files are anything like these, but if so, you might find the comments in the source code to be of interest.