I don't think you can or should assume resources in a resource fork are stored in a single sequence of bytes. Actually, the file format description for resource forks does say each resource is contiguous.
https://github.com/kreativekorp/ksfl/wiki/Macintosh-Resource-File-Format
It also says the four bytes before the resource data is the resource size. In your screenshot - the number is 0x00010000 which is exactly 64K which is what you got in the fwre_136.txt file.
Oh, I see the problem. In the fwre_136.txt file there are a bunch of non-ASCII characters. DeRez is producing text with Mac OS Roman encoding (the encoding of classic Mac OS) where all characters are assumed to be a single byte. But sed is assuming the bytes are UTF-8 which has some multi byte characters - some of the non-ASCII bytes are being interpreted as multibyte UTF-8 characters but not all combinations of bytes are a valid UTF-8 byte sequence.
The default language in Terminal.app is UTF-8.
set | grep LANG -> LANG=en_CA.UTF-8To get around this, you can temporarily change the language for the sed command to "C" (just add
LANG=C before the sed command). "C" is one of the LANG values that uses single byte ASCII characters similar to Mac OS Roman ("C" might not use the same characters above ASCII 0x80 as Mac OS Roman but we don't really care about those unless they were used for the resource type but none of the resource types in the firmware updater app have non-ASCII characters so that's not an issue).
Code:
cd /Volumes/Storage/Downloads/fwre136
theresource=fwre_136
LANG=C sed -nE '/.\$"([0-9A-F ]+).*/s//\1/p' "${theresource}.txt" | xxd -p -r > "${theresource}.rom"
DumpPCIRom.sh "${theresource}".rom > "${theresource}".4th 2> "${theresource}".logThe reason I didn't encounter this problem is because I'm executing the commands from a worksheet in BBEdit.app which does not have LANG=en_CA.UTF-8 by default.
Once you have the 4th file, you may want to make a copy and make your modifications to the copy.
Code:
cp "${theresource}".4th "${theresource}"_modified.4th
bbedit "${theresource}"_modified.4thThen you can use the toke command to recompile.
Code:
toke "${theresource}"_modified.4th "${theresource}"_modified.binThen you can use the DumpPCIRom.sh command to convert that back to fourth and compare with the original:
Code:
DumpPCIRom.sh "${theresource}"_modified.bin > "${theresource}"_test.4th 2> "${theresource}"_test.log
bbdiff "${theresource}"_test.4th "${theresource}"_modified.4th- The variable length padding in the modified rom is all zeros. I don't know if this is used by anything. Maybe there should be a tokenizer option to set the variable length padding just as there is a tokenizer option named
pci-data-structure-start which affects the size of that padding.- As for the fcode itself, the checksum indicates there is differences. But that's not a problem for most differences. For example, different words maybe assigned different fcode numbers (you see how toke defaults to using fcode numbers starting from 0x800). Another change could be if the old fcode used a literal for the values
0 or 1 instead of the more efficient words zero or one.- The original rom defines a variable with fcode number 0x124. This variable is given an fcode number of 0x80c in the modified rom which affects the numbering of all subsequent definitions. 0x124 doesn't appear to be used anywhere so you can maybe just comment out this line. do toke and DumpPCIRom.sh again, and see that there are much fewer diffs remaining.
Actually, there is a way to change the numbering of definitions. Change the line
variable variable_124 to this:
Code:
tokenizer[ 124 next-fcode ]tokenizer
variable variable_124
tokenizer[ 80C next-fcode ]tokenizerThe
next-fcode directive is solves this difference but there should probably be push-next-fcode and pop-next-fcode directives because setting the next-fcode to 80C is only going to work if the number of definitions before this hasn't changed which might happen if you decide to make modifications.
Last edited:
