Worked out why most emulators can't play Densha de Go. There's an error in the game itself!
On console, when you read ROM using the PI, it can't just read a single byte of data. Instead, it will read something like 16 of them. That's why they always pad memory and copy from an offset and such. You have to. Anyway, the number of bytes is actual, counting 0; to read in 0x400 bytes you'd send 0x3FF.
Densha de Go, however, has a slight error. In its ROM grabbing routine it subtracts 1 from the length value. However, everything that uses the routine sends the ordinary values. So, when you send 0x3FF and it subtracts 1 you get 0x3FE. On console this wouldn't be an issue since it pulls a full 0x400 either way, grabbing up to the quadword. Emulators though will read in 0x3FE, final byte usually 0 due to them being nice and initializing data beforehand. Let that hit a decompressor and your data goes splort all over the wall.
Images extracted from decompressed files aren't gibberish like those extracted at runtime from Nemu, and I've already confirmed the bug extends to the decompression routine retrieving only 0x3FE segments. The file at 0x1502B90 decompresses without error until refill; byte 0x7FF remains set to 00, and when used as a command byte fouls up decompression. The resultant file is much larger than declared. All it would take is one corrupted pointer to lock the game.
-Zoinkity
On console, when you read ROM using the PI, it can't just read a single byte of data. Instead, it will read something like 16 of them. That's why they always pad memory and copy from an offset and such. You have to. Anyway, the number of bytes is actual, counting 0; to read in 0x400 bytes you'd send 0x3FF.
Densha de Go, however, has a slight error. In its ROM grabbing routine it subtracts 1 from the length value. However, everything that uses the routine sends the ordinary values. So, when you send 0x3FF and it subtracts 1 you get 0x3FE. On console this wouldn't be an issue since it pulls a full 0x400 either way, grabbing up to the quadword. Emulators though will read in 0x3FE, final byte usually 0 due to them being nice and initializing data beforehand. Let that hit a decompressor and your data goes splort all over the wall.
Images extracted from decompressed files aren't gibberish like those extracted at runtime from Nemu, and I've already confirmed the bug extends to the decompression routine retrieving only 0x3FE segments. The file at 0x1502B90 decompresses without error until refill; byte 0x7FF remains set to 00, and when used as a command byte fouls up decompression. The resultant file is much larger than declared. All it would take is one corrupted pointer to lock the game.
-Zoinkity