I was surprised at how much they all weigh! And the bottom:

As you can see, they look great. Especially noticeable is the silk screen which is beautifully crisp and clear.

After doing some basic continuity checks, the first step was to attach the power related parts.

Unfortunately the SR10S05 (PDF) regulator refused to play, and I measured exactly same voltage at the output side as the input side. This was a bit of a puzzle until I looked again at the datasheet and realised that the footprint was backwards. The regulator was one of the few parts of the computer which I didn’t prototype. Had I done so this mistake would have been spotted. In any case, it was a trivial job to re-solder the part around the correct way, upon doing so a healthy 5V was observed at the Vcc points. So the only damage from that error was the fact that the silk screen didn’t match the installed part.

Next I soldered the configuration flash, JTAG header and FPGAs; the point being to verify that the JTAG chain was intact and that I could program the EPC2 configuration flash with the board powered up. After fixing an error, I inadvertently soldered a PLCC socket in the wrong orientation, I received an error about an unreliable connection in the JTAG chain. This turned out to be caused by a faulty EPC2 configuration flash. Swapping it out for a known good one removed the error and I was able to program the configuration flash. So far so good.

At this point the VHDL for MuDdy and DISCo was, and still is, very minimal; just very basic glue logic. DISCo has a single register for turning on and off the attached LED. To keep things as simple as possible the value cannot be read back by the MPU, yet.

The next step was to attach the CPU, oscillator can, and memory. I hacked together a 4 pin socket for the 8Mhz oscillator can by pulling half the contacts from a 8 pin DIP socket. It seems to work quite well.

Next, the first grand switch on: would the LED flash? No chance. The first obvious issue was with the BA and BS LEDs. They were flashing randomly, indicating that the MPU wasn’t owning the busses properly. It was clear that something was very wrong. Next I attached my logic analyser to the E clock pin. Nothing. Things weren’t looking good at all.

After a few days, and relaxing over Christmas, I had a closer look at the problem. The first job was to figure out what was wrong with the E clock. I decided that, better late then never, I would prototype using a can oscillator with a 6809. All my previous computers had used a resonator, and though the datasheet clearly stated that the EXTAL and XTAL pins could be fed a TTL clock signal, I had not seen it done before. So I breadboarded the minimal parts: MPU, oscillator can and some wires.

Initially I had the same problem, wether I used a can oscillator or a crystal: no E clock. After a little while I realised that the E clock was in fact running, but only for a few hundred milliseconds after applying power to the breadboard. This was encouraging in some ways, confusing in others. As it turned out the breadboard had a problem the MAXI09 had, some missing connections.

It seems that in the switch to KiCAD I managed to forget to connect two vital pins, /DMAREQ and MRDY to Vcc. Therefore these inputs were floating, and hence the MPU was not properly owning the busses, since this is exactly what these two pins are used for: bus mastering control. Unfortunately the only solution to this problem was to attach some jumper wires from a convenient Vcc point (I chose the power pin on the 6809 itself since it was near) to the requisite pins.

After this, and fixing some problems with the MuDdy VHDL: success, a blinking LED! In the end I went back to how I bought up the first 6809 computer on breadboard. First I drove the LED using only code in the EEPROM, then I made things more interesting by using RAM to hold a delay value, and changed this delay through the run of the program. It was a big relief to see this work, since at one point I thought MAXI09 was dead on arrival.

The next step was the UART, or rather QUART, in the form of the SC16C654 (PDF). This, too, was never prototyped. As it turns out this part is quite different from the XR88C681 (PDF) used on my previous board. One of the differences is that the QUART has two bus modes: one for Intel (called 16 in the datasheet) and one for Motorola (called 68). The bus mode is hard configured through a pin. Low for 68 and high for 16.  I naturally chose 68 mode; I’m using a Motorola 6809 after all. Also in 68 mode there is only one interrupt and chip select line. They are shared across all four UARTs. In Intel mode there is one select and interrupt per port. This would have required many more precious FPGA pins.

However, there was a vital extra difference in the form of bus timings. I hadn’t paid enough attention to the fact that the 68 mode is actually for 68000 MPUs not 680x MPUs. There is a vital difference between the two. In the 68000, the chip selects are always asserted after read/write. In the 8 bit Motorola parts it is the other way around. So in summary, the UART didn’t work, at least initially. After struggling with the problem for a little while I came up with a fairly simple fix by delaying the QUART’s chip select to a point after the R/W signal is asserted. There were probably multiple ways to do this, but the way I went for was to only select the QUART when the MPU’s Q clock was high. Q goes high about a quarter of a machine cycle later then the QUART’s address appears on the address bus. See page 3 of the 6809 datasheet for more info on the machine 6809’s machine cycle.

After this small change to MuDdy’s VHDL I was finally able to communicate with MAXI09. This was a big milestone. Using the old monitor which I wrote a few years ago I will be able to test out the peripheral ICs on the MAXI09 board, as well as use it to test out things like the DMA controller and MMU, when they are eventually implemented.

I’m now in the process of soldering up the peripheral ICs and testing each one with the monitor. So far I have attached the 6522 (PDF) VIA, and one of the joystick ports, and I’m happy to report that both appear to be working fine.

Here’s a picture of the board as it currently stands:

There’s obviously quite a bit more to do, construction wise, before I start on the implementations for things like the MMU, DMAC, disk interface, and SPI controller.

While the MAXI09 board is not, of course, fully made up yet I thought it would be interesting to list a few of the things I would improve upon, and list the mistakes I’ve thus far found: