Should be, but not if he reads the opcode from CPU memory then reads some operands from VRAM due to typos. It looks like he's specifying the address space to take the data from each time he pulls in a byte for anything.

Author:

Dartht33bagger [ Fri Aug 23, 2013 8:38 pm ]

Post subject:

Re: Need some help with the PPU

Zeropage reads work correctly on nestest.nes, so I don't understand why they aren't here.

I pass the ppu to readRAM so that if $2002 is read I can clear the writeToggle or if $2007 is read I can use/increment the ppuAddress. I have a separate function for reading from VRAM creativity called readVRAM.

Edit: Somehow I screwed my cpu code up and it wasn't passing any of the tests except for basics. So I reverted back to an older file and everything is working again. I'm trying to figure out why my ROR instructions won't pass.

Author:

miker00lz [ Sat Aug 24, 2013 9:38 am ]

Post subject:

Re: Need some help with the PPU

Ah, okay that makes sense. My mistake.

For ROR, you should have a temp variable to store whether bit 0 of the operand is 0 or 1 before changing it. Now shift the value right by a bit. If the actual CPU carry flag is set, now set bit 7 of the operand. Then, replace the actual CPU carry flag with what you saved in the temp variable. Last, calculate the zero and negative flags. That should do it.

Author:

Dartht33bagger [ Sun Aug 25, 2013 9:30 pm ]

Post subject:

Re: Need some help with the PPU

For some reason only tests 01-03 print out a pass/fail message. 04, 05, and 06 only output the missed opcodes. If no opcodes are missed, then nothing gets printed out. Is that supposed to happen?

Here is what I'm getting right now for 04:

Quote:

�ްaP

�4��/usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0@

�4��/usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0DONE

Author:

miker00lz [ Mon Aug 26, 2013 1:09 am ]

Post subject:

Re: Need some help with the PPU

Yes, that's normal.

Author:

Dartht33bagger [ Mon Aug 26, 2013 10:27 pm ]

Post subject:

Re: Need some help with the PPU

Well I'm happy to report that I passed every test except for 11-stack. I've checked everything that has to do with the stack, and I cannot find my error.

Test output:

Quote:

48 PHA08 PHP68 PLA28 PLP9A TXSBA TSX

11-stack

Failed

I'm guessing that since I'm missing pretty much every instruction that effects the stack, it must be how I wrap around. These are my two stack functions:

Of course it was a dumb mistake like that. I checked that function multiplie times and missed it. Now I passed, which means my CPU checks out.

After comparing my VRAM dump of Donkey Kong to the one posted earlier in this thread, I'm way off. I'm not exactly sure why, though. I went through and rechecked how all the registers worked and how nametable mirroring worked on the wiki to make sure my code looked ok. My function that writes to VRAM in my memory class looks ok, so I'm thinking that maybe my ppu is somehow at an incorrect address when I go to write data to VRAM. Maybe if I ask these few questions I'll be closer to figuring out why my VRAM isn't being filled correctly.

1. What is the ppu address supposed to be at startup? Currently I'm starting it up at $2000, but I have no idea if it matters or not.2. Should the ppu be doing its normal rendering operations during the first few screens at startup? Right now, mine starts fetching data/shifting registers/outputting pixels from the instant the emulator starts. To me, this seems like it would be wrong since the game is going to be polling $2002 until Vblank happens - which means that nothing but the chr-rom will actually be filled. Could my ppu address be incorrect because I'm incrementing it from the get go?3. The only way the game can fill up VRAM is by writing the address it wants to fill with data at $2006 and then the writing data to $2007, correct?

The PPU begins with NMIs disabled and sprites and background disabled. If that's not enough, the game will also likely disable NMIs and disable sprites and backgrounds immediately at boot. So you'll be drawing a bunch of gray pixels (background color) until the game has really started up. Also before the first frame has rendered completely, writes to 2000 and 2001 are ignored, so you can't enable NMIs or enable spites and backgrounds.The Famicom is different in that the PPU is immediately ready after a system reset, so that's why games will disable NMIs and disable sprites and backgrounds. While it doesn't matter on the NES, it does on the Famicom.

Also, it sounds like you might be having problems with disabling rendering. When rendering is disabled (sprites and backgrounds turned off), the PPU doesn't do any memory fetches, and doesn't automatically increment its addresses. So at power on, it won't be incrementing the PPU address at all.

Initial VRAM address simply doesn't matter, nothing relies on it at all. But it's supposed to be 0000.

Also, remember that the first 2006 write sets the high byte, and the second 2006 write sets the low byte. It's the only Big Endian part of the entire system.

Author:

koitsu [ Wed Aug 28, 2013 5:53 am ]

Post subject:

Re: Need some help with the PPU

Dartht33bagger wrote:

1. What is the ppu address supposed to be at startup? Currently I'm starting it up at $2000, but I have no idea if it matters or not.2. Should the ppu be doing its normal rendering operations during the first few screens at startup? Right now, mine starts fetching data/shifting registers/outputting pixels from the instant the emulator starts. To me, this seems like it would be wrong since the game is going to be polling $2002 until Vblank happens - which means that nothing but the chr-rom will actually be filled. Could my ppu address be incorrect because I'm incrementing it from the get go?

Also, the above "VRAM writing code" (which is really just your code used to handle mirroring and certain PPU memory regions) sheds absolutely no light on how you're handling writes to $2000, $2005, $2006, and $2007.

Author:

tepples [ Wed Aug 28, 2013 6:34 am ]

Post subject:

Re: Need some help with the PPU

The way you're handling mirroring appears sort of suspect. You're executing each write more than once into a space larger than the actual memory. But most ASIC mappers can change the mirroring at runtime, and when it changes, games expect the existing data to get moved around. Say a program writes the following to the nametables while mirroring is set to vertical (not to scale):

Code:

Data wri tten toone name tablestays th ere whennametabl es move.

Data wri tten toone name tablestays th ere whennametabl es move.

If the program then proceeds to switch the mirroring to horizontal, it expects the data to instantly become logically rearranged as follows:

Code:

Data wri Data wrione name one namestays th stays thnametabl nametabl

tten to tten totable tableere when ere whenes move. es move.

Rad Racer relies on this, as do a lot of games that use a status bar.

You'll especially notice this when you try to implement one-screen mirroring as used by mapper 7 and some MMC1 games.

Author:

tokumaru [ Wed Aug 28, 2013 9:06 am ]

Post subject:

Re: Need some help with the PPU

tepples has a pretty good point. Mirroring doesn't mean that the data is written to multiple locations... it means that there's only one physical location, which is accessed through multiple addresses. In emulators this is often implemented with pointers, which can be changed to point anywhere you want (and like tepples said, many mappers do constantly change the mirroring settings as they run).

Author:

Dartht33bagger [ Wed Aug 28, 2013 1:52 pm ]

Post subject:

Re: Need some help with the PPU

I completely forgot that I could use pointers to reference data pieces inside of an array. I'll come home and re-write my mirror functions accordingly later tonight with pointers.

Comment in passing (have much to do today, sorry) -- thumbs up to using pointers for the mirroring. That's absolutely the proper way to do it, ditto with a large amount of mapper implementation (PRG/CHR page selection). If I see memcpy() I will stab. ;-)