Ice Climber in my Emulator wants to write to CHR ROM?

Hello,

So I have been making some progress with my emulator and managed to have visual output with my PPU. Donkey kong main screen renders fine. Tests are also able to print to the screen fine.
So another game I tried to render the main screen of was Ice Climber. The text renders fine, but the big "Ice Climber" panel in the main menu doesn't render. But I dunno if it has anything to do with my actual question.

Because my question is, am I correct Ice Climber attempts to WRITE to CHR ROM. Because that is what my Emulator reports(I made it give me an error if a rom attempts to write to ppu address < 0x2000)
Or did I maybe forget to implement something important?(like an offset mechanism or something) If so, any pointers to what?

Thanks!

Is the game by any chance trying to fetch the data for this part from CHR-ROM, like SMB does for its title screen? Some of these old games with limited PRG-ROM space use part of the CHR-ROM space for storing data, which needs to be read through the PPU's data port, which has a 1-byte delay for reads. If you don't implement his delay, the wrong data will be read. When $2007 is read, the byte in the buffer is returned, and a new byte is copied from the current VRAM/ROM address into the buffer (this is what will be returned on the *next* read).


Games aren't perfect, even commercial ones. It's entirely possible that the game code is writing to CHR-ROM by mistake, while trying to clear the name tables (which are located immediately after the pattern tables) or something. You can safely ignore these writes, seeing as they don't do anything on hardware either when the CHR chip is read-only.

Note that I don't *know* for sure that these things are happening in Ice Climber, I haven't checked this game in particular, I'm just saying that these things happen with other games, so this could be the case with Ice Climber as well. You'll have to investigate.

EDIT: I just checked in Mesen and the game is definitely reading data from CHR-ROM on start up (code starting at address $C6FE). Notice how the value returned by the first $2007 read is discarded (this is a garbage byte that was in the buffer), and later comes the loop that actually copies the data from CHR-ROM to CPU RAM. If you look in the pattern table viewer, you'll see that the address being read contains what appears to be garbage, instead of actual graphics. That's because those tiles are never used as graphics, it's actually data that has been put there by the developers probably because they ran out of PRG-ROM space. I also looked for evidence of CHR-ROM being written to, but that never happened during the short time I was playing.

In your emulator, can you log the PC address when the write to CHR ROM occurs?

Oh wow, didn't know there was a 1 byte delay! That is most likely the issue. So jsut to be sure, the byte it fetches is alway 1 byte behind, so first byte is garbage, second byte is the byte you were looking for when you first set the address, right?

Yes, though there is an exception to this for $3F00-3FFF where it connects directly to the palette RAM instead with no delay.

Oh okay, I'll add it as exception.

It is working though! Title screen displays correctly.

But what I think is weird is that nowhere on the internet I can find anything about this 1 byte delay. I'd expect to find at least a reference to it here but can't find it there. Anyone have like a link with all the details about this 1 byte delay?

But it is documented on that page, in section 2.8.1 - "The PPUDATA read buffer (post-fetch)".

Oh wow, can't believe I missed that. Thx