Going back to the spirit of the original thread...
A while ago I disassembled a chunk of code from Dragon Warrior 3. The code is responsible for checking which tiles are underneath the four allies, testing if the tile number is flagged as a swamp or barrier tile, and calling the routine to deal damage to the player. Normally it works fine, but it is possible to get this code to fail in a spectacular way. This happens to be a huge memory corruption bug targeted at the area around your stats.

The way it works is that it iterates over each party member, looks at the tile under the player (which happens to be nicely stored somewhere), and tests if that tile number has the relevant tile-flags set. Because there may be a dead party member, and dead party members go to the back of the walking formation, it keeps a small table to see who's still alive. For example, if the second party member was dead, and the other 3 were alive, the table would contain [0,2,3]. The game also keeps track of the number of living party members, and uses that number to terminate the loop, so it wouldn't check a fourth member if there were only 3 living members.

The code is structured pretty much like this:

i=0;

do

{

  t = tile_under_player[ i ]

  p = living_player[ i ]

  if t is a swamp tile, do 2 damage to player #p

  if t is a barrier tile, do 15 damage to player #p

  i++

} while (i != living_members)

There's an item in DW3 called the Dream Ruby. Normally you just collect it, then take it to the elf queen, and get the Wake-up Powder. But if you use the Dream Ruby as an item, it paralyzes the character who uses it. This paralysis is slightly bugged: It doesn't check if the entire party is paralyzed or dead after you use it. Then there are situations in the game where a member of your party must split from the rest, especially the "fortune telling" house in Assaram. Usually the lead character of the party splits from the group, leaving the allies behind. But if the lead party member is paralyzed or dead, the next character splits ahead instead. Now the kicker: if the lead party member is dead, and the rest of the party is either dead or paralyzed, you will control the leading dead party separate from the other allies.

So now we have a party of one dead member. Here's the swamp-tile-checking routine's fatal flaw: It increments the character number, then tests if it EQUALS the number of living party members or not. So we have character #1, and there are 0 living party members. Now we have a loop overflowing past the limit, until it repeats 256 times. Suddenly, it's reading way out of bounds for the tile_under_player table and living_party table. Now it reads some random bytes from the zero page and interprets them as tiles underneath the player, then picks another random value from the zero page as the player to deal damage to.

So what happens when it deals 2 damage to a player number out of bounds? The players stats are stored in an interleaved-like format. Player 1's HP is followed by Player 2's HP, then Player 3's HP and so-on. When it deals 2 damage to a player number greater than 3, it will modify some other stat. For example it will decrease a player's MAX HP by 2, or maybe their strength, or even their Name or Inventory contents. If the 16-bit value at the random address goes down to zero, it is set to a minimum of zero, and a message is displayed indicating that the player has died.

Now, it will do this many many times each step you take. It's looking through the entire zero page for any numbers which happen to be a swamp tile number after ANDing with $1F. Then it's taking a corresponding byte as a character number, and decreasing some random stat by 2. Then it's going to display that a character has died about 10 times each step you take.

All because the programmer never bothered to properly use a less than operator instead of a not equals operator (BVC vs BNE instruction).

I made a video demonstrating the bug on Youtube. http://www.youtube.com/watch?v=38bEtt6Bxv8
The video shows some item being replaced with the Final Key. Also the max HP of some character goes down to zero.

____________________