SMB1 + SMB2J SRAM Plus (FDS hack)

[8bitMicroGuy]

The checksum utility doesn't support CRC16 anymore! What now?

[ShaneM]

The checksum utility doesn't support CRC16 anymore! What now?

Would you like an older build of it from my library which contains CRC16? I can upload it if you'd like. It seems that the newer builds remove it in place of CRC64, as well as other features. --ShaneM, the Master of ASM

EDIT: If you prefer not to use an earlier build, I recommend using my hex editor of choice, Hex Editor Neo. It has a powerful disassembler/assembler as well as checksum algorithms. It's not free, but the Ultimate edition (the one I use) has a checksum utility.

Checksum Calculation

Hex Editor Neo supports more than 20 checksum calculation algorithms, including MD5, SHA-1, CRC-16, CRC-32 and others. Custom CRC algorithm is also provided. You can compute the checksum for the whole file or for the current (multiple) selection. Several checksums may be computed at the same time in parallel. Results are easily exportable and copyable to the Clipboard.

It can also be used to edit video files that are 4GB etc. Something I've used it for in the past. The Ultimate edition can also be paid for with lifetime upgrades for only $120 USD.

[8bitMicroGuy]

Nevermind, it worked for me. But for some reason, I don't see the color changes of the levels like on the pictures. I came on both games to 2-1 and still no flying leaves or whatever it is or pallette changes other than of the original SMB. Except for Mario's new pallette and lava in underground.

[ShaneM]

Nevermind, it worked for me. But for some reason, I don't see the color changes of the levels like on the pictures. I came on both games to 2-1 and still no flying leaves or whatever it is or pallette changes other than of the original SMB. Except for Mario's new pallette and lava in underground.

Did you patch it to the right SMB2J headerless ROM of CRC16 BA55? The wind first appears on 5-3 of SMB1 and 5-1 of SMB2J. The stage with the palette change is 8-2, if I understand you correctly. If I misunderstood what you mean, can you please clarify? Thank you for responding and taking the time to try my game. --ShaneM, the Master of ASM

EDIT: Do you mean that you'd like the wind to have the red texture of SMAS?

[ShaneM]

EDIT: Do you mean that you'd like the wind to have the red texture of SMAS?

I was inspired to try it....What do you all think? I ripped the leaves straight from the SNES SMAS version and recolored it accordingly. Thoughts? --ShaneM, the Master of ASM

[ShaneM]

I had the leaves upside down before. Turns out that the SMAS does this for some odd reason. I'm not sure if the routine in that version uses more frames or not. But here it is NESized to it's fullest potential. I'm also attaching an SMAS shot to be compared. This build will be v1.2 and released along with the game manual and custom Nestopia build, soon. --Shanem, the Master of ASM


EDIT: Here's one of 5-1, in case A-3 is hard to see.

[ShaneM]

I'm doing one more post for now comparing the pics of the original with the SMAS revamp. I'm doing this rather than editing my last post because I can only have 3 pictures per post and it wouldn't let me do more (I don't feel like signing into Photobucket and logging on using FB and all that now, since this would be quicker). Also, I know that my blue is lighter because I assigned snowy stages a lighter blue and white on the ground to represent snow.

Sorry for posting a few minutes after the last one. --ShaneM, the Master of ASM

[ShaneM]

I've done something pretty cool. I was able to attribute both water and lava underground. It took me many hours to optimize some code to make room and I created a hardcoded routine to do this. Now, there's both! The way I see it is, the developers first wanted water underground, but then during the SNES era they decided to change it to lava. But they wanted to keep the water at the beginning but weren't able to keep both due to limitations by the coders, so they just left it blank at the beginning. I've fixed this for the first time.

Below are pics of my fix (to be released in the next build). --ShaneM, the Master of ASM

[tepples]

It looks like polluted water to me, but that's equally useful.

[Drew Sebastino]

Looks like blood to me. Lava produces its own light, so even if it were in a dark place, it would still be bright.

[ShaneM]

It looks like polluted water to me, but that's equally useful.

Looks like blood to me. Lava produces its own light, so even if it were in a dark place, it would still be bright.

I'm not sure if these are complements or not; point is, I used the Accumulator to load the palettes so that can easily be changed. Though I used the original underground water palette ($22) as well as the lava palette used in castles ($06). So I'm not sure what to say. The lava has been the same color as all previous builds. --ShaneM, the Master of ASM

[ShaneM]

I'm uploading images of both the original FDS and SNES versions so that people can compare them. --ShaneM, the Master of ASM

[ShaneM]

Here's my code for creating both lava and water underground. I figured there are some hackers here who would appreciate this but may be lacking in ASM knowledge. Since I did all the work for you, if you want to use it, simply credit me. The 16 bit addresses would need to be changed depending on where they are found in your PRG. --ShaneM, the Master of ASM

Code: Select all

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 $0750      ;;;;;SHANEM CODE
              cmp #$c1        ;;;;;SHANEM CODE
              beq newlabel    ;;;;;SHANEM CODE
              cmp #$21      ;;;;;;;SHANEM CODE
              beq label3         ;;;;;;;SHANEM CODE
              lda #$22             ;;;;;SHANEM CODE
              bne label           ;;;;;SHANEM CODE
newlabel: lda #$06          ;;;;;SHANEM CODE
label:       sta $6be2        ;;;;;SHANEM CODE you'll need to change this address
              lda #$00           ;;;;;;;SHANEM CODE
              beq label4         ;;;;;;;;;;;;;SHANEM CODE
label3:
              lda #$04          ;;;;;;;;;;;;;;;;SHANEM CODE
label4: 
             sta $84e2         ;;;;;;;;;;;;;;;SHANEM CODE you'll need to change this address
            rts

[Hamtaro126]

Can you add this fix:

May need more adjustments for your hack

Code: Select all

WriteGameText:
               pha                      ;save text number to stack
               asl
               tay                      ;multiply by 2 and use as offset
               cpy #$04                 ;if set to do top status bar or world/lives display,
               bcc LdGameText           ;branch to use current offset as-is
               cpy #$08                 ;if set to do time-up or game over,
               bcc Chk2Players          ;branch to check players
               ldy #$08                 ;otherwise warp zone, therefore set offset
Chk2Players:   lda NumberOfPlayers      ;check for number of players
               bne LdGameText           ;if there are two, use current offset to also print name
               iny                      ;otherwise increment offset by one to not print name
LdGameText:    ldx GameTextOffsets,y    ;get offset to message we want to print
               ldy #$00
GameTextLoop:  lda GameText,x           ;load message data
               cmp #$ff                 ;check for terminator
               beq EndGameText          ;branch to end text if found
               sta VRAM_Buffer1,y       ;otherwise write data to buffer
               inx                      ;and increment increment
               iny
               bne GameTextLoop         ;do this for 256 bytes if no terminator found
EndGameText:   lda #$00                 ;put null terminator at end
               sta VRAM_Buffer1,y
               pla                      ;pull original text number from stack
               tax
               cmp #$04                 ;are we printing warp zone?
               bcs PrintWarpZoneNumbers
               dex                      ;are we printing the world/lives display?
               bne CheckPlayerName      ;if not, branch to check player's name
               ;H126 Fix (Credit: Southbird) - Jump to Lives Fix
               jsr PutLives             ;otherwise, check number of lives
               ldy WorldNumber          ;write world and level numbers (incremented for display)
               iny                      ;to the buffer in the spaces surrounding the dash
               sty VRAM_Buffer1+19
               ldy LevelNumber
               iny
               sty VRAM_Buffer1+21      ;we're done here
               rts

;H126 Fix (Extra Credit: Southbird) - Lives Fix
;Original thanks to Southbird, Based off the SMB3 disassembly!

PutLives:
	ldy #$00	  ; init Y to 0
	lda NumberofLives ; lives counter
	cmp #$ff	 	
	bne ChkLivesCap   ; branch to check lives cap

	; if lives counter is not -1 (255), then:
	lda #$24	  ; blank tile
	jmp StoreLo	  ; branch

ChkLivesCap:
	cmp #100
	bmi Under100	  ; If Player's lives are under 100, jump

	lda #99
	sta NumberofLives ; else, cap at 99 lives

Under100:
	; now loop while A is more than 10!
	cmp #10
	bmi StoreLo
	sec
	sbc #10		 ; A -= 10
	iny		 ; Y++
	jmp Under100	 ; loop!

StoreLo:
	sta VRAM_Buffer1+8	; store into low byte
	tya		 	; most significant digit is now transferred to A
	bne StoreHi		; if it's anything but zero, jump
	lda #$24	 	; else use blank tile
StoreHi:
	sta VRAM_Buffer1+7	; store into high byte
	rts		        ; return

Also requires removal of the Golden Crown attributes, because it should be unused!

[ShaneM]

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: Here

It'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: Select all

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: Select all

;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.)