It is currently Fri Nov 16, 2018 9:56 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Jul 25, 2018 12:45 pm 
Offline

Joined: Tue Apr 17, 2018 3:40 am
Posts: 14
I'm not sure if it is a bug with some logic with my emulator or if games actually edit ROM or access out of range address, expecting some behavior which is not implemented.

When running Super Mario Bros, I see that the code tries to edit the pattern tables. When running Ice Climber, I see it trying to access a VRAM address greater than 0x4000. Both occur when writing to 0x2007 and both cause my emulator to crash.
This is how I handle a write to 0x2007:
Code:
mem.setVRAM8(this->currentVramAddr++, this->DATA);
this->currentVramAddr += ((this->CTRL >> 2) & 0x1) * 31; // Ads extra 31 if bit 2 is set

Is this supposed to happen in those games or is something wrong with my implementation? My CPU passes all the tests from nestest and instr_test-v5. My PPU passes all of blargg's tests (blargg_ppu_tests_2005.09.15b) except for vbl_clear_time if I allow the code to edit CHR.

Another interesting thing to note is that everything works perfectly fine in Release mode in Visual Studio. Both Super Mario Bros and Ice Climber seem to work mostly fine, except for some sprites being all black, but I'm pretty sure that it is unrelated to this issue.


Top
 Profile  
 
PostPosted: Wed Jul 25, 2018 12:55 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 419
I believe the PPU uses 14 bit addresses, so going past $4000 wraps around to $0000.

Writing to cartridge memory depends on the mapper. With NROM it's a nop.

BTW an emulator should never crash from bad user programs. One needs to handle every address.


Top
 Profile  
 
PostPosted: Wed Jul 25, 2018 1:44 pm 
Offline

Joined: Tue Apr 17, 2018 3:40 am
Posts: 14
Quote:
BTW an emulator should never crash from bad user programs. One needs to handle every address.

Yeah, you're right. I made it overflow after reaching 0x4000 and made writing to ROM a nop.

I also figured out why it was working in Release, but not Debug. It was because I didn't initialize the PPU registers, and they got set to values that caused an NMI on the first cycle, stopping the CPU from running initialization code and messing everything up. I simply initialized them to 0 and made the changes you suggested and it worked! Thanks for the help!

However, on the scrolling page on the wiki, it says that the VRAM address is 15 bits long. Is that talking about a different address?


Top
 Profile  
 
PostPosted: Wed Jul 25, 2018 2:16 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20775
Location: NE Indiana, USA (NTSC)
Bits 14-12 of the VRAM address have a different meaning between rendering on the one hand and video memory access through $2007 on the other. During rendering, bits 14-12 represent fine Y scroll, which is reflected as PA2-0 of pattern table fetches. During video memory access through $2007, bit 14 is ignored, and bits 13-12 represent actual PA13-12.


Top
 Profile  
 
PostPosted: Wed Jul 25, 2018 3:48 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3684
Location: Mountain View, CA
ace314159 wrote:
I also figured out why it was working in Release, but not Debug. It was because I didn't initialize the PPU registers, and they got set to values that caused an NMI on the first cycle, stopping the CPU from running initialization code and messing everything up. I simply initialized them to 0 and made the changes you suggested and it worked! Thanks for the help!

Read closely (not all are zero), and also understand the difference between power-on (power cycle) and reset:
https://wiki.nesdev.com/w/index.php/PPU_power_up_state

Similar applies to CPU:
https://wiki.nesdev.com/w/index.php/CPU_power_up_state


Top
 Profile  
 
PostPosted: Wed Jul 25, 2018 4:28 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6955
Location: Canada
I've added a small note to the Wiki. Would this have helped understanding?
https://wiki.nesdev.com/w/index.php?title=PPU_scrolling&diff=prev&oldid=15253


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 9:51 am 
Offline

Joined: Tue Apr 17, 2018 3:40 am
Posts: 14
tepples wrote:
Bits 14-12 of the VRAM address have a different meaning between rendering on the one hand and video memory access through $2007 on the other. During rendering, bits 14-12 represent fine Y scroll, which is reflected as PA2-0 of pattern table fetches. During video memory access through $2007, bit 14 is ignored, and bits 13-12 represent actual PA13-12.

Thank you! This clears everything up!

koitsu wrote:
Read closely (not all are zero), and also understand the difference between power-on (power cycle) and reset:
https://wiki.nesdev.com/w/index.php/PPU_power_up_state

Similar applies to CPU:
https://wiki.nesdev.com/w/index.php/CPU_power_up_state


So if I'm understanding this right, on a power cycle, I set everything but 0x2002 to 0 and set 0x2002 to 0xA0. What I don't understand is the diference between a power cycle and reset. I couldn't find an explanation on the page or through a Google search. Is a reset just a way to change the ROM without resetting all of the registers, and on a physical device without turning it on and off?

rainwarrior wrote:
I've added a small note to the Wiki. Would this have helped understanding?
https://wiki.nesdev.com/w/index.php?tit ... ldid=15253

This would have definitely helped!


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 9:56 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6955
Location: Canada
ace314159 wrote:
What I don't understand is the diference between a power cycle and reset. I couldn't find an explanation on the page or through a Google search. Is a reset just a way to change the ROM without resetting all of the registers, and on a physical device without turning it on and off?

The NES and famicom have two separate buttons: POWER and RESET.

The power switch removes power from the system and turns it off. The reset button doesn't turn anything off, it just restarts the software from the beginning.

A lot of stuff that was happening, most contents of RAM, etc. is preserved across a reset that is not preserved when you power off. Some games will behave differently for a reset than for powering off and on, though I think most games will be the same either way.


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 10:08 am 
Offline

Joined: Tue Apr 17, 2018 3:40 am
Posts: 14
So you can't change the game or cartridge when you hit RESET? It's just to restart the current game?


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 10:18 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6955
Location: Canada
You can yank a cartridge out of your NES while it's on, if you want, but that's not really something I've ever seen emulated. You can also do that while holding reset, I suppose?

If you pull a cartridge out of the machine while it's powered on, the system will more or less just crash. You can stick a new game in without powering it off, but to get it to run you will need to press reset (or power off and on).

There's some obscure possibilities involved with this, but emulators can usually do the same thing in a more convenient way with game genie codes or other methods.


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 11:11 am 
Offline

Joined: Tue Apr 17, 2018 3:40 am
Posts: 14
That's definitely out of the scope of my emulator, but I understand what a power cycle and reset does now. Thanks for the help!


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 11:24 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3684
Location: Mountain View, CA
ace314159 wrote:
So if I'm understanding this right, on a power cycle, I set everything but 0x2002 to 0 and set 0x2002 to 0xA0.

Don't miss the part about the PPU RAM contents, specifically the nametable regions. "Mostly" in this case can probably be interpreted as, for emulation purposes, "fill completely with".


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 11:47 am 
Offline

Joined: Tue Apr 17, 2018 3:40 am
Posts: 14
I'll make sure to remember that.

Looking at it again, I noticed that for OAM and CHR RAM it mentions a "pattern". What does this mean?


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 11:51 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6955
Location: Canada
ace314159 wrote:
Looking at it again, I noticed that for OAM and CHR RAM it mentions a "pattern". What does this mean?

Hmm, that seems misleading. We probably shouldn't suggest that there is some specific pattern these boot with.

They are unreliable. You can implement it as powering on all 0, all FF, all random, doesn't really matter.

There are usually some pattern tendencies to any particular RAM's power on, but it will vary a bit from time to time your turn it on.


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 12:18 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20775
Location: NE Indiana, USA (NTSC)
I've replaced most of the "pattern" stuff in the article with "unspecified values".


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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