It's a hack of SMB2J that brings all the level designs and other various data over from SMB1. I hear all this hype from many other forums of people wanting to add SMB2J stuff to SMB1, such as Wind, Upside-Down Piranha Plants, more Worlds, etc. So I did something about it. I thought to myself: If the point of the hack is to make SMB1 like SMB2J, why not just hack SMB2J?
So that's what this is. SMB1 with all the features of SMB2J. The levels are the same, I've just incorporated SMB2J stuff in various places to add and show off its features. I've done all the work on this myself so that people can now rip their SMB1 levels and paste them to this without having to worry about the ASM work (assuming they don't know it). There are no Worlds A-D in this hack as I NOP'd the code that does a check to see how many stars are on the title screen. But it can easily be added back if anybody wanted to make an extended hack of this. World 9 is still intact. I'm planning to add levels from SMB Special to make up a World 9. The way warp data was called to see which warp would be next was hard-coded, so I did a quick ASM fix to it. It's pretty sloppy but gets the job done.
This work took about 3 days. I already got all 8 Worlds working properly. I just need to finish up 9 and do one final test. The release date is scheduled to be in about a week.
Since this is a hack of my SMB2J SRAM patch, all the beta scenery is used, as well as all the other glitch fixes I made. See you soon.
I've left the title screen logo wide to allow all 24 stars to be recorded (note that I just temporarily changed 0xCC3C here to $18 to show all 24 stars. It's been reverted to $00 for final release.)
Poison Mushrooms, green springs etc. can all be found in this game.
Like I've said, beta scenery and cactus have been used from SMB2J
Saving still occurs upon beating 8-4; high score is also saved to SRAM upon receiving a Game Over and choosing "Quit"
Wind and flying Bloopers have been added to some stages.
Certain levels like 1-3 and 5-3 no longer share data, so you are free to create new levels or scenery. On 5-3 I made it a windy snowy level.
(Since World 5 is already a snow World.)
Upside-down Piranhas have been added to various areas in appropriate places to give it an authentic "Nintendo" feel.
In fact, I've made this so easy that all you'd have to do to create SMB1 hacks with SRAM and SMB2J features is merely rip your levels after editing with SMB utility and paste them. All loop data, demo data, etc have already been taken care of. (I took care of assembling the files and leaving over 400 free bytes for you to use, too. I've also gathered unused bytes that can be used so you never run out! Since SMB2J levels took so much more space.)
Is this still FDS, or is it cart? If someone can make a cart patch for the SMB2J disassembly, this just might be the key to making the 21-world monster that I've been requesting on IRC.
tepples wrote:
Is this still FDS, or is it cart? If someone can make a cart patch for the SMB2J disassembly, this just might be the key to making the 21-world monster that I've been requesting on IRC.
This is FDS. I know that Shiru(?) made an MMC3 port of SMB2J. He released source code. That means that all my changes could supposedly be ported to his version. The problem is, it might not be that easy as I took a look at his source code and it is really different. It almost seems like a new game (in my opinion).
As far as emulation goes, this is virtually identical to the NES'
Super Mario Bros. but with SRAM saving, tons of glitch fixes and SMB2J features. (I know the hacking community will appreciate this and will never have to "bump their feet in the dark" again.)
But as far as this goes, there are four banks in SMB2J (banks $00-$03). In bank $00, which is always-loaded, I have roughly 250 free bytes for level data; on bank $01 (Worlds 5-8), I have 29 rows of 16 $FF bytes, so...29*16+4= 468 free bytes. On bank $02 (World 9 and victory scene bank) I don't know yet as I'm going to start 9 World tomorrow. On bank $03, I have roughly 2000 (two thousand)free bytes for level data. My suggestion would be to use bank $03 when I release this and create an additional 9 Worlds using this bank (you'll need to hack certain checks in bank $00 to add more Worlds). That brings you to 18 worlds. There's a check that will not let any World go pass 9 (which is why A-D are counted as Worlds 1-3 and 8, respectively), but that would be super easy to work around if you know what you're doing.
@Everyone
When this is finished, I plan on adding SRAM to All Night Nippon SMB (ANNSMB). That was a promotional version of SMB2J given out by the Japanese Nippon radio station. ANNSMB did exactly what I do here: Make an SMB1 hack using SMB2J. The coding is almost identical so I'm just going to optimize code to make room and add it to that. I'll fix all the glitches in that version, too. Just a heads up. This SMB1 here will be ready in about a week. So hackers start making 12+ Worlds for your SMB1 hacks (SMB utility lets you choose how many Worlds you want for your hack and just port it to this. So... you can make a backup of your SMB1 NES ROM and create 8 Worlds, then use the other copy and create 4, 5, 6, 7, 8 etc.))
Oh. Before I forget. I'm going to add the code I NOP'd to minus Worlds A-D. I'm sharing this now because I'm starting a new job soon and may forget to share this when I give the patch. This re-adds these Worlds if your hack calls for more than 9 Worlds, simply enter this code I got rid of by means of hex editing:
(I purposefully assembled with 17 NOPs here just in case someone has a hack with many Worlds. Add the code back where you see lines with 5 ";".)
Code:
GameMenuRoutine:
lda SavedJoypadBits ;check to see if the player pressed start
and #Start_Button
beq ChkSelect ;if not, branch to check other buttons
lda #$00
sta CompletedWorlds
sta DiskIOTask
sta HardWorldFlag
;;;;; lda GamesBeatenCount ;check to see if player has beaten
;;;;; cmp #$08 ;the game at least 8 times
;;;;; bcc StG ;if not, start the game as usual at world 1
;;;;; lda SavedJoypadBits
;;;;; and #A_Button ;check if the player pressed A + start
;;;;; beq StG ;if not, start the game as usual at world 1
;;;;; inc HardWorldFlag ;otherwise start playing the letter worlds
StG: jmp StartGame
It's here! 100% glitch free and fully stable, with all the glitch fixes and beta features I made on SMB2J SRAM Plus. As an added bonus, I've included SMB2J SRAM Plus on Side B of this game disk! (See the emulation guide within the Nestopia folder for more info on switching Disk Sides within emulation.)
I know I talked about doing SMB Special levels for 9 World, but I did something even better. What I did was recreate the Minus World from both SMB versions (NES and FDS) to make a World! The NES Minus World has 1 level, while the FDS version has 3. So 3+1=4 or 1 World. This is better because the SMB2J 9 World is based off of this Fantasy glitch from the original game. So doing this is only fitting. Well, minus the glitches that came with the original Minus World. I even gave the NES version a total makeover of its Minus World! (
https://www.youtube.com/watch?v=Dh-3PuJjFN4)
9-1 = NES version of Minus World
9-2 = FDS version of -2
9-3 = FDS version of -3
9-4 = FDS version of -1
(IPS patch of SMB1 with SRAM found at the bottom of this post.)
What's a purple beta cactus, clouds and trees doing under there?
A flying Blooper! I thought this was only found on 7-3! I wonder where else I might find these guys?
Lava underground, just like SMB2J!
A MUCH more difficult version of 7-3 (which is a harder version of 2-3).
An underwater sea current.
New invisible items have been added where there were only invisible coin blocks. Arigatou, ShaneM-chan!
Beautiful clouds from up above have replaced the Mushrooms from SMB1 to give it a more real SMB2J feel.
Wait a minute...That's a decoy!
Remember, my SMB2J is on Side B of this game!
I will add some hack notes for newbies. I made this game easy to hack. I finished it early because I was excited for this, myself. Heh. But anyways, here's SMB1 with all the glory of SMB2J. And I mean ALL.
Shoot. Sorry; I forgot to mention to patch it to an SMB2J ROM that's 65,000 bytes. Heh.
I fixed a glitch caused by the fact that Upside-Down Piranhas on 6-1 were too high and Spinys were getting stuck in between the pipes. Apparently, there are two object identifiers for Upside-Down Piranha pipes in SMB2J, one taller pipe, and one shorter pipe (see the photo below of my special private edition of SMB Utility with SMB1 MMC3 with SMB2J objects; this is the tool I used to create SMB2J object data within SMB1 levels and dumped the data to my disassembly). What I did was just use the shorter pipes. I didn't even know that they existed since no valid SMB2J level even uses them. Anyway, glitch fixed and I'm 100% confident to say that everything is fully stable.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = ADC8
Enjoy.
Look at the previously-used taller pipe how it collides with Lakitu. The shorter ones are now used.
I was thinking of one last thing I could do to make this game even better. I found something. Let me say first that this is NOT a glitch fix, but a new feature, sort of. The original SMB1 is NROM. It only had 8000 bytes of ROM space, so 2-3 and 7-3 shared level/enemy data. The thing is, World 2 was a grassy world while 7 was a snowy one. So what I did was make 7-3 a day snow level. Also, since World 9-2 is based on a harder version of World -2 (FDS Minus World, which is a version of 7-3), I made it a night snow level. So now 2-3, 7-3 and 9-2 are all different! (I already did this with 5-3, which shared 1-3's data on the original NROM version.) Enjoy!
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 658B
This is not a glitch fix. Let me explain: When I was recreating all the SMB1 rooms in SMB2J, in the Worlds 5-8 data I was running out of room pointers, so I assigned an unused underground room as a castle one for the bonus cloud heaven of 6-2. Nothing is really noticeable from the usual apart from the grey being off color. So, I assigned it the unused room of $3A (unused in the original SMB2J, too) to fix this (cloud bonuses are really ground rooms). So this is now fixed.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
I've discovered another original SMB2J glitch. This fix pertains to Side B of this game or SMB2J. This has to do with castle looping on 3-4. Here is a video of this original glitch:
https://www.youtube.com/watch?v=hv8Lhu4T9dY (Please note that I didn't make that video.) This glitch has to do with another lazy oversight by Nintendo and is not fixed in any of their remakes, either (not even SMB Deluxe, which actually introduces yet another glitch to 3-4).
When a castle would loop, they would do so on pages without enemies (not including Piranha Plants because those always appear with the pipe object) on both SMB1 and SMB2J. But they looped to the skip page 5 on 3-4 which introduced a Podoboo where it was never(?) intended to be. Loop data is set up to loop on only page skip pages and the data pointer goes by the skip page's header. So it is virtually impossible to fix this without changing the original level layout because there are only 2 page skips on this level and looping works hand-in-hand with this.
Enemies are buffered to VRAM as OAM; I have only 3 free bytes in the always-loaded bank where this fix would need to take place to clear enemies upon looping page that were skipped. So I fixed this glitch in a way Nintendo would: On the pages where the loop would repeat if the wrong path were taken, I've added a lava pit right under and a Podoboo that's ALWAYS loaded so this glitch is now non-extant. This is what Nintendo would do so it's what I did. (It really is a workaround to the issue at hand.) Level layout and everything is intact. I've also updated the game's manual to include SMB1. One last note: On 9-4 on Side B of SMB2J, it is not a glitch when the underwater current continues until the end of the level. This was done on purpose since it is not considered wind but rather a sea current, so terminators were not necessary (though I had room to add it if I wanted to). On SMB1 on Side A I made the sea current terminate on 9-4, though. So keep that in mind.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = E472
Patch it to a clean ROM with the CRC16 listed above.
Either path that you take, it's now consistent.
Okay. Well, because I'm so OCD, I had to figure a way to make this game even better. So I did. What I did was fix up the original stages that repeat to match the VS SMB counterparts. These include repeats of 5-3 (but I left the snow and wind in), 5-4, 6-4 and 3-4 (I did the last one because it is the same level, but more challenging). Here are maps of the VS SMB stages if anybody needs them for the repeat stages I fixed:
http://themushroomkingdom.net/maps/vssmbAlso, in case no one realized this, I've made the maze of 4-4 to be like ANNSMB, as well as the lava pits of 7-4. The stages of 4-1 and 4-2 have also the Koopas added to them from the ANNSMB version. Here are maps in case you get stuck on 4-4:
http://themushroomkingdom.net/maps/annsmbSo really, this SMB1 with SRAM and SMB2J features is the best because it incorporates the greatest strengths of VS SMB, ANNSMB and the original SMB1.
SMB2J on Side B of the disk has been left intact from the last glitch fix made yesterday. Enjoy. This is my final build unless something comes up.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = F667
Patch it to a clean ROM with the CRC16 listed above.
EDIT: I didn't borrow any SMB2J stages for SMB1, what I did was use the VS SMB counterparts of the SMB1 stages. They are in different Worlds on VS SMB.
I felt bad that the player was not really rewarded when beating the game 8 times since there is no Worlds A-D on Disk Side A (SMB1) of this. So I fixed that. I added some ASM code to create Hard Mode (
https://www.youtube.com/watch?v=4RBZGYEjcxM) when beating the game 8 times. Similar to the original SMB1 and my Side B A-D of SMB2J. The flag at RAM 07FB is unused in this. Instead I did a workaround to code this. Here are parts of my code as I lost my .asm file due to a sloppy desktop and did this in a hex editor (heh
)
Code:
lda SecondaryHardMode
bne $03
jmp initsechardmode
rts
initsechardmode:
lda gamesbeatencount
cmp #$08
bcc $03
inc SecondaryHardMode
rts
lda:
lda gamesbeatencount
cmp #$08
bcc $03
lda #$01
rts
lda $00
rts
ldy:
ldy gamesbeatencount
cpy #$08
bcc $03
ldy #$01
rts
ldy $00
rts
Basically, all the places that checked whether $07FB was set were replaced with JSRs to these codes. I don't really remember all what else I did since I did this in a hex editor. The above notes were scrambled and made in a Word document. Basically, the above code replicates Hard Mode from SMB1. So, problem solved. Also, I fixed a glitch with Lakitu and primed up 8-3 a little. Side B SMB2J is left intact from 09/03/14's maze fix.
There should be zero issues with my fix, but you are free to report if you find anything. (Zero crashes, zero bugs when I just tested it.)
So now, when you beat the game 8 times, you ARE rewarded!
Hard Mode features:
-Buzzy Beetles replace Goombas
-Buzzy Beetle grouped enemies replace Goomba Grouped Enemies
-All enemies move faster
-Stunned (withdrawn) enemies recover faster
-small platforms replace big ones
-Hammer Bros. throw hammers faster
-Bullet Bills initiate faster
-Cheep-Cheeps fly faster
-Bloopers move faster
Note that I didn't create a World select option on the title screen (though I could; I'd need 18 free bytes always-loaded. I could simply write over A-D coding).
EDIT: Here it is. Fully tested and guaranteed. I also added a beta timer to 9-2. Enjoy.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 1100
Okay. In case anyone is confused, you'd need to beat the game 8 times to access this new Hard Mode. Pressing A+Start on the title screen does nothing. To delete this Hard Mode at any time, delete your save file. If any hackers out there want to use my work as a base and add 18+ Worlds, you need to either PM me or request an earlier build as I wrote over World's A-D code in the main bank ($00), and adding Worlds with the code I NOP'd earlier will NOT work on this build (as I wrote over code). The game will crash if you try to add back A-D on this latest build. So request of me the earlier build if needed to make a hack with more Worlds than 9.
That does not change the stability of this build. It is 100% crash and glitch free. --ShaneM
I fixed another Nintendo original glitch. This one I wasn't aware of as it was a hard glitch to initiate:
https://www.youtube.com/watch?v=sZBSuwzMyEsThe fix was easy; it was made to both my SMB1 (Side A) and SMB2J (Side B):
Code:
;In the files sm2data2 and sm2data4, in the routine "NoUDP:"
lda VerticalPipeData,y ;original did this...lazy, stupid Nintendo
lda VerticalPipeData+4,y ;this is my fix...yeah, pretty simple
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 0AD4
Okay. So I decided there was a little more that I could do on this. I've borrowed the Blooper collision detection glitch fix from the European NES version and adapted the code to both SMB1 and SMB2J on this (
http://forums.nesdev.com/viewtopic.php?p=103894#p103894).
Code:
;In "ChkNearPlayer:", I changed
adc #$10 ;original code
;to
adc #$0C ;fixed code
Other changes:
*Fixed a glitch where Bullet Bills were being loaded at a max of 2 Bills at once rather than 3 for Hard Mode. I set a flag with the Y register to do a check, which fixes this issue.
Hard Mode should now match the original SMB1's version entirely.*Added 2 more Goombas to the beginning of 2-1
*Fixed a quirk with enemy data on 8-1.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 8D39
I ran out of room to fix a Nintendo original glitch that I found. This is BS how limited FDS PRG is... Here is the fix to correct if the player went down a pipe and a hammer was thrown at the player at the same time they'd take damage and "fall" through the side of the pipe.
http://www.mariowiki.com/List_of_Super_Mario_Bros.:_The_Lost_Levels_glitches#Hammer_through_the_Pipe This fixes it, so I'm giving the fix to anyone who wants to add it to their hack. I'm a little pissed that I ran out of room. If I find something that I can optimize I will add this in:
Code:
;In the routine "HandlePipeEntry:", add this code right after the "sta GameEngineSubroutine"
lda #$01 ;what we want to do is set the Injury Timer flag
sta InjuryTimer ;to avoid collision with enemies or hammers when
jsr InjurePlayer ;going down pipes
;so flag Z will now be cleared and we will branch off to "ExInjColRoutines"
;and then RTS
This fix takes up exactly 8 bytes...sigh.
I did it!
I also optimized the code to correct the hammer glitch listed above. Turns out I had the code in the wrong place; use this code to add it to your hacks. Also, my patch should be 100% stable. ASM truly is the holy grail of hacking. ^^
Code:
;In "VerticalPipeEntry:", add the following line of code to fix the hammer ;collision glitch
sta InjuryTimer ;add this right after the lda #$01 that's there
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = D835
I have just fixed the mother of all original SMB glitches. *Drum rolls*
I have fixed Small Fiery Mario (
https://www.youtube.com/watch?v=KxMUM1FRym4)! This glitch has got to be the hardest one to fix in the history of glitches. Originally, I had no idea what caused the glitch, as I knew there were two flags (one for player size and the other for player form) but I didn't know what was causing the glitch. It was not until I hacked the SNES version of Allstars (yeah, 65c816 is VERY similar and the code is almost verbatim) that I found the glitch actually had to do with the axe code and how it was erased. (Yes, Allstars fixes it.) The thing was, on the SNES version it took 56 bytes to fix it (0.o); space I just didn't have. But since I located the problem I knew what to do and how I could optimize enough code to create my own custom routine to fix this. So, here it is; fixed on BOTH SMB1 and SMB2J. Enjoy. There is absolutely nothing more to fix/correct on these games as I pretty much fixed every known glitch. My versions are now the most sublime versions of SMB1 and SMB2J. More sublime than the SNES, GBC etc. versions. If you find a bug (not impossible) you can report it to me.
I am the first person in NES hacking history of hacking to fix this. If you borrow the fix, credit me. --
ShaneMSMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 846A
So, maybe nobody has asked this yet: Why are almost all the colours in your screenshots dark and murky? Did you hack the palette to make it that way? If you did I must say it's really visually unappealing.
ccovell wrote:
So, maybe nobody has asked this yet: Why are almost all the colours in your screenshots dark and murky? Did you hack the palette to make it that way? If you did I must say it's really visually unappealing.
No. Those came from the .pal file included. The NES palettes for the most part are the same. I chose what palettes to change on the .pal file based on what I like as a preference. What's "unappealing" to one is "beauty" to another.
^_^
I just reviewed the original SMB2J's code after work today and I realized something else that I could do to improve this game so I did.
When Kasumi worked on this game, I paid him to make it stop counting lives after 128. But really, after looking at the original code, I realize that nothing was meant to go above 19 lives. After 9 lives, the game would replace with Crown lives. (The SNES version went with 128 lives because it also saved lives count to SRAM for later. On the NES this was not needed as level saving was not an option. Also, to account for the fact that the Player will be awarded 100,000 pts. for every life left at the end causing an overflow with the score and strange tiles being loaded for lives.)
So I fixed it. I made a small routine to make it stop counting lives at Crown 9, like it was intended to be. That fixes BOTH issues with score overflow as well as strange tiles being loaded. Now, I found a routine that I can potentially optimize to get me another 56 bytes. If I do it, I may also add water sprite animation cycles. But I need to figure out how to go about it. For right now, here is the 'supposed' final version with lives fix. (This fix was made to
both SMB1 and SMB2J.) Here is my code first:
Code:
lda numberoflives
cmp #$12
bcs end
inc numberoflives
end:rts
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = A7AB
I still have 56 free bytes but it is impossible for me to make animated waves with it because I cannot create additional free CHR RAM space with it. But, I optimized more code to create an even better Hard Mode when the player accumulates 8 stars (SMB2J on Side B is unchanged from the lives fix):
*Red Piranha Plants replace Green ones from 1-1
*Aggressive Hammer Bros. replace regular ones
*Hammer Bowser starts at World 1
(In non-Hard Mode = less than 8 stars, Red Piranhas still start at 4-1, Hammer Bowser at World 6 and Aggressive Hammer Bros. at World 7 as usual.)
This is the final version of this game as I cannot do anymore with it as it is as good as it can possibly be.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 56A7
ShaneM wrote:
This is the final version of this game as I cannot do anymore with it as it is as good as it can possibly be.
I stand corrected. There IS one last thing that I can and did fix:
Mario_Wiki wrote:
This works in World 1-1. Mario or Luigi must hit the block with the Star inside, then they must go to the bit with the half pyramid with 10 blocks on each half, without touching the Star. Then they let the Star touch them, and as quickly as possible, the player must run to the flagpole. If done correctly, when the invincibility wears off, the music from the level will play instead of the usual flagpole fanfare.
Here's a video:
https://www.youtube.com/watch?v=DiFJityZiH4The code I created to fix it:
Code:
;In the routine "NoWind"
lda FlagpoleMusicFlag ;is the flag music playing?
bne NoChgMus ;if so, branch to original code
jsr GetAreaMusic ;otherwise reload area music (this line is original code)
If you borrow this code please credit me or I will be pissed. Thanks. (^_^)" (And I know quite a few people and whether or not you know ASM and I will check the code to see if it's mine and call your bluff, too. So save yourself the embarrassment and just credit me if you use it because it took me time and effort to trace the code. [...Credit me for any/all my glitch fixes, too, since I notoriously fixed every known one.])
Since I made SMB1's code "my bitch" (street slang), I've mastered ASM and the game's code. So, I still have like...say.. 49(?) or so more free bytes from the Cheep-Cheep optimization, so if you have any more original glitches that you want me to fix, NOW is the time to link me to it/them.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = D8A4
A fix I created for the SMB2j ending to make the status bar's coin counter graphic gold like it should be:
Code:
PrincessPeachsRoom:
.db $20, $80, $60, $5e ;Nintendo's original data
.db $20, $a0, $60, $5d
.db $23, $40, $60, $5e
.db $23, $60, $60, $5d
.db $23, $80, $60, $5e
.db $23, $a0, $60, $5d
.db $23, $c0, $50, $55
.db $23, $f0, $50, $55
.db $23, $c2, $01, $d5 ;H126-fix: added for coin icon in status bar
.db $00
It works, but needs more testing (works when playing worlds 1-8, dunno about 9 or A-D)!
Hamtaro126 wrote:
A fix I created for the SMB2j ending to make the status bar's coin counter graphic gold like it should be:
Code:
PrincessPeachsRoom:
.db $20, $80, $60, $5e ;Nintendo's original data
.db $20, $a0, $60, $5d
.db $23, $40, $60, $5e
.db $23, $60, $60, $5d
.db $23, $80, $60, $5e
.db $23, $a0, $60, $5d
.db $23, $c0, $50, $55
.db $23, $f0, $50, $55
.db $23, $c2, $01, $d5 ;H126-fix: added for coin icon in status bar
.db $00
It works, but needs more testing (works when playing worlds 1-8, dunno about 9 or A-D)!
I wasn't aware of any such issue. I will take a look at it. Victory mode data is found in bank $02, meaning it's loaded with World 8 & D's ending, as well as the whole World 9. It is NOT loaded anytime else, so please be weary of that. If you want it to always be loaded, add it to bank $00. (If I were you, I'd generate a .lst file to assist you.)
Thanks for giving me something else to work on. Will look into it. For bank $02, I have almost 200 free bytes left, so more than enough to work with if I need to fix that. (I have 49 or so bytes left from the Cheep-Cheep optimization in bank $00.) Thanks. --ShaneM
EDIT: Save me some time; what exactly does your line of data fix?
The Status Bar Coin Icon's Gold coloring turns White due to the ending doing a revamp of the whole nametable while the ending loads, but Nintendo forgot to fix that issue due to a possible rush or such, my line fixes that...
Hamtaro126 wrote:
Code:
PrincessPeachsRoom:
.db $20, $80, $60, $5e ;Nintendo's original data
.db $20, $a0, $60, $5d
.db $23, $40, $60, $5e
.db $23, $60, $60, $5d
.db $23, $80, $60, $5e
.db $23, $a0, $60, $5d
.db $23, $c0, $50, $55
.db $23, $f0, $50, $55
.db $23, $c2, $01, $d5 ;H126-fix: added for coin icon in status bar
.db $00
If there's one thing I abhor it's a liar. That data is already very well there that you "created":
Code:
UnusedAttribData:
.db $23, $c0, $48, $55
.db $23, $c2, $01, $d5 ;hmm, looks familiar
.db $00
Next time, why not try learning some ASM and actually creating something on your own. It would have been fine if you were like: "Hey ShaneM, I found that the 'UnusedAttributeData' fixes the color of the coin. I'm not sure it's broken as data EXISTS for it."
No credit goes to you if I decide to implement this because you were dishonest.
EDIT: BTW, you didn't even do it right. The unused fix needs to be above the $F0 line and the $50 on the line above that needs to be changed to $48.
I did not mean to lie, I was just trying to make a quick fix for that graphical error, and I forgot to compare it to UnusedAttribData too, so it may be the original lost status bar data.
I guess I will keep it to myself then if you are not satisfied with it, I should have not given help to you...
Hamtaro126 wrote:
I did not mean to lie, I was just trying to make a quick fix for that graphical error, and I forgot to compare it to UnusedAttribData too, so it may be the original lost status bar data.
I guess I will keep it to myself then if you are not satisfied with it, I should have not given help to you...
Bottom line: I don't play games with people. You know what you did and are trying to twist it. Just stop. Period.
ShaneM wrote:
Bottom line: I don't play games with people.
So let me guess: You'd be unwilling to help test a 2-player NES game using an emulator that supports netplay.
Quote:
You know what you did and are trying to twist it. Just stop. Period.
This sort of tone would drive off even legitimate contributors.
tepples wrote:
Quote:
You know what you did and are trying to twist it. Just stop. Period.
This sort of tone would drive off even legitimate contributors.
As I said in my previous to last post, I would not have had an issue if he would have just been honest in the first place:
ShaneM wrote:
It would have been fine if you were like: "Hey ShaneM, I found that the 'UnusedAttributeData' fixes the color of the coin. I'm not sure it's broken as data EXISTS for it."
The fact that this was no accident and that he/she tried to play me pissed me off, which is a fine reason to be upset.
I have no problems with honest mistakes and even someone pointing original code to me. I would be fine playing SMB1 through netplay with anyone who is decent and has honest motives.
Anyone is welcome to share anything with me as long as they are honest and don't treat me like I was born yesterday like how Hamtaro126 did.
I'm moderator elsewhere on another forum where he/she is, so I know the type of person I'm dealing with and the type of posts he/she makes. (Though that does not concern this forum.)
This is all behind me. Anyway, I found something new I can do with the free space. Will post it soon.
ShaneM wrote:
[long string of vitriol removed because there's no point in keeping it]
Woah, woah, wait a moment.
Someone's skin is SUPER thin. Take a moment to take a deep breath and stop biting people's heads off.
You're not doing yourself any favors with the way you've been acting here. Surely you've heard the aphorisms about "catching more flies with honey than with vinegar".
If someone says it's an accident, it's almost always better to take them at their word. It's not worth pissing off everyone else who's watching your Internet Drama.
Flies prefer balsamic vinegar but that's beside the point.
If I were accused of plagiarism, and it actually was an accident, what would be sufficient to exonerate me in your mind? This is the sort of faux pas that makes me go into hiding for two weeks.
Okay. Few things I did with the free bytes that I had left from the optimized code (bank $00 in both SMB1 and SMB2J, with the exception of #2 & 3.1 being in bank $02):
1) Fixed an SFX glitch.
2) Fixed the coin on the status bar during Victory Mode (credit for this goes to Nintendo's programmers, who had unused data present which fixes the issue)
3.1) This is limited to SMB1 on Side A: Added more Bloopers to 9-3 to give it an even more authentic feel of FDS's Minus World (-3)
3.2) This is for both SMB1 and SMB2J: Instead of using sunset palettes for Bonuses, I decided to revert them to original night and day ones (I left stages like 4-3 [SMB1] and 8-2 end, 8-3 & A-3 [SMB2J] with sunset palettes). This has another effect; it fixes the oversight by Nintendo where they left 2-1 and C-1's Bonus as day in the original SMB2J (
http://nesmaps.com/maps/SuperMarioBrothers2j/SuperMarioBros2jMap2-1.html and
http://nesmaps.com/maps/SuperMarioBrothers2j/SuperMarioBros2jMapC-1.html). They now have their proper night palettes and the day ones have theirs. Nintendo either A) chose to make them all day because of lack of room or B) Forgot them.
I've worked a long 40 hour week and I'm tired. So I'm releasing this in confidence that it is glitch free. Tomorrow is my day off. I plan on resting, so I will thoroughly test this by Monday. I'm releasing this early by my goodness and because I'm confident that I did everything right. --ShaneM
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 1E8C
I have fully tested this build today and it is indeed 100% stable. (I used my day off to test.
) I also fixed one last thing, on 8-4 on both SMB1 and SMB2J, the palettes were off on the water segments. This is due to incorrect data on my part. This has now been corrected. (Also, the map I linked to of C-1 was missing the Bonus, so here is a better one:
http://themushroomkingdom.net/maps/smb2j/C-1)
(I added pics of the confirmed 9-3 working. It shows how closely I adhered to Minus World -3 of the original FDS SMB1. So you all can be confident that this is a fully stable build of BOTH games. All I really did was use more Bloopers this time around.
)
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = B17C
You're fixing up mario brothers eh? It appears you haven't fixed a huge bug readily apparent in those pictures you posted! The squids don't collide with the level. This is a really bad immersion breaking bug that only an assembly master like yourself could possibly fix! Good luck can't wait to see more progress keep up the hard work
!
Light-Dark wrote:
The squids don't collide with the level. This is a really bad immersion breaking bug that only an assembly master like yourself could possibly fix!!
What exactly is the issue? I already fixed a collision issue with Bloopers that I found a fix for in the EU version. (I've also corrected Tepples and he credited me, here:
http://forums.nesdev.com/viewtopic.php?p=103473#p103894).
If you mean that the Bloopers "go through" the blocks, then that is how it is supposed to be. They have higher "z-order" than the blocks. (Though this game really doesn't have z-order per se except for the routine "SpriteShuffler:".) I could render collision between them and non-OAM objects, such as blocks, ground etc., but no version makes it this way. Next to mine, the GBC Deluxe version is the next accurate one and on the Super Players mode they still don't render it that way.
If I misunderstood you then please clarify. Thanks.
ShaneM wrote:
Light-Dark wrote:
The squids don't collide with the level. This is a really bad immersion breaking bug that only an assembly master like yourself could possibly fix!!
What exactly is the issue? I already fixed a collision issue with Bloopers that I found a fix for in the EU version. (I've also corrected Tepples and he credited me, here:
http://forums.nesdev.com/viewtopic.php?p=103473#p103894).
If you mean that the Bloopers "go through" the blocks, then that is how it is supposed to be. They have higher "z-order" than the blocks. (Though this game really doesn't have z-order per se except for the routine "SpriteShuffler:".) I could render collision between them and non-OAM objects, such as blocks, ground etc., but no version makes it this way. Next to mine, the GBC Deluxe version is the next accurate one and on the Super Players mode they still don't render it that way.
If I misunderstood you then please clarify. Thanks.
No the squids don't supposed to go through block, that is BAD immersion breaking bug that needs to be fixed. WHY WON'T YOU FIX???? The squid MUST respect block collide or my immersion is BROKE! If you don't fix this then what is point of this patch?? if no squid fix then GARBAGE!
Light-Dark wrote:
No the squids don't supposed to go through block, that is BAD immersion breaking bug that needs to be fixed. WHY WON'T YOU FIX???? The squid MUST respect block collide or my immersion is BROKE! If you don't fix this then what is point of this patch?? if no squid fix then GARBAGE!
The only things that are "broken" here are manners and good sentence structure. I don't take orders, only requests. So take a chill pill.
@Everyone
LeviathanMist (a member over at another forum who tried my hack) found a glitch with demo data on SMB1 (Side A). Since physics in my SMB1 are that of SMB2J, the demo action is off in timing. Also, when Hard Mode is initiated (after getting 8 stars) the demo would end early due to faster enemy movement. So what I did was fixed it. I rerecorded new demo data using SMB Utility 1.08 (the newest one, since older ones were inaccurate with demo recording/timing...yep, this one supports joypads, too to ease recording/testing and yep it was recently translated into English, too:
http://tinyurl.com/8564ztk)
Here is the new build/fix.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 5EAE
Has it bothered anyone else that there is no collision between Piranha Plants and kicked Shells? Should I add collision between them?
EDIT: Should I also add collision between Piranha Plants and other enemies???
In which levels of SMB1 and SMB2J does this come up?
tepples wrote:
In which levels of SMB1 and SMB2J does this come up?
Well, one I can think of is 5-1 of SMB2J. After the midpoint there is an opportunity to get 5 lives in total if the shell would have made collision with the Piranhas. But because there isn't any, it only accumulates a total of up to two. I also find it weird that enemies such as Goombas create a static effect where them and the Piranhas blink upon contact when the Goombas go through them.
Another level I can think of is 8-1 of SMB2J (Buzzy Beetle not colliding with an Upside Down Piranha midway, whether moving or stunned and then kicked). I'm sure there's more, just not off the top of my head. (I can look at NESmaps.com to find all.)
EDIT: I just took a quick look and 4-1 in both games (Spiny causing static due to no collision when they go through Piranhas), 4-2 of SMB2J (shell at the end), 5-2 has both issues with the Red Troopa at the beginning and the potential kicked shell midway. Will look at SMB1 for levels, later.
EDIT2: I still have to create a routine for collision if you all think it's a good idea, but SMB3 onward has collision and every known game after that.
I did it. I created collision between kicked shell and Piranha Plants (even Upside Down ones). I left enemy touch collision alone because it was causing issues. But if anybody wants to know the fix, let me know and I'll PM you a build with it.
I will post my new build on Friday. My damn job has me burnt out working 40 long hard hours this week. Will post then.
Here is a pic for now.
Here it is, with Piranha Plant to Shell collision. No other changes have been made. I am still open to suggestions or issues concerning this game.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = CB03
I've further fixed collision bug with Piranha Plants as well as enemy code and enemy loading code.
1.) Fixed Piranhas to have collision when touching enemies instead of being limited to shell collision.
2.) Fixed bug with Piranha Plants and Upside Down Piranha Plants where they wouldn't load on many occasions. This is another Nintendo original glitch and has NOTHING to do with too many enemies being on the screen at once. Stages where this fix is most noticeable (but not limited to) are 5-1 (SMB1), 6-2 (SMB1), 8-1 (SMB2J), D-2 (SMB2J) etc.
3.) Turns out there are actually 3 Goombas on 1-1 (SMB2J) where one never ever previously loaded (under any circumstances). This has now been corrected. Other enemy issues have been resolved, too.
4.) I made a change to 3-1 where the end Red Koopa Troopas were previously on top of Piranha pipes. Since I added Piranha collision they would get caught in a loop. So I moved them a little after the pipes, into a "Nintendo-logical" place.
This is really D-2. I just loaded it though A-1 to test it. It shows off shell to Upside Down Piranha collision. Points have been awarded for defeating them, too.
Me showing off my newly-added enemy-to-Piranha collision.
All the enemies now load since I optimized the enemy slot buffer glitch. Here is 8-1 of SMB2J with the Upside Down Piranha Plant loading successfully for the first time!!! (Along with all enemies properly loading.)
This is really one of the most comprehensive
SMB hacks and most awesome *FDS* ported hack of this game. The fixes in this game are superior to any other official remake of this game including the GBC/SNES versions. This is how this is going to go down:
The final deadline for this finished product is 10/12/14 for users to submit their suggestions on this game. After that, this will be a finished product. As of now, I've got nothing I can think of to make this game more sublime. (I can't add water/lava animation as I don't have enough free CHR RAM.)
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = F7E4
-
ShaneM
I've invented a new enemy to the SMB2J portion of my game. It is only found on World 9 (Fantasy World). I'd like some feedback. What do you all think? I call it Piranha Trio. It's a 3-headed Piranha Plant...I got the idea from Dugtrio.
This'll be in the new build when it's ready.
Let's see what my Furby has to say about it:
Dah Goo Doh Lee Oh!
(Translation: Clever way to reuse sprite tiles.)
Man, that takes me back. Didn't you make animutations yourself, or am I confusing you for another NESDever?
Dwedit made Miko Miko Nurse. Andrew Kepple made French Erotic Film. I never owned a copy of Adobe Flash.
tepples wrote:
Dwedit made Miko Miko Nurse.
Dwedit made a whole bunch of 'em, including "Suzukisan", the source of his avatar (and forum signature).
It'll be ready soon. I made use of them in SMB1 on Side A, too. I've also "created" an enemy for 4-4 on SMB2J, since the Firebar never previously loaded. I call it a Fuller Bar. It's really two Firebars. One going clockwise while the other one counter-clockwise. It's twice the speed of a regular Firebar and compensates for the original Firebar that never loaded.
The deadline for users submitting ideas on how to improve this as a finished product has ended. The final release is due anytime between now and 10/20/14. So stay tuned. --ShaneM
Here is the newest and final version. I have made the following changes:
1) Further fixed collision errors with Piranha Plants.
2) Fixed "missing" enemies on many stages.
3) Added the newest enemy Piranha Trio to
both SMB1 and SMB2J.
4) Added 720 (or Fuller Bar) to SMB2J's 4-4.
5) Created a second palette for a more authentic feel.
Here, I compare my two palette files to the original. You can choose whichever one floats your boat:
Original unmodified colors
AV-Famicom quality (Custom2.pal)
Sublime colors (further improved; Custom.pal)
Some pics of Piranha Trio in my SMB1:
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 32A3
Okay, I have fixed two more Nintendo original glitches that I was unaware of.
1) Lakitu was originally 8 pixels too low when spawning for the first time. This has to do with residual data being used. This has now been fixed. I noticed this when I was looking at an SNES Super Mario Allstars guide by Nintendo Power. In it, they compared the FDS version 4-1 with the SNES version and I noticed that SNES fixed it. (This fix has been applied to both my SMB1 and SMB2J.)
Code:
CheckpointEnemyID:
lda Enemy_ID,x
cmp #$15 ;this is the issue. Change this to cmp #$11. $15 is Bowser's ;Flame. $11 is for Lakitu (the issue), $12 is for Spiny (never spawns without Lakitu throwing it) and ;$14 is Cheep-Cheep frenzy. ($13 is an unused enemy ID slot.) I think this set to $15 is residual ;because it has no other effect but lowering the enemy based on ID by 8 pixels. Also, it has the ;affect of setting mask offscreen enemies to player collision bits. This is residual as it does not ;affect Lakitu, Spiny or Cheep-Cheep frenzies. There is an abundant amount of residual Cheep-Cheep ;code. Maybe this was intended for another purpose that never was fully developed
bcs InitEnemyRoutines
tay
lda Enemy_Y_Position,x
adc #$08 ;add eight pixels to what will eventually be the vertical coordinate.
sta Enemy_Y_Position,x
lda #$01
sta EnemyOffscrBitsMasked,x
tya ;get original enemy ID back to A
2) I fixed this unknowingly. I didn't even know it existed. But it could have possibly been corrected when I moved the JSR for the Spiny bounding box after the enemy identifier and TYA (a few months ago); I like when things are fixed unknowingly ^^:
http://www.mariowiki.com/List_of_Super_Mario_Bros._glitches#Red_Shell_Out_of_Thin_AirI will release this when I get my fuckin' paycheck tomorrow. The issue is, my hex editor, Hex Editor Neo costs $120 USD and I need to wait to add the binary checksums to my FDS header (though the assembly work is finished on these fixes). I lost my other product key when I sold my old laptop so I need to pay for another one.
--
ShaneM
Okay. In this build, I finally get around to correcting SMB1's header to make it, well...reflect SMB1. Remember, this was originally a hack of SMB2J and so I initially overlooked giving this game its correct FDS header (both internal and external ones).
Another issue that was corrected is on Side B's SMB2J, on 2-1 the enemy data was broken for the Coin heaven bonus. This has now been corrected. It seems that when I added a page to either 1-1 or 4-1, I forgot to add +$04 to the pointer address for the bonus. I really think this is the final build as I fixed every glitch known to the game (including one that I accidentally made with this enemy pointer; something I rarely do
).
I've also edited the included SMB guidebook to reflect SMB1's header. In addition, I've corrected the primary custom palette file. For the second one, I've edited two blues to better reflect the AV Famicom.
SMB2J original ROM (65,000 bytes) CRC16 = BA55
My hacked SMB game CRC16 = 32A3
--
ShaneM
I recently got my hands on not 1 but
3 different dumps of the Wii special version of SMB1 with the 25 replacing the ? Block. It is an ultra rare version of the game with two different Japanese versions and one European version. My question is, should I release a special version of my games with only Side A (SMB1) containing this sprite? I've already ripped the sprite straight from one of my Japanese dumps of this rare edition and added it to my FDS version though YY-CHR (sprite editor). Would you all like a special build with this rarity? (More info found, here:
http://themushroomkingdom.net/games/smb25ae and
https://www.youtube.com/watch?v=UvvnOeFxcU4Here are some shots of my FDS version with the blocks ripped straight from one of my Wii dumps. --ShaneM
EDIT: Oh yeah, I'm also going to disassemble one of my Japanese versions of this game and post the results of differences in the General Topic thread I made with VC differences, soon.
I've been playing the 17th Final version of this FDS hack for less than 2 minutes, and there's already two bugs that come to mind.
- On 1-1, when you hit the second mushroom out of the box, the first one magically vanishes.
- Mushrooms do not collide with any enemies (yet you added collision for everything else, making this unexpected behaviour)
I also wished to play previous versions of your hack (mainly the first two 'final' versions before the addition of collision 'fixes'. They are not linked, could you please provide a comprehensive list of previous versions of this hack?
Stealthii wrote:
I've been playing the 17th Final version of this FDS hack for less than 2 minutes, and there's already two bugs that come to mind.
- On 1-1, when you hit the second mushroom out of the box, the first one magically vanishes.
- Mushrooms do not collide with any enemies (yet you added collision for everything else, making this unexpected behaviour)
I also wished to play previous versions of your hack (mainly the first two 'final' versions before the addition of collision 'fixes'. They are not linked, could you please provide a comprehensive list of previous versions of this hack?
1) Yes. That is no glitch. Two mushrooms/powerups cannot be on the screen at the same time. The NES has OAM limitations. This was carried all the way onto SMB3. Even later versions follow this trend.
2) Why would powerups collide with enemies? In what game/games do they do that?
3) I
may have previous builds available. I'll have to see what I have saved in Mediafire. When I got my new laptop last month, I only carried over necessary files. The same goes for people wanting earlier builds of my Pokemon green (can be found in the GB section on here).
@Everyone:
Surprise--
ShaneM
Most of you have probably read my previous posts concerning the SMB promotion over at Board 2. Well, I fixed some more things up in it. One I will share, with code exclusively I'm sharing here (since I'm probably the only one at Board 2 that is fluent in 6502 ASM). It has to do with an obscure glitch that I recently discovered with platform code (more info here:
http://themushroomkingdom.net/bugs/10 and here
http://themushroomkingdom.net/bugs/56).
This fucker was a real son of a bitch to fix, let me tell you. It took me 6-7 hours to trace code. Initially, I didn't have the slightest clue on what caused this. The fully labeled SMB2J disassembly really didn't help much; the balance lift code is HUMONGOUS. I mean, about 200 lines or so of code just for this, branching off to many subs. I tested this glitch out on Side A SMB1, on level 3-3. Before I hit the debugger, I hit the built-in FCEUX hex editor and looked at $18 and $19, where the enemy slots are stored for these enemies. They have an ID of $24 after being buffered in VRAM. Whatever platform I stood on (the one falling), would get cleared after going under $03 on the screen Y position and go to $00, while the other one would stay at $24. So, the first thing I noted was that the
opposite platform was the one not being cleared. Which is why there is still collision where it stood. The next thing I did before setting Writes in the debugger was looked at the "jmp EraseEnemyObject" in the main routine "BalancePlatform:". I found that this was responsible for clearing the OAM object enemy (yeah, platforms are all considered enemies in SMB1/2J). It cleared what was in A plus X offset. I then hit the debugger, setting Write breakpoints to $18; next I stepped into the code. This is what I found: $95d1 was responsible for clearing the object. It was only clearing what was stored in X, while the opposite platform is always Y. So, whenever X was below $03's Y position on the screen, it would clear the object, but Y (the opposite platform) wasn't. Well, not the collision, anyway. SO I came up with a simple fix:
Code:
BalancePlatform:
lda Enemy_Y_HighPos,x ;check high byte of vertical position
cmp #$03
bne DoBPl
;;;;;; jmp EraseEnemyObject ;if far below screen, kill the object
JMP freespace ;my custom code
freespace:
JSR EraseEnemyObject
TYA
TAX
JMP EraseEnemyObject
It worked...for some platforms but not others. This was obviously the issue but I didn't understand why it was working half of the time and not other times. Then I tried replacing the "lda Enemy_Y_HighPos,x" with a "lda Enemy_Y_HighPos,y" and bingo! It worked. (What this does is make sure the opposite platform or "Y" is cleared FIRST, thereby clearing X, since Y fell after X (the one the player is on.)) Ever had one of those situations where when you fixed a glitch you caused another? Well, that's here. I fixed the invisible platform but caused something strange to happen. Well, not directly caused by my fix. Whenever the platforms fell, it would clear the objects completely, but then some strange collision was created by the rope of the pulleys when they fell. Also, now if the player was standing too close to the rope, they would be pushes away! Sort of like the Wind effect, except more brutal. So much so that the player could barely cross the lifts. (I checked and the lifts were indeed cleared from $18 and $19 or whatever enemy slot they were loaded from.)
The rope code seems stable and I'm sure this code is the issue, not sure what was going on. Lifts would fall randomly on 4-3, other enemies disappeared from the screen randomly (no fixed pattern and sometimes they didn't disappear at all). I thought to myself and came to the conclusion that the platform code is so fucked up that it's a lost cause. So what did I do? After all, I fixed every other glitch I ever came across, I probably broke a record for optimizing SMB code and fixing glitches etc. I recoded the main portion of the troubled code for the platforms! I now made it to the platforms not falling off at all. I made it VERY realistic. The player is no longer awarded 1000 points when getting the platform off because that's now impossible (plus, I wrote over that code). I made it so that when the player stands on the platform and it gets to a certain point, it ceases to move, that is, until you jump onto the other platform. Sort of like a seesaw. But, I made it realistic, so if the platform ceases on one end and you jump up directly above it a certain amount, it drops slightly. Like in real life if a platform stops and a heavy person jumps on the ceased platform. Though it never falls off, with a hundred or so jumps you can get it visibly a little lower. This was HARD. Here is my code, as promised:
Code:
balance_no_possessed:
lda #$2F ;;;;are we at a certain point where the screws are at the top of the balance lift on the opposite ;;platform?
cmp Enemy_Y_Position,y ;;;;;has the opposite platform reached a certain point close to the top of the lift?
;;If so, time keep em' stopped and then RTS.
bcc $04 ;;;;;; yea boi!
jsr StopPlatforms ;;;;;;cease and desist!
rts ;;;;;;return from whence ye came
lda #$20 ;;;;;;;the movement force
jsr $A1D2 ;;;;;;store em' over speed and moveforce in RAM, I did a JSR here instead of having to write out ;;the STA $xx,y and STA $xxxx,y addresses. It's redundant and a waste of space.
pla ;;;;;;get the contents of X back
tax ;;;;;I'm back!
rts ;;;;;um...yep. Pretty self-explanatory
This code is actually called twice, so I made two JSRs to it. If you borrow it, CREDIT me or else I will know it's my code.
I may share my Luigi code (pics on Board 2 from the last post) where I gave Luigi his proper Fiery form colors by doing a palette swap routine. (Getting his regular non-fiery palette was easy, just a simple hex change. Though, the fiery code was shared by Mario and Luigi and I had to create a routine to separate them.) --ShaneM, Master of ASM
Fixed the double-jump glitch that I recently found:
http://www.mariowiki.com/List_of_Super_Mario_Bros._glitches#Jumping_in_MidairEven more reason to participate in the giveaway. Here's my code; I don't always play nice and share my code but I'll share this one, cuz it took one line of code to fix and it took me less than 5 minutes to figure out (I must be getting better at this...if that's even possible at this point):
Code:
PlayerChangeSize:
lda TimerControl ;check master timer control
cmp #$f8 ;for specific moment in time
bne EndChgSize ;branch if before or after that point
JSR DisJoyp ;ShaneM's fix
jmp InitChangeSize ;otherwise run code to get growing/shrinking going
Is there any glitch too hard for me? The labels borrowed from doppleganger's SMB2J disassembly. I'll try to see if there's any more glitches on the worldwide web that I missed before Jan. 05th, the due date for this special build. Too bad, if time passes and I don't get deadline videos by then, nobody will get this special build.
I've already fixed all glitches found on Mariowiki, TheMushroomKingdom and many YT videos. (Excluding ones like "Disappearing Power-Ups" and "Disappearing Trampolines" which aren't glitches but are programmed that way to erase them because there can only be so much OAM buffered at once [but the trampoline one was programmed different in SMB2J to just not load at all instead of trapping the player but I optimized this some], but those reports were probably written by someone without ASM knowledge or knowledge of SMB1 mechanics.) --ShaneM, Master of ASM
Alright; I'm going to share how I fixed the fireball glitch (
http://themushroomkingdom.net/bugs/12). Took me about 5 minutes to fix. There are two ways to fix this.
Code:
ProcFireball_Bubble: ;original routine
lda PlayerStatus ;check player's status
cmp #$02
bcc ProcAirBubbles ;if not fiery, branch
;...some ways down you find
lda CrouchingFlag ;if player crouching, branch
bne ProcFireballs
Method #1 (my choice) = Simply NOP the LDA CrouchingFlag and BNE following it. That way, the player can now crouch and still shoot fireballs, thereby adding a feature as well as "fixing" the glitch.
Method #2 (hardcore/precise) = This merely fixes the glitch instead of letting the player crouch and shoot fireballs. I didn't choose this road because I like the idea of crouching and shooting fireballs.
Code:
ProcFireball_Bubble:
;new code found where the old "lda CrouchingFlag" was
lda Areatype ;if water type level ($00), then branch. ShaneM's code
beq ANDing ;ShaneM's code
lda CrouchingFlag ;original code
bne ProcFireballs ;original code
Fix: ;... some ways down, where the original code "lda #Sfx_Fireball" is located
lda #Sfx_Fireball ;etc...the rest of the routine and so on. I just created a label here
ANDing: ;found wayyy at the end of this routine, entirely. ShaneM's code
lda SavedJoypad1Bits
and %00000100
beq fix
rts
--ShaneM, Master of ASM
So I've fixed every known glitch found in formal sites. But, I found one today on YT that was unmarked on any formal site:
https://www.youtube.com/watch?v=CGk3emjoh8I&list=PL576CDD8E4A2E5A07&index=7. Look at 15 seconds into the video. Notice that he went through the pipe there? That's a glitch having to do with the BG collision of invisible blocks. That happens to any and all invisible blocks, whether they be 1UPs, Invisible Coin, Powerup or Poison Mushroom. This has now been fixed. I tried to get it to emulate the SMAS SNES fix. But this is 6502 and I had to recode it myself. Here is my fix, it will be available only on the version on Board 2 of whomever submits to me entries in the contest giveaway. CREDIT ME IF USED!!!
Code:
RetYC:
and #%00001111 ;and mask out high nybble/ORIGINAL CODE
sta $04 ;store masked out result here/ORIGINAL CODE
lda Player_X_Scroll ;;;;;Is the player horizontally moving? SHANEM's CODE
beq new_label ;;;;;if not, branch SHANEM's CODE
lda $03 ;;;;;SHANEM's CODE
cmp #$5E ;;;;;any object less than the invisible coin, branch. SHANEM's CODE
bcc new_label ;;;;;SHANEM's CODE
cmp #$62 ;;;;;any object greater than invisible powerup, branch SHANEM's CODE
bcs new_label ;;;;;SHANEM's CODE
lda #$00 ;;;;;clear block buffer collision if player moving horizontally otherwise attribute collsion, ;;;;;SHANEM's CODE
sta $03 ;;;;;SHANEM's CODE
new_label: lda $03 ;get saved content of block buffer/ORIGINAL CODE
rts ;ORIGINAL CODE
;notes
;$5E = invisible coin
;$5F = invisible 1-UP
;$60 = invisible Poison Mushroom
;$61 = invisible powerup
tepples or any other person who somewhat knows SMB1/2J, are there any other glitches on the the worldwide web that I'm missing? --ShaneM, Master of ASM
I've decided as a present before X-mas to share my glitch fixes, in which I fix every single glitch in the promo giveaway on Board 2. I know I don't get much acknowledgment for this work, cuz SMB1/SMB2J aren't very popular. But to me, they trumph SMB3 or any other SMB game. So these fixes are a HUGE deal to me. I'll space them out and share them some at a time. Remember, Jan. 05th 2014 are the video contest deadlines.
Here, I fix this glitch, dealing with player-to-enemy collision:
http://www.mariowiki.com/File:SMB_W1-1_Glitch2.ogg (Look at 1:38 into the video; and yeah, I fix the other glitches it presents, too.)
Code:
PlayerEnemyCollision:
;...Some ways down in the routine we find
lda Enemy_State,x
;;;;;and #%00100000 ;if enemy state has d5 set, branch to leave
and #%00100001 ;SHANEM FIX; what we want to do is also branch if d0 is set
bne NoPECol
;...Some more ways down
NoPECol: rts
;notes
;the LSBs we are checking if set are d5
;which is if the enemy is in a defeated state against $1E plus X offset
;or d0, if the enemy is in a falling state
;if either are true and therefore set, collision between enemy and player are void
Thanks for those bothering to even read this. I'll try to post some of my code each day, but I've fixed probably over 60 glitched in total. So I may not be able to post them all. Oh yeah, and as a bonus, here is my code in which I separate fiery Mario and Luigi and give them their own, proper palettes. Credit me if used, please. Here are pics at the bottom, too. (Luigi's colors based on their current official palettes. Only fiery forms depicted, though I corrected Luigi's standard palettes, too; those were simple data changes, though.)
Code:
PlayerColors: ;original shit, here
.db $22, $16, $27, $18 ;player's normal colors, may be overwritten
.db $22, $37, $27, $16 ;player's colors after grabbing fire flower
ClrGetLoop:
lda selectedplayer ;SHANEM's CODE; is Mario or Luigi playing?
bne Luigi ; SHANEM's CODE; if Mario, branch
lda $1a ;SHANEM's CODE; otherwise, load Luigi's shade of green
sta PlayerColors+8 ;SHANEM's CODE; write over the $16 stored at PlayerColors+8 to the offset
bne VRAM ;SHANEM's CODE unconditional branch
Luigi:
lda $16 ;ShaneM's CODE; fetch the shade of red used by Mario
sta PlayerColors+8 ;SHANEM's CODE; store it at PlayersColors+8 to the offset
VRAM:
lda PlayerColors,y ;original code
sta VRAM_Buffer1+3,x ;this too is original code...continue the routine as normal
;notes
;the label "VRAM" is actually the start of the original routine, "ClrGetLoop"
;I just added it for the unconditional branch after loading Luigi's colors
;it may seem redundant that I created code to 'reload' Mario if by default
;Mario's palette is used
;the issue is, if you play as Luigi and choose Quit after a Game Over, then
;choose Mario, Luigi's colors would still be used until a hard reset
;this way palette gets properly swapped no matter which character is playing
Fiery Mario
Fiery Luigi
Some pics of Luigi's regular proper colors, too. These I matched to the SMB Deluxe colors, though that's Z80 and VRAM renders big-endian addressing for each palette instead of single bytes, which it uses 4 palettes just like the FDS does.
SO participate for your chance to win this cool prize. Also, you can see the VC rip of the 25th anniversary blocks I mentioned using, something currently undumped, straight from the source! Also, you can see the star from SMB Special and the ANNSMB mics used, too. Hurry, time's almost up!
--ShaneM, the Master of ASM.
EDIT: One more pic showing off the promotional sprites; SMB2J still on Side B with all these fixes, present (minus the promotional sprites).
So, how could I make this special version of SMB1 and SMB2J extra special? By adding a level from SMB Special!!! Originally released in Japan for the PC88 as a special version of SMB, I've remade 6-2 of this game's level and have replaced the old A-1 secret stage on Side B with it (the secret Warp to this level is still found on A-1 as before)! SMB2J's A-1 is left intact, there is just a secret Warp to this, now. Originally it was a remake of SMB1's 1-1. But now, for the first time, an SMB Special level has been remade for the FDS! That lucky contest winner will sure get to enjoy the fruits of their labor with this prize. Faithful to it's original PC88 version; with SMB2J features, too. Here is a map of the level:
http://www.mariouniverse.com/images/maps/x1/smb/6-2.pngThat's a total of over 22 Worlds; 89 levels! Hours upon hours of fun and excitement while reliving classics to their fullest. Sublime to any other official Nintendo version as I've fixed all the glitches.
Here are some in-game pics of this level:
Production on this promotional game has been completed. I await entries until Jan.05th. --ShaneM
ShaneM wrote:
Code:
PlayerEnemyCollision:
;...Some ways down in the routine we find
lda Enemy_State,x
;;;;;and #%00100000 ;if enemy state has d5 set, branch to leave
and #%00100001 ;SHANEM FIX; what we want to do is also branch if d0 is set
bne NoPECol
;...Some more ways down
NoPECol: rts
;notes
;the LSBs we are checking if set are d5
;which is if the enemy is in a defeated state against $1E plus X offset
;or d0, if the enemy is in a falling state
;if either are true and therefore set, collision between enemy and player are void
I didn't take into account that d0 was masked out to take care of upside down shell to player collision. So I had to come up with a new fix. Here it is:
Code:
PlayerEnemyCollision:
;...Some ways down in the routine we find
lda Enemy_State,x ;ORIGINAL CODE
and #%00100000 ;if enemy state has d5 set, branch to leave ORIGINAL CODE
bne NoPECol ;ORIGINAL CODE
lda Player_Y_Position ;SHANEM's CODE
cmp $b1 ;SHANEM's CODE is the player vertically one pixel below the ground?
bcs NoPECol ;SHANEM's CODE if so, then void collision
;...Some more ways down
NoPECol: rts ;ORIGINAL CODE
Code of the day: Glitch fix #999 Timer glitch:
http://www.mariowiki.com/List_of_glitches_in_Super_Mario_Bros.:_The_Lost_Levels#999_TimerFix:
Code:
EndCastleAward:
;Some ways down we find:
;;;; jsr AwardTimerCastle ;original code
;Replace that jsr with this one:
jsr AwardGameTimerPoints ;SHANEM's CODE
Stay tuned for more as I've conquered them all. --ShaneM
I've made a couple more fixes...Seriously, I'm done this time. Remember, the contest ends in about 11 days. What I fixed:
-Added collision between fireballs and powerups...I don't know why I did this, probably because I made collision for everything else. Though the fireballs do not defeat powerups, they just mark collision.
-Fixed the
Powerful_Wind glitch. I thought this was caused by an NES limitation, but it wasn't! This was a real bitch to fix. I mean this has got to be the hardest thing in the world to fix in the world of NES. I had to create a specific routine for when the windflag was set. Wind would CLC then ADC #$01 to player_x_position, causing horizontal scroll $6FF to increment and decrement between nanoseconds. I was REALLY REALLY tight on space. It took me 7 hours to do but I did it! I traced code and created a new subroutine for "ChkPBtm:", the root of the issue. Did I mention that this was HARD?
-Fixed an issue with Piranha Plant collision being buffered in d6 of the enemy slot. All Piranha Plants issues are now fixed and 100% stable collision with shells/fireballs/enemies, now.
In an earlier post,
ShaneM wrote:
Code:
RetYC:
and #%00001111 ;and mask out high nybble/ORIGINAL CODE
sta $04 ;store masked out result here/ORIGINAL CODE
lda Player_X_Scroll ;;;;;Is the player horizontally moving? SHANEM's CODE
beq new_label ;;;;;if not, branch SHANEM's CODE
lda $03 ;;;;;SHANEM's CODE
cmp #$5E ;;;;;any object less than the invisible coin, branch. SHANEM's CODE
bcc new_label ;;;;;SHANEM's CODE
cmp #$62 ;;;;;any object greater than invisible powerup, branch SHANEM's CODE
bcs new_label ;;;;;SHANEM's CODE
lda #$00 ;;;;;clear block buffer collision if player moving horizontally otherwise attribute ;;;;;collsion, SHANEM's CODE
sta $03 ;;;;;SHANEM's CODE
new_label: lda $03 ;get saved content of block buffer/ORIGINAL CODE
rts ;ORIGINAL CODE
;notes
;$5E = invisible coin
;$5F = invisible 1-UP
;$60 = invisible Poison Mushroom
;$61 = invisible powerup
Today, I've made a discovery. "Player_X_Scroll", or RAM $6FF did a check for if the player is horizontally moving, which includes horicontally moving when vertically inclined. This caused an issue when jumping too hard vertically as it registered as horizontal movement. There wasn't an address to do what I wanted it to do. The SNES version seems to use RAM $E4 for this purpose of this fix which is unused in the FDS version. I didn't have room to create an extra flag. None of the addresses doppleganger listed in his SMB2J disassembly helped for this specific need. I have discovered an address in use by the CPU which is not labeled by doppleganger. It is RAM $089F. It seems that this is purely for vertical movement and is negative (#$FF-#$FD) when the player is ascending but goes to #$04 when the player is descending and finally back to #$00 when the player is standing/running on something solid. This is a more proper register to use for this fix. So, here is the proper fix:
Code:
;replace
lda Player_X_Scroll ;;;;;Is the player horizontally moving? SHANEM's CODE
beq new_label ;;;;;if not, branch SHANEM's CODE
;with this
lda $089F ;SHANEM's CODE, a register I discovered to fix this
bmi new_label ;if player is jumping (ascending), then branch to initiate block buffer collision for
;invisible objects. SHANEM's CODE
--ShaneM, the Master of ASM
Anything using $0800-0FFF, $1000-17FF, and $1800-1FFF will equal to $0000-$07FF, As they are mirrored in the NES's internal RAM... Therefore $089F equals $009F, or simply $9F in zero page, which equals to both ''SprObject_Y_Speed'' and ''Player_Y_Speed'' in the original disassemblies.
Also, If you have the disassembled the shell animations from SNES SMB1, I would like to see it in your hacks, if not... I could add it to mine and credit you.
EDIT - I deleted my second message, I misunderstood at first about tepples' message, Giving it a second look reveals that he said the SNES equivelent to the mirroring problem.
On the Super NES ("The Lost Levels" in Super Mario All-Stars), they mirror to $7E009F and $7E089F.
tepples wrote:
On the Super NES ("The Lost Levels" in Super Mario All-Stars), they mirror to $7E009F and $7E089F.
Right, for RAM. When I said $E4 earlier as the address created for this fix on the SNES, I meant $7E00E4. I forgot that Geiger's debugger gives the ROM, RAM, SRAM etc. in hex mode, too. Anyway, my fix does not do the same thing as on the SNES, which bases its fix on horizontal acceleration while I make use of vertical. Because $06FF was the closest one that I originally had but that didn't quite fix this. So if anyone borrows my fix, credit me and replace the $06FF from earlier with $089F, and change the BEQ to BMI; everything else is the same to correct this glitch with invisible blocks. --ShaneM
@hamtaro
65c816 is similar to 6502. Use Geiger's SNES9x build to find what you want. I never studied 65c816 but since I'm fluent at 6502 I was able to trace the code and see how the SNES fixed it. Basically, use dopplerganger's disassembly when tracing code to the SNES because it's the same, for the most part.
ShaneM wrote:
So if anyone borrows my fix, credit me
Always!
ShaneM wrote:
65c816 is similar to 6502. Use Geiger's SNES9x build to find what you want. I never studied 65c816 but since I'm fluent at 6502 I was able to trace the code and see how the SNES fixed it. Basically, use dopplerganger's disassembly when tracing code to the SNES because it's the same, for the most part.
Actually, I never got to edit SMAS successfully due to Lunar Address (FuSoYa's SNES address decoder) acting up on my ROM, only exception is SMW, And your advice here may be what I need, at least for the RAM!
EDIT: You know, I just realized, all the fixes I made to my FDS games could be applied to the SNES versions. That's what I did when I started my SNES project on this. I'll list some more fixes later on this week; I'll eventually get around to sharing them all and maybe they could go on some sort of Mariowiki for all hackers to have access to. I think I got about 50 original glitches fixed.
Here's one more for today (I think I shared a handful of them last week). How to fix these:
Small_and_Fiery and
Thank_You_Dead_Mario (Same code corrects both glitches.)
Code:
HandleAxeMetatile:
lda #$00 ;ORIGINAL CODE
sta OperMode_Task ;ORIGINAL CODE
lda #$02 ;ORIGINAL CODE
sta OperMode ;ORIGINAL CODE
LSR ;SHANEM's CODE. Divide the #$02 loaded in A to get #$01
STA InjuryTimer ;SHANEM's CODE. Set $079E to #$01 to impose temporary invincibility for whenever
;the player touches the axe object metatile
jsr LoadMarioPhysics ;ORIGINAL CODE
lda #$18 ;ORIGINAL CODE
sta Player_X_Speed ;ORIGINAL CODE
EDIT: My bad; I edited my post to correct the links I listed...
I just thought I'd post the Nintendo-original SNES fix for invisible blocks just for the hell of it. Here is what SNES Lost Levels does to fix it; it can be compared to my fix (routine taken from doppleganger's SMB2J disassembly but commentaries with "SNES FIX" unique to SNES version; also note that both the "lda $03" and "rts" of 'new_label' is present in the original FDS version but the SNES version adds a label not present in the FDS):
Code:
RetYC: ;found at 0x6EB3E in the NTSC Allstars ROM (literal hex offset)
and #%00001111 ;and mask out high nybble
sta $04 ;store masked out result here
lda $E4 ;SNES FIX; loads the new X position that alternates with running speed, if any (unused
;address in FDS)
bne new_label ;SNES FIX; if X speed > 0, player not standing still thus branch to not impose collision
;with invisible blocks (the fall through issue and 'walking through pipes' issue that I listed in an earlier video of
;the FDS version (YT video)
lda $03 ;SNES FIX; get saved content of block buffer
CMP #$5C ;SNES FIX; compare to invisible coin block (BG ID)
BCC new_label ;SNES FIX; any BG IDs less than this, branch
CMP #$62 ;SNES FIX; any object that is bridge (BG ID $62) or greater, branch
BCS new_label ;SNES FIX
STZ $03 ;SNES FIX; the 6502 equivalent would be "LDA #$00, STA $03"
new_label:
lda $03 ;get saved content of block buffer
rts ;return from subroutine
--ShaneM, Master of ASM
I haven't forgotten about this. I have been SUPER busy with a new year around the corner. Some news:
1) I've made a discovery in the Allstars version concerning the fix I made with invisible blocks. Nothing is wrong I just discovered two new items in that version not in the FDS counterpart; more on that soon.
2) I found a new glitch that I fixed; Nintendo-original, of course:
https://www.youtube.com/watch?v=pAQU1jcN-5A It is caused when the player touches any short firebar (there are four valid ones in the game [$1b-$1E and $1F is the long one. These are enemy IDs I'm using]). I also fixed this one, too (how many glitches did Nintendo create?!?). I really think I got them all, now. I had to search like nobody's business through the web. This one took me until like the 16th YT page of videos to find. Here is the fix:
Code:
ChgSDir:
ldx #$01 ;ORIGINAL CODE set movement direction by default
lda $04 ;ORIGINAL CODE if OAM X coordinate of player's sprite 1
cmp $06 ;ORIGINAL CODE is greater than horizontal coordinate of firebar
bcs SetSDir ;ORIGINAL CODE then do not alter movement direction
inx ;ORIGINAL CODE otherwise increment it
SetSDir:
txa ;SHANEM FIX move either #$01 or #$02 into A as directional offset
ldx ObjectOffset ;SHANEM FIX get the Firebar offset and ONLY the Firebar offset
sta Enemy_MovingDir,x ;SHANEM FIX store movement direction here
;;;;stx Enemy_MovingDir ;ORIGINAL CODE store movement direction here
;;;this STX was the issue. A was not used with X's offset causing the wrong enemies to turn
If you use my code, credit me as I fixed what Nintendo couldn't.
3) Because I'm a nice guy, I'll be releasing a standalone version of my SMB2J on New Year's day or right before! This includes every single glitch fixed! It will not have the same bonuses as the promo build got the contest on the fifth, but it gives you all an opportunity to behold perfect mario bros. in action!
4) The Koops sprites on the FDS are shitty. They've been replaced with the SMAS version equivalents. I've also added the eyes for the clouds for sunset stages like 8-3 from SMAS. I also gave Bowser eyebrows from the SMAS version. Enjoy! --ShaneM, the Master of ASM
EDIT: The pic that says 1-1 is really A-3. I just modified RAM to test the level with the new clouds. Also, I removed the eight stars on the titlescreen. I modified ROM 0xCC3C temporarily to test the letter world, some.
ShaneM wrote:
1) I've made a discovery in the Allstars version concerning the fix I made with invisible blocks. Nothing is wrong I just discovered two new items in that version not in the FDS counterpart; more on that soon.
The two new items are "hidden vines" and "hidden starmans". So, these are the SNES BG ID defines in the SNES version, compared to the FDS version:
Code:
;SNES
Invisible Coin = $5C
Invisible 1-UP = $5D
Invisible Poison Mushroom = $5E
Invisible Powerup = $5F
Invisible Vine = $60 ;new
Invisible Star = $61 ;new
Code:
;FDS
Invisible Coin = $5E
Invisible 1-UP = $5F
Invisible Poison Mushroom = $60
Invisible Powerup = $61
They are found on stages such as 8-3 where the castle wall has been removed in the SNES version. In the NTSC Allstars ROM, 8-3's new invisible items are found at 0x760CA ($2F, $60, $96) and 0x760D9 ($4F, $70, $18). Notice that these are three byte objects. Their object IDs are $16 for the invisible vine and $18 for the invisible Starman. If you want to experiment, grab a hex editor and edit these into level 1-1 found in NTSC ROM 0x74C84. (The first 16 bits, or 2 bytes of level data are specific to stage background, timer, scenery, start position and midway points just like the FDS counterpart.) I could disassemble and label the whole SNES ROM, but I don't feel like it.
I set the release date of SMB2J FDS on Jan. 02, 2015. --ShaneM, the Master of ASM
ShaneM wrote:
I set the release date of SMB2J FDS on Jan. 02, 2015. --ShaneM, the Master of ASM
Here you all go, as promised. I now present you a list of every glitch that has been fixed, glitches due to technical limitations and customizations (Many glitches present in SMB1 were present in SMB2J, too. The ones fixed by Nintendo themselves in SMB2J marked with an *):
List of fixes present in this build:
Vine of the dead*
Bullet on a stringDouble jumpKoopa Troopa factoryMario CopperfieldMario's double deathMushroom magic -
my code used for "Jumping Damage Glitch" fixes this since Super Mushrooms share normal enemy code.Jumping Damage GlitchMushroom through the blocksSmall and FieryStarman kills fanfare*
Stuck underwater -
Nintendo now adds block at the end of water levels. This is also done in the EU version of SMB1.Thank you dead Mario!The magic Koopa Troopa -
Could originally be done on stages like 1-1 and 8-2 in SMB2J.Un-Fiery MarioInvisible platformPoints for the patientPowerful windBlue Bowser GlitchInstant Game Over*
Invisible Piranha Plant*
Over the Flagpole -
Scroll stops have been added at the end of each level. They were messy and caused flag cut off at times so I neatened them by manipulating data.CorruptionDisappearing Power-UpDisappearing SpringboardsFireball Through Compact SpaceHammer ImmunityHammer through the Pipe*On 2-3 and 8-2 it was previously impossible to get 5000 pts. on the flagpole due to it being too far from the previous platform. This has been fixed.
Flagpoles need to be exactly 8 blocks away from the jumping platform.Platform glitchInvisible Block Glitch -
Also makes the player fall through like on 3-1.Stuck at the flagpole3-4 GlitchKoopa Moonwalking Glitch*
Disappearing Trampoline*
Vine teleportThings not glitches but have code present to avoid issues:
Disappearing Power-UpsThings due to FDS limitations:
Harmless EnemyWalk through wallsNew Features:
*SRAM saving of high scores when choosing "Quit" on Game Over or when beating 8-4
*Hard Mode taken from the SMAS version for Worlds A-D. Buzzy Beetles replace Goombas, ehemies are faster and platforms are smaller
*Aggressive Hammer Bros. on Worlds A-D
*Bowser as his own identities on Worlds A-D, just like the Allstars version
*Springs code on A-D no longer share 1-9 code so their structure taken from SMAS
*The lettering cutoff on Worlds A-D has been fixed on the status bar
*World A-1 extra bricks from SMAS redone
*Ability to pause on 8-4 and D-4 fixed and recoded
*Various level inconsistencies fixed according to the SMB Deluxe and SMAS versions
*New hidden 1-UP has been added to A-1, since the original forgot to assign one for this stage (every X-1 stage has one)
*Luigi now has his official palettes and has his own fiery form
*Balance lifts redone and more realistic
*Proper palette assignment taken from SMAS
*Some sprites such as Koopas ripped from SMAS
*Skid sfx plays while wind blows and player skids
*When the player is defeated by an enemy while wind is blowing, the wind stops, just like in the SMAS version
*New underwater currents can be found on stages like 9-4
*Three-headed Piranha Plants found on World 9
*Fuller bars found on stages like C-3
*Three new bonus rooms added; one on 9-4, one on B-1 and one on C-1
*New Sunset palette added for cloud levels (similar to SMAS)
*Snow on ground added to snowy levels
*New lives concept; cannot exceed Crown19, just like the original programmer intended
*Bowser now throws hammers on Worlds A-D, just like the SMAS version
*Player now starts with 5 lives, just like in the SMAS version
*The message on 9-4 has been translated into American English
*Collision added for enemy-to-Piranha Plants
*Collision added for shell-to-Piranha Plants
*Improved enemy buffering
*Improved collision with shrooms/Starman
I have two guys helping me beta test this. I am also testing this myself. I'm releasing this as-is at the moment in good confidence that it is glitch-free. If nothing is found, then this will be the final. Remember also, the contest is due on the 5th. Patch it to an SMB2J headerless ROM with a CRC16 of BA55. --ShaneM, the Master of ASM
DOWNLOAD: SEE NEXT POST
I accidentally posted a beta, above. Please download this one instead.
I also forgot to mention another fix I made:
-Fixed big player immunity when standing on the sea floor and collision is made with Blooper. Fix for this borrowed from the EU version of SMB1.
-Cheep-Cheep code optimized and taken from the EU version of SMB1; it's no longer broken but fully functional, like Nintendo intended it to be. --ShaneM, Master of ASM
DOWNLOAD: SEE BELOW
I got to ask, Why the ending music is removed along with part of the ending?
also, Why not disassemble and use Vs. Super Mario Bros's ending music, or at least use Super Mario Bros. 1's ending music
Hamtaro126 wrote:
I got to ask, Why the ending music is removed along with part of the ending?
also, Why not disassemble and use Vs. Super Mario Bros's ending music, or at least use Super Mario Bros. 1's ending music
What? Where did you get that it was removed? All I did was fix the pause sfx on the princess scene since it was missing in the original. (Try pausing on an unedited SMB2J when you see the princess on 8-4 or D-4 and the sfx is absent.) Before I learned ASM, I had Kasumi help me with it, but it was not correctly done so I redid it. That's all I said. Kasumi is my mentor in teaching me ASM, so it's not his fault previously, he was just working without source. But since I have source code and know ASM, I redid it myself. (All of the above fixes are mine, btw.)
Vs. SMB you say? Most routines are similar to SMB2J in that version, actually. Though RustedLogic seems to have many motes in it, if you want to ask him. I could disassemble it since the source is so similar, but I have no need to. I sent you a PM, btw. --ShaneM, the Master of ASM
Here is the new build. It is RC2. It fixes some bugs I found in RC1. I will continue doing some testing and if anything else comes up there will be an RC3, if not, then this is the final. I've decided to release both SMB1 and SMB2J together (SMB2J is on disk side B, as usual). Here is the download. I will continue to do testing on these and will also improve the game manual I've made. --ShaneM, the Master of ASM
DOWNLOAD: SEE BELOW
Is this another "IPS that can be applied to a blank file to produce something working"?
tepples wrote:
Is this another "IPS that can be applied to a blank file to produce something working"?
I'm not sure where you got 'another' from. I've always made patches to be patched to an unedited SMB2J copy. I've never made patches to blank files. Anyway, here's me quoting patching info that I posted on last Friday:
ShaneM wrote:
Patch it to an SMB2J headerless ROM with a CRC16 of BA55. --ShaneM, the Master of ASM
If SMB2J is one side, where does the other side's data come from? Unlike xdelta and BPS and the like, IPS has no built-in way to replicate the first side to the second. What happens if you patch it on top of a file of zeroes and play side B?
Patching the IPS over a blank 128kb file full of zeros (didn't bother to fix the size to whatever FDS images are supposed to be, and a completely empty file crashed the patcher), one side (I assume SMB1) gave me error 20, but the other has a seemingly fully playable SMB2J (though I suck too much at Mario to bother to play very far).
ShaneM wrote:
I'm not sure where you got 'another' from. I've always made patches to be patched to an unedited SMB2J copy. I've never made patches to blank files.
Not intentionally, but I believe tepples' point is that IPS is not a good format to describe extensive changes made to a file, because it can't deal with code relocation and will in many cases contain nearly the entire file.
You might want to require users to double up the disk and then make the patch against smb2j-2sides.fds.
In Windows Command Prompt:
Code:
copy /b smb2j.fds+smb2j.fds smb2j-2sides.fds
In UNIX and UNIX clones:
Code:
cat smb2j.fds smb2j.fds > smb2j-2sides.fds
The "another" refers to
this post.
I think the best thing to do then is make two separate .ips patches since that is the only form of patching I am familiar with. What I will do is create two patches, here. One of SMB1 SRAM Plus and one of SMB2J SRAM Plus. They are both hacks of SMB2J to begin with. So both patches will have the same SMB2J headerless ROM-base. Patch either/both of these to a headerless SMB2J with a CRC16 checksum of BA55.
I think this solves the issues, tepples, no?
Here is RC3 of both. Hopefully, this should be the final.
"I'm all about that BA55, 'bout that BA55, no treble"
That should work at first glance. Is there anything substantial in this patch that doesn't move, so that it can be assured not to work if patched on top of some random FDS side?
tepples wrote:
"I'm all about that BA55, 'bout that BA55, no treble"
That should work at first glance. Is there anything substantial in this patch that doesn't move, so that it can be assured not to work if patched on top of some random FDS side?
Everything in ROM should be different as I assembled with ASM6 and just about every routine is different since I fixed all the glitches. So I would assume so. If anything comes up let me know and we can work on a different type of patch. --ShaneM
I want to hear your all's thoughts on this:
Hit the Axe and Keep It ThereDo you all think that's a glitch or not? Would you all like it fixed? I seem to have overlooked this one when fixing glitches as it still occurs. The routine is found in "ChkFootMTile:" in doppleganer's disassembly and has to do with the CMP check with RAM $03 (what's loaded into A; block buffer) against the CMP #$C6 (axe BG tile ID).
So, who would like to see this fixed? Is it really a glitch? Thoughts or opinions? --ShaneM, the Master of ASM
From a game designer's point of view: I think if Mario already burned Bowser to death, the axe should stay visible no matter the angle at which Mario touches it. This makes the rule consistent: hide the axe if and only if the bridge is collapsing.
tepples wrote:
From a game designer's point of view: I think if Mario already burned Bowser to death, the axe should stay visible no matter the angle at which Mario touches it. This makes the rule consistent: hide the axe if and only if the bridge is collapsing.
Thank you for your input. I've interpreted your post as "this is an oversight on the developer's part". So, I will sum it up to "this is a glitch".
This has now been fixed. But slightly different from tepple's suggested fix. I've made it to always disappear because the code that jumps to it either loads RAM $03 (left foot metatile) or $00 (right foot metatile) to the CMP #$C6 for the axe tile. Going too far right caused the current ID to get cleared from the block buffer. Since either $00 or $03 is used and this is the main routine for all collision in the game (a stupid place to put axe tile code) I couldn't push A onto the stack to be loaded after this since PHA only stores immediate values (even found at RAM addresses). I couldn't use register X for a CPX routine after the CMP #$C6 if the Z flag was set (hence it didn't branch) and Y is also being used too. What I did was a data fix for this. I changed all scroll stops from $5D for castle levels to $4D. Surprisingly, it is absolutely not noticeable but rather it fixes this glitch from occurring. I've fixed it in SMB2J so far and will change it in SMB1, soon. I am also still working on the manual to improve it, too. So for now, here's SMB The Lost Levels RC4. --ShaneM, the Master of ASM
Fixed:
Hit the Axe and Keep It There
You know what I just realized? The SNES version of Super Mario Bros.: The Lost Levels actually fixes the Axe by doing EXACTLY what I did by shorting the scroll stops! o_0
I'm getting ready to release the new SMB1 build fix. I want some opinions: How many of you would like to see the original SMB1 GFX for the SMB1 portion? How many prefer the Lost Levels tiles? --ShaneM
Still haven't heard what people want me to do with SMB1. But, I've corrected all 'Engrish' found on SMB2J and will release it soon. Text fixed includes the World 9 intro screen, as well as Game Over screen for World 9. Another text corrected is the poem on 8-4 to make it slightly more poetic and logical, as well as make use of another beta tile that I discovered. The beta tile is from ANNSMB (All Night Nippon) and can be found in the FCEUX PPU viewer as tiles $FB-$FE. One is a heart, two are Japanese and one is an exclamation point. I've added the heart from ANNSMB into the SMB2J Princess poem as sort of a border. I will release this soon; work on improving the manual has begun! --ShaneM, the Master of ASM
EDIT: For those wondering how I got the 'heart' beta tile to fit from ANNSMB into SMB2J, I've replaced the "J" tile with it since "J" is never used.
In your current script, as well from the original version:
Code:
HURRAH TO (two spaces) [Player Name]
The two spaces needs to be changed to only one space, essential if correcting errors!
EDIT: I agree, SMB1 can still use most of it's original graphics, and it will still be fun,
- move the title screen to the PRG instead of CHR (of which you already did that),
- remove off the sprite graphic associated with sprite 0 (as IRQ is used instead),
- Remove one of the duplicate tiles for the stem of the Piranha Plants,
- Remove the semi-duplicate tiles for the top of bricks, as SMAS SMB1 uses the same character as the bottom,
- OPTIONAL: If score sprites does not matter, remove the sprites only (Scoring can still be used if you need it!)
- PROTIP: The second coin sprite can be flipped like in SMB3 by adding a bit of code to flip the second frame, using 3 CHR tiles instead of 4.
and now you got a bit more CHR to use
A SUGGESTION: Maybe making Princess Peach and the Ending Door different colors for use in your SMB2J and SMB1, Just replace Peach's Attribute to the one used in-game as Green, but make it so that the door is not green and uses a colorset of $08,$28,$18 (Wood-like colors) and when Peach appears, the palette turns to the following colors: $25,$36,$08 (pink, skin, brown)
Hamtaro126 wrote:
- Remove the semi-duplicate tiles for the top of bricks, as SMAS SMB1 uses the same character as the bottom,
But then there'd be no contrast for the brick in front of the "castle wall" repeating tiles near the end of 8-3. SMAS doesn't need it because it removes the repeating tiles in favor of a parallax background.
Hamtaro126 wrote:
In your current script, as well from the original version:
Code:
HURRAH TO (two spaces) [Player Name]
The two spaces needs to be changed to only one space, essential if correcting errors!
EDIT: I agree, SMB1 can still use most of it's original graphics, and it will still be fun,
- move the title screen to the PRG instead of CHR (of which you already did that),
- remove off the sprite graphic associated with sprite 0 (as IRQ is used instead),
- Remove one of the duplicate tiles for the stem of the Piranha Plants,
- Remove the semi-duplicate tiles for the top of bricks, as SMAS SMB1 uses the same character as the bottom,
- OPTIONAL: If score sprites does not matter, remove the sprites only (Scoring can still be used if you need it!)
- PROTIP: The second coin sprite can be flipped like in SMB3 by adding a bit of code to flip the second frame, using 3 CHR tiles instead of 4.
and now you got a bit more CHR to use
A SUGGESTION: Maybe making Princess Peach and the Ending Door different colors for use in your SMB2J and SMB1, Just replace Peach's Attribute to the one used in-game as Green, but make it so that the door is not green and uses a colorset of $08,$28,$18 (Wood-like colors) and when Peach appears, the palette turns to the following colors: $25,$36,$08 (pink, skin, brown)
I'll try to go in order, here.
1) The two spaces within the poem on 8-4/D-4 for player's name was intentional on Nintendo's part for symmetry. Look at the end of the sentence lines, see how they match and go in pattern? Removing that space would break symmetry. (ie "saved" on line 2 and "Luigi" on line 3)
2) Thanks for the SMB1 opinion; it will be weighed in.
3) "remove off the sprite graphic associated with sprite 0 (as IRQ is used instead)" - SMB2J does not use Sprite 0 for the undercoin anymore. Since SMB1 is a hack of that, it's not used anyway.
4) "Remove one of the duplicate tiles for the stem of the Piranha Plants" - Why? Then the Piranha Plant will look odd...
5) "Remove the semi-duplicate tiles for the top of bricks, as SMAS SMB1 uses the same character as the bottom" - What tepples said.
6) "The second coin sprite can be flipped like in SMB3 by adding a bit of code to flip the second frame, using 3 CHR tiles instead of 4." - I would need more CHR RAM to create animated sprites. Now, if you've ever hacked SMB2J on the FDS, you'd know that this is next to impossible to do.
7) "A SUGGESTION..." - We'll see.
Right now I'm trying to rip some code from the EU version of SMB1 to improve TLL. The SNES version actually make the same changes to the EU TLL. Turns out not all their changes were necessary. So far, I've ripped the vertical collision fix for underwater blocks from that version, except it I coded myself a little differently. New build coming soon. I will make more comparisons and some to the SMAS EU, too. For now, here is the Nintendo-original EU fix for minusing vertical gravity when bumping underwater blocks vs. my fix from scratch.
Really, this is not a glitch that they fixed more or less a customization. Commentary notes are mine and so is the "watertype" label. If you borrow my method, credit me.
Code:
;original NTSC/Japan
NYSpd:
lda #$01 ;set player's vertical speed to nullify
sta Player_Y_Speed ;jump or swim
Code:
;original Nintendo EU SMB1
NYSpd:
ldy #$01 ;set player's vertical speed to nullify (one by default)
lda AreaType ;are we in a water type level?
bne watertype ;if not, then branch
dey ;otherwise set Y as #$00 to impose gravity
watertype:
sty Player_Y_Speed ;store either #$01 or #$00 depending on terrain type
Code:
;the ShaneM way
NYSpd:
ldy #$00 ;set player's vertical speed to nullify (zero by default)
lda AreaType ;are we in a water type level?
beq watertype ;if so, then branch
iny ;otherwise set Y as #$01 to set gravity
watertype:
sty Player_Y_Speed ;store either #$01 or #$00 depending on terrain type
I plan on releasing the next RC on Tuesday as well as an updated manual. --ShaneM, the Master of ASM
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:
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 think I have an idea of what this fix is for. It's some sort of fix for if the player collides with the Cheep-Cheep at a weird angle. It corrects collision to "stomp" on the enemy rather than taking damage when collision is made while the player is jumping. (This fix implies that the player is jumping thereby having a signed integer at RAM $9F to do this check.) I'm going to try and figure out why the check was made to add #$14 for other enemies (though it's inverted in the EU and we ADC Player_Y_Position instead of loading A with the value). Point is, I want to see why that was done differently in EU to include enemies that are #$06 or less into the comparison (thereby making the label "ChkETmrs:" completely useless in the EU build).
ShaneM wrote:
I think I have an idea of what this fix is for. It's some sort of fix for if the player collides with the Cheep-Cheep at a weird angle. It corrects collision to "stomp" on the enemy rather than taking damage when collision is made while the player is jumping. (This fix implies that the player is jumping thereby having a signed integer at RAM $9F to do this check.) I'm going to try and figure out why the check was made to add #$14 for other enemies (though it's inverted in the EU and we ADC Player_Y_Position instead of loading A with the value). Point is, I want to see why that was done differently in EU to include enemies that are #$06 or less into the comparison (thereby making the label "ChkETmrs:" completely useless in the EU build).
Okay. I now have a
perfect understanding of what this EU difference does. I will get into more detail tomorrow when I get up and after I get some free time. In a nutshell, this really doesn't fix any glitch. Rather, if corrects an oversight on the NTSC programmer's part. It is customization, as well as optimization. It has to do with a very specific jump slightly over an enemy, so close to the head that it should be counted as a "stomp" in the NTSC but counts as a player injury if the enemy is #$06 or less. I tried changing the code and specifically testing with an enemy that sets Carry (Lakitu) to verify. The EU separates Cheep-Cheep frenzies from this because on the account of diagonal enemy jumping on their part since their bounding box data is different. I will incorporate this into my SMB2J build; it only takes 1 additional byte and I found an opportunity to optimize code in "KillPlayer" to earn two free bytes. --ShaneM, the Master of ASM
ShaneM wrote:
Okay. I now have a perfect understanding of what this EU difference does. I will get into more detail tomorrow when I get up and after I get some free time. In a nutshell, this really doesn't fix any glitch. Rather, if corrects an oversight on the NTSC programmer's part. It is customization, as well as optimization. It has to do with a very specific jump slightly over an enemy, so close to the head that it should be counted as a "stomp" in the NTSC but counts as a player injury if the enemy is #$06 or less. I tried changing the code and specifically testing with an enemy that sets Carry (Lakitu) to verify. The EU separates Cheep-Cheep frenzies from this because on the account of diagonal enemy jumping on their part since their bounding box data is different. I will incorporate this into my SMB2J build; it only takes 1 additional byte and I found an opportunity to optimize code in "KillPlayer" to earn two free bytes. --ShaneM, the Master of ASM
Okay, here is my more in-depth explanation. (Lakitu is my guinea pig in this example, since it will set the MSB thereby not cause the code to branch in ChkInj.)
Picture 1: For this to work, you must be no further from Lakitu than this.
Picture 2: This demonstrates when the code is in action in the NTSC version. See how Mario is not exactly hitting Lakitu's head from the top, though collision is counted as Lakitu being stomped from the 800 pts. above? That's the CMP Enemy_Y_Position,x in action there.
Picture 3: This is what happens when I NOP those nine bytes to see what happens. The player is injured instead of Lakitu being damaged. You can see Mario's swim animation, there. When the player takes damage and shrinks, there are actually two swim animations used in the process.
I used savestates to test this to make sure everything is exactly the same to verify. Look at the timer and Spiny's on the ground. Everything is exact between photo 2 and 3.
The EU version changes it to include all enemies because there are instances where, for example, Goombas are going down stairs while the player is jumping up and Mario/Luigi wrongfully takes damage. It singles out Cheep-Cheeps because they can (and will) jump at a diagonal angle, which causes damage to the player if A still contained #$14 at the time. It was specifically changed to load #$07 with flying Cheep-Cheeps to fix that. (I tried changing the #$07 to a #$14 in the EU version to verify that I was correct.)
The new build is scheduled to be released tomorrow of SMB2J and will add this fix from the EU version. It will be RC5. RC2 of the manual is due tomorrow, too. --ShaneM,
The Master of ASM
Alright. I was able to add the code into SMB2J by optimizing the routine "KillPlayer" to make room. Yay. ^_^
Here is a picture of the code in action against the Goomba that's loaded on 1-1 all the way at the top. Damage is no longer taken by the player but is counted as a stomp if at the right angle. --ShaneM, the Master of ASM
EDIT: Btw, the enemy keeps falling when stomped like it's supposed to do, too.
EDIT2: Turns out I was able to optimize enough code to earn me 3 free bytes. So I still have two more to spare from that optimization.
I like how the SNES version gave purple for the night skies. I could add stars to M-tileset 3 to make them glow (by using the star metatile used on the titlescreen; tileset 3 contains glowing objects like coins, axe etc.) but I simply don't have PRG to do so. Or else I would add it to the scenery tileset as well as code it for night. To make up, I assign each stage type a new background. To ice levels I assign arctic blue, to regular levels sky blue, night stages black, sunset stages for pure cloud levels (only 8-2 ending, 8-3 and A-3) and dark purple skies for night snow (just like how the sky is colored in real life when it snows).
Thoughts? 5 different color in total, as pictured below. --ShaneM, the Master of ASM
Here is the next RC5, as promised. Though this still hasn't been tested yet. I'm releasing a rough build in assumption that it is fully stable. I will begin heavy testing in the first week of Feb. All ASM work on this SMB: The Lost Levels is final and complete. I will only correct errors I find, if any on my part. I will tackle SMB1 really soon. I want to release the manual now, too. But I will pass it by tepples to see if it's okay, first. Patch it to an SMB2J FDS ROM with a CRC16 of BA55. --ShaneM, the Master of ASM
Here is a copy of the .pal file, which keeps all the original colors in order, except replaces $3F with the dark purple used on Snow Night levels. No game that I know uses it anyway. (rename it from .ips to .pal)
Here's RC6 of both SMB1 and SMB2J. It has the latest fixes. I'll just list them, quickly. Also, you'll need the custom palette file above to enjoy the new night snowy palette which uses $3F.
Changelog:
*Added routine from EU SMB1 to void underwater block collision
*Fixed the Axe glitch
*Added the routine from the EU SMB1 for when hitting enemy from their upper sides
*Corrected some Flying Cheep-Cheep code that I messed up on
*Added customized palettes for various levels
*Fixed and corrected various "Engrish" text
*When I implemented the hitting enemy fix from the EU SMB1 I seemed to have overlooked the fact that the bounding boxes were changed for Tall Enemy (enemy ID $09), so this has been fixed, too.
Code:
BoundBoxCtrlData:
.db $02, $08, $0e, $20
.db $03, $14, $0d, $20
.db $02, $14, $0e, $20
.db $02, $09, $0e, $15
.db $00, $00, $18, $06
.db $00, $00, $20, $0d
.db $00, $00, $30, $0d
.db $00, $00, $08, $08
.db $06, $04, $0a, $08
.ifdef Japan
.db $03, $0e, $0d, $16
.else
.db $03, $0c, $0d, $16
.endif
.db $00, $02, $10, $15
.db $04, $04, $0c, $1c
This is released as-is until early Feb., when intense testing begins. Like SMB2J, all ASM coding on this is complete unless some error on my part comes up. --ShaneM, the Master of ASM
I forgot to post my wind fix
http://themushroomkingdom.net/bugs/55. Here it is for those who want it, credit me if used:
Code:
;Make all previous branches to "ImpedePlayerMove" branch to "windfix4" instead
windfix4:
lda WindFlag ;if wind is off, then branch
beq StopPlayerMove
dec Player_X_Position ;otherwise decrement from the player's X position to neutralize movement
StopPlayerMove:
jsr ImpedePlayerMove ;stop player's movement
ExCSM: rts ;leave
ShaneM, The Master of ASM
The beta ground tiles unused in SMB2J is actually used in the game's manual! The manual was written on June 03rd, 1986; two months before the release.
https://tcrf.net/Super_Mario_Bros._2_%28Famicom_Disk_System%29Glad I made use of the tiles!
In the above post, that release date on TCRF is wrong, so if the author of it is reading this, correct it to being "unknown". The game was manufactured on Wednesday July 23rd, 1986, but the commercial release date is unknown. (That date listed is the written date of my manual.) --ShaneM
The saga continues with another look at the mysterious SMB2J manual. Today, for the first time in history, I share a look at an SMB2J beta stage! Nothing like this has been discovered by anyone else concerning SMB1 or SMB2J. Brace yourselves.
Here is the level in question:
http://nesmaps.com/maps/SuperMarioBrothers2j/SuperMarioBros2jMapC-1.htmlNow, look at the attached picture below. You'll see the same clip of the beginning of C-1 except for: 1) It seems to take place at day, with a Snowy terrain (the All-Stars version has this level as a Snowy Night one). 2) The level is different with arrangement of blocks and slightly different spacing. 3)
The level is assigned as 5-1 rather than C-1. Does this imply that 5-1 was changed at last minute and the original 5-1 was moved to C-1? In intrigues me whether what's now known as 5-1 may have been C-1 at the time and swapped before release or if the current 5-1 didn't exist at the time. 4) As usual, the beta ground tiles are also used.
EDIT: The pipes in the beta screenshot replaces the vertical blocks used in the final level with bricks.
Enjoy. --The Master of ASM
Exactly what do you mean by SRAM? Ability to save your progress? When I think of SRAM I think of cartridges, not FDS floppies.
What I'm asking is: Does this run on real hardware?
SRAM is found built-in via FDS RAM around 6000-DFFF, But unlike NES's SRAM in carts (6000-7FFF), A seperate file is required to be loaded into ram from the disk.
As for testing: The easiest way is by PowerPak, otherwise you can try finding a good, empty FDS formatted disk (it's an officially modified Mitsumi Quickdisk, I think!) and the only way to write a disk is very hard and unreliable, and if you were to do one anyways, ask someone like Chris ''Toungeman'' Covell for instructions
The saga continues. So far, I've shared some beta images. I've got some more to share from the manual, but I wanted to take today's post to elaborate on one I've already shared. (The next post will have a new image.)
The level in question is 1-1 of SMB2J:
http://nesmaps.com/maps/SuperMarioBrothers2j/SuperMarioBros2jMap1-1.htmlNow compare it to the attached screenshot below. Some comments:
1) All the way up at the top the row of 8 coins was originally 2.
2) The Starman on the left of the second row of bricks was originally 5 bricks to the right.
3) The Goomba is not seen on the top; perhaps it is there but just walked offscreen?
4) The 10 Coin Brick to the right of the 4-block stairs is absent.
5) The beta ground tiles are used (of course).
Other updates:
I've removed halfway pages to SMB1 when playing Hard Mode (after accumulating 8 stars on the titlescreen). The other enhancements to Hard Mode still stand. I was able to optimize another routine to earn 13 free bytes. (I found another routine that I could save 6 on but it's only loaded during the title screen routine.)
Here's the code and RC7.5 of both game attached at the bottom. For SMB2J I've done more thorough testing and fixed a couple of things. It seems stable. More testing to follow on both games this month. So far, no crashes and no bugs whatsoever; only Mario perfection and Nintendo-original glitches fixed. ^_^
Code:
StillInGame:
lda gamesbeatencount ;ShaneM code
cmp #$08 ;ShaneM code
bcs new_label ;ShaneM code
lda WorldNumber ;multiply world number by 2 and use
asl ;as offset
tax
lda LevelNumber ;if in level 3 or 4, increment
and #$02 ;offset by one byte, otherwise
beq GetHalfway ;leave offset alone
inx
GetHalfway: ldy HalfwayPageNybbles,x ;get halfway page number with offset
lda LevelNumber ;check area number's LSB
lsr
tya ;if in level 2 or 4, use lower nybble
bcs MaskHPNyb
lsr ;move higher nybble to lower if
lsr ;level number is 1 or 3
lsr
lsr
MaskHPNyb: and #%00001111 ;mask out all but lower nybble
cmp ScreenLeft_PageLoc
beq SetHalfway ;left side of screen must be at the halfway page,
bcc SetHalfway ;otherwise player must start at the
new_label: ;ShaneM label
lda #$00 ;beginning of the level
SetHalfway: sta HalfwayPage ;store as halfway page for player
jmp ContinueGame ;continue the game
I've also found SMB1 FDS' proper header from a No-Intro clean dump. The true SMB1 FDS header is now used.
I've also corrected doppleganger on an error he made with his commentary on the SMB1 and SMB2J disassembly in "ChkStart:"; he's credited me. (My name on the disassembly is on line 16.) The new version can be found here:
SMB1. I will remind him about the SMB2J one if he doesn't correct it.
Patch these to an SMB2J ROM with a CRC16 of BA55. --ShaneM,
the Master of ASM
6) The breakable brick above the bottom step is absent.
ShaneM wrote:
1) All the way up at the top the row of 8 coins was originally 2.
To play devil's advocate, the tester could've collected the leftmost ones by bonking the bricks, then circled around the platform...if some bricks didn't exist. I suppose the scenarios EXIST for doing it, but require more convolution than I thought. Nevermind.
Myask wrote:
6) The breakable brick above the bottom step is absent.
ShaneM wrote:
1) All the way up at the top the row of 8 coins was originally 2.
To play devil's advocate, the tester could've collected the leftmost ones by bonking the bricks, then circled around the platform...if some bricks didn't exist. I suppose the scenarios EXIST for doing it, but require more convolution than I thought. Nevermind.
I can prove that that's not the case. Look at the number of coins on the status bar; they tally up to 3, so that is not possible. The possibility exists for up to five coins on the top bricks if they were indeed collected (counting that no other coins were collected earlier in the level). Either way, 8 is an impossibility. --ShaneM
EDIT: And the #6 that you listed is my #4. So that was not necessary.
ShaneM wrote:
4) The 10 Coin Brick to the right of the 4-block stairs is absent.
Yeah, probably just fewer coins.
But I'm talking about the brick to the left of the stairs, not the one to the right. It doesn't look like the stairs moved, comparing scenery and the upper platform. Just those two bricks.
Myask wrote:
Yeah, probably just fewer coins.
But I'm talking about the brick to the left of the stairs, not the one to the right. It doesn't look like the stairs moved, comparing scenery and the upper platform. Just those two bricks.
Ah. I see what you mean, now. Yes, that is indeed #6; good find!
The infinite 1-UP trick is actually not present in the beta build there, since that brick is needed to accomplish it in that part. I truly wonder why it was added to the final to begin with? Big Mario/Luigi can easily break it and little Mario/Luigi can just jump it. I truly believe it was added for that purpose of getting more lives.
Proof of this can be seen as Nintendo themselves mention it on page 84 of the official SMB2J guide. (They make mention of how to accomplish this as well as in other locations; the others being the first part of 1-1 at the beginning of the level with the Red Koopa, 2-1 at the beginning by stomping a Koopa repeatedly on the stairs, the beginning of 2-3 using the Koopa before the fish bridge, 6-1 using the Buzzy Beetle at the beginning of the level and 7-1, 7-2, 8-2 and A-1. Though these last four are just mentioned in the guide but don't state how to perform them.) --ShaneM, the Master of ASM
I've got a new build coming tomorrow. As well as a new beta shot and some other interesting news. Stay tuned. --The Master of ASM
ShaneM wrote:
Now, look at the attached picture below. You'll see the same clip of the beginning of C-1 except for: 1) It seems to take place at day, with a Snowy terrain (the All-Stars version has this level as a Snowy Night one). 2) The level is different with arrangement of blocks and slightly different spacing. 3) The level is assigned as 5-1 rather than C-1. Does this imply that 5-1 was changed at last minute and the original 5-1 was moved to C-1? In intrigues me whether what's now known as 5-1 may have been C-1 at the time and swapped before release or if the current 5-1 didn't exist at the time. 4) As usual, the beta ground tiles are also used.
EDIT: The pipes in the beta screenshot replaces the vertical blocks used in the final level with bricks.
So from this post on page 8 of this thread, I actually found a game guide on Ebay from a Japanese seller which uses this exact same screenshot, but in color! My assumptions were all dead on. (See below.)
After it, you'll see a beta shot of the Game Over menu. Some things to note:
1) It replaces the mushroom used on the final Game Over menu with a big white circle. Not sure if this is just a placeholder or not, but the final uses the mini mushrooms used on various platforms.
2) It is clear from reading the manual that the mushroom from the title screen menu was originally going to be used.
Here is a new build of both SMB1 and SMB2J. It corrects A-3 of SMB2J as well as B-4's Warp area. In addition, I've further fixed wind collisions on both builds. Previously, the player could still go through springs, an oversight on my part. That's now fixed. I've also improved sunset and snow palettes since the last time. Patch these to an SMB2J ROM with a crc16 of BA55. --ShaneM, the Master of ASM
The RCs are out of the way now that I'm ready to release the final versions, real soon. Keep an eye out for them early next week. I've also created a cool new version of SMB2J that will serve as a mini hack, too. So, in all, look out for all three games soon! --ShaneM, the Master of ASM
What's the delay, you ask? Well, I've added back the mushroom platforms! Ripped from ANNSMB and recoded from scratch. I had to optimize code to earn around 20 free bytes to pull this off, but I did it! Honestly, I didn't do it earlier because space was so tight and I optimized all I could (...so I thought). Will be ready soon. I had to basically renumber all BG IDs to make room for the lower stems.
I've also added some more surprises. The wait will well be worth it; trust me. --ShaneM, the Master of ASM
EDIT: Who would like to see eyes on the mushroom platforms?
I think the forced eyes on everything are kinda creepy. The developers of Mischief Makers obviously thought differently.
tepples wrote:
I think the forced eyes on everything are kinda creepy. The developers of Mischief Makers obviously thought differently.
Yeah, I hear you. SMB2J is one of those games that has eyes on everything. I recently gave Podoboo (aka Lava Bubble in later games) eyes.
Thanks for your input, though. I sorta added eyes to it already. Here's a pic with it so that you all can judge if it should stay or not. Also, a pic of Podoboo with eyes, something that has stuck with the franchise since Super Mario World.
I think the eyes are great, can't wait to play it.
Okay. So I'll share another surprise about this upcoming build. I've recreated the SMAS atmosphere of an autumn level with Bullet Bills on 8-2, something not previously possible with the original setup. Only mushroom platforms stages (cloud platforms in SMB2J) could have orange backgrounds and changing with certain level features like tall trees or cannons was not previously possible. I've fixed this and upgraded 8-2. I've hardcoded it so this is only possible with 8-2. Here and some pics. (The SNES version did this by using parallax scrolling.)
SNES map of 8-2:
http://www.mariouniverse.com/images/maps/snes/smb/8-2.pngOriginal NES map:
http://nesmaps.com/maps/SuperMarioBrothers/SuperMarioBrosWorld8-2Map.htmlMy code:
Code:
GetAlternatePalette1:
lda AreaPointer ;;;;;ShaneM code
cmp #$35 ;;;;;;ShaneM code...are we at level 8-2 yet?
beq NewLabel ;;;;;ShaneM code, if so then branch ahead to apply autumn scenery
lda AreaStyle ;check for mushroom level style
cmp #$01
bne NoAltPal
NewLabel:
lda #$0b ;if found, load appropriate palette
SetVRAMAddr_B:
sta VRAM_Buffer_AddrCtrl
NoAltPal:
jmp IncSubtask ;now onto the next task
Please credit me if used; thanks.
Also, the cloud platforms are still found in SMB2J, I've just reverted the clouds in SMB1 to the original SMB1 mushroom platforms in my last couple of posts (though they are based on the All Night Nippon upgraded mushroom ones). --ShaneM, the Master of ASM
I plan on releasing the final versions on Monday, 03/16/15. I did find some bugs during my beta testing. A lot has to do with the third PRG ASM file (World 9); it had to do with a rare disk no. 5 error (wasn't easy to fix). They have all been corrected and I will continue testing until the release date. So far, in my latest playthrough, I've found zero issues and it looks promising. So what I have so far appears to be final. --ShaneM, the Master of ASM
It's finally here. The finals! Here are both SMB1J and SMB2J. Patch them to an SMB2J ROM with a CRC16 of BA55. Also, I promised a surprise. Here are some details about the soon upcoming game:
SMB Special with SMB2J features! (What do you think of the improved title screen?)
I've done a lot with Levi's hack and have fixed all the glitches that he and his team accidentally created. In addition, I've added skid sound and added all my bug fixes from these current games (still pending on finishing some). I will also restore some beta tiles, too. I plan on adding SRAM for saving high scores. This to be released in the near future... Some screenshots:
--ShaneM, the Master of ASM
SMB Special has been called off due to this:
http://forums.nesdev.com/viewtopic.php?f=5&t=12518Unless that symbol stands for something else.
What I will do is either release an SMB1 NES patch with SRAM or share my SRAM code so people can add it to their hacks. It was really easy and took very little space (SMB1 in it's NROM form can have around 300 free bytes or so if you really know what you're doing and how to optimize). --ShaneM, the Master of ASM
There's a v1.1 coming soon. Two things have been corrected in it:
1) I forgot to give Fire Flower eyes (something that the SMAS remakes do).
2) I found a non-gamingbreaking glitch in the SMB1 portion. I'm working on fixing it.
Look out for this new build sometime early next week. --ShaneM, the Master of ASM
Here is the new build. I'm now using Xdelta format, since it's probably better than .ips patches. Now what I've done is put both games on the single game file; SMB1 is on Side A and SMB2J is on Side B. If you need any help figuring out how to swap disk sides within your emulator, just ask. Here are the changes from the last build:
1) Attributed Fire Flower to have eyes according to the SNES SMAS remake.
2) Fixed various end of level stages on SMB1 where the forts/castles at the end were too far from the Flagpole and caused cutoff at the end (such as 6-1 and 8-3) if the player jumped over the flag (since I ripped the scroll stops from ANNSMB, this needed to be fixed).
3) Customized my SMB1's Hard Mode to match my SMB2J one (on Worlds A-D) where the Firebars all move faster.
4) Fixed 4-3 on SMB1's Hard Mode where the player couldn't previously attain 5000 pts. due to the fact that platforms are shorter in my version on Hard Mode (the original never suffered that issue since its hard mode isn't as advanced as mine). I basically did minor swapping in PRG ROM to accomplish this.
Patch it to an SMB2J headerless ROM with a CRC16 of BA55
Enjoy v1.1. --ShaneM, the Master of ASM
Someone has emailed me asking about how Xdelta is supposed to be patched. The executable tool that I recommend is
deltapatcher. I've used this tool to create my Xdelta patch; it can also be used to patch existing Xdelta patches, too.
How to switch disk sides on Nestopia (for the purpose of playing the fixed version of SMB2J on Side B): To switch disk sides, go to
Machine,
External,
Disk System,
Insert, then select
Disk 1 Side B. Now, what you want to do is go to
Machine,
Reset,
Hard.
The same can be applied for playing SMB1 on Side A afterwards.
I'll be releasing a full package release of this game and a special build of Nestopia, soon. So newbies will have (almost) everything they need, including a translated, colored game manual I wrote and a guide to Nestopia and much more.
Hash checksums of the true FDS bios image (8kb):
Filename: [BIOS] Nintendo Famicom Disk System.bin
CRC16: CD1E
CRC32: 5E607DCF
SHA1 (non-base32): 57FE1BDEE955BB48D357E463CCBF129496930B62
My checksum utility for checking a variety of checksums is called
CHK Checksum Utility. --ShaneM, the Master of ASM
The checksum utility doesn't support CRC16 anymore! What now?
8bitMicroGuy wrote:
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.
Quote:
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.
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.
8bitMicroGuy wrote:
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 wrote:
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
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.
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
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
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.
tepples wrote:
It looks like polluted water to me, but that's equally useful.
Espozo wrote:
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
I'm uploading images of both the original FDS and SNES versions so that people can compare them. --ShaneM, the Master of ASM
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:
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
Can you add this fix:
May need more adjustments for your hack
Code:
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!
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.)
I redid the snowy palette as I sort of disliked my original light blue. Here is the wind again compared to the original. --ShaneM, the Master of ASM
Some have suggested the lava was too dark. I've corrected this. --ShaneM, the Master of ASM
tepples wrote:
It looks like polluted water to me, but that's equally useful.
Espozo wrote:
Looks like blood to me. Lava produces its own light, so even if it were in a dark place, it would still be bright.
Maybe it's the blood of all those poor Koopas I made Mario stomp as a kid? Come to think of it, didn't Mario throw flames? Damn, maybe Bowser was not the only villain! (LOL, :facepalm:)
tepples has informed me of a Nintendo-original glitch that I recently fixed. My code and the topic can be found,
here. Here are some shots with it fixed in my game. This will be available in my next release build v1.2 come this mid-May. --ShaneM, the Master of ASM
alphamule wrote:
tepples wrote:
It looks like polluted water to me, but that's equally useful.
Espozo wrote:
Looks like blood to me. Lava produces its own light, so even if it were in a dark place, it would still be bright.
Maybe it's the blood of all those poor Koopas I made Mario stomp as a kid? Come to think of it, didn't Mario throw flames? Damn, maybe Bowser was not the only villain! (LOL, :facepalm:)
Maybe it's from all the Marios dying while the developers were making the game.
The PitAttachment:
mariodeaths.jpg [ 270.24 KiB | Viewed 14831 times ]
LocalH wrote:
The PitAttachment:
mariodeaths.jpg
Scary! Many Zombie Marios! So many deformations!
I added a couple more original bug fixes that I found throughout the web. In addition, I've added new features to the SMB1 portion. I will release this on the anniversary I started this on, August 23rd, 2015. Changes will be noted with the release; that is all. --ShaneM, the Master of ASM
I redrew Bowser in a way that gave him hair. Something that the original crew wanted to do as seen in promo art but were unable to due to CHR RAM limitations. I also gave him an eyebrow. Expect this in next week's build.
Original art:
Mine:
I know release for a new build was due a week and a half ago but my job is hard and I will release it as soon as I'm not so tired to type properly. For now, I found a way to add onto this project. I've recreated ANNSMB from my SMB1J assembly files (which is a hack using my SMB2J assembly files). I will release it really soon. I will release the ANNSMB for Halloween as a surprise! Maybe I'll add an Xmas version too, like on the NES Remix for Wii U? Who knows. But here are some shots. So far, I've recreated all the ANNSMB levels using my assembly files; this version contains every single bugfix, just as my other Mario games. There are some changes from the original ANNSMB:
*All stages are now night
*Wind is present
*Poison Mushrooms
*Negative warps
*A downgrade of the SNES special SMW Bullet Bill (see photo) new sprite
*World A-D was replaced with 9 (which the original ANNSMB lacked in)
*No room for the palette swapping routine so Goro Itoi is used on all castles.
*Created custom code for when the game is beaten 8 times for a surprise
*More additions until October?
Here are some shots. I gave myself 8 stars to show off the moon sprite I created to replace the stars when the game is beaten, to give it its own theme. I also assigned the Fuji TV icon to the title screen, so the language of the title is "universally" a symbol. --ShaneM, the ASM man
I still don't know when I will release the final version of this, but soon. I've done a lot of creative things with both games so far, here are some more original glitches I found and fixed:
1.
Goomba Glitch2.
Double Death #13.
Double Death #2 - I couldn't find a video of this one, but the site describes it very well.
On SMB1 I decided to do a little more with (because I had the opportunity to). I remade the tiles of SMB1's Ghost House from Mario Maker and made use of them in my tile swapping routine.
I've utilized tiles from all the remakes and ports of SMB1 (since I used level designs from ANNSMB, VS SMB and SMB Special on these games).
The pixelated bushes from SMB Special have been used in place of the beta cactus; the VS SMB ground tile has been used in the place of the beta ground tile.
On SMBTLL on Side B, the beta tiles are still there and used.
In addition, I've used the special 25th anniversary tiles on SMB1 from the special Japanese Wii red bundle.
The most amazing thing this far are the SMB1 Ghost Tiles which I think I'm the first one to make for the NES.
Here are some shots:
If you read my post from earlier today, you should see that I've made some tile additions to the SMB1 portion. But I cannot decide on this and want some opinions: should I leave the water tile alone I ripped from VS SMB or should I use this new one I remade which is from the wintry stage of SMB1 in NES Remix?
EDIT:
video
Is your gamma just out of wack, or are your palettes all extremely dark?
annuvin wrote:
where is the IPS
If I see ShaneM hanging around in IRC, I'll try to remember to remind him to upload it.
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.
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.
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.
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 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
I'm seeing no reason for this apparently dead project to remain sticky.