shift/jump unit backplane PCB is etched

I got the backplane etched.  Not really my best work, but passable.  Before I started the etching I had to touch up a bunch of spots where the toner didn't transfer very well with an etch resist pen.  So that's what  all the big globs of copper are.  One improvement from my last PCB was that I was able to do a toner transfer to add a silkscreen to the top side.  Sweet!

Solder side of the board

Looks like these traces may have run together.

These traces seem to be OK, though they're on the same 10mil pitch.

Silk screen layer!

Quite readable...

shift/jump unit backplane PCB

I've started the etching process on the shift/jump unit backplane PCB.  Here's a "photo-realistic" view of what it will look like when done...let's see how close I get!

shift/jump unit preview

I've decided on the final design for the shift/jump unit.  The unit itself implements four types of instructions:

• Shift data in register A left one position and write to register B
• Copy data in register A to register B
• Jump (based on a few conditions) to an address encoded in the instruction
• Jump (based on a few conditions) to an address in register A

All four of these instruction types use the same model: read from a bus, do something, then write to another bus.  To simplify construction, I'm building a backplane that makes these buses accessible, and will implement four instruction boards and a control board that plug into it.

The backplane will have SIP sockets, and the risers will have right-angle SIP headers that plug into them.  By expanding the buses from a 40-pin socket to a single row, it will make wiring much easier.

Here's what the backplane currently looks like:

You'll notice that the traces aren't complete -- since I can't do a two-sided board, I'll have to hand-wire some of the more complex bits, such as expanding the 40-pin register A/B bus to the proper SIP sockets.

Once the backplane is complete, it's just a matter of building the various boards one at a time.  Each board will be relatively simple, making building and troubleshooting much easier than trying to build the whole thing in one shot.

Welcome, Reddit readers!

Wow, one of my friends posted a link to my blog on Reddit.  Welcome!

The number of followers on my blog have gone up quite a bit -- I'm glad folks are interested.  Please take a few minutes to go back and read some of my first posts about my project to get a feel for what it's all about.

To quickly answer some of the questions/comments that came up in the Reddit thread:

• Yes, I'm building a CPU out of discrete logic, primarily 7400-series.
• I am "cheating" on the ALU by using 4x 74LS181 units -- though I hardly think that building an EEPROM program memory, register file, RAM unit, jump processing, and an I/O unit out of discrete components can be called "cheating".  Furthermore, who cares?
• I'm not an EE, nor do I strive to be, so those of you that are will likely notice design flaws or inefficiencies that I won't see.  Feel free to point them out in the comments.
• No, when this thing is done it won't run Minix or Linux or anything.  First off, it's a Harvard architecture, which would make porting any "real" OSes quite difficult.  Harvard architecture computers are more akin to the old IBM punched-card computers -- the program memory is separate from the computational memory.  Secondly, I'm not  a software developer, so porting an OS would be grievously difficult and not fun for me.
• When it's all done, I plan to write a few simple programs in assembly language:
• A loader that lets you select a program to run.  Being a Harvard architecture, all the programs will be on the EEPROM; the loader will just handle displaying a menu and letting you pick which one to run, and give the system somewhere to go once the program finishes.
• A few simple games, such as Pong, maybe Tetris or something.
• If I can get a serial port or maybe even an ethernet connection to work, it would be really awesome to write a text-based game like LORD or something and let folks on the internet connect to it and play.  I'd say that getting to that state would probably be the farthest I'd take the project.
• Yes, I know it's been done before, in a hundred different ways.  In fact, it was projects like BMOW that gave me the confidence to think I could do it myself.
• Yes, I am aware that there are things like FPGAs and microcontrollers and various other kinds of programmable logic that would make building something like this easier.  But what's the fun in that? I don't want to write a Verilog program describing a CPU and then simply compile it and upload it to some faceless chunk of silicon on a development board.  I wanted the visceral, pat-myself-on-the-back pride that comes with building something with my hands -- to create something from nothing.
• There seem to be two distinct camps out there -- the "PCBs are lazy/cheating/etc" crowd, and the "If you're not designing PCBs you're doing it wrong" crowd.  Somehow, I'm somewhere in the middle.  As you can see from my posts, I'm dipping my toes in the PCB creation pool, and it's got pros and cons.
• Pros
• Can save hours of tedious soldering or wire wrapping when there are lots of connections to make.
• Get it right the first time by designing in a schematic, with assurance that the end product will be wired up right.
• Along with the above, avoids the dreaded "WTF just happened" after soldering 32 new wires down, and hunting in vain for the short that mysteriously appeared.
• Cons
• Time-consuming for simple designs
• Complex designs really need to have vias and at least two layers to be feasible, and etching a two-layer board is beyond my capabilities...so this severely limits what I can do with PCBs.
• Expensive -- everything from the copper clad boards to the etchant is expensive.  At least with point-to-point, the incremental cost is just a few dollars per board.
• I suspect most of this project from this point forward will end up being a hybrid of PCB and point-to-point design.  PCBs will likely be etched for things like backplanes where there are a lot of parallel connections, and point-to-point boards will plug into the backplanes to get the more complex wiring.

I'm glad folks are interested -- I'll be sure to keep you posted with posts as I continue to make progress.  Stay tuned for info about the shift/jump unit.

Program counter + instruction buffer is complete!

After about 6 hours working today, I managed to get the remainder of the program counter + instruction buffer complete.  Here's what the completed setup looks like:

 The leftmost board is the control unit, the center board is the program counter, and the rightmost board is the custom PCB I built that houses the instruction buffers.

I ended up spending about 2 of the 6 hours trying in vain to build a reliable cable to connect these two boards using standard SIP sockets and ribbon cable.  But it was all just too flaky and unreliable so I decided to brute-force it and just graft a piece of old perfboard between the two SIP headers, then wire-wrap and solder the interconnect.  It's not pretty, but it's definitely reliable, when is crucial when it comes to the more complex parts of the system.  I don't want to be chasing down a loose wire in a cable while I'm trying to debug the complex inner workings of the various execution units!

Here's how it looks with all the logic analyzer probes attached.

Success!  My test pattern appears properly on the analyzer.  I also double-checked the 40-pin sockets behind the buffers and found (and fixed) one short, but aside from that everything was perfect!

Now onward to the shift/jump unit.  I've got some new ideas about how to implement it that will take  most advantage of single-sided PCB etching without having to resort to a lot of convoluted, complex extra wiring.  More on that as I start getting the board designs finished...

PCB try #3: WIN.

I decided that my previous PCB design for the instruction buffer was too complex for what it really needed to do.  The primary goal is to ensure that the execution modules take their instruction signals from buffers rather than directly from the EEPROMs.  So I scaled the PCB design back to just a single set of buffers (24 bits) and a pair of 40-pin sockets that will be used to distribute the instructions to the boards.  Recognizing that since it's a single-side board, I'm going to have to do some manual soldering anyway, I left the final leg from the buffers to the 40-pin socket empty, since trying to route those connections on a single-sided PCB would be a mess, and it will actually be tidier to simply solder in 24 wires on the back.

Here's the front with the components attached -- pretty slick, if I do say so myself!

Now I just need to get the last 24 wires soldered in and I can start working on the jump/shift unit.

Based on my experiences building this PCB, I expect that I'll implement the jump/shift unit in several "units," each of which is relatively easy to implement on a single-sided PCB.  I'll then wire those together using wire-wrap (or solder, depending on the situation).