My one cent in PPU documentation
Moderator: Moderators
- dreampeppers99
- Posts: 77
- Joined: Mon Aug 21, 2006 4:19 am
My one cent in PPU documentation
I started to code a NES emulator in Java a long time ago, but anyway I think my understanding (with lots of visual aid) can help some guy trying to grasp it.
https://docs.google.com/document/d/1mLI ... sp=sharing
PS: If you want to edit this document, please tell me then I'll give you the access.
https://docs.google.com/document/d/1mLI ... sp=sharing
PS: If you want to edit this document, please tell me then I'll give you the access.
Re: My one cent in PPU documentation
You might consider fixing all the links to nesdev.parodius, since it's gone and the content has been moved here.
- dreampeppers99
- Posts: 77
- Joined: Mon Aug 21, 2006 4:19 am
Re: My one cent in PPU documentation
Thanks ;> I also make it open to public to comment, if you find something wrong or something that could be written better just comment there.lidnariq wrote:You might consider fixing all the links to nesdev.parodius, since it's gone and the content has been moved here.
Re: My one cent in PPU documentation
Right in the introduction:
Also, not all the bits exist for the 4 bytes of data in sprite ram, but that's just an unimportant nitpicky detail. The bits that do nothing can't even be read back.
24% of all NES games used CHR RAM instead of ROM.The tiles are stored in a ROM chip on the game cartridge
Also, not all the bits exist for the 4 bytes of data in sprite ram, but that's just an unimportant nitpicky detail. The bits that do nothing can't even be read back.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
- dreampeppers99
- Posts: 77
- Joined: Mon Aug 21, 2006 4:19 am
Re: My one cent in PPU documentation
Now it is in the doc, thanks.Dwedit wrote:Right in the introduction:24% of all NES games used CHR RAM instead of ROM.The tiles are stored in a ROM chip on the game cartridge
Also, not all the bits exist for the 4 bytes of data in sprite ram, but that's just an unimportant nitpicky detail. The bits that do nothing can't even be read back.
Re: My one cent in PPU documentation
Also, it seems like you were struggling on the attribute tables.
Divide up a byte into bits like ddccbbaa, and the bits apply to the four 16x16 sections of a 32x32 region like this:
AB
CD
aa means it's a 2-bit value (0-3) that determines which palette goes into A, aa is the lowest two bits of the byte. Then bb is another two-bit value, etc.
Attribute tables are 8 bytes wide and 8 bytes tall, and take up the last 64 bytes of a nametable, instead of having two more rows of tiles.
Divide up a byte into bits like ddccbbaa, and the bits apply to the four 16x16 sections of a 32x32 region like this:
AB
CD
aa means it's a 2-bit value (0-3) that determines which palette goes into A, aa is the lowest two bits of the byte. Then bb is another two-bit value, etc.
Attribute tables are 8 bytes wide and 8 bytes tall, and take up the last 64 bytes of a nametable, instead of having two more rows of tiles.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
- dreampeppers99
- Posts: 77
- Joined: Mon Aug 21, 2006 4:19 am
Re: My one cent in PPU documentation
It might be my weak college but attribute tables almost killed me, and now I see it so simple. =/ Maybe was the docs I looked into or myself over complicating ... anyway. thanks, if you want I can give edit permission.Dwedit wrote:Also, it seems like you were struggling on the attribute tables.
Divide up a byte into bits like ddccbbaa, and the bits apply to the four 16x16 sections of a 32x32 region like this:
AB
CD
aa means it's a 2-bit value (0-3) that determines which palette goes into A, aa is the lowest two bits of the byte. Then bb is another two-bit value, etc.
Attribute tables are 8 bytes wide and 8 bytes tall, and take up the last 64 bytes of a nametable, instead of having two more rows of tiles.