When should the controllers be polled? Once per PPU frame, at some specific line?
The test ROM "test_cpu_exec_space_apu.nes" gives an error on $4016/7.
EDIT: the test requires ORing $40 on reads. Now it's ok.
The high three bits of $4016 and $4017 are open bus.
The controller data will be accessed when the strobe is high and then low, so the emulator should read them while the strobe is high, making the data available to the emulated program when it is low.
As for WHEN to poll the controllers, that's up to you. On a real NES, the controllers can be read several times per frame and the data returned will always reflect their current state. In an emulator you will most likely read the actual control(er)s once per frame and return that to the game as many times as it requests.
I read about "open bus", but I couldn't take any conclusions on it. I read about "returning the last value written there" or "returning 0xFF", I'm not sure. Usually, the value is (address >> 8).
The 6502 has a data "bus", which is a set of paths for the data bits to travel. When the CPU reads instructions from ROM, the bytes that make up the instruction travel through this bus, one at a time. If the instruction is "LDA $4016", the CPU will read $AD, $16 and finally $40. So $40 is the last value to travel through the bus before the command is executed. When answering back, the controller uses this same bus to send the data, but it doesn't use all of the lines (there's no need to control all 8 lines if the answer fits in less bits). The lines that are not used simply retain their old values, so the result is a mix of the controller data with the previous value that traveled through he bus. In most cases the old value is the high byte of the address of the register you read from.
Code:
ldx #$16 + 1
lda $3fff, x
Clarification: just posting an example of how to have the open-bus value be different than $40, in case it helps someone think more concretely about it.
blargg wrote:
Code:
ldx #$16 + 1
lda $3fff, x
Yeah, this is why I said "in most cases". If different addressing modes are used to access the registers you might get something other than the high byte of the register's address from open bus, so you shouldn't assume it's always that.
blargg wrote:
Code:
ldx #$16 + 1
lda $3fff, x
I think according to how the 6502 instruction set works, in such a case it will first read without carrying, so from $3F16 (a mirror of the PPU address register; I don't know what happens when you read that register), and then it will try again, this time using the correct address.
Also, on RF Famicom (and others that use the same internal logic; I don't know if Famicom Titler does), the high five bits of $4016 are open bus; on all other systems, it is the high three bits.
Do any games rely on the true open bus behavior? If so, which ones?
According to
the wiki, Paperboy does. Other games might; I'm not sure.
freem wrote:
According to
the wiki, Paperboy does. Other games might; I'm not sure.
It says: "Paperboy relies on this behavior and requires that reads from the controller ports return exactly $40 or $41 as appropriate." It seems to me, this means it only cares when actually reading like
LDA $4016, so it isn't the complete use of the open bus.
However, if writing an emulator you should emulate the full behavior of the open bus, even if nothing known currently uses it. Doing so would improve the accuracy, and may also be useful in future.
A test ROM would be nice.