Need help debugging asm

[tacrec]

Still learning this whole thing. I disassembled Super Pro Football, fixed the symbols jacked by disasm, assembled it again, no errors but will not play in any emulator. I've tried editing on two different text editors. Can someone please take a look? Thanks.

iflnew.asm

[+nanochess]

I would suggest doing a binary comparison of the result files, where there are differences check the LST file to cross-reference the address with your source code.

[intvnut]

Run the original and the reassembly through "tohex", and then run "diff" on the two hex dumps to see which bits differ.

Edited October 21, 2014 by intvnut

[Nebulon]

Run the original and the reassembly through "tohex", and then run "diff" on the two hex dumps to see which bits differ.

 

First off, I love the "Hammer Time" UNIX avatar GIF for your profile.

 

And second.... Just wanted to send respect out to all assembly language programmers out there. Thanks for keeping real computing alive (and for doing what I just can't seem to get the grasp of).

[tacrec]

The hex comparison is different because of the symbols table at the start of the disasm version.

 

How do I do a binary comparison?

[intvnut]

The hex comparison is different because of the symbols table at the start of the disasm version.

 

How do I do a binary comparison?

 

 

If you run the 'tohex' program that comes with SDK-1600 on the actual .BIN file for each, you will get two hex dumps. You should be able to compare those with any text-compare utility. The tohex utility outputs text that looks like this:

 F0 10 A1 D3 5B 61 B7 2C   42 7F 64 5E FC E5 2E EB  # ....[a.,B.d^.... 00006200
 85 5F 55 C8 26 C1 AC F4   1D 0B 3D 53 8F 14 6A 4E  # ._U.&.....=S..jN 00006210
 F4 87 C5 10 52 08 A2 FC   9F 49 BE 85 EF B9 33 16  # ....R....I....3. 00006220

The stuff to the left is the hex rendering of the data in the file. The number at the far right is the offset within the file.

 

Once you find the differences between the hex dumps, you'll need to work out where in the address map the differences correspond to. It's a little fiddly, but doable.

 

First, find the exact offset of the differing byte. For example, suppose the highlighted byte was the one that changed:

F0 10 A1 D3 5B 61 B7 2C   42 7F 64 5E FC E5 2E EB # ....[a.,B.d^.... 00006200
85 5F 55 C8 26 C1 AC F4   1D 0B 3D 53 8F 14 6A 4E # ._U.&.....=S..jN 00006210
F4 87 C5 10 52 08 A2 FC   9F 49 BE 85 EF B9 33 16 # ....R....I....3. 00006220

That byte's file offset is $6218, as it's on the row that starts at $6210, and it's 8 bytes over from the left.

 

Divide that number by 2. $6218 / 2 = $310C. This is the word offset within the ROM file.

 

Now open up the .CFG for the ROM. You should see lines like this:

; example config.  Be sure to use the one for your game.
[mapping]
$0000 - $1FFF = $5000
$2000 - $2FFF = $D000
$3000 - $3FFF = $F000

The numbers on the left are word ranges from the .BIN file, and the number on the right is the address it maps to.

 

So, in this example, $310C maps to that last range. Offset $310C maps to $F10C in the ROM.

 

Armed with this, you can go in the .lst file generated by AS1600 and figure out what instruction (or data) assembled to $F10C

[+DZ-Jay]

Still learning this whole thing. I disassembled Super Pro Football, fixed the symbols jacked by disasm, assembled it again, no errors but will not play in any emulator. I've tried editing on two different text editors. Can someone please take a look? Thanks.

 

As I remember when I disassembled the Baseball game, the problem is that the disassembler decodes any operation on the stack as a MOV operation. So even ADD operations get mis-translated.

 

-dZ.

[intvnut]

 

As I remember when I disassembled the Baseball game, the problem is that the disassembler decodes any operation on the stack as a MOV operation. So even ADD operations get mis-translated.

 

-dZ.

 

Didn't I post a link to a fixed version of dis1600? I vaguely remember that thread on INTVPROG.