#mc68030

Isn't it beautiful? The lovely formatted tables of register and stack contents, the trace of function addresses and parameters, the error message ... it's the most beautiful kernel panic I have ever seen.

Why on earth would I be so excited to see a computer crash? What could possibly be beautiful about a kernel panic?

This kernel panic is well-earned. I fought hard to get it.

This kernel panic came from a current NetBSD kernel, freshly compiled and running on Wrap030, my 68030 homebrew computer. It is the result of hours upon hours of work reading through existing code, scattered documentation and notes, writing and rewriting, and endless compiling.

And it's just the start.

As I've said before, a goal of this project has always been to build something capable of running some kind of Unix-like operating system. Now that I finally have all the necessary pieces of hardware, plus a good bootloader in ROM, it's time to give it a shot. I'm not that great with this type of programming, but I have been getting better. I might just be able to brute force my way through hacking together something functional.

It is hard.

There is some documentation available. The man(9) pages are useful, and NetBSD has a great guide to setting up the build environment for cross-compiling the kernel. There are some published papers on what some people went through to port NetBSD to this system or that. But there's nothing that really explains what all these source code files are, and which parts really need to be modified to run on a different system.

I had a few false starts, but ultimately found an existing 68k architecture, cesfic, which was a bare minimum configuration that could serve well as a foundation for my purposes. I copied the cesfic source directory, changed all instances of the name to wrap030, made sure it still compiled, then set about removing everything that I didn't need. It still compiled, so now it's was time to add in what I did need.

... how ... do I ... ?

This is where things get overwhelming very quickly. There is documentation on the core functions required for a new driver, there's documentation on the autoconf system that attaches drivers to devices in the tree, and there's plenty of drivers already to reference. But where to start?

I started by trying to add the com driver for the 16550 UARTs I'm using. It doesn't compile because I'm missing dependencies. The missing functions are missing because of a breaking change to bus.h at some point; the com driver expects the new format but the cesfic port still uses the old. So I needed to pull in the missing functions from another m68k arch. Which then required more missing functions and headers to be pulled in. Eventually it compiled without error again, but that doesn't mean it will actually run. I still needed to add support for my new programmable timer, customize the startup process, update hardware addresses, make sure it was targeting 68030 instead of 68040 ...

So many parts and pieces that need to be updated. Each one requiring searching for the original function or variable declaration to confirm expected types or implementation, then searching for existing usages to figure out what it needs ... which then requires searching for more functions and variable types.

But I got something that at least appeared to have all the right parts and compiled without error. It was time to throw it on a disk, load it up, and see what happened.

Nothing happened, of course. It crashed immediately.

I have no debugging workflow I can rely on here, and at this stage there isn't even a kernel console yet. All I could do was add little print macros to the locore startup code and see where it failed. Guess, test, and revise.

I spent a week debugging the MMU initialization. If the MMU isn't properly configured, everything comes to an abrupt halt. Ultimately, I replaced the cesfic machine-specific initialization code and pmap bootstrapping code with functions from yet another m68k arch. And spent another day debugging before realizing I had missed a section that had comments suggesting it wasn't for the 68030 CPU, but turned out to be critical for operation of kernel memory allocation.

Until this point, I was able to rely on the low-level exception handling built into my bootloader if my code caused a CPU exception. But with the MMU working, that code was no longer mapped.

So then came another few hours learning how to create a minimal early console driver. An early console is used by the kernel prior to the real console getting initialized. In this case, I'm using the MC6850 on my mainboard for the early console, since that's what my bootloader uses. And finally the kernel was able to speak for itself.

It printed its own panic.

The first thing the kernel does is initialize the console. Which requires that com driver and all the machine-specific code I had to write. The kernel is failing at its step #1.

At the end of my last post on getting NetBSD running on my 68030 homebrew computer, I had a (mostly) working root shell prompt in single-user mode.

Well here we are a week or so later and I have ... a (mostly) working root shell prompt in single-user mode.

It turns out bringing up a modern operating system is hard.

The first problem was the default collection of init scripts. There are a ton of scripts in /etc/rc.d that are run at startup to finish bringing up the system after the kernel is loaded but before users can log in. These scripts do things like check filesystem integrity, mount disks, initialize networking, etc. Most of the scripts are not relevant to my specific hardware, but I wasn't even getting far enough along for that to matter. I was getting stuck early on in two steps in particular: filesystem checks and initializing /dev/random.

The latter issue there's not really anything I can do about. I can copy a pre-populated entropy file from an existing system, but I don't have the hardware support for random number generation. Frankly I don't need it either, if I'm not doing anything with cryptography like using TLS certificates. So remove that script.

I can check and repair the filesystem much faster on my host machine, so remove that script for now also.

And remove all of those networking-related scripts since I don't have the hardware for networking either.

…

It turns out init scripts have declared dependencies on other scripts. So removing one, especially an early important one like checking filesystem, means editing others to continue without it. It's dependency hell.

So for the sake of just getting things running, I removed everything and wrote my own. There were just a few things I really needed, like mounting the root filesystem as writeable and initializing TTYs.

It took a few tries to get it right, but my init script did eventually run without stalling. This was it, time for it to initialize the terminals and print the login prompt …

init: can't add utmpx record for 'tty01': Bad file descriptor

… That's not a login prompt. That's not a login prompt at all. What does that even mean? What on earth is utmpx?

The error message itself is printed by init. UTMPX keeps record of logged-in users, and it does so using a file, /var/run/utmpx. But is the bad file descriptor error relating to that file or to /dev/tty01?

I was stuck here for a while. I tried everything I could think of to make sure my tty devices were created properly and with the right major/minor numbers and permissions. I finally realized that I didn't get the error if the utmpx file didn't exist. So something was wrong with writing the file, possibly due to never being able to properly shut down and close out the file & filesystem any time it got created. But it's easy enough to just make sure it's deleted by the init script before getting to that point.

It's at this point where I went down a rabbit hole of trying to create a RAM disk for root just to eliminate the possibility of lingering problems with the ATA driver or similar. This proved to be a dead end because the system would only boot single-user from a RAM disk, and I also got stuck in dependency hell trying to get it to compile a RAM disk image that included the actual login binary.

After some more experimentation, I learned that if I had no extra terminals defined in /dev/ttys, then it would at least show the login prompt on the root console, but would never actually log in. Kernel debugger & SIGINFO would show that login was stuck waiting for something. If I did have multiple terminals defined, I would never see a login prompt and it would show that getty, which spawns the terminals, was sleeping, waiting for something.

And that's where I'm stuck. I have no idea what these programs are waiting on, and don't really have any way to check. I suspect it's possible they need those hardware interrupts I don't have, but since I can see activity on the UART chip select lines, I don't think that's the case.

So for now, facing a looming deadline and burnout setting in after a solid month of working on this, I've decided to accept the victory I have and admit defeat where I must. I have a computer that I built myself which can load and run a modern operating system up to the point of a root shell prompt. That is a remarkable accomplishment and I will absolutely accept that victory. There is already so much the machine is capable of just getting to that point. And going from knowing nothing about porting an OS to a new machine to having a running shell in under a month is a victory all on its own.

But, I was not able to get it fully running in multi-user mode on all of my terminals. I will happily accept that defeat in light of the major victory of getting as far as I have.

To run a simple program, a computer needs some kind of storage, and some kind of input/output device. To run a simple operating system, a computer will also need some random-access memory for holding onto information temporarily. To run a sophisticated operating system that supports many users and programs reliably, a computer will also need some way to make sure one user doesn't hog resources and prevent other users' programs from running.

My Wrap030 homebrew computer currently has a flash ROM which holds a bootloader program from starting other programs from disk. It has 16MB of RAM. It has 9 total serial ports for I/O. It just needs that last thing to be able to run a sophisticated operating system.

I've written before about how computers can share a single processor between multiple users or programs. The simplest option is to have each program periodically yield control back to the system so that the next program can run for a little while. The problem with this approach is if a program malfunctions and never yields control back to the system, then no other program can run.

The solution is to have an external interrupt that can tell the CPU it's time to switch programs. Each program can be guaranteed to have its chance to run because if a program tries to run too long, that interrupt will come to force a switch to the next program.

The way this is typically accomplished is with a periodic timer — ticking clock that interrupts the CPU regardless of what it's doing.

And that's what my Wrap030 project is missing. I need a timer interrupt.

The catch is, my system has always been a little fragile. I have it running well right now with three expansion boards, but there's always a risk of it being very unhappy if I try to add another expansion board. If I could somehow pull a timer interrupt out of what I already have, that would be ideal.

Nearly all of the glue logic pulling this system together is programmable logic in the form of CPLDs. This gives me the flexibility to add new features without having to rework physical circuitry. As it happens, the logic running my DRAM card currently consumes under half of the resources available in the card's CPLD. It also has several spare I/O pins, and is wired to more of the CPU bus than any other chip in the system.

So I added a timer interrupt to my DRAM controller.

It is very minimal — just a 16-bit register that starts counting down every clock cycle as soon as it's loaded. When the timer gets to 1, it asserts one of those spare I/O pins to interrupt the CPU.

And all it took was a couple bodge wires and a little extra logic.

I put together a quick test program to check if the timer was running. The program would spin in a loop waiting to see if a specific address in memory changed. When it changed, it would print out that it had, and then go right back into the loop. Meanwhile, the interrupt service routine would change the same address in memory every time the timer expired.

This is great! It was the last significant piece of hardware I was missing to be able to run a proper operating system like Unix or Linux — which has always been a goal of the project. While I still have much to learn before I can attempt to get a proper OS running, I can still put this new timer to use.

I had previously built my Multibasic kernel to run cooperatively. Each user instance of BASIC would yield control whenever it needed to read or write to its terminal (which it does at every line while running a BASIC program, checking for the Ctrl-C stop sequence). This worked well enough, but a particularly complex BASIC program could still slow down other users' programs.

Converting my Multibasic kernel from Cooperative multitasking to Preemptive multitasking was actually fairly easy. I just needed to initialize the timer at startup, and add an interrupt service routine to switch to the next user.

(It's not really something that can be seen in a screenshot, but it's doing the thing, I promise.)

I left off previously with init immediately crashing when trying to run NetBSD on Wrap030, my 68030 homebrew computer. I was completely lost and didn't know where to start looking. The error code it gave, 11, didn't tell me much.

Until now, most error codes I've gotten have been defined in kernel errno.h, which has 11 defined as:

EDEADLK 11 /* Resource deadlock avoided */

That … also isn't helpful. I'm still not entirely sure what that means, but since this is process 1 we're dealing with, I didn't think it was relevant.

Finally, I was able to find someone who had encountered the same error six years ago. Helpful soul [Martin] explained the exact cause of the error, how to fix it, and why the kernel errno didn't line up:

I'm running a NetBSD live disk on a laptop as a test host, so I mounted my disk on it and spent some time with mknod adding the essential device nodes, referencing the "majors" file for my arch. Sure enough, on next boot it skipped right past the point it had been panicking. It worked for a bit then finally printed on the console:

Enter pathname o

Enter pathname of what? The machine appeared frozen. Nothing further printed, and it responded to no input.

I was afraid this would happen. That string is 16 characters. The 16C55x UART chips I'm using have a 16-byte buffer. The system is hung up waiting for the UART to interrupt to indicate it has finished transmitting everything in its buffer.

There's just one problem — I don't have any serial interrupts wired.

I have a confession to make. Until a few weeks ago when I got my timer working, I hadn't really worked with hardware interrupts before. So between a limited understanding of how to use them effectively and limited board space, I had omitted the interrupt signals from my 8-port serial card. This was now a Problem, and I was going to have to find a solution.

I had a few options:

Force the com driver to 8250 mode so it doesn't try to use the buffers

Use my timer interrupt to check status bits on the UARTs and fake the interrupts

Deadbug an interrupt handler onto my serial card

Respin the serial card

Option 4 would've been expensive and risked passing my deadline. I wasn't sure option 1 would even help. And option 3 would have been difficult and error-prone. I decided option 2 would be the way to go so I set about researching how to accomplish it

I spent a few hours digging through the com driver. In the process I found softintr(9), a native NetBSD software interrupt process that looked like just the thing I needed. Digging in a little deeper, I realized that the com driver was already using softintr. And then I realized all it needed to do polled mode serial ports instead of interrupt-driven was to set a single variable, sc_poll_ticks, before initializing the driver. It's such a simple thing, but it's not really documented anywhere I could find, so the only way to know it was even an option was to spend hours studying the code.

With that in place, I recompiled my kernel and tried again.

It was asking for a shell. This is promising. I accepted the default shell, /bin/sh, and waited a moment. It printed a single #.

I had a shell prompt.

I typed in the first thing that came to mind, echo "hellorld" (thanks, [Usagi]). It responded:

hellorld

and printed another # prompt.

I had a working shell.

This is a major milestone. I have a modern operating system kernel loaded and running on my homebrew computer, and I have a functional root shell. I can navigate disk directories and run commands and programs.

But only as root, and only on this one console. I have seven other serial ports I want terminals on, and I certainly don't want them all running as root.

What it's running here is single-user mode. It is just the kernel and a few core services, somewhat analogous to Safe Mode in Windows. It's a fall-back for setting up or repairing a system. It's not quite the full operating system just yet.

Getting the rest of the operating system up and running is going to be a significant task, on par with getting just the kernel running. Setting up a working Unix system from scratch is not easy. It requires a lot of detailed knowledge of the various programs and libraries and config files scattered across the disk. For a sense of scale, the AT&T Unix System V manual was over 1100 pages, plus an 800 page programmer's guide and a handful of other manuals … and that was 40 years ago. That's a lot of specialized knowledge that I don't really have.

But still, this is something I've wanted to do for years and after countless hours of work, I finally have a glimpse of what it can look like. I have a lot to learn and a lot of work to do yet, but I'm certain I can figure it out.

Just before disaster struck with my 68030 homebrew, I had a plan to fork the project and take it in two directions in parallel.

The first would be my minimal Multibasic setup which was running great and was something I would be proud to exhibit at VCFSW '25.

Since that was working well, I didn't want to do anything that might make it not ready for the show. So I had assembled a second main board that I could use with other peripheral cards to continue development. My plan was to rework the memory map to move ROM and I/O addresses to the upper half of the 32-bit address space, which would allow me to use a DRAM card for up to 16MB of contiguous memory starting at address 0 — a perfect setup for running a proper OS

And then I burned up my good mainboard.

I had a spare CPLD on-hand, and I was able to get another 40MHz 68EC040 for cheap. But the 4Mbit SRAM chips are expensive, and I thought that if I was going to be paying for more SRAM, I should get the 12ns parts that would allow me to run RAM with no wait states at 50MHz. Which would require adapter boards, and more pin headers, and would have just driven the cost up even more.

Paralyzed by indecision and the rising cost, I decided to switch gears. I already have the DRAM board I built years ago, I just needed to get it working. And if I'm doing that, I may as well do the work on reorganizing my memory map.

So that's what I did. I made a new branch on my newly cleaned up repository, and set to work. I updated the mainboard bus controller logic to remove the no-longer-needed SRAM control, adjust the ROM address to start at 0x8000,0000, and move the 6850 UART address to 0x8008,0000. This freed up the entire 2GB space between 0x0000,0000 and 0x7FFF,FFFF for the DRAM card to use for main memory (my bus connector layout only allows for up to 16MB main memory, but that's plenty for my purpose).

Next, I needed to build the control logic for my DRAM board. I've done this once before on my Wrap030-ATX project a couple years ago, so I used that logic as a starting point. It … kind-of worked. Sometimes. Maybe.

I was getting random errors all over the place. Sometimes it was able to copy all of ROM into RAM and verify the copy without error, but it would fail when running code from RAM. Sometimes it wouldn't even pass the first two simple tests of writing a longword to RAM and reading it back.

Back to the data sheets to plan out the logic. I drew out a new timing diagram down to 1ns resolution, accounting for the specified propagation time for my CPLDs, and the measured signal delays for my CPU. This gave me the information I needed to build out a new state machine for the DRAM controller. In the process I also caught a few other bugs in my original logic, such as not ensuring the DRAM Write Enable strobe did not get asserted during refresh cycles.

The new state machine worked much better, but I got my timing off a bit. It worked reliably at 16MHz, but not at the intended 25MHz. At least it was working though; I can move forward with 16MHz.

The next thing to do was get my 8-port serial card working with this new setup. Every time the computer tried to access one of the 8 serial ports, it would get a bus error. This was a tough one that had me stuck for a while.

It looked like the serial card was getting addressed and asserting DSACK0# as expected, but I couldn't confirm the signal was making it back to the CPU. Every time I tried to measure the DSACK signals, the probes would increase the line capacitance (I think) too much and cause the whole computer to fail before it even got to the point of trying to address the serial ports.

I have the DSACK signals in a wired-or configuration. The logic on each card connects to the proper DSACK signal via an open-collector buffer, and is able to pull the signal low to signal that card acknowledging the bus cycle. The signal is then pulled back up to +5V by a 1kΩ resistor. This works well enough for small, slow systems, but with long bus wires or lots of chips on the bus, the extra capacitance means it can take a long time for that pull-up resistor to get the signal back up to +5V.

I made a change to my DRAM controller to actively drive the DSACK signals to +5V briefly at the end of a bus cycle before setting the pin to high-impedance. This helps ensure a fast rise time at the end of the cycle so it doesn't disrupt the next bus cycle.

It didn't fix the problem with the serial card, but it did allow me to actual probe the signals live to see what was happening — the Bus Error signal was getting asserted immediately after the CPU addressed the serial card. This didn't make much sense to me. My main board logic will assert Bus Error if no peripherals acknowledge a bus transaction within 64 clock cycles. Nothing should be asserting Bus Error so quickly.

Except … the main board bus controller. My original memory map used the lower half of the address space for the main board, and peripheral cards used the upper half. So my original main board logic was built to assert Bus Error immediately for an unused address in the lower half of the address space. I hadn't properly removed that bit of logic, so it was now asserting Bus Error for any accesses to the upper half of the address space that weren't used by the main board.

The challenges of working on a project after six years. I had forgotten that bit of logic was even there.

With that erroneous Bus Error assertation removed, the machine was finally able to properly load my Multibasic kernel and run BASIC for 8 users again.

In April of 2020, user [CaptainTivo] commented on [Ken Sherrif]'s look inside the Am2901 bit-slice processor:

The Apollo workstation ... actually emulated the 68000. I was in the Motorola 68000 design group from 1985 to 1996. The first project I worked on was the 68030, which was essentially the 68020 with an integrated MMU and virtual memory capability. We did have a full hardware breadboard of the 68020. The 68030 breadboard was 18 24"x24" wirewrap breadboards, each with a 23x14 array of 20 pin DIP sockets! The chips were mostly PALs and RAM/ROM, no bitslice. This was before software logic simulation was a real thing.

Normally I would not have been allowed to take pictures of this, or even bring a camera into the building, but I gave a talk on the 68030 at Stanford in 1986 and I got permission …

I did not work on the emulator (that was the Tiejen brothers), I did design on the TLBs.

The cards were about 24" on a side, with 20 pin wirewrap DIP sockets. Mostly PALs, RAMs and ROMs. Although the 68020 and 68030 have relatively complex instruction set, a lot it was implemented in microcode, so the actual logic is quite as hairy as you might think.

It's a fascinating look at what it took to develop a new CPU well into the late 1980s. Imagine what it would take to build out a hardware simulator for a modern CPU in this manner.

After working through a silly design mistake and then having to reverse engineer my own project to make up for my own bad habits, my 68030 homebrew computer was running great. Better than ever, in fact — I finally had it running stable at 50MHz. It was absolutely flying.

The only thing keeping the machine from running faster was my 8-port serial card, which really needed another wait state to surpass the 50MHz mark. Luckily, I had designed the board with this need in mind and had included a jumper to select between 0 to 3 wait states. Unfortunately I had missed a single exclamation point in the logic equations for that wait state generator and so the signals were inverted. Not to worry — it's reprogrammable. I just need to add the missing mark, recompile, and re-burn the chip.

And that's when everything went wrong.

All I did was swap out the logic chip for the serial card, why won't the computer boot anymore? I haven't even changed the jumper setting yet. Swapping that chip shouldn't have affected anything else.

... It's not booting even with the serial card disconnected.

Out comes the oscilloscope. Reset is good, but nothing else is moving. All the bus signals are holding steady instead of doing their jobs.

Lower the clock speed; still nothing. Double-, triple-check power supply and bus connections; still nothing. Check the clock pin on the CPU ... nothing.

There's no clock signal on the CPU, so it can't do anything.

A quirk of this design, coming from my limited knowledge when I first started building it, is that the bus control CPLD drives the CPU clock, not the oscillator directly (the original intent was to divide the bus clock for the CPU — something that was more common in the 8-bit era). If there is no CPU clock something must be wrong with the CPLD.

That CPLD seems awfully warm.

I pulled the CPLD and dropped it in my programmer. ATMISP reported that the chip was not blank. That meant it was at least responding to some JTAG queries. I tried erasing the chip and it reported success. I tried reflashing my bus controller configuration. It failed verification every time. Nothing left to do but pull it and try another chip.

That's when I noticed not only was it getting quite hot, but it was drawing enough current that the LED on my programming adapter wasn't even lit. Something in that chip had shorted and was causing excessive current draw. Luckily I have some spares. New chip burns without any problems. Drop in into the main board and success — we have clock and bus signals!

But it's still not booting.

Out comes the oscilloscope again. Address strobes are working as expected. Cycle termination is happening as expected. ROM read & enable strobes are working as expected. RAM and the on-board serial port are never getting selected.

Time for the logic analyzer. After working through bus signals 16 at a time, I finally got to the point where I was watching enough of the address bus to see what it was loading.

The CPU was stuck in an odd loop. It would load the initial stack pointer & reset vector as normal, then start fetching & executing instructions. But before it had even finished fetching the second instruction, it would go back to loading the reset vector, then start again with fetching & executing instructions. Then it would go back to the beginning with loading the initial stack pointer & reset vector, and just continue on in this fashion endlessly.

There is nothing I'm aware of in the documentation that describes this behavior. It is possible to halt the CPU on startup by trying to use a misaligned stack pointer or reset vector, but it's not indicating a halt.

Thoroughly stumped, I turned to Discord for help. One user, [arminius97] had encountered something similar with the 68020 that ultimately required replacing the CPU. Another user well-versed in the 68030, [transistorfet], helped me walk through possibilities, and ultimately we came to the conclusion that something is very wrong with this CPU.

So something burned up my CPLD and my CPU.

I have one other 68030 CPU — a full-featured ceramic-package chip rated for 25MHz (it was my plastic-package 40MHz 68EC030 that failed). Time to swap chips around and see what happens.

A memory error.

It was running code! But it was also consistently reporting a memory error on startup at address 0x00000084. Always the same location, always the same bad byte. So I swapped around SRAM chips. The error followed. I have a bad memory chip.

So that's a CPLD, a CPU, and an SRAM chip that all failed at the same time.

This is quite a setback, especially because it had been running better than ever before. I don't even have any spare 4mbit SRAM chips I can test with. Repairs will be expensive.

Perhaps this is a good time to spring for some 15ns or faster SRAM and run with no wait states for main memory. Or perhaps I could finally finish building & testing the 72-pin SIMM board I assembled for this machine years ago.

A few months ago I built an I/O expansion board for my homebrew 68030 project with a 4-port serial card to go with it, and got BASIC running for four simultaneous users. It worked, but not as well as I had hoped. I wanted to be able to run two of those serial cards to support 8 total users, but it had proven unstable enough that with just the one card I had to slow down the whole system to 8MHz.

So I designed a new serial card.

I had previously been running this computer without any issues at 32MHz with a mezzanine card with FPU & IDE as well as a video card. The main board by itself can clear 56MHz. Having to go all the way down to 8MHz just didn't sit well with me. I want this machine to run as fast as possible for its 8 users.

I put extra time into reviewing worst-case timing for all components and graphing out how signals would propagate. The 16C554 quad UARTs I'm designing around are modern parts that can handle pretty fast bus speeds themselves — easily up to 50MHz with no wait states on the 68030 bus — assuming all the glue logic can get out of the way fast enough.

Signal propagation delays add up quickly.

My first draft schematic used discrete 74-series logic for chip selection, signal decoding, timing, etc. At slower bus speeds this wouldn't have been a problem. But I want this thing to run as fast as possible. By the time critical signals had made it through all those logic gates, I was looking at already being well into one wait state by the time the UART would see a 50MHz bus cycle begin.

I needed something faster. I was also running low on space on the board for all the components I needed. The obvious answer was programmable logic. I settled on the ATF22V10 as a good compromise of speed, size, availability, and programmability. It's available in DIP with gate delays down to 7ns. Where discrete gates were necessary, I selected the fastest parts I could. The final design I came up with showed a worst case timing that would only need one wait state at 50MHz and none for anything slower.

It ended up being a tight fit, but I was able to make it work on a 4-layer board within the same footprint of my main board, putting some components on the back side. (It may look like a bunch of empty space, but there's actually a lot going on running full RS232 with handshaking for 8 ports).

New problem. I had blown my budget for the project. As much as I love those stacked DE9 connectors, they're expensive. And there's no getting around the $10 pricetag for each of those quad UARTs. Even using parts on-hand where possible, I was looking at a hefty Mouser order.

[jbevren] suggested using ganged RJ45 connectors with the Cisco pinout instead of stacked DE9, to save space & cut costs. [Chartreuse] suggested buffering the TTL serial TX/RX signals to drive the LEDs that are frequently included on PCB-mount RJ45 connectors. Both great ideas. I was able to cut 20% off my parts order and add some nice diagnostic lights to the design.

Two weeks later, I received five new PCBs straight from China. I of course wasted no time setting into starting to assemble one.

I really set myself up for a challenge on this one. I learned to solder some 25 years ago and have done countless projects in that time. But I think this might be the most compact, most heavily populated, most surface mount board I've ever assembled myself. (There are 56 size 0805 (that's 2x1.2mm) capacitors alone!)

After a few hours soldering, I had enough assembled to test the first serial port. If the first port worked then the other three on that chip should work too, and there's a great chance the other chip would work as well.

And it did work! After some poking around with the oscilloscope to make sure nothing was amiss, I started up the computer and it ran just fine at 8MHz.

And at 16MHz.

And at 25MHz.

And at 32MHz.

And at 40MHz.

And almost at 50MHz!

Remember what I said about my timing graphs showing one wait state for 50MHz? The computer actually booted up and ran just fine at 50MHz. The problem was when I tried typing in a BASIC program certain letters were getting switched around, and try as I might, BASIC just refused to 'RQN' my program. It was pretty consistently losing bit 3, likely from that signal having to travel just a tiny bit farther than the others. A problem that will probably be resolved with an extra wait state.

Good enough for a first test! A few hours more and I finished assembling the card.

I did have some problems with cleaning up flux off the board, and I had to touch up a few weak solder joints, but so far everything seems to be working. I've updated my little multi-user kernel to run all 8 users from this new card and it's running stable at 40MHz.

I need to update my logic on the 22V10 to fix a bug in the wait state generator. I would love to see this thing actually running at 50MHz — a 25% overclock for the 40MHz CPU I am currently running. I also want to expand my little kernel program to add some new features like the ability to configure the console serial ports and maybe even load programs from disk.