Crazy Lightnode SRM strat for Title File on Wii VC

This is a slightly faster method to load the title (debug) file on JP-region Wiis. The effect in the video doesn't look much different from existing methods, but some really crazy stuff is going on behind the scenes.
First of all the "setup":
Use filename 80834D7C 90024550 (ラレづモョ2ごば)
Do a standard heap manip for 1.2 lightnode and a standard angle setup for ACA0
Drop hands and cross the loading plane three times to do the lightnode RAM write and load the withered deku babas. The deku babas will trigger a load of the title file while they're loaded.
Do not load any more withered deku babas for the rest of the run (unless you save and reset the game first), attempting to do so will crash.
And now, how it works:
N64 ram is located in Wii RAM at Wii address 80E74000-81274000. So when the Wii emulates N64 code that tries to write to N64 address X, the Wii actually writes to Wii address X+E74000. No bounds checking is done here, which means that theoretically you can write to anything in Wii memory, not just N64 ram.
The lightnode SRM filename given here tries to write to N64 address 90024554. Writing there on a real N64 would crash or do nothing, but on the wii, it writes to Wii address 90024554+E74000 = 90E98554. And this is actually in where the N64 rom is stored in memory. So what this ram write actually does is modify the withered deku baba overlay, in ROM, so that their update function pointer has a value of our choosing. And we choose it to be the "load debug file" function.
Note that there are several difficulties involved in making rom edits in this way:
Only certain regions of the ROM are actually possible to reach using characters that can be typed in the filename - pastebin.com/j...
The rom data is compressed, so editing it to have useful results after decompression can be difficult. Fortunately the withered baba's update function pointer appears plainly in the compressed data, and so can be edited directly.
The new function pointer that we write is NOT actually used directly. When the overlay gets loaded from rom into ram, it gets "relocated", which roughly means that a certain amount gets added/subtracted from it, depending on where the overlay actually loads (so, depending on the heap manip). The pointer we write only ends up pointing at the title file function with this particular heap manip, any other heap and it will just point so some random garbage location. This is why you can't load any more withered babas later on without the game crashing.
Finally, there is one important/funny disclaimer to this SRM as a whole, which is that it ONLY works on Japanese region Wiis - it will not work if you use homebrew to run the Japanese WAD without actually changing your Wii's region.
The reason for this is the "you will need the classic controller" disclaimer screen at game boot. On a JP Wii, it will load a japanese font and appear as normal japanese text ( i.imgur.com/nL... ). For other regions, it will load a western font and display the glitched text ƒNƒ‰ƒVƒbƒNƒRƒ"ƒgƒ [ƒ‰.ª•K-v,Å,· B instead ( i.imgur.com/54... ). The size of these two fonts is different, and as a result the distance between the N64 RAM and ROM in memory will be different depending on which of the fonts is loaded. So if you want to use this SRM on what was originally a non-japanese wii, you need to use different homebrew that actually changes the Wii region.

[@quaternaryyy]

Time to install the Homebrew Channel via wii vc glitching 🐢

[@InfoManiac742]

I read this as "Wii U VC" for a second and almost had a heart attack

[@renakunisaki]

Next: using SRM to fix VC crashes

[@TheLastScoot]

Holy shit, this deserves that title.

[@catgirlsonja]

i already have a JP wii so might try it out

[@Patashu]

This is really cool lmao

[@thehockeymontages4338]

ELITE

[@dragonwizerd]

If it weren't already way easier in other ways, would OoT ACE be a viable vector to get total control of the wii hardware?

[@MrCheeze]

yes

[@dragonwizerd]

@@MrCheeze fuckin POG