racketboy.com

https://techcrunch.com/2019/01/03/zelda ... nus-world/

You never know what is lurking beneath!

Wow not a reply about this?! I'm mind blown I guess. I see how it would make a whole lot of sense in such a limited amount of space, and I did know the dungeons were in a master file that kind of interlocked like puzzle pieces. I just didn't know you could get into a -1 minus world like situation. Doesn't seem as cut and dry where anyone can glitch themselves into it like on SMB but still pretty nice.

I doubt I'll bother with it though, time and all, but given I had it I'd love to explore.

Whoa, this is crazy.

Awesome! Is there a tutorial explaining how to glitch into this monus world?

From what I understand (very little), it's actually reading data for other things in the game.
Found this guys comment interesting/informative, if a bit negative:

I wonders what the 2nd quest-minus looks like, or if much the same.

nightrnr wrote:Found this guys comment interesting/informative, if a bit negative:

SoheiFox
They were using that space to hold other code. This is not a "minus world" or "easter egg" it's just you expanding the rom past it's actual file size by adding a subroutine to incorrectly look at random data fed into the map interpreter. This is not a "secret area" this is just a "hacker" misunderstanding how scumming lines of code and using tricks to make amazing things within small limits works. He can point that idiot code at anything, at any place in the ROM and come up with more "secret areas."

There are no secret areas, it's just demonstrating how the map rendering engine works.

Edit: and let's make this EXTREMELY clear... people who made map editors for Legend of Zelda not only figured this out, but they also figured out how to generate cohesive maps rather than random garbage. You people celebrating something that real hackers had achieved, and gone far beyond, almost twenty years ago

Oh, this is very interesting, and makes much more sense to me. Basically what he's saying is that the minus world is nothing, and therefore, asking what the minus world of the 2nd quest is, is asking the wrong question. So, there would be a subroutine in the program code that loads map tile and other sprite data positions as its inputs, and generates the map screen out of those inputs, which should be placed in specific layouts for specific grids on the map (I assume, as I don't know what they used for an exact algorithm). That comment is describing this as changing the inputs to the map generation subroutine ('subprocess,' if you prefer) from those known/intended tile constructions to some "random" (or garbage) inputs. The input positions would then be essentially random, and not remotely intended. In all likelihood, the input is a pointer, and the glitch is forcing that pointer into data, or ram locations that it shouldn't be accessing, and using that disassociated data as positioning values instead.

Hopefully that makes some sense. There isn't really enough detail for me to say definitively that this is what's happening, but that response just triggered a bit of my general embedded systems knowledge.

Yeah; old games were pretty good about interpreting garbage data as maps. The "hidden worlds" of the original Metroid are well documented examples of this. There's a speedrun of Super Mario Land 2 which ends up loading the game's RAM as level data, and you then maneuver through it to flip a flag in the RAM to make the game think you won.

MrPopo wrote:There's a speedrun of Super Mario Land 2 which ends up loading the game's RAM as level data, and you then maneuver through it to flip a flag in the RAM to make the game think you won.

Oh, I kind of remember seeing that at a GDQ. Was that a TASbot run?

It was at a GDQ, but it wasn't TASbot; it was a runner doing it live. So he had to do it twice, because the first time he screwed up the RAM manipulation.