Distella Issue

[Just Jeff]

Good Morning,

 

I used Distella to disassemble Chopper Command but the bin didn't run when recompiled with DASM.  I found missing assembler instructions such as ORGs SEGs and the Processor spec.  It runs now with issues.  I'll continue fixing it up but I'm curious- Did I use Stella wrong?  Is there a switch I should have added?  I used -a only.  I made notes of my changes in the attached asm- just search for semicolons to see them.  The second attachment is my current .bin.  The third attachment is the original .bin if someone wants to disassemble to compare results.

 

Thanks!

CPRCMD.asm CPRCMD.asm.bin Choprcmd.bin

[Nukey Shay]

I use -pafsc

 

The -p switch includes the processor type in the disassembly.

 

-a suppresses the argument "A" when disassembling an opcode which acts on the accumulator directly (such as LSR).

 

-f forces correct size of instructions (.w .wx or .wy are appended to an opcode when its 16-bit argument begins with $00, without it Dasm will shorten these to zero page and throw the assembly off by 1 byte for each occurrence!)

 

-s displays the cycle time for every opcode...useful when counting cycles in time-critical areas such as the display (which often take up a great deal of the program code anyway)

 

-c allows you to include a configuration file to aid Distella from separating code/data/gfx.  This is pretty much required in bankswitched programs (where Distella's code detection will fail), or programs which use opcodes such as BIT or triple-NOP to skip over instructions.

 

These days, I'm really getting into using Stella's own debugger to create disassemblies.  Take any program, play through all of the differing circumstances, and Stella will configure a file all on its own.  Write a disassembly with the savedis command in the debugger window.

[Nukey Shay]

BTW about your question of what LFDEA is...take a look at what exists at that address:

LFDE9: LDA    #$FE

Distella could not label it, because the address is the argument of $FDE9's instruction.  Why is the program doing this?  Check the routine which uses it:

       LDX    #$0B    
       STA    HMCLR   
LF8E8: LDA    LFF1D,X 
       EOR    $F5     
       STA    WSYNC   
       STA    HMOVE   
       AND    $F4     
       STA    COLUBK  
       LDA    LFE8D,X 
       STA    GRP1    
       LDA    LFDEA,X 
       STA    GRP0    
       LDA    LFF17,X 
       EOR    $F5     
       AND    $F4     
       STA    $C9,X   
       DEX            
       CPX    #$06    
       BCS    LF8E8   

Notice that this routine counts X from $B to $7.  In other words, X is always at least 7.  All the labels which are using X as the offset here are actually OFF by 7.  What the routine is really up to is this:

       LDX    #$0B    
       STA    HMCLR   
LF8E8: LDA    $FF24-7,X 
       EOR    $F5     
       STA    WSYNC   
       STA    HMOVE   
       AND    $F4     
       STA    COLUBK  
       LDA    $FE94-7,X 
       STA    GRP1    
       LDA    $FDF1-7,X 
       STA    GRP0    
       LDA    $FF1E-7,X 
       EOR    $F5     
       AND    $F4     
       STA    $D0-7,X   
       DEX            
       CPX    #$06    
       BCS    LF8E8   

The program code continues to use X after this point...

       LDY    #$01    
       LDA    #$70    
       STA    HMP1    
       LDA    #$80    
       STA    HMP0    
LF917: LDA    $CF,X   
       STA    WSYNC   
       STA    HMOVE   
       STA    COLUBK  
       LDA    LFE8D,X 
       STA    GRP0    
       LDA    $00AF,Y 
       STA    PF0     
       LDA    $00B2,Y 
       STA    PF1     
       LDA    $00B5,Y 
       STA    PF2     
       LDA    $00B8,Y 
       STA    PF0     
       LDA    $00BB,Y 
       STA    PF1     
       LDA    $00BE,Y 
       STA    PF2     
       CPX    #$03    
       BNE    LF949   
       STX    $D5     
       DEY            
LF949: DEX            
       BPL    LF917   

...but since this loop is counting down from 6 to 0, the labels are correctly identified.  You'd need to add .wy to those 6 LDA's so Dasm will use 16-bit addressing, tho (otherwise, the cycle time is incorrect and the display portion ends up fudged).

[+stephena]

On 6/29/2019 at 8:21 AM, Nukey Shay said:

These days, I'm really getting into using Stella's own debugger to create disassemblies.  Take any program, play through all of the differing circumstances, and Stella will configure a file all on its own.  Write a disassembly with the savedis command in the debugger window.

I agree.  Thomas J. has done some amazing improvements on the Distella code in Stella, and it really shows.  You get all the advantages of standalone Distella, along with augmented info from runtime (which is impossible in standalone mode).  In the 4K case at least, I no longer see a need for standalone Distella.

 

Now, one area that obviously needs work in multi-bank support.  Distella doesn't handle it either, but at least you can break the ROM into 4K pieces and play around with it.  In Stella, it just says "multi-bank ROM not supported", and stops there.  For the next major release after the upcoming one, I hope to find time to work on this.  In fact, it should be relatively straightforward for Stella to do this, since internally it knows all about the scheme, how it maps to ROM, etc (it needs to, for emulation to work).  So generating a multi-bank disassembly should be relatively easy, at least for the common bankswitch types.

 

This is something I've wanted to revisit for years, but never find the time.  Hopefully I can get back to it soon ...

[Just Jeff]

Oh yeah it's way better that DiStella.  I was able to get a good DiStella disassembly with the additional switches, but once I disassembled with Stella, I dropped it entirely.  The Stella disassembly is nice!

[Nukey Shay]

Posting instructions to disassemble programs larger than 4k using Stella (since this question came up again):

 

Aquaventure being used as an example...

 

First, run the program with the debugger enabled.  Try to get as many differing circumstances to execute as possible.  If you know the ram locations for level select, etc...go ahead and use them (to get differing screens to be defined, for example).  Launch the debugger when you feel that Stella has a complete configuration of how the program is constructed (using the tilde key).

 

Select each bank, and copy the configuration Stella worked out into a .cfg text file...listing entries for start and end addresses for the various code, data, gfx, and pgfx sections.  You can make the .cfg Dasm-compatable if you wish (as I usually do, listing everything sequentially), but it's not required.  The finished .cfg would look something like this:

aquavent.cfg

 

Using a file split program of your choice, split the original binary file into separate portions based on the programs bankswitching method.  Aquaventure uses the F8 scheme, so the file splitter was set to 4k portions in this case:

Aquaven1.bin

Aquaven2.bin

 

For completeness sake, I also compared the original to the CCE release.  Only the logo gfx differs between binaries in the first bank, so that is all I needed:

AquaCCE1.bin

 

With each binary portion, launch them in Stella and hit the tilde key immediately to enter the debugger before the file executes (to avoid crashing or other weirdness).  Now you can enter all of the .cfg information that you copied originally into Stella's interface.  Currently, there's no paste function...so You gotta do them line-by-line.  Sequential order does not matter, tho (probably easier to keep track of, however).  When all the data has been entered, save a disassembly using the SAVEDIS command.  You'll need to do each portion separately.

NOTE: CCE's version only differed from B601 to B623, so that was the only portion I configured there

Aquaven1.asm

Aquaven2.asm

AquaCCE1.asm

 

Finally, use a text editor to merge all the disassemblies into 1 file.  You'll need to alter Start labels for each portion (as well as changing ALL Lxxxx labels to a different letter if 2 or more portions are using the same origin address).  Paste them back-to-back, editing the ORG lines to include RORG (the 2600 cannot use even-numbered 4k blocks for ROM).  ORG addresses will run sequentially, while RORG specifies the actual base addresses used in the disassemblies.  Equates, Ram assignments, and User-defined labels can be pasted directly into their own sections (if only Start tags are listed in the latter, those can usually be ignored).

Aquaventure.asm

 

Then all that is left to do is clean up the completed disassembly.  You can remove all the asterisks and non-essential whitespace characters, sort out the equates and Ram assignments, etc.  You'll notice above that I added a switch at the top of the disassembly to invoke the CCE version, with an IF-ELSE-ENDIF condition in the data for the addresses which differ between binaries.

[+stephena]

Most of the procedure here is what we want to get Stella to do automatically (that's what computers are for, right?)   The process definitely works, but it's obviously a manual process and very laborious.  Hopefully we can get Stella to do some (all?) of it automatically.