Hii ![:)]( "Smile")
This is my first post on the Forum. I've been a long time lurker here, now I'm stepping forward.
Anyway, as Fiskbit asked me to do in the nesdev discord, I'm posting my FastPoll test ROM here, even though I should have done it sooner, but better late than never I guess...
What this ROM is doing is very simple, it tries to read the controller... fast.
How fast the controllers are read shouldn't matter but, it allegedly does matters on PAL consoles that have diodes in their controller ports, because we should allegedly get double inputs when reading the controllers too fast on these consoles.
This is very unlikely to cause issues for games, because for double inputs to allegedly get registered, you would need to have a weird controller polling routine, which is what I did when I was making some of my first NES programs a while back.
The PAL console with diodes is an important detail, because PAL consoles without diodes should have the same behavior as NTSC, although, this has not been confirmed yet.
(Please note that this this test ROM only reads controller 1, everything should however be the same for controller 2)
When you load up the ROM, you will be greeted with the different tests, I'll explain what they do:
First, Write then read:
These starts with the controller's shift register empty, that is, when all the inputs have already been read (such as at the end of the previous frame's controller read).
It writes 1 to $4016 and then directly reads the controller's first bit after X number of cycles.
The number of cycles shown indicates in how many cycles, after the write to $4016, will the read occur.
So for example, the shortest delay is 4 cycles, which means that it's writing to $4016 and immediately reads it afterwards, with nothing happening in between.
It reads twice the controller in this state (second read is always 4 cycles after the first one).
You may notice that there is a PUT and GET column, these will show the results of what has been read based on if the write to the controller happens on a GET cycle or on a PUT cycle.
Theoretically, it should be returning only 00 if A is not pressed, and only 11 if A is pressed.
This is allegedly not the case with PAL consoles with diodes, as it should register like if the A button was pressed, even though it is not.
This test should probably only be done with genuine NES controllers as AFAIK third party controllers may not always output 1 when the shift register is empty, which will not give expected results here.
Then, Delay between reads:
These starts by strobing the controller normally, and then do each controller reads every X amount of cycles.
There is nothing much to it really, except it reads one more bit at the end, so that one should always be equal to 1.
It should theoretically, never register anything as a double input, but as you may have guessed, this behavior is allegedly different on PAL consoles with diodes.
Finally, Normal polling:
I feel like this is pretty much self explanatory, nothing weird should happen there.
Sorry for the overabundance of the word "allegedly", we actually need your help to confirm what Fiskbit and I got after testing the ROM is happening with everyone else, even though we didn't quite exactly get the same results, and I expect potentially more differences between consoles.
So far, here are mine.
Looking forward to see everyone's test results![:)]( "Smile")
This is my first post on the Forum. I've been a long time lurker here, now I'm stepping forward.
Anyway, as Fiskbit asked me to do in the nesdev discord, I'm posting my FastPoll test ROM here, even though I should have done it sooner, but better late than never I guess...
What this ROM is doing is very simple, it tries to read the controller... fast.
How fast the controllers are read shouldn't matter but, it allegedly does matters on PAL consoles that have diodes in their controller ports, because we should allegedly get double inputs when reading the controllers too fast on these consoles.
This is very unlikely to cause issues for games, because for double inputs to allegedly get registered, you would need to have a weird controller polling routine, which is what I did when I was making some of my first NES programs a while back.
The PAL console with diodes is an important detail, because PAL consoles without diodes should have the same behavior as NTSC, although, this has not been confirmed yet.
(Please note that this this test ROM only reads controller 1, everything should however be the same for controller 2)
When you load up the ROM, you will be greeted with the different tests, I'll explain what they do:
First, Write then read:
These starts with the controller's shift register empty, that is, when all the inputs have already been read (such as at the end of the previous frame's controller read).
It writes 1 to $4016 and then directly reads the controller's first bit after X number of cycles.
The number of cycles shown indicates in how many cycles, after the write to $4016, will the read occur.
So for example, the shortest delay is 4 cycles, which means that it's writing to $4016 and immediately reads it afterwards, with nothing happening in between.
It reads twice the controller in this state (second read is always 4 cycles after the first one).
You may notice that there is a PUT and GET column, these will show the results of what has been read based on if the write to the controller happens on a GET cycle or on a PUT cycle.
Theoretically, it should be returning only 00 if A is not pressed, and only 11 if A is pressed.
This is allegedly not the case with PAL consoles with diodes, as it should register like if the A button was pressed, even though it is not.
This test should probably only be done with genuine NES controllers as AFAIK third party controllers may not always output 1 when the shift register is empty, which will not give expected results here.
Then, Delay between reads:
These starts by strobing the controller normally, and then do each controller reads every X amount of cycles.
There is nothing much to it really, except it reads one more bit at the end, so that one should always be equal to 1.
It should theoretically, never register anything as a double input, but as you may have guessed, this behavior is allegedly different on PAL consoles with diodes.
Finally, Normal polling:
I feel like this is pretty much self explanatory, nothing weird should happen there.
Sorry for the overabundance of the word "allegedly", we actually need your help to confirm what Fiskbit and I got after testing the ROM is happening with everyone else, even though we didn't quite exactly get the same results, and I expect potentially more differences between consoles.
So far, here are mine.
Looking forward to see everyone's test results
Statistics: Posted by Gros chien — Sat May 18, 2024 7:25 pm — Replies 0 — Views 57