A single board 68K system is fun to make. My senior year at Caltech, in 1982, I took a microprocessor lab and for my project built a general purpose 68K system (as a joint project with a friend--we shared the design, and then each built a system).

Here are photos of my system: http://imgur.com/a/jS42c

I don't recall the specs exactly, but it was 6 MHz CPU clock speed, something like 4K of EEPROM and 2K of static RAM, and two serial ports.

We almost weren't allowed to do this, because in prior years there had always been a few general purpose systems, and they wanted people to try something that hadn't been done to death. However, those were all 8-bit systems. This was the first year they had obtained some 16-bit processors, and decided those were sufficiently different that they would let us get away with general purpose systems.

Some of the part choices might seem odd. That was due to cost. They gave us the 68Ks, and I think we got the EEPROM and static RAM from them, too. Everything else was on our dime, which meant there was a lot of scrounging around at surplus stores to find things that fit into a broke student budget.

One design feature I really liked was the way we did the serial port connectors. Note that the connection to the board uses a standard DIP socket. That has two advantages:

1. It was cheap!

2. It is NOT a keyed connector. That allowed plugging it in two ways. We wired them up so that both worked, but one was equivalent to inserting a null modem.

My friend's system had a funny problem. His and mine should have worked identically, since they were the same design and same layout. However, for some reason his serial ports would not run faster than 2400 bps, whereas mine went up to at least 19200 (the speed of the fastest terminal we had access to). If he tried to go faster, some characters would work, and some would not.

It turns out that when he went to the EE stockroom to buy bypass capacitors for the serial lines, the stockroom gave him the wrong capacitors. They were much much much larger than they were supposed to be, and so were filtering out as line noise frequencies that were low enough to affect the data. If a character only had a couple 0/1 or 1/0 transitions, not too close together, it would work. If it had more, or they were too close together, it got messed up.

There was also an hilarious incident with the development system. The EEPROM burner was hooked up to some HP system. The 68K cross assembler ran on Caltech's IBM 360. So, we'd write our assembly code on the VAX, then there was a process to submit it to be cross assembled on the 360, then you could go to the HP and download it from the 360 and burn it into EEPROM.

There were strict orders to delete your files from the HP as soon as you burned your EEPROM, because the disk was near full. The thing had been there a long time, and was full of junk from old projects, and no one knew what was really junk (such as past student files) that could be deleted, and what might be someone's research files. The space crunch on the machine was starting to get very annoying.

Also, no one really knew much about the OS on the HP. Everyone just learned a set of commands by rote to transfer files, burn EEPROMs, and things like that.

One fine day, I happened to notice that there was a place in all the commands that manipulated my files that a "1" or an "A" (I forget which) appeared near the file name. Curious as to what it might mean, I tried copying a file but changing that to a "2" (or "B") for the destination, and it worked. I then asked for a listing, again using "2" (or "B"), and there was my file, alone on an empty disk.

I had discovered that there were actually TWO drives in the computer--and the second was empty (except for my file)! So...a bunch of (allegedly) bright people at Caltech had spent months, or even years, struggling with low disk space in the lab, and all that time there was an empty second disk in the computer...wow