And it does not cause an error, despite being written back when bytes mattered. Hats off, anonymous Nintendo programmer, you are the modern equivalent of medieval artists who painted parts in cathedrals which would be occluded by planned construction "because God would see if they were unpainted."
I'm not sure whether that kind of being error-proof was actually intended. The point is that the data structure of the level was so simple that basically any memory location could be interpreted as level data.
There's another glitch with the warp pipes that you can enter before the location they point to has been completely loaded at which time you basically warp to a more or less random memory address leading to this:
In that case though, if you are not really careful, you can actually quite easily crash an emulator which highly likely also would cause the NES to crash.
Dunno about that. I have played the "Minus World" since 1990 when I found out how to do it from my friend. I try it on tons of emulators too, and they all seem to handle it pretty well. I don't recall crashing an emulator with it, and I've never crashed the NES. (Of course it does just get stuck in a big endless loop since the level never advances when you get to the end, but it's a cool trick to do nonetheless).
There is an awesome disassembly of the code available: http://www.romhacking.net/docs/344/ . Almost every line is commented, so it's possible to follow along without knowing too much 6502.
I took a very quick look at it. If you search for 'L_GroundArea1', you'll find the level data for area 3-3. Notice the end-of-data marker is $fd. I then searched for this value, and found the 'ProcessAreaData' subroutine compares against it. By the look of it, this routine decodes new level tiles, except if $fd is found, in which case it just leaves the current tile in the buffer.
This all looks like child's play now, but 30 years ago this was cutting edge engineering. These arcade board sets generated pretty great games for the era without framebuffers (RAM was hellishly expensive), high-speed CPUs, or a lot of other conveniences we take for granted today.
It's not always vast emptiness beyond the flagpole. In level A-3 of Super Mario Bros. "Lost Levels", there is a strategically placed spring board and red koopa that you can use to jump over the flagpole and warp to world C.
11 comments
[ 4.4 ms ] story [ 30.4 ms ] threadThere's another glitch with the warp pipes that you can enter before the location they point to has been completely loaded at which time you basically warp to a more or less random memory address leading to this:
http://tasvideos.org/1365M.html
In that case though, if you are not really careful, you can actually quite easily crash an emulator which highly likely also would cause the NES to crash.
I took a very quick look at it. If you search for 'L_GroundArea1', you'll find the level data for area 3-3. Notice the end-of-data marker is $fd. I then searched for this value, and found the 'ProcessAreaData' subroutine compares against it. By the look of it, this routine decodes new level tiles, except if $fd is found, in which case it just leaves the current tile in the buffer.
http://www.donhodges.com/archive.htm
This all looks like child's play now, but 30 years ago this was cutting edge engineering. These arcade board sets generated pretty great games for the era without framebuffers (RAM was hellishly expensive), high-speed CPUs, or a lot of other conveniences we take for granted today.
http://www.youtube.com/watch?v=xYkucsrbF8w