Skip to main content

TPC65 - History: breadboards and protoboards

Since I was a teenager, something I've always wanted to do was design and build a computer, chip-by-chip. I was inspired by the movie Pirates of Silicon Valley, specifically when Steve Wozniak built a computer, the Apple 1, that started an empire. So, I started learning electronics with the main goal of making my own computer.

 

Breadboard Shenanigans 

 In 2018, I finally got around to working with the legendary 6502 CPU and built my first rudimentary computer that barely worked.

This version of the computer relied on an Arduino Mega to act as an EEPROM and serial interface. Thus, the entire computer needed to be synchronized to the Arduino to function.

Unfortunately, building computers on breadboards is a pretty frustrating task. Breadboards are prone to manufacturing defects that can cause intermittent shorts between components, intermittent connections between the breadboard and components, massive amounts of parasitic capacitance and inductance. All of which are incredibly difficult to diagnose. The single largest problem I had was loose connections. Often, just by touching the wires, the computer would go in-and-out of stability.

I disassembled and rebuilt the computer multiple times to try and get a more stable build. Unfortunately, the breadboard version never worked properly. 

Time for Protoboard

So, in August, 2020, during the initial waves of COVID-19 lockdowns, I decided to make the computer a bit more permanent:
 

Over the course of about three days, I hand-soldered the breadboard design above to a generic protoboard using kynar wire. Kynar wire, primarily used for wire-wrapping, is nice in that it's very, very easy to solder with. You can often solder straight-through the insulation without stripping it beforehand. But, unlike Ethernet cabling, the insulation won't shrink.

And... this computer worked perfectly fine! All the issues with instability
disappeared as soon as I soldered everything down. Which, ultimately leads me to a somewhat common piece of advice that I learned first-hand the hard way: breadboards can't be trusted! The amount of time I spent chasing ghosts with this computer was almost 100% due to the breadboards themselves. I was convinced at several points that I wasn't understanding the datasheets correctly.

The downside with this particular build, apart from how long it took to make, is that it's relatively fragile. Kynar wire is handy, but very thin. I used this particular build for months, until I decided to try laying out a retro computer on PCB. 

Continued on next post.


Comments

Popular posts from this blog

TFORTH

Overview TFORTH is my custom version of FORTH. It started as a programming exercise that grew into a somewhat usable language. This version of FORTH is a bit odd in that it has no compiling mode at all . Not even bytecode compiling. Everything is 100% interpreted. So, it's essentially a fancy text parser. It also doesn't try to be ANSI compliant at all. That being said, it does support a lot of common FORTH things like you would expect, including: custom function definitions, calling external functions via function pointers, full access to the system's memory map, input/output, etc.   Variables There are some big differences, under-the-hood, with this version of FORTH. For one, there are no variables. Instead, I define variables as functions with a index to the "variable page," a page in memory dedicated to temporary storage. So, for example,    5 0 ! would assign the literal value 5 to index 0 in the variable page. So, to declare a "variable," I would d...

TPC65 - Arduino Optimization

One feature/limitation of my computer design is that it uses an Arduino to replace a lot of extra logic and interface components. Specifically, the Arduino performs the following functions: Serial I/O The computer piggy-backs off of the Arduino's built-in serial to USB interface chips to communicate with the host laptop. Power-up reset circuitry The 6502 needs to run for 50 or so full clock cycles with the RESET line held low, and then RESET is sent high for normal operation. System clock Because the computer uses the Arduino's USB interface, the Arduino must be kept synchronous to the computer. If the computer runs too quickly, it could outpace the Arduino's ability to read and send data.   The last point is the most important of all. The Arduino must be kept in lock-step with the computer at any given time in order to ensure that I/O data isn't missed. Thus, the the clock output is just a digital output from the Arduino. This means that the computer's maximum spee...