It is currently Mon Oct 14, 2019 3:50 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Wed Aug 28, 2019 5:46 am 
Offline

Joined: Tue Jul 23, 2019 10:41 am
Posts: 35
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!


Top
 Profile  
 
PostPosted: Wed Aug 28, 2019 6:22 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11415
Location: Rio de Janeiro - Brazil
timl132 wrote:
The text renders fine, but the big "Ice Climber" panel in the main menu doesn't render.

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).

Quote:
Because my question is, am I correct Ice Climber attempts to WRITE to CHR ROM.

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.


Top
 Profile  
 
PostPosted: Wed Aug 28, 2019 7:31 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 928
Location: New York, NY
timl132 wrote:
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!


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


Top
 Profile  
 
PostPosted: Wed Aug 28, 2019 8:24 am 
Offline

Joined: Tue Jul 23, 2019 10:41 am
Posts: 35
tokumaru wrote:
timl132 wrote:
The text renders fine, but the big "Ice Climber" panel in the main menu doesn't render.

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).

Quote:
Because my question is, am I correct Ice Climber attempts to WRITE to CHR ROM.

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.

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?


Top
 Profile  
 
PostPosted: Wed Aug 28, 2019 9:01 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7598
Location: Canada
Yes, though there is an exception to this for $3F00-3FFF where it connects directly to the palette RAM instead with no delay.


Top
 Profile  
 
PostPosted: Wed Aug 28, 2019 9:06 am 
Offline

Joined: Tue Jul 23, 2019 10:41 am
Posts: 35
rainwarrior wrote:
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?


Top
 Profile  
 
PostPosted: Wed Aug 28, 2019 9:09 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1481
timl132 wrote:
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)".

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
PostPosted: Wed Aug 28, 2019 12:19 pm 
Offline

Joined: Tue Jul 23, 2019 10:41 am
Posts: 35
Quietust wrote:
timl132 wrote:
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group