Page 1 of 3
Posted: Thu Feb 09, 2006 10:59 am
To keep from crowding out the forum this will be the resident thread for my PPU questions (and there'll be a few).
First up: What in the heck do I do CHR-ROM? Is it loaded into VRAM sort of like PRG-ROM? Or does the program do this? Thanks.
Posted: Thu Feb 09, 2006 11:21 am
Robin: Holy smokes Batman, where now?
Batman: To the Batmobile! I mean, to the Newbie Help Center!
CHR-ROM is loaded into $0000-1FFF in PPU memory. If there isn't any present in the ROM then $0000-1FFF is VRAM. It can be switched in and out of that area via memory mappers.
Posted: Thu Feb 09, 2006 1:07 pm
Holy scanlines, Batman!
Which brings me to the next quesiton: how in blazes does one handle screen drawing? Should I draw the screen one pixel at a time, or fake v/hblank times? What I currently have set up now (sort of) is to redraw the screen every 1000/59.97 ms and call NMI after that. The time in between is set to vblank. I'm guessing this'll probably screw timing up something terrible. EDIT: Also, how do fields come into play, PCs being progressive? Thanks again
EDIT: Another thing. How does $2006 work exactly? I know it takes two writes to set the address, but how does that work? I assume save the low byte somewhere temporarily and wait for the high byte?
Posted: Thu Feb 09, 2006 8:55 pm
The NES is also progressive.
The CPU and PPU run in parallel, with 341 PPU cycles per line (except 340 in some cases that you can worry about later) and 5 CPU cycles for every 15 or 16 PPU cycles (depending on region). You can emulate the CPU up to the point where it reads or writes a PPU register ($2000-$3FFF or $4014), and then render pixels up to that point.
And about $2005 and $2006: Loopy's document "The skinny on NES scrolling" explains how writes to $2005 and $2006 are translated into writes to internal V and T registers.
Posted: Sat Feb 11, 2006 12:44 pm
Okay, got that working. Next question: is sprite ram actually seperate from vram?
Posted: Sat Feb 11, 2006 1:03 pm
dxprog wrote:Okay, got that working. Next question: is sprite ram actually seperate from vram?
lmao, er yes it is. There are three memory maps on the NES, CPU, PPU and Sprite. It has 256 bytes of it's own memory, enough to hold data for 64 sprites.
Posted: Sun Feb 12, 2006 2:08 am
Ack! I've been n00bd! Anyways, no more questions at the moment. SMB seems to have gotten itself stuck in an infinite loop (8057: JMP 8057). Actually, I do have a question. Can an NMI fire while the NMI routine is executing (gives you an idea of how porly timed my code is
Posted: Sun Feb 12, 2006 4:33 am
SMB is supposed to get itself into an infinite loop (8057: JMP 8057). It is a method of waiting until the VBlank time starts. The loop is exited by executing an NMI.
Posted: Wed Feb 15, 2006 1:10 am
I assume that the internal VRam counter wraps after &H3FFF?
Posted: Wed Feb 15, 2006 4:21 am
Well here is where it gets tricky. PPU Memory is 14 bits wide, enough for $0000-$3FFF, BUT the PPU VRAM Address/Temp Address are 15 bits wide enough for $0000-$7FFF. If you try to access PPU memory above $3FFF then actual address accessed in the same minus $4000, (i.e. $63FC would return the value at $23FC. As far as incrementing the PPU Address whenever $2007 is accessed, I assume that the Address goes up to $4000.
Posted: Wed Feb 15, 2006 10:54 am
Well, after a little searching (amazing feature, eh?) and reading I found that I'm handling $2005/$2006 all wrong anyways. Hopefully when I get that written properly I won't have out of bounds problems (at least, not with SMB).
Posted: Wed Feb 15, 2006 10:16 pm
Okay, a question that isn't quite as n00bish as the last one. One pixel is drawn every PPU clock and there are 340/341 PPU clocks per scanline yet the screen is only 256 pixels wide. What's the PPU doing after that last pixel is drawn?
Posted: Wed Feb 15, 2006 10:33 pm
dxprog wrote:Okay, a question that isn't quite as n00bish as the last one. One pixel is drawn every PPU clock and there are 340/341 PPU clocks per scanline yet the screen is only 256 pixels wide. What's the PPU doing after that last pixel is drawn?
Loading sprite data, HBLANK, pre-fetching the first two tiles for the next scanline.
Posted: Fri Feb 17, 2006 12:57 pm
The boards were down all day yesterday and I was sad
I assume all the scroll values (written to 2005) esentially say where to start reading tiles (y * 32 + x + $2000)? And how is $2006 updated every frame during rendering (+1 every 8 pixels to point to the next tile)?
Posted: Sun Feb 19, 2006 2:24 am
Ignore the previous question for now (actually I may have figured it out).
New question, though. What do you do when a palette entry is greater than 51?