16

As you may know, the classic NES controller was not the only NES controller that Nintedo released with the NES. These included the NES advantage, the NES Max, and the Dogbone. All of these new controllers featured turbo buttons (buttons for frame perfect spam). The thing that confuses me about this is that the controllers had no way of knowing when the NES changed frame, so how how did it know when to switch from on to off or vise versa? The reason I don't think the NES communicated this information to the controller is because controllers with turbo buttons came out after the NES, so Nintendo hadn't even thought of the concept yet, and wouldn't have been able to design the NES to work with it.

Chenmunka
  • 8,141
  • 3
  • 39
  • 65
Badasahog
  • 4,031
  • 3
  • 24
  • 61
  • 1
    "...for frame perfect spam" - Can you narrow down what made you believe this is 'frame perfect' or was it just a choice of words we shouldn't read too much meaning into? – RyanfaeScotland Nov 02 '18 at 13:29
  • Yeah, just a strange choice of words. You can edit the question accordingly, if you want. – Badasahog Nov 02 '18 at 16:28
  • Na that's cool, I was wondering if it was worth looking more into this frame perfectness as it sounded interesting and different to how I imagined the controller would work. But you've cleared it up enough for me, cheers :) – RyanfaeScotland Nov 02 '18 at 16:49

4 Answers4

21

In the case of the NES Advantage at least, the Turbo rate was adjustable, by turning the dial at the top of each button.

You are right in assuming that the NES does not communicate the start of a frame to the controller. But also, these buttons do not need to know when the frames are. All they need to do is open and close the circuit; the software will usually treat each opening and closing as an individual button press. It does not matter if this device oscillates every n frames exactly, it just needs to open and close the circuit.

A similar device exists on some modern gaming controllers as well. They include a very simple circuit which just "make it look like" the user is mashing the button.

Omar and Lorraine
  • 38,883
  • 14
  • 134
  • 274
  • 2
    But wouldn't that make it miss a frame every once in a while? Is that a thing that happens? – Badasahog Nov 01 '18 at 16:54
  • 5
    @JackKasbrack sure, but it doesn't matter. Let's say the button fires a bullet of some kind. Use the turbo button and you get a load of bullets. It doesn't really matter if this is frame perfect, so it isn't frame perfect. – Omar and Lorraine Nov 01 '18 at 16:57
  • 2
    That's kind of a crappy answer, but at the same time the best possible one. – Badasahog Nov 01 '18 at 16:59
  • 4
    Often there were limits on how many fired bullets (for example) could be on screen at once (if they were implemented as sprites) so once you'd hit that limit the autofire wouldn't help you until a previous bullet had either hit something or moved off screen. I found autofire tended to be more of a hindrance than a help – bodgit Nov 01 '18 at 17:05
  • @bodgit yeah, like in Metroid! – Jonathan O'Brady Nov 01 '18 at 17:21
  • Are you sure modern gaming controllers have a built-in circuit to do this, instead of just sending a "button held down" signal to the system? The latter would allow much more flexibility, i.e. adjustable repeat rates, non-repeat behavior, etc. –  Nov 01 '18 at 18:13
  • 16
    "You are right in assuming that the NES does not communicate the start of a frame to the controller." actually a read of the NES/SNES controller is a discrete event triggered by the game, usually once per frame. This has allowed devices to be built that play back tool assisted speedruns frame-perfectly on real hardware. https://www.youtube.com/watch?v=2JNf0lAo3Ns – Peter Green Nov 01 '18 at 18:15
  • 1
    I had old Atari 2600 controllers way before NES that did the same thing. It just simulates, on the controller, mashing the button really fast... – Brian Knoblauch Nov 01 '18 at 18:18
  • 1
    @PeterGreen Not necessarily once per frame. A read doesn't mean a new frame happened, nor does a new frame mean that the controller will be read from. – Omar and Lorraine Nov 02 '18 at 07:30
  • @Undo I seem to remember reading something like that. I've slept since then, but I think some games seem to try and detect if a "button mashing driver" was being used. So they did a hardware solution instead. Not really sure. – Omar and Lorraine Nov 02 '18 at 07:35
  • @PeterGreen - Would you say that this still isn't really the NES communicating to the controller the start of the frame though? The way I picture it mentally is the controller is constantly shouting its state to the NES, and every now and then the NES decides to listen. It doesn't actually have to tell the controller it is doing so though, right? (In my head they are both people, the controller is a sidewalk preacher and the NES is a coffee vendor that works near by so hears the preacher occasionally but I think that's beside the point!) – RyanfaeScotland Nov 02 '18 at 13:35
  • @RyanfaeScotland what – Omar and Lorraine Nov 02 '18 at 13:39
  • 1
    The NES controllers use a serial protocol; the programmer signals when a new reading is desired. Unlike something like an Atari, where the process is entirely passive. But I'd still disagree with the assessment of @PeterGreen as that's not the NES signalling a frame, that's the programmer signalling a read. A software effect not a hardware feature. And not guaranteed to be frame aligned, especially e.g. if your game is suffering frame lag. But it is a hook you could hang an autofire circuit off if desired. – Tommy Nov 02 '18 at 14:08
13

According to Standard controller#Turbo - Nesdev wiki,

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.

Here are the pictures of the controller from an overview of Dendy Junior, a Chinese Famiclone, the most popular model sold in Russia in the 90s, which was stocked with turbo controllers out of the box:

controller controller board controller board backside

And these are schematics of encoder circuits compatible with these controllers (images are links to the origin articles). The 2nd one is a scan from the Radio journal, the top Soviet journal for radio and electronics enthusiasts that was famous for publishing hard-to-find information, including schematics for various devices.

schematics 1 schematics 2

This is the schematic for К561ИЕ10 which is DD1 in the 2nd scheme:

enter image description here

The 1st one, according to @duskwuff, is a free-running RC oscillator with the frequency of about 8 Hz.

The 2nd one uses a 4-digit counter on D triggers, thus switching the button each 8 controller's clock cycles. Since the triggers are edge-triggered by the same clock signals and it takes exactly 8 clock cycles to read the controller's state, this effectively switches the button between every two controller state reads.

ivan_pozdeev
  • 245
  • 1
  • 5
  • 4
    The schematics you've included show two different schemes. The first one uses a free-running RC oscillator. The second one uses a counter. –  Nov 02 '18 at 05:58
  • @duskwuff could you add some description about that oscillator -- at least, an approximate frequency (here's the IC spec)? – ivan_pozdeev Nov 02 '18 at 15:49
  • 1
    A quick run in the simulator says 8 Hz. The specs on that IC are incomplete, though, so it may have some characteristics that aren't reflected in the simulation. –  Nov 02 '18 at 16:21
  • 1
    The correct way to do it is to use an independent oscillator with either fixed or adjustable speed, as mentioned in your first quote. The NES can (and will, in the case of working around the DPCM glitch) poll the controller multiple times in a single frame, so counting latch or clock pulses is not a reliable way to detect frame rate, and will result in erratic turbo rate in games that do this. – db2 Nov 02 '18 at 19:29
  • Games almost never poll continuously during a frame. A monostable timer which would blank the buttons on the polling cycle after the timer expires and then reset the timer when the blanked buttons are sampled would make it possible to have the output active for half the frames, or 2/3, or 3/4, etc. yielding more regular results than a free-running counter. – supercat May 03 '20 at 01:41
7

To read a controller, the NES says to the controller "Save the current state of the buttons" then says "Send me the saved value for the next button" eight times. Each time, the controller sends the saved value for one of the buttons to the NES. The controller sends the button values in the following order: A, B, SELECT, START, up, down, left, right.

Because of the "request and report" nature of the signals, it's possible for a turbo controller to keep track of how many requests have been sent and report buttons as being on or off for an exact number of requests.

Note about frames: Games will usually get a full report from the controller once a frame, but be aware that there is no requirement to get exactly one report per frame. Some games don't bother requesting reports from the controller during parts of the game you can't control. Some games need to request multiple reports in a frame.

Details:

Nesdev Wiki has several documents:

https://wiki.nesdev.com/w/index.php/Controller_port_pinout https://wiki.nesdev.com/w/index.php/Controller_port_registers https://wiki.nesdev.com/w/index.php/Standard_controller https://wiki.nesdev.com/w/index.php/Input_devices

Putting the information in these documents together, I gather the process works like this:

  • The game writes a 1 to memory address hex 4016.
  • The NES sends a 1 on the OUT pins of both controller ports.

  • While the OUT pin is 1, the controller(s) will continually save the current state of the buttons.

  • The game writes a 0 to memory address hex 4016.

  • The NES sends a 0 on the OUT pins of both controller ports.
  • The controller(s) will stop continually saving the current state of the buttons, but keep the last saved values.

Repeat 8 times:

  • The game reads memory address hex 4016 (for controller 1) or hex 4017 (for controller 2).
  • The NES sends a 1 then a 0 on the CLK pin of the controller port.
  • The controller changes the D0 pin to the saved value of the next button in the sequence.
  • The NES reads the value from the D0 pin and presents it as the lowest bit value of the memory address being read by the game.

(The other data lines, D3 and D4, are used by other kinds of controllers like the Zapper and Power Pad. These values show up in other bits of the memory address being read by the game.)

Bavi_H
  • 336
  • 2
  • 6
  • 1
    Did you mean to mark this as community wiki? That means that you won't get reputation for the answer. You can flag this for moderator attention or let me know in a reply if you'd like to change this back to a normal answer. – wizzwizz4 Nov 02 '18 at 17:28
3

I don't know about these controllers, but according to this, you could know when to toggle buttons by watching the shift register clock pin. Example:

  1. set button to on
  2. wait 8 clock pulses
  3. set button to off
  4. wait 8 clock pulses
  5. go to step 1
astorga
  • 131
  • 1
  • How could the controller watch the shift register clock pin? Wouldn't that be in the console? – Badasahog Nov 01 '18 at 20:52
  • 2
    The shift register clock comes from one of the controller's pins. Since the shift register does need it to work, you could also use it for whatever you need. – astorga Nov 01 '18 at 20:57
  • 2
    @Jack the console reads the buttons once per frame. Every 8 clock pulses represents one reading of the 8 buttons on the controller. – penguin359 Nov 01 '18 at 22:18
  • @Jack Kasbrack: In this context, the shift register being referred to is in the controller. The controller uses the shift register to save the state of the buttons, then send the button values one at a time back to the NES. – Bavi_H Nov 02 '18 at 07:05