nesdev.org

Hello, everyone. I searched "reread" and didn't find the target. So I post it.

Authors of [url=http://wiki.nesdev.com/w/index.php/Standard_controller#Evil_Details]Standard controller[/url] on the wiki wrote:Turbo
A turbo controller such as the NES Max or NES Advantage is read just like a standard controller, but the user can switch some of
its buttons to be toggled by an oscillator. Such an oscillator turns the button on and off at 15 to 30 Hz, producing rapid fire
in games. A controller MUST NOT toggle the button states on each strobe pulse; that'll break any game that rereads the
controller.

I have simply verified what wiki said, and it does exist reread case.
Why does some game read the controller twice?
Is it necessary to do that when I write an NES demo?
I guess it is related to hardware but don't sure.
Is there any case where a game read controller three(or more) times in history?

Boolean wrote:Why does some game read the controller twice?

The APU DMC can interfere with controller reading. To ensure the correct value has been read, most games using the DMC channel will read the controller at least twice.

Boolean wrote:Is it necessary to do that when I write an NES demo?

Only if you use the DMC.

Boolean wrote:Is there any case where a game read controller three(or more) times in history?

Yes. From this thread:

• Super Mario Bros. 3
• Batman
• Tetris

Boolean wrote:Why does some game read the controller twice?

Please read the immediately preceding section titled "Evil Details".

Is there any case where a game read controller three(or more) times in history?

Try logging $4016 writes on any game published or licensed by Nintendo that uses DMC.

Boolean wrote:Hello, everyone. I searched "reread" and didn't find the target. So I post it.

wiki wrote:Turbo
A turbo controller such as the NES Max or NES Advantage is read just like a standard controller, but the user can switch some of
its buttons to be toggled by an oscillator. Such an oscillator turns the button on and off at 15 to 30 Hz, producing rapid fire
in games. A controller MUST NOT toggle the button states on each strobe pulse; that'll break any game that rereads the
controller.

I have simply verified what wiki said, and it does exist reread case.
Why does some game read the controller twice?
Is it necessary to do that when I write an NES demo?
I guess it is related to hardware but don't sure.
Is there any case where a game read controller three(or more) times in history?

Not sure of the context for the wiki post, but I can share my own insight with my current project. As stated above, if you use DPMC samples you need to verify a valid return value by reading the controller multi times at each loop update. My code reads the controllers in the main loop much faster than the NMI @ 60Hz.
I have tried:
1. an open ended routine that reads the controller till it get two in a row that match
2. a Routine that reads twice and updates only if they match
3. and finally settled on a routine that does three reads and compares for two that match or doesn't update.
All these routines read the controller back to back without 'breaking' the loop.
I don't think it is a hardware issue, but has to do with how the game rom handles the controller reads. For a very high rapid fire rate, there may be glitchy movement of sprites if there is no checking for false values returned, but that's just a guess.
yogi