On the NES and SNES a common feature on 3rd party controllers was "Slow-motion". It worked by repeatedly pressing and releasing the start button. Because many games simply froze gameplay when paused, this effectively caused the game to run at half speed.

I had the thought that it would probably be possible to add a pseudo-analog directional input mode in a similar way by converting an analog joystick input to a PWM signal on the D-pad inputs.

It could be synched with the 60 Hz controller reading, turning 0-100 % analog voltage into say, the number of frames in a 6 frame (100 ms) period that the direction button is pressed. This obviously wouldn't work with games that use fancy startup animations for moving, but many NES-generation games use a simple "if pressed: position/velocity++" routine that should behave fine (especially shooters).

Was/is there any 3rd-party (or even first-party) controller that did something like this?

Or am I overlooking some fatal flaw?

1 Answer 1


There's no reason why that wouldn't work. I'm not aware of any controllers that did PWM on Atari-style two-axis digital directional input, though.

I think the main caveat would be that I suppose the resolution wouldn't be particularly great, and many action games have transitional states for the main character's movement (such as sliding about or moving into and out of non-interruptible animations), or non-reversible states (in RoboCod, the main character can stretch up vertically up and up while 'up' is held, but when that's released he'll slip back down to regular size regardless of whether you start to hold 'up' again while he's descending, so analogue stretching wouldn't help). * For games with a fully free-floating cursor motion, like shmups as you suggest or the console versions of Lemmings, then the cursor would move slower like you want.

As noted by davolfman and Justme below, the NES and SNES systems control the bit-by-bit reading of the input bits (directions and buttons), so the PWMised controller with a microcontroller would detect the console's requests for input state, determine the corresponding lapse in real time since the previous read, and determine the correct output bits for the direction states based on the frequencies you want to output, and supply these bit values as they're clocked out. This means that for the NES and the SNES the PWMised controller's output will be stable and reliable, whether its square waves that toggle every frame, every other frame, or some other duty cycle. But, what the games do with the information may not be. nesdev suggests that certain NES games will not function correctly if the inputs toggle at their maximum speed.

A controller should not toggle the button states on each strobe pulse. Doing so will cause problems for games that poll the controller in a loop until they get two identical consecutive reads (see DMC conflict above). The game may halt while the turbo button is held, or crash, or cause other unknown behaviour.

For simpler systems where the directional inputs are just switches-to-ground are read in parallel (like Atari joysticks, the Master System, or the Amiga), the resolution would be limited by the synchronisation with the system (the controller input being sampled by the game once per 60 Hz, or 50 Hz frame (or 30 Hz, or 25 Hz, or FPS/n Hz frame) - or even arbitrarily as noted by Tommy) and the electrical analogue characteristics. A PWM-ised system, if it wasn't transitioning so suddenly and frequently or interacting with the rest of the electronics so that an inaccurate half-slewed voltage was measured, -could- present a digital value that transitions with a maximum resolution at the controller input is sampled. -But- getting a perfect maximum 30 Hz square wave frequency input would require synchronising with the frame rate and phase, which is unlikely generally.

As an example of a slightly different system where your approach would work great, consider the mouse on an Amiga. A joystick port on an Amiga can be used for a digital joystick, or a mouse. (Among other things.) The Amiga mouse transmits fine-grained continuous motion signals through a system not dissimilar to your suggestion to apply PWM to the digital direction inputs. The Amiga's mouse input uses a 2-signal quadrature system where the movement of the mouse becomes a pair of square wave waveforms whose relative phase encodes quanta of negative/positive movement. These waveforms are generated by plastic rotary encoder wheels inside the ball mouse, so the faster the mouse moves, the faster the wheels turn, and the faster the waveform transitions through its sequence. These waveforms are generated by LEDs and detector diodes, producing voltages which are passed through the digital inputs of the joystick port to the Amiga, where the Amiga's motherboard asynchronously updates a binary counter reflecting the accumulating the positive or negative motion of (independent axes of) the mouse instantly and in real-time. If you re-implemented the waveform encoding by some other means, for example, with a microcontroller that sampled a potentiometer (analogue stick) and output the quadrature waveforms at rate proportional to the deflection of the stick, you would be presenting an analogue input to a digital system, as you desire, and it would be at a resolution limited by the counter and its associated circuitry - certainly much higher than PWM on the directional inputs would allow. This is how projects that allow you to use an analogue stick on the Amiga to control the mouse, like the PSCD32 work.

The reason applying this method to the quadrature inputs is more fine-grained than applying it to the digital direction inputs is due to the quadrature inputs being sampled in hardware in real-time (effectively an 'arbitrary resolution'), as opposed to being sampled at a fixed rate.

*I misremembered, actually RoboCod can resume an upward stretch that's cancelled at least on the SNES - but until I can recall a better example this is the most illustrative one I can muster.

  • Strangely - I believe the C64 mouse does the quadrature-to-counter step internally within itself, and then presents this to the C64 as an analogue value as if it were an analogue paddle. You sample the analogue values in software, and then you're at the same position you are as an Amiga programmer. If I'm right, from the C64's perspective, mouse axis motion appears as if you're slowly rotating a large un-stopped circular dial potentiometer whose resistance is a linear sawtooth. But that's not relevant to your question at all. :)
    – knol
    Apr 19 at 15:20
  • Specifically on Nintendos I don't think you need to sync up with the screen: they use a shift register for polling so there's a built-in timing signal.
    – davolfman
    Apr 19 at 16:08
  • That's true - the NES controller responds to the console's requests for bits, doesn't it. I'm going to rewrite that entire section. Thank you.
    – knol
    Apr 19 at 16:15
  • The interface between controller and host unit is bit-serial, synchronized by a load signal. Sort of like SPI with chip select. It will be known when host unit loads button data to shift register and clocks it out. Should be doable by a simple microcontroller between controller and host.
    – Justme
    Apr 19 at 16:16
  • 1
    That's also true Tommy. A small digital pad connected to memory mapped IO (Amiga, GB) could read any fragment of its state anytime as frequently as it liked. I've edited that in. I was thinking of systems like Mega Drive or CD32 where controllers have enough state that it's split across multiple memory locations or pages within oncontroller registers so you'd rather just like to grab it all once and store it. For some hard evidence supporting my intuition, please read section 2.4.12 'Chattering' in the Nintendo Game Boy Programming Manual: "keys are normally read approximately once per frame."
    – knol
    Apr 19 at 16:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .