Language…
10 users online: Batata Douce, DanMario24YT, dotCoockie, dubiousdinobot, Dzing, Edu X, Hammerer,  Saphros, StarWolf3000, TheOrangeToad - Guests: 269 - Bots: 302
Users: 64,795 (2,378 active)
Latest user: mathew

Yoshifanatic's ASM Showoff: Part 12 (Day 4)

ToolPatchSuper Mario WorldYoshi's IslandMisc. HackingDemoResource ReleaseVideo/TrailerScreenshots

Fanatical like a Demon
The Jurassic Park randomizer looks sick. The palettes in the vid remind me of some nightmare mod from Resident Evil 5 were they made all the colors similar in darker shades and red skies. The Mario smooth turnaround patch is awesome! Are there any bugs to it? Cutscene wise (vanilla and your patch) or anywhere else? I may use this in my SMW 30 hack though I don't want it to mess with the sma2 cutscenes since the turn rounds Mario and Luigi do when they see Peach is missing make more sense as is since it looks like they're worried/freaking out (plus Luigi would still have sharp turns since he's simply animated).
Major thanks to Suika Ibuki for layout!
I'm open for music requests, just DM me on discord and we can further discuss there.
SMAS Soundtrack Status: 100% finished
YI Soundtrack Status: 100%
YI Unsampled Soundtrack Status: 100%
NSMB Soundtrack Status: 7.89%
Killer Instinct Soundtrack Status: 14.63%
SPC Thread
From our family to you, keep your pants dry, your dreams wet, and remember, hugs not drugs.
at risk of sounding illiterate, does that turnaround patch work w/ 32x32 / sa-1 innately? it looks very funny and good
Originally posted by yoshifanatic
This game uses a trick for the exterior areas where instead of updating the tilemap as you scroll, it updates the graphics like it was a tilemap. This is to allow the game to have a much wider variety of tiles to use for the exterior areas with no restrictions on where the tiles could be used. It did come at the cost of ROM space and V-Blank time however, in case any of you want to try this for a SMW hack.

That's pretty cool, though aside from the fact that there are more things to upload, how does it handle the palette? After all, 16 colours are limited. I also wonder how the outside sections are stored in the ROM.


Despite being quite interesting, the first two are quite familiar to me.
Though there still are some quirks with the HDMA polygons which are probably worth to point out, namely the spinning platforms (those with a vertical pivot) theoretically allow you to place them onto different X positions but due to the limitation of HDMA (which is also used for the horizontal position), it is possible for the platforms to appear at an incorrect position.
I can also understand that the island is rendered dynamically and not with different sprites with fixed graphics considering there would be too many object per scanline.

Originally posted by yoshifanatic
The running Yoshi on the map screen is initialized wrong. The game uses "LDA.w $0000" rather than "LDA.b #$00", which results in it using the value from RAM address $00 rather than a constant. $00 was last written to at $00BA7A with the low byte of a pointer to $5FA000. If that pointer is moved, then this bug becomes noticeable.


Originally posted by yoshifanatic
The running Yoshi on the map screen is initialized wrong. The game uses "LDA.w $0000" rather than "LDA.b #$00", which results in it using the value from RAM address $00 rather than a constant. $00 was last written to at $00BA7A with the low byte of a pointer to $5FA000. If that pointer is moved, then this bug becomes noticeable.

What does that exactly mean?


Originally posted by yoshifanatic
Turns out, I don't blame the developers for not implementing a save feature, because this game has a lot of stuff to save. The SRAM needs to be 64 KB minimum for just 1 save file and 128 KB to have the standard 3 save files. Why? Because this game keeps track of the state of every single sprite that's located outdoors. In order to put the game into the same state between play sessions, I had to save every single one of those exterior sprite RAM addresses. Interior sprites are not kept track of anywhere close to as extensively by comparison.

Wow, just wow... It's even moreso when you consider that RAM was quite expensive back in the day (especially SRAM). That's still some very cool, though.
Now my eyes can handle SMA2's cutscenes
Originally posted by LadiesMan217
The Jurassic Park randomizer looks sick. The palettes in the vid remind me of some nightmare mod from Resident Evil 5 were they made all the colors similar in darker shades and red skies. The Mario smooth turnaround patch is awesome! Are there any bugs to it? Cutscene wise (vanilla and your patch) or anywhere else? I may use this in my SMW 30 hack though I don't want it to mess with the sma2 cutscenes since the turn rounds Mario and Luigi do when they see Peach is missing make more sense as is since it looks like they're worried/freaking out (plus Luigi would still have sharp turns since he's simply animated).


Yeah, that's one of the custom palettes that can be chosen. I called it "Moody". Other ones include "Bizarre", "Monochrome", "Winter", and more.

As for the turn around patch, I don't think there are any bugs, and I doubt it would have a negative effect on the cutscenes (that scene with Mario turning around repeatedly wouldn't be affected, because this patch hijacks the code for when the player turns around using the d-pad. That scene writes to $76 directly to turn Mario around, so this patch would have no effect).

Originally posted by idol
at risk of sounding illiterate, does that turnaround patch work w/ 32x32 / sa-1 innately? it looks very funny and good


If Mario's turning looks fine while holding an item with that patch applied, then it will look fine with this patch applied. I also added the SA-1 defines so it should work with the SA-1 patch.

Originally posted by MarioFanGamer
That's pretty cool, though aside from the fact that there are more things to upload, how does it handle the palette? After all, 16 colours are limited. I also wonder how the outside sections are stored in the ROM.


The game still updates the property bytes of the layer 1 tilemap so it has access to more than 16 colors for everything. The devs saved V-Blank time by not updating layer 2 at all, as it's just a 32x32 tilemap containing a repeating grass pattern.

Originally posted by MarioFanGamer
Despite being quite interesting, the first two are quite familiar to me.
Though there still are some quirks with the HDMA polygons which are probably worth to point out, namely the spinning platforms (those with a vertical pivot) theoretically allow you to place them onto different X positions but due to the limitation of HDMA (which is also used for the horizontal position), it is possible for the platforms to appear at an incorrect position.
I can also understand that the island is rendered dynamically and not with different sprites with fixed graphics considering there would be too many object per scanline.


Regarding the former, I figured there would be limitations like that with these HDMA polygons.

As for the latter, I was surprised it wasn't just sprites when I saw it, since it really does look like Nintendo just rotated around a bunch of sprites (perhaps with some clever handling to avoid potential sprite overdraw by culling out sprites that can't be seen).

Originally posted by MarioFanGamer
What does that exactly mean?


The short answer is that I found a bug resulting from a typo that causes the game to use a pointer's low byte to initialize something unrelated.

The long answer: You know how when you move the cursor on a level, the Yoshi that will play that level does an animation where it runs while carrying baby Mario? That RAM address that controls that is initialized wrong. The instruction used is supposed to use a constant, but it instead reads from RAM address $00. The last place $00 was stored was at $00BA7A, where $00 contains the low byte of a pointer to some data at $5FA000. By sheer chance, $00 contains #$00 so nothing appears wrong in game. But, when I scrambled the ROM around to make the disassembly edit friendly, that pointer to $5FA000 was changed, so $00 would contain a different value. This caused the bug to now be visible. Here is an image I took demonstrating this, where I replaced the instruction at $17A6A3 with LDA.b #$13 : NOP to simulate it:


Notice how green Yoshi is both running and holding the level 1 sign? That's the bug. This happens if you exit out of an extra/bonus level.

Originally posted by MarioFanGamer
Wow, just wow... It's even moreso when you consider that RAM was quite expensive back in the day (especially SRAM). That's still some very cool, though.


Yeah. There is a noticeable delay when erasing a file because of the sheer size of the data (and also because I opted to save ROM space over speed with the implementation). Saving doesn't cause a delay due to how this game's main loop works, but it does sometimes cause Grant to blink out of existence for a frame for some reason.
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Once again it's neat to see all your disassemblies, including the Ms. Pac-Man SNES port which I actually grew up with. the Jurassic Park randomizer and SimCity hack are very neat as well!
SMRPG event scripts are, frankly, ridiculous and I don't blame anyone for not wanting to muck with them.

A couple years ago, I started on a disassembler for those, saw I needed to write an animation script disassembler because of the inline animation, noped out and wrote a battle script disassembler instead. Was definitely useful for cleaning up some of how the SMRPG Randomizer handled changing battle scripts.

Plus, I got to write these lines of code:

Code
if name == 'if_item':
    # Good luck using that in battle
    self.script[i ] = ('if_item', [items.BrightCard])


Anyway, pidgezero_one took a design I had for an event disassembler and ran with it. That code is probably as close to "good" documentation as you're likely to find.
Originally posted by DeppySlide
Once again it's neat to see all your disassemblies, including the Ms. Pac-Man SNES port which I actually grew up with. the Jurassic Park randomizer and SimCity hack are very neat as well!


That's pretty neat you also had this Ms. Pac-Man port! I don't have a lot to say about it, but the disassembly went very smoothly. Most of the time I spent on the disassembly within those 11 hours were spent on just creating the extraction script and setting up ROM tables. My disassembly script practically gave me the cleaned up code from the get go. XD

Regarding the JP Randomizer, this was the first time I've ever done something like this. It's was definitely an interesting experience, particularly when I wrote the logic for the V1.1 Beta.

As for the SimCity hack, it was neat trying to find ways to speed it up. Given how this game was among the first SNES games, I have a feeling it helped contribute to the stigma that the SNES has a slow CPU. While that is true to an extent, a big part of it was definitely bad programming in some of those early games. To give an idea of how bad SimCity was in that department, it says something that code like this:

Code
CODE_01F8E9:
	SEP.b #$20
	REP.b #$10
	LDA.w $0451
	PHA
	LDA.b $B3
	AND.b #$7F
	STA.b $B1
	PLA
	STA.l !REGISTER_Multiplicand
	LDA.b #$78
	STA.l !REGISTER_Multiplier
	PHA
	PLA
	NOP
	LDA.l !REGISTER_ProductOrRemainderHi
	XBA
	LDA.l !REGISTER_ProductOrRemainderLo
	PHA
	LDA.b $B3
	STA.b $B1
	PLA
	REP.b #$20
	CLC
	ADC.w $044F
	ASL
	TAX
	LDA.l !RAM_SIMC_City_MapDataBuffer,x
	AND.w #$03FF
	RTS


...could be shrunk down to this:

Code
CODE_01F8E9:
	SEP.b #$20
	REP.b #$10
	LDA.w $0451
	STA.w !REGISTER_Multiplicand
	LDA.b #$78
	STA.w !REGISTER_Multiplier
	PHA
	PLA
	NOP
	REP.b #$21
	LDA.w !REGISTER_ProductOrRemainderLo
	ADC.w $044F
	ASL
	TAX
	LDA.l !RAM_SIMC_City_MapDataBuffer,x
	AND.w #$03FF
	RTS


...And when code like this can be expected to be run through thousands of times in a loop as is the case with the procedural generation.... yeah, it's not going to be pretty. XD The real WTF in this example was the attempt at making it interrupt safe ($B1/$B3 are a mirror for $4200), but the devs didn't use multiplication in the interrupt routines so this was pointless to do.

Originally posted by patcdr
SMRPG event scripts are, frankly, ridiculous and I don't blame anyone for not wanting to muck with them.

A couple years ago, I started on a disassembler for those, saw I needed to write an animation script disassembler because of the inline animation, noped out and wrote a battle script disassembler instead. Was definitely useful for cleaning up some of how the SMRPG Randomizer handled changing battle scripts.

Plus, I got to write these lines of code:

Code
if name == 'if_item':
    # Good luck using that in battle
    self.script[i ] = ('if_item', [items.BrightCard])


Anyway, pidgezero_one took a design I had for an event disassembler and ran with it. That code is probably as close to "good" documentation as you're likely to find.


It's nice knowing I'm not alone in thinking that about the scripts. SMRPG is definitely the most advanced game I've disassembled aside from EarthBound (which I haven't finished disassembling). Frankly, it's a miracle that I even had the patience to get the disassembly in the state it's currently in, especially as this was the next disassembly I started after I lost patience from the sheer tediousness of making my Yoshi's Island disassembly.

Either way, I'll bookmark that GitHub page in case I come back to SMRPG. Thanks!
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

ToolPatchSuper Mario WorldYoshi's IslandMisc. HackingDemoResource ReleaseVideo/TrailerScreenshots