Slow down - the danger to mix up things is big (i know what i'm speaking off)!
Quite right. If the intent is to start modifying the disassembly, then there's a LOT more work to be done in Resource before you get to that stage. I'm doing some of that for you guys but you will need to do a lot of checking yourselves.
The reason? Just because the disassembly will compile back to the original binary and run is good. But there are heaps of references that will be pointing to the wrong places if the size of code and data is changed.
When disassembling a binary that uses absolute addresses with a fixed origin in memory, Resource can only do part of the work automatically. There are three areas where the job has to be done manually and thoroughly. All the examples below are taken from the original BW binary brought up to the same standard as the extended levels one and with Hungry Horace's labels overlaid:
- Short Absolute effective addresses. These look like, for example (file offset $00023C):
move.b d0,$05C9
Resource does not automatically resolve these. They have to be manually resolved to a label at the target address:
move.b d0,adrEA0005C9.w
That ".w" at the end is critical to tell the assembler that this is a SHORT absolute pointing to the label.
- Word-size code Jump Tables. You'll have already seen these in the BW_EXT disassembly. For example (file offset $0011F2):
adrEA0015AE: dc.w $0000
dc.w $FF6C
dc.w $00F0
dc.w $FF4E
dc.w $FFFA
which becomes:
adrJT0015AE: dc.w adrJB00166A-adrJB00166A
dc.w adrJA0015D6-adrJB00166A
dc.w adrJA00175A-adrJB00166A
dc.w adrJA0015B8-adrJB00166A
dc.w adrJA001664-adrJB00166A
after the offsets have been resolved to the 'distance' between the base address and the destination addresses. Again, these have to be resolved manually (with the help of a couple of macros to do the donkey work).
- Word- and Byte-sized data offset tables. These are similar to the jump tables above but act as pointers to blocks of data. The binary contains many of these, For example (file offset $005D64):
OutcomeMsgOffsets:
dc.b $00
dc.b $07
dc.b $0E
dc.b $15
dc.b $21
dc.b $29
dc.b 'MISSES'
dc.b $FF
dc.b 'SHOOTS'
dc.b $FF
dc.b 'CHANTS'
dc.b $FF
dc.b 'CASTS SPELL'
dc.b $FF
dc.b 'DEFENDS'
dc.b $FF
dc.b 'HITS FOR'
dc.b $FF
becomes:
OutcomeMsgOffsets:
dc.b OutcomeMsgs_0-OutcomeMsgs_0
dc.b OutcomeMsgs_1-OutcomeMsgs_0
dc.b OutcomeMsgs_2-OutcomeMsgs_0
dc.b OutcomeMsgs_3-OutcomeMsgs_0
dc.b OutcomeMsgs_4-OutcomeMsgs_0
dc.b OutcomeMsgs_5-OutcomeMsgs_0
OutcomeMsgs_0:
dc.b 'MISSES'
dc.b $FF
OutcomeMsgs_1:
dc.b 'SHOOTS'
dc.b $FF
OutcomeMsgs_2:
dc.b 'CHANTS'
dc.b $FF
OutcomeMsgs_3:
dc.b 'CASTS SPELL'
dc.b $FF
OutcomeMsgs_4:
dc.b 'DEFENDS'
dc.b $FF
OutcomeMsgs_5:
dc.b 'HITS FOR'
dc.b $FF
after the offsets have been fully resolved.
It should be becoming obvious why all these three cases have to be fully resolved. If the code or data changes size when you add mods, any original, unresolved, references will be pointing to the wrong addresses. At best a tiresome bug would result, or far more likely for code changes, a nice fat red Guru!
I'm manually resolving these (in the same order as they appear above). BUT how can I be sure I've got them all?
Short Absolutes are a bugger to find as they can appear in just about any instruction format. So pattern searching for them is very tricky.
Word-sized Jump Tables are not too hard to find as they always result in something like:
jsr (a0)Word-sized and Byte-sized data offset tables can be very difficult to spot. And it looks like the code sometimes uses calculated offsets into an offset table itself that come from yet another table. I may be wrong as I'm trying to get all the obvious ones nailed down and haven't spent time chasing down what the code's actually doing.
I think I've got all the Short Absolutes nailed. But needs checking.
I think I've got all the code Jump Tables nailed. More confident than the above but pretty sure.
I'm about halfway through the data Offset Tables. I'm not at all sure I will have got all of them!
So you guys will have to spend some time looking through the detail to check after I'm finished. You'll need to do it in Resource so that the symbols referring to labels change automatically as you turn my "adrXXxxxxxx" labels into something meaningful. To do that you need to understand Resource's "Dynamic String Indirection". It's explained on page 4 of that PDF I published from the help files. It works like this:
Dynamic String IndirectionUsing the Short Absolute example in (1.) above, we need a symbol that will replace:
move.b d0,$05C9with
move.b d0,adrEA0005C9.wIf we just add a symbol as the text
adrEA0005C9.w it will work but will not change if we later change the label to which it points to something more meaningful. To do that, we can use Resource's Dynamic String Indirection. This locks on to the file offset where the label is and expands it to look like the label itself. The syntax for the above label looks like this:
\e0$0225\e.w \e0 tells Resource the target is a label.
$0225 is the file offset.
\e ends the Dynamic String Indirection format.
.w is plain text that Resource will just tack to the end.
Note that the offset is the target absolute address, $0005C9, minus $03A4 to adjust for the origin (GameStart) being at address $000400. I use a macro to do all that for me.
If you've ever used these instructions to resolve a jump table or a data offsets table:
*/Convert specific EA''s/Set base #1 ( [ctrl]+[alt]+[shift]+[1] )
*/Convert specific EA''s/Set base #2 ( [ctrl]+[alt]+[shift]+[2] )
*/Convert specific EA''s/Set base #3 ( [ctrl]+[alt]+[shift]+[3] )
*/Convert specific EA''s/Cvert W/base 1 ( [ctrl]+[1] )
*/Convert specific EA''s/Cvert W/base 2 ( [ctrl]+[2] )
*/Convert specific EA''s/Cvert W/base 3 ( [ctrl]+[2] )
Resource does all the work for you. It creates the correct symbol automatically. To see what's underlying these conversions, use:
LABELS/Edit single/Symbol - destAnyway, enough waffle. To show where I'm up to, I've attached the latest work-in-progress of the BW Resource file. The finished versions of that and the revised BW_EXT file will be available shortly (bearing in mind how time consuming some of these searches can be
).
Author
Topic: Bloodwych Amiga Disassembly (Read 53336 times)