Jump to content

vidak's Blog

Sign in to follow this  
  • entries
    18
  • comments
    21
  • views
    6,864

Disassembly of Commando #2

vidak

394 views

After a day working on Commando, it's proving very confusing.

 

The disassembler has obviously scrambled all the variable names, labels and routine titles.

 

Maybe tomorrow I will start posting snippets of code on the forums and ask for help.

 

I know what some of the most important variables are, I just can't seem to work out what any of them are doing.



3 Comments


Recommended Comments

The disassembler has scrambled nothing...such labels and variable names simply do not exist within a binary (they don't have to...it's an assembled program). So you need to "reverse engineer" the program by making up your own variable names and comments. This is a VERY lengthy process...taking months of work (or longer!) for even a veteran programmer to decode everything. Start with things you DO know, comment those, replace the generic labels and Ram addresses with something descriptive. For example, Ram address $C5 tracks the number of grenades your player has on hand (BCD format)...so you can add:

 

grenadesBCD = $C5

 

to the top of the disassembly, then replace all instances of $C5 in the disassembly with the word grenadesBCD instead. Stella can be of great help here, because you can alter Ram values in the debugger as a game runs to help figure out what the different addresses do. Take it slow and do not edit your disassembly with a lot of guesses (keep the guesswork confined to the debugger). After you've got a bunch of them nailed, the program will begin to be more understandable as you read through the various routines that handle your decyphered (and now more-descriptive) addresses. Have you made a starting disassembly? I did one a while back to fix the number of scanlines @262...but that is all I did with it.

Share this comment


Link to comment

Thanks a lot! I'm really glad I made this blog post - it got someone to give me help!

 

I never thought of using the Stella Debugger! I haven't been making guesses, I've just been going through the kernel and trying to guess what each of the variables are for based on what the program is doing. I've found a variable which counts from 0-37, i've found the horizontal positioning routine for the Player1 graphics.

 

I've been trying to track down where each of the variables that set the graphics in the kernel come from. There seems to be an elaborate set of code that does this:

    lda    ram_97,X              ; 4	- Make A = ram_97,X again	<- Here is ram_97 again
    and    #$07                  ; 2	- Mask off #00000111 again
    sta    ram_D7                ; 3	- Then store in ram_D7 (then next variable on from D6)
    asl                          ; 2	- Arithmetic shift left in A(multiply by 2)
    adc    ram_D7                ; 3	- Then add another ram_D7 in A (multiply by 3)
    adc    #$02                  ; 2	- Then add #2
    tay                          ; 2	- Transfer A to Y

then this subroutine:

    lda    ram_97,X              ; 4	- Make A = ram_97,X

    lsr                          ; 2	- Divide by 2
    lsr                          ; 2	- Divide by 4
    lsr                          ; 2	- Divide by 8
    lsr                          ; 2	- Divide by 16
    lsr                          ; 2	- Divide by 32
    eor    #$FF                  ; 2	- Flip all the bits
    clc                          ; 2	- Clear carry
    adc    #$20                  ; 2	- Add 32 to A
    rts                          ; 6

    sec                          ; 2	- Set Carry
    sbc    #$17                  ; 2	- Subtract 23+1
    sta    ram_D7                ; 3	- Store in ram_D7
    lda    (ram_DB),Y            ; 5	- A = (ram_DB),Y - where Y was the result of (3*A)+2		<-here is ram_DB again
    sec                          ; 2	- Set Carry
    sbc    ram_D7                ; 3	- Subtract (ram_D7)+1
    sta    ram_A1,X              ; 4	- Store in ram_A1,X
    iny                          ; 2	- INC Y

Then in the kernel, ram_A1,X is transferred into ram_DD, which is then used to set GRP1.

Very confusing... I am trying to figure out what this is doing...

Share this comment


Link to comment

The overuse of AND's and LSR's can only mean that the bits in $97,x are being shared among different variables. Bits 0-2 are doing one thing at the top, bits 5-7 are doing something different in the subroutine. Look to be subset pointers for animation frames, I think.

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...