It is currently Mon Dec 18, 2017 2:09 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 76 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Sat Oct 12, 2013 1:56 pm 
Offline
User avatar

Joined: Fri Oct 04, 2013 11:56 pm
Posts: 42
Location: Wisconsin
Okay. How does it actually deal with incrementing? Right now, I have it add the upper and lower bytes together and then store them in a separate variable. Then when the data register is written to, that separate variable gets incremented and the registers are left alone. Is that right, or should I actually increment the register?

_________________
Current emulator progress http://forums.nesdev.com/viewtopic.php?f=3&t=10558


Top
 Profile  
 
PostPosted: Sat Oct 12, 2013 2:47 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3969
The registers are write only, and cannot be read back. So writing to 2005 or 2006 will make changes to the state of the PPU, and 2005 and 2006 can not be read back.
There's lots of more details about scrolling, and it's been posted to death on the boards and wiki already.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Sat Oct 12, 2013 3:26 pm 
Offline
User avatar

Joined: Fri Oct 04, 2013 11:56 pm
Posts: 42
Location: Wisconsin
Well what I'm curious about is, say a game writes to the address register with $10 and then $00, the address would then be $1000. If in increments 256 times, it would then be $1100. Then you write $08 to the address register, without resetting the latch... Would it then be $1108? Or does it go off of the original last byte written, so it would be $0008?

By the way, I got attribute tiles and the background color palette working. I still don't know why the Donkey Kong letters are messed up, or why some of the ladders are too, or why only half of Donkey Kong is showing... Any ideas?
Image

_________________
Current emulator progress http://forums.nesdev.com/viewtopic.php?f=3&t=10558


Top
 Profile  
 
PostPosted: Sat Oct 12, 2013 3:41 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
janzdott have you passed all of the nestest.nes opcode tests? Just a thought to rule out CPU error.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Sat Oct 12, 2013 5:12 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3969
Looks like you haven't implemented the 32 or 1 increment mode.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Sat Oct 12, 2013 5:58 pm 
Offline
User avatar

Joined: Fri Oct 04, 2013 11:56 pm
Posts: 42
Location: Wisconsin
It passed all the CPU tests up until it hit unofficial opcodes. I'm assuming my CPU is working fine, but I wouldn't be surprised if there was still a couple bugs. And I've implemented both incrementing modes. I've checked my code several times and it looks fine. But I'll check again by doing some test writes,

_________________
Current emulator progress http://forums.nesdev.com/viewtopic.php?f=3&t=10558


Top
 Profile  
 
PostPosted: Sat Oct 12, 2013 6:23 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Things to note:

The $2006 latch is only updated to LoopyV when the 2nd write is done, could that be it? But when it is, it'll update it...I don't know what the default first value is honestly.


Top
 Profile  
 
PostPosted: Sat Oct 12, 2013 8:37 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10172
Location: Rio de Janeiro - Brazil
janzdott wrote:
say a game writes to the address register with $10 and then $00, the address would then be $1000. If in increments 256 times, it would then be $1100. Then you write $08 to the address register, without resetting the latch... Would it then be $1108? Or does it go off of the original last byte written, so it would be $0008?

Loopy's famous document, "the skinny on NES scrolling", documents everything that happens on each write to $2005/$2006 and to the lower 2 bits of $2000 (i.e. everything that deals with scrolling). The basic idea is that writes to $2006 don't affect the PPU's address register directly, the data actually goes to a temporary register first, and only after the second write the contents of the temporary register are copied to the actual address register. So writing $08 to $2006 won't really do anything to the address register, since the address is only modified after the second write.

But if you do manage to trick the PPU into setting an incomplete address (like by writing to $2005 and then to $2006), bits that are not updated will most likely maintain the value from when you last set the address, because unlike the address register, the temporary register doesn't auto increment.

PS: Loopy's document is not the easiest to understand, but there's a wiki page about it, which tries to explain things further (and ends up making things look pretty complicated!). The basic idea is that writes to $2000, $2005 and $2006 don't affect the VRAM address directly, but instead go to a temporary register (the original document uses 1's to indicate which bits get copied where), and only after the second write to $2006 (the latch that selects between first and second writes is shared between $2005 and $2006, so if you write to $2005 and then to $2006, the $2006 write is still detected as a second write) the temporary register is copied to the address register.

The document also says that the X coordinates are copied from the temporary register to the address register every scanline (so that each scanline starts from selected horizontal position), and that the full address is copied at the beginning of the frame (because games are supposed to use $2000/$2005 to set the scroll during VBlank, not $2006).

In case it's not clear, the PPU's address register is used when the CPU needs to access VRAM, but also when the PPU reads it for rendering the image, which is why talking about the address register eventually brings up talks about scrolling.


Top
 Profile  
 
PostPosted: Sat Oct 12, 2013 10:47 pm 
Offline
User avatar

Joined: Fri Oct 04, 2013 11:56 pm
Posts: 42
Location: Wisconsin
I came across that page and thought it looked like a good read for when I work on scrolling. I'll give it a look tomorrow after I try fixing the graphics bug :)

Edit: I fixed it, and it was because it was checking for the 2nd bit of the controller register to be set for 32 incrementing, instead of the 3rd bit. *Sigh* its always the little things that get me haha. There's still something funky going on with my attribute tiles. Part of Donkey Kong is discolored, and the numbers are strange because they should all be white. I've checked my code several times and rewrote it once, and I don't know what it is. I'm just going to move on and see if I can get sprites to show up

Image

_________________
Current emulator progress http://forums.nesdev.com/viewtopic.php?f=3&t=10558


Top
 Profile  
 
PostPosted: Wed Jan 08, 2014 2:22 pm 
Offline
User avatar

Joined: Fri Oct 04, 2013 11:56 pm
Posts: 42
Location: Wisconsin
Hey guys. I stopped working on my emulator for a while, but I recently started again. I was using SDL, but I switched over to WinApi and OpenGL. I may switch to Qt or some other cross-platform GUI library if this ever gets finished. I completely changed the way my PPU renders. Now I'm actually emulating the shift registers and fetching the nametable, attribute, and patterns at the correct times, though there's a glitch with the leftmost 2 tiles. Surprisingly, its faster than before. I also fixed my color glitch, which was caused by reading attributes incorrectly. No controls yet, I'm going to add that after sprites. Kinda pointless to have controls and no character to move around haha. I also wrote a nice little CPU debugger window. I can see and change the registers in real time, and also view the disassembly.

It runs the demo screens of Donkey Kong and Donkey Kong 3 fine. There's some problem with Super Mario Bros 1 after it draws the title screen background where it tries writing to CHR ROM. Not sure what's causing that yet. Here's a screen of Donkey Kong 3 and my CPU debugger window.

Image Image

_________________
Current emulator progress http://forums.nesdev.com/viewtopic.php?f=3&t=10558


Top
 Profile  
 
PostPosted: Wed Jan 08, 2014 2:42 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6540
Location: Seattle
Looks like an off-by-one. Are you using the Y value for the preceeding scanline for the first two fetches of the next scanline?


Top
 Profile  
 
PostPosted: Wed Jan 08, 2014 4:13 pm 
Offline
User avatar

Joined: Fri Oct 04, 2013 11:56 pm
Posts: 42
Location: Wisconsin
Yep lol. I had to leave right away, so I didn't have time to fix it before I posted the screens. I started working on sprite evaluation, so I should have sprites showing up soon. Probably by tomorrow if I feel like programming later tonight :D

_________________
Current emulator progress http://forums.nesdev.com/viewtopic.php?f=3&t=10558


Top
 Profile  
 
PostPosted: Wed Jan 08, 2014 7:43 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10172
Location: Rio de Janeiro - Brazil
janzdott wrote:
There's some problem with Super Mario Bros 1 after it draws the title screen background where it tries writing to CHR ROM.

Writing to CHR-ROM? It's a known fact that SMB *reads* data from CHR-ROM in order to draw the title screen. For this to work, it's important that you emulate the $2007 read delay: when $2007 is read, a buffered value is sent to the CPU and the actual value from VRAM/ROM is put into the buffer, meaning that games have to throw away the first of a group of $2007 reads in order to read data from VRAM/ROM. The palette is an exception, because it's stored inside the PPU itself so there's no delay.


Top
 Profile  
 
PostPosted: Wed Jan 08, 2014 9:15 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19355
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
Writing to CHR-ROM?

Some of Shiru's programs do this on accident, and I've been guilty too. I had to patch out these bugs for the multicart. I wonder whether this is something that lot check would normally have caught during the NES's commercial era.


Top
 Profile  
 
PostPosted: Wed Jan 08, 2014 10:40 pm 
Offline
User avatar

Joined: Fri Oct 04, 2013 11:56 pm
Posts: 42
Location: Wisconsin
By writing to CHR-ROM, I don't mean its SUPPOSED to be doing that haha :wink:

There's a bug in my emulator somewhere causing it to do that. I'm not sure if it's a CPU or PPU problem. I tried for a while to find what's causing it, but it's not easy to track down. My emulator throws exceptions when writing to ROM. If I comment out the exceptions, it continues running but doesn't finish drawing the title screen. It gets here and doesn't set the background color or draw the title.

Image

_________________
Current emulator progress http://forums.nesdev.com/viewtopic.php?f=3&t=10558


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 76 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 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