SMB1 + SMB2J SRAM Plus (FDS hack)
Moderator: Moderators
Re: SMB1 + SMB2J SRAM Plus (FDS hack)
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.
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: SMB1 + SMB2J SRAM Plus (FDS hack)
I think he's frequently on IRC (EFNet #nesdev), though I don't recall the last time he said anything there.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.
Re: SMB1 + SMB2J SRAM Plus (FDS hack)
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.rainwarrior wrote:I think he's frequently on IRC (EFNet #nesdev), though I don't recall the last time he said anything there.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.
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.
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.
Re: SMB1 + SMB2J SRAM Plus (FDS hack)
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.
Re: SMB1 + SMB2J SRAM Plus (FDS hack)
*noVantastic 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.
Re: SMB1 + SMB2J SRAM Plus (FDS hack)
I'm seeing no reason for this apparently dead project to remain sticky.
-
- Posts: 19
- Joined: Thu Nov 26, 2020 1:15 am
Re: SMB1 + SMB2J SRAM Plus (FDS hack)
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
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
Re: SMB1 + SMB2J SRAM Plus (FDS hack)
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.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
~Ben
Re: SMB1 + SMB2J SRAM Plus (FDS hack)
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.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):
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.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
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
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
And the same for SMAS:
Code: Select all
lda Player_Y_Speed
bmi ChkInj
beq ChkInj
jmp EnemyStomped
I wonder if anybody knows exactly what these variations do.
Thank you,
Ben