Whilst integrating the debugger into Killer Bees it occurred to me that whenever the call to the debugger or a breakpoint is inserted into the code, everything gets shifted down by five decles to accommodate the required three instruction sequence:
BEGIN ; call into the debugger
CALL RKD_DEBUG ;
PULR R5 ;
Now obviously, once you're done with debugging you remove these sequences and everything contracts back up, right?Well, what happens if you're you don't finish debugging? Or if you finished with a particular breakpoint and don't want to add and remove breakpoints, screwing things around and messing with your recollection of useful addresses? Perhaps you just replace these commands with NOPs. That way the code remains the same, but the breakpoint is no longer active. Hmmm.
Let's take a peek at the disassembly of World Championship Baseball:
JSR R5, X_TIMER_START ; 510B 0004 0118 0044 [..D]
J L_58B6 ; 510E 0004 0358 00B6 [...]
NOP ; 5111 0034 [4]
NOP ; 5112 0034 [4]
NOP ; 5113 0034 [4]
NOP ; 5114 0034 [4]
NOP ; 5115 0034 [4]
PSHR R5 ; 5116 0275 [.]
MVI G_0320, R0 ; 5117 0280 0320 [..]
SWAP R0, 1 ; 5119 0040 [@]
Interesting...
CMPI #$8, R0 ; 5120 0378 0008 [..]
BGE L_5129 ; 5122 020D 0005 [..]
L_5124:
NOP ; 5124 0034 [4]
NOP ; 5125 0034 [4]
NOP ; 5126 0034 [4]
NOP ; 5127 0034 [4]
NOP ; 5128 0034 [4]
L_5129:
MVI .PSG0.rgt_hand, R5 ; 5129 0285 01FE [..]
XORI #$ff, R5 ; 512B 03FD 00FF [..]
Very interesting...
It looks as though we can see where Mike Minkoff has inserted breakpoints in the code. In fact there are 32 of these sequences of 5 NOP instructions! They are located at $5111, $5124, $526c, $52ea, $53a3, $55c8, $56a5, $56b5, $5767, $5914, $594d, $59cd, $59e4, $5a00, $5a27, $5a97, $5ab6, $5ae0, $5b4e, $5b98, $5f99, $5fb6, $5fcf, $5fdf, $633c, $634f, $6474, $6859, $6990, $6d3e, $6ddf and $d000
It seems Mike really went to town trying to debug this sucker.
There are also 6 other 4 instruction NOP patterns at $5d47, $5d4c, $5d5c, $5d61, $5d6e and $5d73. These come in pairs like this:
ADDR R2, R1 ; 5D44 00D1 [.]
ADDI #$200, R1 ; 5D45 02F9 0200 [..]
NOP ; 5D47 0034 [4]
NOP ; 5D48 0034 [4]
NOP ; 5D49 0034 [4]
NOP ; 5D4A 0034 [4]
MVO@ R0, R1 ; 5D4B 0248 [.]
NOP ; 5D4C 0034 [4]
NOP ; 5D4D 0034 [4]
NOP ; 5D4E 0034 [4]
NOP ; 5D4F 0034 [4]
PULR R1 ; 5D50 02B1 [.]
CMPI #$1, R3 ; 5D51 037B 0001 [..]
I'm not sure what is happening here. These sequences are used to draw the playfield, including the baseball diamond at the start of the game. The MVO@ instruction at the centre of the NOP writes a character to the screen. Therefore, it seems unlikely these NOP chains are part of any debugging effort. I wondered if this represented a port and tweaking of code from David Rolfe's original Baseball. However, looking at that code, the drawing of the playfield seems to be handled very differently. Perhaps the NOPs represent a change in the way that the playfield data was encoded subsequently written to the screen that was not optimised.
In the mean time, back to reverse engineering the main debugger source...
Comments
Post a Comment