[Quinn Dunki]’s Veronica, a homebrew computer based on the 6502 CPU, is coming along quite nicely. She’s just finished the input board that gives Veronica inputs for a keyboard and two old Nintendo gamepads. [Quinn] is building this computer all by her lonesome, including etching all the PCBs. She’s gotten very, very good at etching her own boards, but this input board did inspire a few facepalming moments.
In an earlier post, [Quinn] went over her PCB etching capabilities. As demonstrated by the pic above, she’s able to print 16 mil traces with 5 mil separation. This is just about as good as you can get with homebrew PCBs, but it’s not without its problems.
[Quinn] is using a photographic process for her boards where two copies of a mask is printed on an acetate sheet, doubled up, and laid down on a pre-sensitized copper board. The requirement for two layers of toner was found by experience – with only one layer of toner blocking UV light, [Quinn] got some terrible pitting on her traces and ground planes.
Two photographic masks means the masks must be precisely aligned. This example shows what happens when the acetate sheets are ever so slightly misaligned. With a 5 mil gap between traces, [Quinn] needs to align the masks to within ±2.5 mils; difficult to do by eye, and very hard once you factor in flexing and clamping them down to the copper board.
Even when this process goes perfectly, [Quinn] is pushing the limits of a laser printer. When printing at 600 dpi, the pixels of the print are about 1.5 mils. While GIMP, printer drivers, and the printer itself have some fancy software to help with the interpolation, [Quinn] is still seeing ‘bumps’ on the edges of perfectly aligned parts. This is one of those things that really makes you step back and realize how amazing fabbing PCBs at home actually is.
With most of the hardware for Veronica out of the way, it’s just about time for [Quinn] to start programming her baby. We’re not expecting a full-blown operating system and compiler, but those NES gamepads are probably crying out for some use.
[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.
Continue reading “Veronica Gets A Pair Of Gamepads And A Bugged Chip”
Two students at the University of Bristol wanted to create a computer to demonstrate how ALUs work. The result is the TwitALU, a Twitter connected mechanical calculator.
The device uses a custom 7400 series ALU based on the famous MOS 6502 processor. Instead of doing the calculations on a silicon die, the ALU drives mechanical relays. This produces a nice clicky-clacky sound as the calculation is computed.
To start a calculation, you tweet @twittithmetic with your input. A Raspberry Pi is used to load the instructions into the ALU. Once the computation is done, it’s tweeted back to you and displayed on the Nixie tube display. It’s not efficient, or fast, but it does the job of demonstrating the inner workings of the device while doing simple math.
The device’s schematics are all available on the website, and are helpful for understanding how a simple ALU works. After the break, check out a quick clip of the TwitALU in action.
Continue reading “A Twitter Connected Mechanical Calculator”
Perfection is achieved not when there is nothing more to add, but when there is nothing left to fail. Going by that metric, [Stian]’s three-chip 6502 homebrew computer is the epitome of perfection. It’s a real, working, homebrew retrocomputer using only three chips: a CPU, some RAM, and a microcontroller to bootstrap the computer and provide a video output,
The key to this minimalist build is having the entire boot process controlled by an ATMega16 microcontroller, This interfaces to the 6502 through a dual-port SRAM, a 1 kilobyte Cypress CY7C130. This dual-port RAM allows the CPU and microcontroller to access the same bit of memory, making it easy to bootstrap a computer from a bit of AVR code.
Output is provided with [Stian]’s ATMega video text generator putting a 37×17 characters on any television with an RCA jack. While input isn’t handled yet, [Stian] says it should be possible with his AVR PS/2 keyboard library.
While other 6502 homebrew computers such as [Quinn Dunki] Veronica can reach unparalleled heights of complexity, there is a lot to be said about the minimalism of [Stian]’s three-chip computer. With some clever coding and a modified parts list, it may well be possible to put a retrocomputer in the hands of everyone with a bare minimum of cost and parts.
When building a homebrew computer, there are a few milestones that make all the work seem worth it. Of course, seeing the CPU step through address lines on the blinkenlights is near the top, but even more important is being able to type a character on a keyboard and have it show up on a display. [Quinn] didn’t want her Veronica computer to deal with serial terminals or PS/2 keyboards when she typed her first characters in; instead she wanted to read a USB keyboard using 80s-era hardware.
Back in the early days of USB, design specs and keyboard manufacturers included a legacy mode in nearly every USB keyboard ever manufactured. This allows a USB keyboard to work with the ancient PS/2 protocol. [Quinn] tapped into that functionality nearly every PS/2 keyboard has using a 6522 Versatile Interface Adapter. This VIA is in the same family of chips as the venerable 6502 CPU that provides GPIO pins and timers.
[Quinn] connected the keyboard connector tapped for PS/2 input to an ATtiny13. This microcontroller reads the scan codes from the keyboards and sends them to the VIA and the rest of Veronica. It’s quite a bit of work to get to this point, but [Quinn] finally has a computer she can type on, the first step to developing software for her homebrew computer.
Gather ’round children, we’re about to hear a story about the good old days. Except that this is really more of a horror story of what it used to be like as a code monkey. [John Graham-Cumming] shares his experience programming a 6502-based KIM-1 machine back in 1985. Simple, right? The caveat being that there was no assembler or hardware for loading the finished code!
The machine in question was a label application tool for a production line. You know, product goes in bottle, label gets slapped on the side. But the slapping needed to be perfect because consumers shy away from packaging that looks shoddy. Computer control would end up being far superior than the mechanical means the factory had been using because it simplifies the ability to adjust calibration and other parameters. [John] started from square one by interfacing the KIM-1 with the existing hardware. It has a hex keyboard which is how the program was entered into the device. But first he wrote the software on sheets of notebook paper like the one seen above. It includes his hand assembled code, which was then typed in on the keypad. Kind of makes you appreciate all the tools you take for granted (like Eclipse), huh?
It seems strange that RAM is being added to a computer so late in the build, but [Quinn Dunki] must have had it in the back of her mind the whole time because it turns out to be a rather painless experience. For those of you keeping score, this makes her Veronica project Turing complete.
The brightly colored rats nest pictured above connects the new components to the 6502 computer backplane seen in the upper left. [Quinn] decided to go with two 32K SRAM modules which need very little in the way of drive hardware (it’s hanging out on the breadboard to the left). The RAM module will simply listen for its address and react accordingly. There is one hitch regarding a two-phase clock and the need to protect the RAM from erroneous data during the first of those phases.
Getting this all to work actually pointed out a bug in the ROM module she had long ago completed. After picking up on the problem she was able to correct it simply by cutting traces and soldering in jumper wires.