Hamtaro126 wrote:
Can you add this fix:
May need more adjustments for your hack
While I appreciate the suggestion, I must point out that I've already corrected this issue around September of last year:
HereIt's obvious that the game designers intended the crown to be used after attaining 9 lives rather than setting it up that way. Crown9 lives, or simply 19 was the implied max until I officially corrected it. A game like SMB1/SMB2J would never even need more lives than that to complete the game let alone in the 100. While I appreciate the gesture I must kindly decline from this. But if you think of anymore ideas be sure to share them.

@Everyone
There was a slight oversight in my code yesterday as I overlooked the fact that one of the byte locations I changed yesterday was not always-loaded. I had to fix that and it required 5 additional bytes...bytes I didn't have. So what I'm going to do is share the fix, as well as a new method I found for optimizing code on SMBTLL/SMB1. First, my fixed code:
Code:
SetBGColor: lda BackgroundColors,y ;to background color instead
sta VRAM_Buffer1+3,x
lda #$3f ;set for sprite palette address
sta VRAM_Buffer1,x ;save to buffer
lda #$10
sta VRAM_Buffer1+1,x
lda #$04 ;write length byte to buffer
sta VRAM_Buffer1+2,x
lda #$00 ;now the null terminator
sta VRAM_Buffer1+7,x
txa ;move the buffer pointer ahead 7 bytes
clc ;in case we want to write anything else later
adc #$07
SetVRAMOffset:
sta VRAM_Buffer1_Offset ;store as new vram buffer offset
lda SecondaryHardMode ;;;;;;;;;;SHANEM CODE
bne label5 ;;;;;;;;;;SHANEM CODE
lda areapointer ;;;;;;;;;;SHANEM CODE
cmp #$b9 ;;;;;;;;;;;;SHANEM CODE
beq label3 ;;;;;;;;;;;;SHANEM CODE
bmi newlabel ;;;;;;;;;;SHANEM CODE
lda #$06 ;;;;;;;;;;SHANEM CODE
bne label ;;;;;;;;;;SHANEM CODE
newlabel: lda #$22 ;;;;;;;;;;SHANEM CODE
label:
sta $6be2 ;;;;;;;;;;SHANEM CODE
lda #$00 ;;;;;;;;;;;;SHANEM CODE
beq label4 ;;;;;;;;;;;;SHANEM CODE
label3:
lda #$04 ;;;;;;;;;;;;SHANEM CODE
label4:
sta $d032 ;;;;;;;;;;;;;SHANEM CODE
label5: rts
I'll share what I changed as well as how I attained the 5 bytes. I changed the "CMP #$C1, BEQ newlabel" to simply "bmi newlabel". This saved me 2 bytes and has the same function. I then moved the "cmp #$21, beq label3" before the bmi and changed it to "cmp #$B9, beq label3". I know that this would set flag N, too, but I specifically needed to do this. The "lda SecondaryHardMode, bne label5" is what fixed the always-loaded issue. Since this routine is always-loaded, it affects ROM when Worlds greater than 4 are loaded. Secondary Hard Mode is only set after World 4-4, so this fixes that issue and simply RTSs if on a later World thereby solving the issue. I did a BNE because if it's over World 4-4, then the flag is set to 1.
Now, how I optimized code to attain the other three bytes (and this method can be used to save me many more bytes if I need them in the future; you have to be extremely careful when doing this and really trace the routines to make sure it's safe):
Code:
;codes in the ares of what I was working with
SetupIntermediate:
lda BackgroundColorCtrl ;save current background color control
pha ;and player status to stack
lda PlayerStatus
pha
lda #$00 ;set background color to black
sta PlayerStatus ;and player status to not fiery
lda #$02 ;this is the ONLY time background color control
sta BackgroundColorCtrl ;is set to less than 4
jsr GetPlayerColors
pla ;set up colors for intermediate lives display
sta PlayerStatus
pla ;return bg color control and player status
sta BackgroundColorCtrl
jmp IncSubtask ;x bne ;then move onto the next task
GetAreaPalette:
ldy AreaType ;select appropriate palette to load
ldx AreaPalette,y ;based on area type
SetVRAMAddr_A: stx VRAM_Buffer_AddrCtrl ;store offset into buffer control
NextSubtask: jmp IncSubtask ;move onto next task
See the two "jmp IncSubtask" right after each routine? For the one in "SetupIntermediate:" Change that to BNE NextSubtask to the "jmp IncSubTask" in the following routine "GetAreaPalette:". See that? saved me another byte. I was able to do this for 3 bytes in the area, including the SetVRAMAddr_A above (something JMP'd to it earlier locally within Memory). It works because we see that "BackgroundColorCtrl" will always be greater than 0 (says so in the note, too that #$02 is as low as it gets), so this will always be an unconditional branch. In the 6502, whatever was last pushed onto the stack will be pulled first, hence this will be pulled afterwards. Branching is similar to a JMP except it's local (meaning that it can jump anywhere within Memory locally if the right condition is met...it can jump up to $7F signed or unsigned in Memory from its location). In cases like this, you can do that but you have to be careful that it will
always be unconditional if you are replacing a JMP. --ShaneM, the Master of ASM
EDIT: I wish I had STZ to work with. (Also be sure to take advantage of LSR and ASL when you can as axe code calls for #$01 in A followed by an #$02, many many cases where these two can work.)