Is PPU_DATA read slow?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
Posts: 2
Joined: Fri Dec 11, 2020 12:57 pm

Is PPU_DATA read slow?

Post by UsernameInUse » Mon Jan 11, 2021 3:58 am


I work on a platformer and I'm making collision check right now.
My question: is PPU_DATA ($2007) read as slow as write and can I use it for collision detection?

User avatar
Posts: 2033
Joined: Sat Sep 07, 2013 2:59 pm

Re: Is PPU_DATA read slow?

Post by DRW » Mon Jan 11, 2021 4:33 am

My advice: You shouldn't use any of the PPU registers for anything that has to do with game logic.

Not only can most of the registers not be accessed outside of vblank, but this way, you're mixing graphics output with game logic.
If you want to check a character against a background, you should have an abstract data structure made up of regular variables that holds the state of the screen. It's not good practice to check game logic against the actual tile values of the graphics, no matter how fast or slow the access is. Because as soon as you want to have an invisible wall or as soon as you use the same tiles for a background and for a wall object, this attempt goes down the drain.
My game "City Trouble":

User avatar
Posts: 11947
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Is PPU_DATA read slow?

Post by tokumaru » Mon Jan 11, 2021 6:03 am

Everything DRW said. You don't want to deal with the limited access times of VRAM, and you don't want to decide the behavior of your tiles based on their graphics. Most games will either include the solidity information as an attribute of the metatiles (blocks used to construct the levels) themselves, or have a separate map with just the solidity data.

User avatar
Posts: 4400
Joined: Fri Nov 19, 2004 7:35 pm

Re: Is PPU_DATA read slow?

Post by Dwedit » Tue Jan 12, 2021 10:53 am

Reading from the PPU can only be during VBLANK time, or during Forced Blanking (sprites and background disabled).
Furthermore, using the DMC sound channel will corrupt your PPU reads, just like it does with joystick input.

Because reading from the PPU is so restrictive, it's generally only used for storing blocks of data in CHR-ROM. For example, SMB1's title screen, Dragon Quest 1's game script text, MC Kids's compressed levels, and Family Feud's nametable layouts and puzzle answers.

So don't read from the PPU unless you are storing data in CHR-ROM. You need to stop any DMC samples from playing during that time.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
Posts: 7979
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada

Re: Is PPU_DATA read slow?

Post by rainwarrior » Tue Jan 12, 2021 2:06 pm

An answer to the literal question: individual PPU reads/writes are the same speed as any other read/write on this CPU. It's probably worth saying so, just because there are lots of platforms (modern and old) where video memory access is slower.

As others have pointed out, you have a bandwidth problem due to the window of timing you have for access.

Other nitty details:

Serial access to the PPU data is actually more efficient than CPU, due to its auto-increment behaviour. On the CPU you have to increment an index between bytes to do the same. (Workaround: you can store a small amount of data on the stack area and auto-increment with PLA.)

Random access to the PPU data is grossly inefficient, since you have to write 2 extra bytes to $2006 to set the address. If reading, you also need to discard one byte read before you start getting valid results.

Post Reply