21 March 2013, 20:44
Join Date: May 2001
Location: New York City
BlankVector, from the docs:
8. File structures
8.1 .RTB file
.RTB file consists of two parts. The first part contains all the relocation
offsets compressed by my own simple algorithm. It is created with a special
program called RTG (relocation table generator) from specially pre-processed
kickstart image. How to get this image, it is my magic and I'll never tell
anybody about it. One note only: generation of 39.046 .RTB took 1 1/2 hours.
(Manual work, + about 10 mins my 7MHz '010 CPU time). Second part contains BCPL
relocation table and it is required for 1.3 ROM only. It was created manually,
analysing dos.library, which is written in BCPL in 1.3. .RTB file is not easy
to create. I don't recommend anybody to try it *without* very good knowledge of
assembly language and machine code (not the same). N.B. Auxiliary tools to do
such work took 1 month to develop.
8.2 .PAT file
Patch file has a very simple structure. It contains pairs of longs. Every pair
represents an offset from kickstart beginning (first long) and the value to
patch (the second one). Bytes and words cannot be patched individually, every
patch must be coded as a long, even with 3 bytes identical with original. When
a longer patch is to be coded, it must be coded as a sequence of these simple
patches. This stupid mechanism will be improved in next release. There is no
order specified, because every patch has its own, fully coded offset. It allows
simple addition of new patches to the existing file. Patch file must be ended
with two longs of zeros.
From revision 3.12, there may be also relocative patches coded. They
differ from a standard patch by the most significant bit of offset, which is set
to 1. In this case, current loading address is added to the patch value before
storing it. This feature is needed for 39.110 patch. For example, to code JMP
start+$7F900 patch to the address start+$100, where start is the current loa-
ding address, use the sequence 000000fe XXXX4ef9 80000102 0007f900, where XXXX
is original contents of ROM at address start+$fe.
N.B. To create patch file, I'm using this algorithm:
1) First, I patch new values directly into the kickstart with a debugger.
2) I load another copy of kickstart into memory (my 6Megs allow this)
3) I write simple program to generate the patch file directly with debugger's
assembler (I'm using Mon 1.55 by Timo Rossi, which seems to be the most
powerful PD debugger known to me). This program is so simple so I never save
4) I save (with the debugger) the table to the disk.
So I guess since he "won't tell", we're all royally fucked. But I am sure EmuTOS can be softkicked.