Hi David.
+0000: magic1, 0x3B513B51 +0008: headerlength +0014: magic2, 0x00544F42 ("BOT") +0064: execaddress +0068: magic3, 0xB513B513 +006c: destination (0x04000000) +0070: imagetype 0 == plain 2 == compressed +0074: compressedlength
Aye - that pretty much matches whats on the E3.. only the header runs from 0x3B513B51 to 0xB513B513. The rest is image specific. fyi : in the E3 theres over a hundred of these sections - bits containing wavs, images, etc... magic2 is the "filename" - theres also a description string in there somewhere - fixed length/zero filled.. Theres also a simple image crc system there too - you crc the file and if the result is 0 then its a good image - theres a fix-up byte that must be introduced to make sure of the zero result.. Once you work out where that is ( or you can just hack the description :P ), you can either edit the existing image ( simpler under the e3 ), or reflash completely.
I've included what I think is a decompilation of the boot logic at the end (because it's big and antisocial). Basically, PBL supports both compressed and uncompressed images; the data is copied or decompressed to the target destination and the execution address called. Couldn't be simpler (although the code took me several hours to decipher... god, this stuff is hard. I couldn't have done it without Ralph's crib sheet).
What crib sheet ?
This should be dead easy to write code for.
Next order of business is to try and figure out how to reflash it, and then I can give it a try...
Does it do similar keypress checks to the E3 on boot ? I've a list of about 8 "special function" keys - Only 2 of which I can activate, so I'm assuming the others require some sort of special circumstance to be available - I'm still working through the disassembly on this.. Cheers Jake