Defender II Hack Attempt - Trying to find 2 portions of code

Nukey Shay · August 15, 2019

HMOVE in the city kernel wasn't corrected...it was still @ cycle 1. Fixed here.

BTW you need to correct the smart bomb routine. As it is, the program does not check for the button being held across frames (so you can drain all your bombs in 1 press if you aren't quick). A dirty fix would be to skip 3 of 4, or 7 of 8 frames to provide a delay. A better fix is to set a flag when the button is pressed to check on the next frame if it was already pressed.

v19fix.bin

rallyrabbit · August 16, 2019

23 hours ago, Nukey Shay said:

HMOVE in the city kernel wasn't corrected...it was still @ cycle 1. Fixed here.

BTW you need to correct the smart bomb routine. As it is, the program does not check for the button being held across frames (so you can drain all your bombs in 1 press if you aren't quick). A dirty fix would be to skip 3 of 4, or 7 of 8 frames to provide a delay. A better fix is to set a flag when the button is pressed to check on the next frame if it was already pressed.

v19fix.bin 8 kB · 2 downloads

I'm going to be honest, disassembling this, I do not understand the line in your routine that is:

BEQ LFFE9

where LFFE9 is

LFFE9 = $FFE9

But FFE9 looks like its in between instructions.....

rallyrabbit · August 17, 2019

On 8/15/2019 at 7:38 PM, Nukey Shay said:

HMOVE in the city kernel wasn't corrected...it was still @ cycle 1. Fixed here.

BTW you need to correct the smart bomb routine. As it is, the program does not check for the button being held across frames (so you can drain all your bombs in 1 press if you aren't quick). A dirty fix would be to skip 3 of 4, or 7 of 8 frames to provide a delay. A better fix is to set a flag when the button is pressed to check on the next frame if it was already pressed.

v19fix.bin 8 kB · 3 downloads

I get what you're saying. Essentially in your routine you have edited lines LF402 to LF407 for kicking off the City Kernel. And it loads the current city position into index X before jumping into the kernel. And the city kernel is updated. I can say, every time I add in this code, the people on the group start having trails. So, either there's another piece I'm missing or this doesn't work in my source. I'm going to jump over to the smart bomb problem in the meantime.

v19_hmove fix attempt.bin

rallyrabbit · August 17, 2019

For the smart bomb fix, I think I can use a pseudo fire button debounce from the value setup in 0xAC. When the bomb goes off, it sets up a countdown in this value. As long as this is non-zero, I should be able to use it to block another bomb from firing.

Nukey Shay · August 17, 2019

2 hours ago, rallyrabbit said:

I'm going to be honest, disassembling this, I do not understand the line in your routine that is:

BEQ LFFE9

where LFFE9 is

LFFE9 = $FFE9

But FFE9 looks like its in between instructions.....

It is. That portion is deciding whether to bump the city gfx pointer (done when the scanline counter is a multiple of 4). If so, it branches to the INX instruction. If not, the program proceeds to the next byte...which is the opcode for the CMP $zp instruction. INX becomes the argument there, so it reads CMP $E8, wasting 3 cycles. This ensures that the same number of cycles are used whether or not the branch was taken.

I originally used SKIP.B (which uses the BIT $zp opcode), but ran into some weird issue when the pointer was originally using DEX in a previous build. Looks like it can be safely changed back.


    tya                             ;2 35 scanline count
    beq     LFFED                   ;2³37 exit if at zero
    and     #$03                    ;2 39 divisible by 4?
    beq     LFFE9                   ;2³41 branch if so
    .byte   $C5 ;cmp                ;3 44 skip next byte (3 cycles)
LFFE9
    inx                             ;2 44 adjust city pointer
    dey                             ;2 46 dec scanline count
    bne     LFFB7                   ;2³48 continue if not zero
LFFED
    jmp     LF14D                   ;3 51 exit city

Nukey Shay · August 17, 2019

1 hour ago, rallyrabbit said:

I get what you're saying. Essentially in your routine you have edited lines LF402 to LF407 for kicking off the City Kernel. And it loads the current city position into index X before jumping into the kernel. And the city kernel is updated. I can say, every time I add in this code, the people on the group start having trails. So, either there's another piece I'm missing or this doesn't work in my source.

v19_hmove fix attempt.bin 8 kB · 1 download

You put it back at cycle 1 again ? This has the effect of shifting the humanoids on the surface by 3 pixels (noticeable when moving, the humanoids kind of wobble into place when slowing down). Watch the humanoid close to the ship when you press reset for an example.

But I cannot see the trails you mention in Stella when using the newer city kernel (which removes the flicker from the player ship). That problem should only crop up if the city kernel was not 76 cycles total (or if HMCLR is somehow being skipped). PM the source if you need help tracking the bug down.

Nukey Shay · August 17, 2019

47 minutes ago, rallyrabbit said:

For the smart bomb fix, I think I can use a pseudo fire button debounce from the value setup in 0xAC. When the bomb goes off, it sets up a countdown in this value. As long as this is non-zero, I should be able to use it to block another bomb from firing.

The original game was using cartridge Ram (read+$4D/write+$4D), value $0F as a timer that inviso or bombs are being used.

This is checked to be zero before either are allowed to be freshly activated:


       LDA    read+$4D                ;4
       BNE    LD5D2                   ;2
       LDA    smart_bombs             ;3
       BEQ    LD591                   ;2
 

...

 

LD591:
       LDA    inviso_units            ;3
       BNE    LD5B3                   ;2
       BEQ    LD5BD                   ;2 always branch

When neither are, the value 0 is placed there by the controller check:


       LDA    SWCHA                   ;4
       EOR    #$FF                    ;2
       AND    #$03                    ;2 check up/down on stick 2
       BNE    LD5A6                   ;2
       STA    write+$4D               ;4
       BEQ    LD5D2                   ;2 always branch

rallyrabbit · August 17, 2019

13 hours ago, Nukey Shay said:

You put it back at cycle 1 again ? This has the effect of shifting the humanoids on the surface by 3 pixels (noticeable when moving, the humanoids kind of wobble into place when slowing down). Watch the humanoid close to the ship when you press reset for an example.

But I cannot see the trails you mention in Stella when using the newer city kernel (which removes the flicker from the player ship). That problem should only crop up if the city kernel was not 76 cycles total (or if HMCLR is somehow being skipped). PM the source if you need help tracking the bug down.

I've got nothing to hide in the source. This is kind of a group effort at this point. Here's the code. I am working on the smartbomb routine now, so bombs may not be 100% in this.

bank0.asm bank1.asm

Nukey Shay · August 17, 2019

$FFDF...you didn't force STA PF2 to use absolute addressing (STA.w PF2) to consume the remaining unused cycle in the revised city kernel. This is where the skew originates.

There are some other issues in here as well.

LF457: 
       CPY    _ramA1                        ;3
       BCS    LF407                         ;2 ****Go back to LF407 until the whole play
                                            ;      area is complete......
       LDA    (_ram9D_objectGfxVector),Y    ;5
       STA    GRP0                          ;3
       BNE    LF407                         ;2

The last line is incorrect...it should be branching to LF40A (to the argument of the BIT opcode). Speaking of which, this:


LF404: 
       LDA    #$FF                          ;2 Color of Enemy shots
;       .byte $2C                            ;4 ao why is this line needed?
LF407:
       BIT    $9FB1   ;4

...is just confusing. What the program is really supposed to be doing is this:

LF407:
       LDA    #$FF                          ;2 Color of Enemy -shots-
       .byte $2C                            ;4 skip next 2 bytes
LF40A:
       LDA    ($9F),Y                       ;5 load color of -enemy-

...or rather

LF407:
       LDA    #$FF                          ;2 Color of Enemy -shots-
       .byte $2C                            ;4 skip next 2 bytes
LF40A:
       LDA    (_ram9F_objectColorVector),Y  ;5 load color of -enemy-

Notice what is happening there? Not only is it more readable, but it would also avoid a glitch in the program if you changed the address of

_ram9F_objectColorVector some time in the future. (aside from getting back the missing tag LF40A to begin with). There is no LF404 in the program either, that tag was unnecessary.

I need some time to weed through this...suffice it to say that when you see a BIT instruction in a program, double-check if it's argument is concealing an instruction itself. BIT is often used to skip bytes.

Edited August 17, 2019 by Nukey Shay

Nukey Shay · August 17, 2019

Move the LF3FB jump instruction on top of the LF3EE tag. This keeps it's branch to LF461 on the same page as the destination.

Humanoids in the city will be pushed to the right a couple of pixels otherwise (occasionally wobbling back into position to the left).


LF3FB:
       JMP    LF53B                         ;3 exit display

 

LF3EE: 
       LDA    #$30                          ;2
       STA    HMM1                          ;3
       LDA    #$D0                          ;2
       STA    HMBL                          ;3

;new page starts here in current assembly

       BNE    LF461                         ;3 always branch

rallyrabbit · August 19, 2019

On 8/17/2019 at 3:49 PM, Nukey Shay said:
$FFDF...you didn't force STA PF2 to use absolute addressing (STA.w PF2) to consume the remaining unused cycle in the revised city kernel. This is where the skew originates.

There are some other issues in here as well.
LF457: 
       CPY    _ramA1                        ;3
       BCS    LF407                         ;2 ****Go back to LF407 until the whole play
                                            ;      area is complete......
       LDA    (_ram9D_objectGfxVector),Y    ;5
       STA    GRP0                          ;3
       BNE    LF407                         ;2
The last line is incorrect...it should be branching to LF40A (to the argument of the BIT opcode). Speaking of which, this:
LF404: 
       LDA    #$FF                          ;2 Color of Enemy shots
;       .byte $2C                            ;4 ao why is this line needed?
LF407:
       BIT    $9FB1   ;4
...is just confusing. What the program is really supposed to be doing is this:
LF407:
       LDA    #$FF                          ;2 Color of Enemy -shots-
       .byte $2C                            ;4 skip next 2 bytes
LF40A:
       LDA    ($9F),Y                       ;5 load color of -enemy-
...or rather
LF407:
       LDA    #$FF                          ;2 Color of Enemy -shots-
       .byte $2C                            ;4 skip next 2 bytes
LF40A:
       LDA    (_ram9F_objectColorVector),Y  ;5 load color of -enemy-
Notice what is happening there? Not only is it more readable, but it would also avoid a glitch in the program if you changed the address of

_ram9F_objectColorVector some time in the future. (aside from getting back the missing tag LF40A to begin with). There is no LF404 in the program either, that tag was unnecessary.

I need some time to weed through this...suffice it to say that when you see a BIT instruction in a program, double-check if it's argument is concealing an instruction itself. BIT is often used to skip bytes.

My apologies. So you basically, you attached the bin files with a fix. So, I used distella to extract and diff against my code to see where you made the changes. Those were the lines that distella output for sections that you changed. My label names have no all been cleaned up for sure. As I have added a removed lots of code, I haven't rampantly changed the labels to match up with the actual addresses yet. I was going to clean this up when I finally stopped coding. I think I get what is going on here vs what distella output, and only the absolute store to PF2 I think I confused something else you recommended earlier as well. So I maintained my loss of cycle here.

Yes, the trails of objects are gone in the city, but I am still seeing the humans migrate around their locations corresponding to a building.

On a side note, I did fix the smart bombs as well.

Nukey Shay · August 19, 2019

Count yer cycles...the HMOVE instructions should always begin at zero, or you are going to see sprites shifting positions. Stuff like this is easy to spot, Just let Stella's debugger draw a screen by hitting the (Scan +1) button repeatedly while keeping an eye on the Scn Cycle value in the top center. It should always remain zero during the gameplay area (scanlines 81 to 222). If you get any other value, you know the problem spot. More often than not, it's a branch that went over a page break (this often crops up when adding/deleting program lines).

rallyrabbit · August 19, 2019

Version 20 update.

Fixed some routines based on the suggestion above.

Fixed the smart bomb use.

v20.bin

rallyrabbit · March 11

Nothing like playing your own game and finding a bug 5 years later.

Needless to say, going to work this and and release a new version.

It appears that if you are on screen when an abduction happens that you will explode no matter what happens. No good. I'll have to get a fix out for that. Not sure if anyone cares, but, its a matter of pride at this point.