Fushigi no Dungeon: Fuurai no Shiren GB: Tsukikage Mura no Kaibutsu, translated as Mystery Dungeon: Shiren the Wanderer: The Monsters of Moonlight Village, is a roguelike game developed by Aquamarine and published by Chunsoft, apparently released back in 11/22/1996. The game follows Shiren the Wanderer, and his talking weasel Koppa. The game has also gotten some ports/re-releases on Windows and Android. And there really isn't anything I can say past that, the game was only released in Japan, and there's really not much info about this game. The RTA leaderboards don't even have any runs on the Gameboy version. Luckily, this game is buggy so it won't matter for me.

The run is fairly short, so there isn't too much to comment on. The key exploit used is simply the L/R|U/D glitch. Essentially, the game doesn't handle L/R and U/D inputs correctly; often they will freeze the game, but sometimes they will cause ACE. This movie specifically uses the combination L/R/D to cause ACE at EDF0 (echo RAM for CDF0). I use my player name to store most of the payload, however, I simply don't have any bytes that can cause any jumps. That's where luck manipulation comes into play. The game stores 4 bytes for RNG at D601-D604. The game uses rTIMA (somewhat similar to rDIV, but much more restrictive for manipulation) for seeding the RNG, and uses a fairly complicated LFSR to cycle through RNG. I only need 1 byte from this RNG though, so it isn't too hard to manipulate what I need.

I need to create a save file to really do anything, which can be quickly done. It also needs to be the 3rd save file, the 1st one won't work. I hard reset once the save file is actually made. As a note, the game doesn't seem to have any soft reset, and going back through the main menu without resetting is much slower, and will simply not work for my purposes anyways (due to the game splashing FFs in a huge chunk of RAM I need to slide past). As a note, this reset is why I need to use the 3rd save file, as the game will load the 3rd save file's data by default, and will only load the other save files if they actually go into the game (which I don't want to do).

After the reset, I manipulate for an E9 (jp hl) byte to appear at D601. I don't particularly care how good the manip is though, you'll see why later. I then proceed to re-name myself, which will write the following code into memory:

ld hl,7C17 ; credits location
ld (bc),a ; bc = 2800

Afterwards, I need to flash the rename screen again. This will clear out a troublesome buffer of my name, leaving in some $88 bytes. I then just have to wait for a counter at CE0D to go down to $AA, which is a xor d opcode. This counter is why it doesn't particularly matter how long it takes to manipulate the E9 byte, as I will need to wait a bit before this counter will reach this value. This will make it so when the game executes the ld (bc),a in my name, a will equal $7C, which will allow for a bankswitch to the credits' bank. Once the counter reaches that value, I can press L/R/D, and that's all the input I need to do, as the ending goes on without any inputs.

Credits to ThunderAxe31 for telling me about this ACE exploit and helping in finding the credits.

ThunderAxe31: Judging.

ThunderAxe31: All right, I confirm that this is a game end glitch, as I can see from looking at the trace log. No cheats or debug codes are involved. Also, the game is considered properly beaten, as the credits sequence is performed in its entirety, including the fact that it's cleared when you press A button after the end. Then, the game freezes, probably because the credits routine was called from the menu instead than after beating the last dungeon, but this isn't an issue, as what it matters is the execution of the credits routine itself, not what happens after.

The movie itself is very short and lacks visible action, so I understand why the reception was mixed and little. As such, accepting for the Vault.

fsvgm777: Processing. Zinfidel is handling the encodes for this one. We have a new publisher in our ranks!

Zinfidel: Processing...