Implementing a DPCM-safe code for input reading

BinaryLab

New member
I have a learning (technical) question, and I don't know exactly which topic to place it into, in the forums. I'm trying to understand a specific loop related to vBlank and gamePad reading.

In the MainASM.asm file, at the MainGameLoop, we have these lines

MainGameLoop:
JSR GamePadCheck

LDA vBlankTimer
vBlankTimerLoop:
CMP vBlankTimer
BEQ vBlankTimerLoop

Here's how I read this: we update the gamepad variable with input reads for this frame and wait for vBlank (which is updated by an interrupt) until we proceed. After this comes everything else. My question is:

Does this mean that we are using screen-rendering time to read inputs?

Since my objective is to implement a DPCM-safe version of input reading, so I'm digging deeper into the GameEngine. I have two options:

1) Read it twice and keep repeating until two consecutive readings agree. This introduce lag (which should be unnoticeable, but it is lag nevertheless) and has the probability to ignore real inputs if they change between reads.

2) Implement an even-cycle reading procedure which uses the OAM-DMA instructions to start an odd-even cycle counter. However, this can't be done during screen rendering or else the procedure would mess up the screen.

So, if anyone could confirm this, I would be happy to proceed with the implementation =)
 

Kasumi

New member
A separate CPU (called the Picture Processing Unit, PPU) is responsible for rendering the screen. Most all of your code runs while it is doing that (during screen rendering time).

Similar to 1. Read twice, use the buttons from last frame if the two reads aren't the same. This uses about the same amount of time every frame.

I wouldn't do 2. Emulation is kind of a moving target. Emulators used to be considered more accurate when they made DPCM "always" affect the buttons. If your game is played on one of those emulators, you'll get DPCM interference, because the even-cycle thing is a new discovery and not widely emulated.

There are several controller read routines right here: http://wiki.nesdev.com/w/index.php/Controller_reading_code

Though NES Maker stores its buttons in the byte in the reverse order from this, if I recall correctly.
 
Top Bottom