Veronica Gets A Pair Of Gamepads And A Bugged Chip

veronica

[Quinn Dunki]’s awesome 6502-based computer is coming right along, and she decided it’s time to add one of the most important features found in the 80s microcomputers she’s inspired by – gamepads.

There were two ways of implementing gamepads back in the 80s. The Apple II analog joysticks used a potentiometer for each joystick axis along with a 556 timer chip to convert the resistance of a pot into a digital value. Analog controls are awesome, but a lot of hardware is required. The other option is the Atari/Commodore joystick that uses buttons for each direction. Surprisingly, these joysticks are inordinately expensive on the vintage market but a similar hardware setup – NES gamepads – are common, dirt cheap, and extremely well documented.

[Quinn] wrote a few bits of 6502 assembly to read these Nintendo controllers with Veronica’s 6522 VIA with the help of an ATMega168, and then everything went to crap.

In testing her setup, she found that sometimes the data line from the controller would be out of sync with the clock line. For four months, [Quinn] struggled with this problem and came up with one of two possible problems: either her circuit was bad, or the 6522 chip in Veronica was bad. You can guess which option is correct, but you’ll probably be wrong.

The problem turned out to be the 6522. It turns out this chip has a bug when it’s used with an external clock. In 40 years of production this hasn’t been fixed, but luckily 6502 wizard [Garth Wilson] has a solution for this problem: just add a flip-flop and everything’s kosher. If only this bug were mentioned in the current datasheets…

Now Veronica has two NES controller inputs and the requisite circuitry to make everything work. Video evidence below.


15 thoughts on “Veronica Gets A Pair Of Gamepads And A Bugged Chip

    1. It’s difficult to know for sure, but Garth Wilson has reported that yes, the latest W65C22S made by WDC does have it.

      There have been some revisions by some manufacturers that did not have it, but it isn’t well documented, so you basically have to assume they all have it.

      To clarify a bit, I never determined for sure whether I was being burned by this bug and the accepted flip-flop workaround wasn’t working correctly, or whether the workaround was working, but something else was wrong.

      In the end I punted and bypassed the problematic register in the VIA with an external ‘595, as Charlie mentioned.

  1. Love the veronica system.
    I intend to do something similar but haven’t really sat down yet to do it.
    That bug smells of clock domain issues,and the fix is a synchronizer as seen here!
    If you want analog you could try the midi port hack(only resistor and capacitor needed).
    Keep it up :P

    1. Yup, instantly discharge a capacitor with an output from the computer. Then, at a certain time, set it to charge up thru the resistance of your joystick’s whichever-axis pot. Count the time it takes for the cap to reach a certain voltage threshold, connected to a single digital input.

      Many 8-bit computers did the timing in software. Needs interrupts turning off, so as not to mess the timing up. The Atari 2600’s paddles, the IBM PC’s joystick, and many other 8-bits used this method. Pretty sure that’s how Pong games worked, too, least it’s the assumption I made when I wrote a halfway-emulator of it ages ago.

      Simpler than bothering with an actual DAC, when you only need 50 or 60 samples per second.

      Some of the early 8-bit home computers had the CPU bit-bang great chunks of the hardware. Towards the end they had polyphonic sound, 3 channels, through a speaker that was only driven by a single bit, IBM-PC style. Using the (Z80 in this case) CPU registers as 3 counting timers, flipping the speaker when one overflowed.

      Similarly using the CPU to bit-bang disk read / write heads, tape reading / writing, serial ports, and even sometimes video signals. It’s handy that humans are so slow and gigantic, compared to CPUs and software.

      This was a bit of a lost art until recently, when microcontrollers have become fast enough to do stuff like this again in pure software. As I believe Quinn’s video circuit shows, IIRC.

  2. “Armchair Q.B. with 20/20 hindsight” time :)
    Rather than use separate latch & clock lines, add an extra chip, and use up another port on the 6522, why not offload pad reading to the ATmega168 (it would use the same amount of I/O – 1 latch + 1 clock + 2 data instead of 2 latch + 2 clock), and send the button data as extra “keycodes” (or even overlay them on WASD, arrows, etc) over the existing 6522 port?
    Besides reduction of hardware complexity, it would allow simpler, unified keyboard/gamepad input code on the Veronica side.
    It would even allow upgrading to the far superior SNES pads (although that would dilute the “8-bitness” of the whole exercise ;).
    Otherwise, I’m really impressed with the project as a whole and can’t wait to see more.

  3. Fix the bug and who knows how many thousands of designs it’d break?

    Zilog ran into that when they fixed a few long standing bugs in one revision of the Z-80. For years programmers had written workarounds and exploits that depended on the bugs. So Zilog had to rebug the Z-80 because the errors had become defacto features.

    I don’t recall if they also somehow made it with fixed versions of the bugs, and the original bugs so software written for the debugged Z-80 would also work.

  4. The fact that static datasheets can’t tell you there is an errata sheet available, or even that there may be a newer revision of the datasheet available is why I want to see something like the datasheet.net service succeed. What loading up a datasheet imcluded a sidebar for related errata and app notes? What if you could see a diff when a new revision of the datasheet is released?

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.