SMB1 + SMB2J SRAM Plus (FDS hack)

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

hdofu
Posts: 1
Joined: Sun Apr 09, 2017 2:12 am

Re: SMB1 + SMB2J SRAM Plus (FDS hack)

Post by hdofu »

Thanks alphamule, I to was also interested in trying this as it looks like a fantastic effort on shanem's part but he seems to have went MIA and his mediafire account seems to have been banned.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: SMB1 + SMB2J SRAM Plus (FDS hack)

Post by rainwarrior »

hdofu wrote:Thanks alphamule, I to was also interested in trying this as it looks like a fantastic effort on shanem's part but he seems to have went MIA and his mediafire account seems to have been banned.
I think he's frequently on IRC (EFNet #nesdev), though I don't recall the last time he said anything there.
alphamule
Posts: 62
Joined: Fri Aug 29, 2014 1:45 pm

Re: SMB1 + SMB2J SRAM Plus (FDS hack)

Post by alphamule »

rainwarrior wrote:
hdofu wrote:Thanks alphamule, I to was also interested in trying this as it looks like a fantastic effort on shanem's part but he seems to have went MIA and his mediafire account seems to have been banned.
I think he's frequently on IRC (EFNet #nesdev), though I don't recall the last time he said anything there.
If you see both ShaneM and alphamule in there, we're probably both talking assuming I'm not asleep or AFK. He doesn't tend to stay logged in unless talking in PMs. :)
Idealogical
From: I have an idea. It seems logical. Thus everyone must agree.

Fail, fail, fail again. Keep trying, then maybe this damn thing will work. Eventually you might even know why it worked.
Vantastic
Posts: 2
Joined: Fri Dec 22, 2017 8:18 am

Re: SMB1 + SMB2J SRAM Plus (FDS hack)

Post by Vantastic »

Hey, um... Does anyone know what happened? This seems like a very cool romhack, yet I find no links, not new posts, and the links I do find are broken. Does anyone know what happened or at least has a copy of the romhack to post on here? Thanks.
Vantastic
Posts: 2
Joined: Fri Dec 22, 2017 8:18 am

Re: SMB1 + SMB2J SRAM Plus (FDS hack)

Post by Vantastic »

Vantastic wrote:Hey, um... Does anyone know what happened? This seems like a very cool romhack, yet I find no links, not new posts, and the links I do find are broken. Does anyone know what happened or at least has a copy of the romhack to post on here? Thanks.
*no
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: SMB1 + SMB2J SRAM Plus (FDS hack)

Post by tepples »

I'm seeing no reason for this apparently dead project to remain sticky.
Charizard700
Posts: 19
Joined: Thu Nov 26, 2020 1:15 am

Re: SMB1 + SMB2J SRAM Plus (FDS hack)

Post by Charizard700 »

ShaneM's project was very interesting.
But he disappeared.
I created my own cart port for All Night Nippon Super Mario Bros. (ANNSMB).

All Night Nippon Super Mario Bros. (ANNSMB) MMC3 Port. and disassembly
viewtopic.php?f=2&t=21299
SMB2J-2Q
Posts: 152
Joined: Thu Jul 27, 2017 5:13 pm

Re: SMB1 + SMB2J SRAM Plus (FDS hack)

Post by SMB2J-2Q »

Charizard700 wrote: Tue Dec 29, 2020 11:41 am ShaneM's project was very interesting.
But he disappeared.
I created my own cart port for All Night Nippon Super Mario Bros. (ANNSMB).

All Night Nippon Super Mario Bros. (ANNSMB) MMC3 Port. and disassembly
https://forums.nesdev.com/viewtopic.php?f=2&t=21299
I agree with you and that I too wish to know if anyone else as of late has the latest version of this hack, that way, I'd know for sure what he did exactly to fix all the outstanding bugs in this game, besides what code he did provide us with when he was active.

~Ben
SMB2J-2Q
Posts: 152
Joined: Thu Jul 27, 2017 5:13 pm

Re: SMB1 + SMB2J SRAM Plus (FDS hack)

Post by SMB2J-2Q »

ShaneM wrote: Sun Jan 18, 2015 3:36 pm Okay, I'm puzzled. Thoughts?

I'm a little confused about this EU's change, though I understand what the code is doing. Below is the code and I was hoping to get your all's weigh in on what you think. After it, I give my info on what the code does (I give the routine "ChkForPlayerInjury" that branches right before it as well):

Code: Select all

ChkForPlayerInjury:
          lda Player_Y_Speed     ;check player's vertical speed
          bmi ChkInj             ;perform procedure below if player moving upwards
          bne EnemyStomped       ;or not at all, and branch elsewhere if moving downwards
ChkInj:
.ifdef Japan
          lda Enemy_ID,x         ;branch if enemy object < $07
          cmp #Bloober           ;(Goomba, Buzzy Beetle, Green/Red Koopa and Hammer Bro will branch)
          bcc ChkETmrs           ;to check stomp/invincible timers and enemy facing direction
          lda Player_Y_Position  ;otherwise load player's vertical position
          clc                    
          adc #$0c               ;and add 12 pixels to player's vertical position
.else
          lda #FlyCheepCheepFrenzy   ;#$14 gets loaded into A
          ldy Enemy_ID,x         ;branch if enemy object is not FlyCheepCheepFrenzy
          cpy #$14                         
          bne +                  ;branch to Player_Y_Position
          lda #Bloober	         ;load #$07 into A
+         adc Player_Y_Position  ;RAM $ce, add carry player's vertical position to A
.endif          
          cmp Enemy_Y_Position,x ;compare modified player's position to enemy's position
          bcc EnemyStomped       ;branch if player's position above (less than) enemy's
ChkETmrs: lda StompTimer      ;check stomp timer
          bne EnemyStomped       ;branch if set
My thoughts: I think this code is only branched to if the player is vertically moving upward or standing still; moving downward vertically causes the BNE to branch in "ChkForPlayerInjury". "Player_Y_Speed" (RAM $9F) will be a signed value if the player is going up and unsigned if going down (so MSB or d7 WILL be set if this branch occurs). Now, if the player is indeed going up, we branch to "ChkInj", the routine in question. What the NTSC seems to do is branch to check various timers if dealing with enemies such as Goombas etc. or anything less than Blooper (#$07) as I labeled above. If the enemy in A plus X offset is #$07 or greater it will thus not branch because the Carry is set. Next, we load A with what's loaded at RAM $CE, or Player_Y_Position. (The player's Y is stored as #$B0 when on the ground at the lowest playable part of the level, decrementing from that value as the player is vertically inclined/stomps on an enemy.) $CF plus X offset is where the Enemy_Y_Position is stored and is #$08 greater than the player's when on flat ground. So, for example, a Goomba (RAM $16,x will load an #$06 in Memory) on flat ground will have a #$B8 loaded into RAM $CF plus X whereas the protagonist will have #$B0 in that occurrence stored at RAM $CE.

So anyway, if the enemy object in Memory plus X is #$07 or greater, Carry will be set so we will clear Carry and add #$0C to A (which is loading the player's current Y position). So A will thus have whatever that value is plus #$0c added to it for the upcoming comparison with RAM $CF plus X register (in layman's terms, the enemy which is loaded for the comparison since 6 enemies can be loaded at once). At the end of the .endif conditional statement above, we now move onto comparing the current value in A with the enemy offset. If the player's Y is at all above (being less than) the enemy's, we thus branch to the enemy being stomped "EnemyStomped" (and the timer flag at RAM $0791 will be set to branch; from there it checks for certain enemies such Spinys or other 'untouchable' enemies and branches accordingly to injure player or else award player certain pts.). If Carry is set, then we move on to check various timers and branch accordingly to injure player/turn enemies around etc. For enemies that are not Lakitu, Cheeps or the likes, we skip all of this. That makes sense, logically.

What the EU does: It appears to use the Y register for the check, but loads A with #$14 by default. Y register is loaded with the value stored at RAM $1E plus X register. The next thing we do is compare register Y with #$14 (or Cheep-Cheep frenzy enemy) and any other enemy which is NOT Cheep-Cheep frenzy will thus branch and we clear the Z flag. If it is the Cheep-Cheep, d6 will be set and thus skip the branch. If it is Cheep, then we now load A with #$07 rather than the previously loaded #$14. (So A will either be loaded with #$14 or #$07 depending on the current enemy plus X register and whether we previously branched or not we will end up with at the "adc Player_Y_Position") Next, we are at "adc Player_Y_Position", instead of A being loaded with this value we ADC with it instead, but Carry will be cleared here so we need not CLC. Neither will Carry be set with what's at RAM $CE. From there we move onto the linear code with the CMP,X. If the player's Y is at all above (being less than) the enemy's, we thus branch to the enemy being stomped "EnemyStomped" (and the timer flag at RAM $0791 will be set to branch; from there it checks for certain enemies such Spinys or other 'untouchable' enemies and branches accordingly to injure player or else award player certain pts.).

So my question is, what's the point of changing this in the EU? Obviously all enemies are now checked instead of those that are #$07 or greater. And we add either load A with #$07 or #$14 rather than the ADC #$0C like NTSC does. It singles out flying Cheep-Cheep and gives them #$07, but why? What kind of fix is this?

EDIT: Oh, forgot to mention, I had to comment on everything on the code myself since doppleganger didn't really go into detail. I will submit a better commented version to RHDN when I'm done. Really want to hear thoughts on this code, though, as I'm perplexed. --ShaneM, the Master of ASM
I have checked out the variations of this code for both Super Mario Bros. 2 (Japan) and Super Mario All-Stars, and both are different than for the two he looked into.

Here's the first part of the code as was represented in the original FDS Lost Levels:

Code: Select all

ldy Player_Y_Speed    ;check player's vertical speed
dey                   ;branch elsewhere if player not moving downwards
bpl EnemyStomped
What this interpretation does is check the player's vertical speed, and decrements from the current value if the player moves downward. If not, it branches forward to EnemyStomped if the positive flag is set. I wonder if maybe the DEY should be placed after the BPL here, because we want it to branch only if player not moving downwards?

And the same for SMAS:

Code: Select all

lda Player_Y_Speed
bmi ChkInj
beq ChkInj
jmp EnemyStomped
Here, we have two consecutive branch-tos to ChkInj (one if the minus flag is set and the other if result equal), and the last a jump-to to EnemyStomped. This also means there are earlier checks under HandlePECollisions that contain jump-tos to InjurePlayer if Mario collides either with a Piranha Plant or a Podoboo, in order to make the second ChkInj branch-to work.

I wonder if anybody knows exactly what these variations do.

Thank you,



Ben
Post Reply