Nukey Shay Posted August 15, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted August 16, 2019 Author Share Posted 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..... Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted August 17, 2019 Author Share Posted 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 Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted August 17, 2019 Author Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 17, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 17, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 17, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted August 17, 2019 Author Share Posted 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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 17, 2019 Share Posted August 17, 2019 (edited) $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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 17, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted August 19, 2019 Author Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 19, 2019 Share Posted 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). Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted August 19, 2019 Author Share Posted August 19, 2019 Version 20 update. Fixed some routines based on the suggestion above. Fixed the smart bomb use. v20.bin Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted March 11 Author Share Posted 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. 1 Quote Link to comment Share on other sites More sharing options...
rallyrabbit Posted March 11 Author Share Posted March 11 Found the culprit bad BNE call. Updated it. DefenderCity+ v21.bin 1 1 Quote Link to comment Share on other sites More sharing options...
Living Room Arcade Posted March 24 Share Posted March 24 Holy crap! I just saw this! This hack is AWESOME!!! I loved the ol' Defender when I was a kid, but this is AMAZING!! @rallyrabbit Thanks!!! Quote Link to comment Share on other sites More sharing options...
+Karl G Posted March 24 Share Posted March 24 Is there a TL;DR description of what changes to the original game are in this hack? 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.