Shift/Jump control board finished!

After a long hiatus, I finally got the last bits of wiring finished on the Shift/Jump unit control board.  I haven't actually powered it up yet to see if it works (even if I did, I wouldn't know for sure, since I still don't have a reasonable way to get a signal onto the A/B buses).  But at least it's all wired up and ready for the (comparatively simple) transfer boards, which move a 16-bit signal from one bus to another.

Front of the control board

Yay point-to-point wiring!

Installed in the Shift/Jump unit backplane

Nice guide to 74LS vs 74HC vs 74HCT

I've been tinkering recently with my Launchpad, with the goal of developing a 32-bit I/O expander that I can use to simulate traffic on my CPU's buses without having to run an actual program.  This will allow me to debug individual modules without having to wire up the entire system, upload test software into the EEPROMs, and trace the signals across a half dozen boards.

Along the way I've had to start taking a hard look at signal voltages for various stuff, because the TI MSP430 is a 3.6V part, and I need to drive my 5V TTL and CMOS logic with it.  This requires some logic level conversion, and as it turns out, some deeper knowledge about the differences in the chips I'm plugging into my breadboard.

I was under the mistaken impression that 74LS (TTL) logic was effectively identical to 74HC (CMOS) logic except for maximum frequency capability.  Turns out I was way off, and in fact you cannot mix these components in a system without performing logic level conversions.  I also thought that the 74LS series was the "most preferred" for new projects; but it looks like I'm wrong there too -- the 74HC series is the "best" these days.

I found this very helpful link that describes the differences in the series and notes the interoperability of them.  It also has a really nice breakdown of the basic 74 series chips, their pinouts, and how to do basic daisy-chaining of things like counters.  An excellent page to have bookmarked so that you're not constantly digging up datasheets just to see what the pinout is for a chip...

http://www.kpsec.freeuk.com/components/74series.htm

Launchpad!

Hey!  Believe it or not, I'm still here, and still working on this project.  Just not a whole lot of spare time these days :-)

This weekend I purchased something that I swore in my first post that I wouldn't -- a microcontroller.  I got myself a TI Launchpad development board.  It was only $4.30 with free shipping.  How could I pass that up?!

But don't fret -- I'm not planning to use it to take the easy route on any parts of the CPU.  I will, however, be using it to simulate certain components (primarily the register file) while I work on the other CPU components.  I'm finding that it's quite difficult to properly test the various units when I don't actually have registers with which to put data on the bus...

Once the Launchpad comes in I'll get familiarized with the interface, write a few "hello world" programs for the MSP430 and then get crackin' on the register file simulator...

Xprotolab

I recently took delivery of a Gabotronics Xprotolab device.  For less than $50 I now have a fully functional 2-channel oscilloscope, 8-channel logic analyzer, arbitrary waveform generator, frequency counter, and spectrum analyzer, all in a tiny matchbox-sized little package.  Very very cool.

Here's the device as it was shipped to me:

Out of the box

Sitting on keyboard for scale

One of the reasons I wanted an oscilloscope was to investigate why my control board doesn't seem to function properly at 32kHz but does fine at 16kHz.  So I wired it up to my control board:

I have channel one hooked to the output clock that goes to the other boards, and channel two hooked to the output of the inverter where the clock signal comes right off the crystal.

What I found was interesting.  Here are the signals while in 16kHz mode:

CH1 (top): 16kHz output clock
CH2 (bottom): 32kHz input clock

Notice that the 32kHz signal coming from the crystal/inverter is nice and square, with equal time spent at high and low.  Then I switch into 32kHz mode (which causes the output from the clock to skip the ripple counter and simply feed directly into the output buffers:

CH1 (top): 32kHz output clock
CH2 (bottom) 32kHz input clock

Yikes!  The resulting clock (top signal) is heavily skewed toward high, with barely any time at all spent at low.  The input clock clearly shows why: what was once a neat square wave has turned into a badly squished sine wave.  I suspect this is due to excessive current draw out of the inverter circuit.  Since I'm using a basic clock circuit using a crystal, two capacitors, and an inverter, the current sink into the output stage of the inverter can have very dramatic effects on how the resulting signal looks.

Since in 32kHz mode the output is going through a different (presumably higher draw and/or capacitance) path, the crystal is not able to generate the even periodic pulses that it's supposed to.

While it's unlikely that I'm going to rework my control board just to fix this one issue, it was very interesting being able to finally see down into the actual signals being generated, instead of having to infer this behavior from traces on the logic analyzer.

Shift/Jump unit control board in progress

I've started working on the shift/jump unit control board.  Today I implemented the MODSEL/!MODSEL logic and the LR selectors.  For reference, here's the schematic:

Back side of board -- point-to-point wiring being used in this case.

Front of the board -- the sharpie labels will get replaced with proper printed ones when finished.

Interface

I went ahead and soldered the headers onto the perfboard that the control bits will end up on...

 

shift/jump unit backplane PCB is finished

All done: the shift/jump unit backplane is now complete.  I think it turned out pretty darn good, all things considered.

Solder-side view.  The gaggle of wires at the bottom is the
B register bus.  Since the pinout of the 40-pin socket is
such that the rightmost pin must go to the leftmost breakout,
there was no way to run the traces without using vias, which
I am not able to do.  So a little point-to-point soldering finishes it off.

Component side

I got these plastic snap-in feet from Jameco.  Must simpler than trying
to scrounge up brass standoffs and screws.

The worst section of etching on the board.  Surprisingly I only had to
re-route two of the traces.  Also notice the gummy stuff between the
pins -- I still haven't perfected my flux application, and I tend to use
too much, resulting in a gummy mess between all the pins.

I'm very happy with how the silkscreen came out.  It's surprisingly
legible, and I'm shocked it lined up as well as it does, given
that I had to align it pretty much blind.

The next steps will be building the four data transfer modules (each board will just be a pair of 74245 tristate buffers on an etched PCB), the control module (perfboard with point-to-point connections), and an A/B register bus simulator.

The A/B register bus simulator will just be a board with 32 DIP switches (16 for bus A and 16 for bus B) and a little control logic to set the outputs to hi-Z when the write signal is not asserted.  This will let me test whether the board actually works, before having actually constructed a working register file.

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).