#mc68000

I have more ideas for projects than time or budget to work on them. Already this year I've gone completely through the design process for two new large homebrew projects that are currently too large for my project budget, plus a few small ones I never got around to ordering. So rather than spend more than I should taking on a new project, I decided to revisit an existing one.

It's been over a year since I last worked on the original Wrap030 project — my old stack-of-boards MC68030 system. Its current configuration includes the main board with CPU, ROM, RAM, UART, & glue logic; a hand-wired breakout board to add a second UART; a custom video output board; and a mezzanine board with FPU and provision for an IDE disk that is not yet working. It has been functional in this configuration since last February.

My goal for this project from the beginning was to build something capable of running a proper operating system, like Unix System V or Linux. To do that though, I'm going to need to get disk access working.

I had started on disk access, but didn't quite have it functional when I turned my focus to integrating all of boards into the single Wrap030-ATX motherboard. I had added IDE cycles to the CPLD on the mezzanine board, and had added a few rough drafts of disk functions to my ROM. I set the project aside when I realized my function for checking dish presence was reporting a disk was present when there wasn't one.

I have worked with IDE before — my original 68000 project had an IDE port on it. I had gotten that project to the point where I could read a sector of data from the disk, but never could wrap my head around how to actually navigate even a simple file system like FAT16. It was this code that I had adapted for Wrap030, so when it didn't work, I assumed it was a problem with my logic.

Turns out I had just inadvertently clobbered a register in the disk check function. The logic worked just fine. I was able to write a couple quick BASIC programs to read a sector of data and even run code from the boot sector.

My assembly function for reading data from disk however was still not working.

I tried rewriting it.

I tried rewriting it in C instead of assembly.

I tried again, and again, and again. I added delays and loops and print statements and everything I could think of. I scoured datasheets, read though all the different release versions of the ATA specification, ported code from other projects, looked at every example of reading from an IDE disk I could find.

No matter what I did, I always got the same result.

This did not make any sense. Reading from an IDE disk involves setting up the sector address, the number of sectors to transfer, sending a read command, and then reading the IDE data port 256 times per sector. Each time the data port is read, the disk will give another 16-bit word of data. But for some reason, all I was getting was the first word of data returned 256 times.

There is nothing in the specification to explain this.

I knew there was nothing wrong with my logic, because I could read the data just fine with my BASIC program or by manually poking the right addresses using the monitor. Maybe there was some edge case affecting timing when running in assembly, but even adding delay loops and print statements didn't have any effect.

I reached out for help. I got great feedback on my read functions and my timing and how IDE and CompactFlash cards worked, but still could not solve this problem.

But then @ZephyrZ80 noticed something —

I had shared my code and was explaining that I had added some extra NOP instructions to enforce minimum time between IDE access cycles in PIO-0 mode. At 25MHz with cache enabled, the 68030 can complete an instruction in as little as 80ns, so a few NOPs would ensure enough time elapsed between cycles.

With cache enabled.

… cache enabled.

… cache.

The 68030 has 256 bytes of data cache. My disk read function is running in a tight loop that only really hits a few addresses; not nearly enough to invalidate and flush the entire 256 bytes of cache. The CPU does have a cache inhibit signal to use with peripherals that return new data on subsequent access to the same address, but it turns out I was only asserting it when accessing the UART on the main board.

It's a simple enough hypothesis to test. When I initially added support in my ROM for enabling cache at startup, I included user functions for enabling and disabling cache.

… It was cache all along.

I ordered some boards for my Mac SE accelerator. I'm quite pleased with how they look.

Assembly wasn't too bad. The 0805-size resistors and capacitors can be a bit fiddly to work by hand, but they're still manageable. In all, it just took a couple hours to put together the first test board.

It fits in my SE with plenty of clearance between it and the floppy drive cages.

So the big question is — does it work?

Of course not! What fun would that be?

First run attempt was just a garbled screen, and not even the infamous checkerboard pattern. I didn't expect it to be fully functional at first attempt, but that pattern is a new one.

Time for the logic analyzer.

I can see the hand-off working. The accelerator asserts the Bus Request signal to take the SE 68000 off the bus, and waits for the Bus Grant signal in response. Once the 68000 is off the bus, the 68030 is brought out of reset and allowed to take over. That much worked as expected.

Next thing to look at is whether the 68030 is starting up properly. The first thing it's going to do is load the initial startup vector and stack pointer from ROM. These are 32-bit values, so each will take two access cycles over the 16-bit SE bus. It was getting stuck on these initial read cycles, waiting for a bus termination signal

The 68k processor family has a great asynchronous bus that relies on peripherals providing an appropriate bus cycle termination signal. Macintosh computers generate the termination signal synchronous to the system clock. What I found was the faster 68030 (running at 12MHz for testing) was sometimes ending one cycle and starting the next within a single clock pulse of the main 8MHz SE clock. The SE motherboard logic never saw the new CPU cycle begin.

My first draft of logic was largely asynchronous, and paid little attention to the system clock. But since the SE motherboard logic is synchronous and expecting 68000 bus cycles, I need my logic to better emulate 68000 bus cycles.

So I rewrote nearly all of the logic for the CPLD to roughly emulate 68000 bus cycles.

Never thought I'd be happy to see a Sad Mac error. That error means the 68030 is running enough code for the initial ROM checksum to fail. That's quite an improvement over not even loading the initial vectors.

Dynamic Bus Sizing

I finally figured out what was going wrong with my RAM. The 68030 has a pretty unique system bus that can interface with 8-, 16-, and 32-bit wide peripherals, regardless of alignment and actual transaction size (with some exceptions). This is incredibly useful because a single instruction, MOVE.L for instance, can be used without having to know exactly how the hardware is built. The MOVE.L instruction can move 32 bits to an 8-bit peripheral one byte at a time, with the CPU automatically dividing up the transaction into bytes.

On my 68000 build, I had to use a bit of a hack with a register to use an 8-bit ROM with the CPU's 16-bit bus. For the 68030, I can just tell the CPU that it is accessing an 8-bit device, and it will go ahead and fetch that second byte.

What does this have to do with my RAM problem?

I'm using four 8-bit wide SRAM chips so that I can use the full 32-bit 68030 data bus. For any read operation, the CPU will ingest the full 32 bits and ignore what it doesn't need.

The problem comes when writing to that 32-bit memory bus. When the CPU starts a write operation, it doesn't know what size the peripheral is, and doesn't know what data may already be stored in that location (if it's even a memory device at all). So when, for instance, the CPU needs to write a 16-bit word, it will duplicate that word on both the high and low words of the 32-bit bus. It's up to the peripheral to decode the two least significant address bits and the two bit size parameter to determine which bytes the CPU actually intends to be written.

I did not implement the size decoding. Every time the CPU wrote to RAM, I was latching the entire 32-bit data bus, regardless of the transaction size.

I had been writing ever more sophisticated exception handler routines to try to get some understanding of what was happening when a program crashed. Ultimately, it was a bug in one of these routines that finally led to the answer.

Instead of printing out the system stack, a bug ended up printing out the entire contents of memory.

This gave me something I could compare against. The BASIC interpreter I'm trying to run sets up a jump table during its initialization routine. Each jump instruction in the table is three words — a one word JMP opcode ($4EF9), and a longword destination address.

Compared with the simulator output and a listing of what the table should look like, it quickly became obvious what was happening. When the code tried to write the one word opcode $4EF9, RAM was latching the two word $4EF94EF9 — mangling whatever was already in RAM at the second location.

So now I know what is going wrong, and thanks to a schematic in the 68030 manual I know how to fix it. I need to implement the size/address decoding for write operations to RAM.

There's just one problem. As it stands currently, the CPLD I'm using for glue logic only has one I/O pin free. I need to expand the one !RAM-CE signal into four, and add SIZ0, SIZ1, and A0 inputs.

RS232 and Reading from Compact Flash

I decided that instead of adding a MAX232 level shifter for RS232 serial directly to the board, I would be better off building a separate board. This would allow me to use the existing header with either the MAX232 or a TTL-USB adapter.

I got to use an interesting unique part on the MAX232 board — a quad capacitor network in DIP8 package. I couldn't find any similar parts still in production, and couldn't find any data sheets either. I got the part from a local electronics surplus shop, and it's perfect for use with a MAX232 because it's four 0.1μF capacitors in a convenient package.

I don't actually have a computer running right now with a proper RS232 serial port, so I used a USB-RS232 adapter to test with. I did have the Receive lines wired backwards at first, but other than that the breakout works. There is a weird quirk though that I have to connect it and turn on my 68000 computer before plugging it in to the other computer's USB port or else Receive doesn't work. Strange, but not really a show stopper.

So then I moved on to trying to read from the Compact Flash card. It's a no-name 64MB card that I've formatted FAT16. I've been looking at it by running:

$ sudo xxd /dev/disk4 | less

on my iMac to read the actual raw data from the card (especially the boot block and FAT). There is something immensely satisfying to see the exact same data come through my 68000 computer when reading the card as I got from the Mac with a proper card reader.

Generating Errors ... In a Good Way

I finally have a functional bus error generation circuit. Now if the program attempts to access an invalid address, the computer will time out and assert !BERR. This will generate a Bus Error Exception, which the program can catch and deal with appropriately. In the case of TSBug, a bus error will output the contents of the CPU registers for debugging.

I started designing this circuit in Logisim so I could make sure it ran as expected in simulation before I even started trying to build it on a breadboard. I was able to reduce it do to a minimal chip count - only adding a 74′74 dual D flip-flop, and a 74′08 AND gate to the computer, and using a couple spare inverters and a buffer for the !BERR signal.

The circuit worked just as expected on the breadboard. I soldered it into place and ... it didn’t work. I removed the CPU from the board and tested the circuit manually with switches and LEDs and it worked as expected. Replaced the CPU and it didn’t work. 

It didn’t make any sense. It worked just fine with the CPU when I first tested it on the breadboard, so why did it not work now? I pulled out the continuity tester and verified everything matched the schematic multiple times. It just didn’t make sense.

Finally, I pulled out the logic analyzer, moved the 74′74 onto a breadboard so I could monitor each of its signals, and stared at the waveform diagrams for far longer than I care to admit. 

In the end, the answer was painfully obvious. On the breadboard I had grabbed a spare 70′04 inverter for testing. When I soldered the circuit into place, I used a couple extra inverters on the 40106B Hex Schmitt Trigger I was using for the Reset circuit, since it was closest. The 40106B simply wasn’t fast enough to keep up with !AS. Worst-case propagation delay for the 40106B is 280nS versus only 25nS for the 74HCT04 I had tested with on the breadboard.

So, I upgraded. Instead of the old 40106B I had used because it was what I had on hand, I now have a 74HCT14 to run the reset circuit and to provide the two extra inverters for the bus error generator. Now !BERR works, reset still works, and I didn’t even have to break out the soldering iron to fix it.

Lending A Voice

I have Serial! Picked up a MC6850 ACIA from a local electronics surplus shop. The 6850 is much simpler than the Zilog SCC, with just a couple registers to set up. Writing a test program was much easier. 

The 6850 doesn’t have a baud rate generator, just an option to divide the Tx/Rx clock by 16 or 64. This means that the clock fed to the ACIA should be one of these multiples of a common bit rate. 

One common crystal frequency for serial work is 1.8432MHz because it can be evenly divided into the common bit rates (or perhaps the other way around). This is the crystal I had tried to use with the SCC, and without any additional circuitry, it would have given the ACIA a bit rate of 115200. That’s a little fast for a slow computer with no hardware flow control (since the TTL-USB adapter I’m using doesn’t have it). 

What I ended up using was the 6.144MHz main system clock. Now, 6.144MHz divided by 16 or 64 doesn’t give a common bit rate, but 614.4KHz does. So I used a 74′192 decade counter to first divide the system clock by 10. This gives a option of using 38400 (÷16) or 9600 (÷64). 

Ultimately, I like this design. It finally forced me to set a system clock, and it gives me a couple good options for serial bit rate. And with the 6MHz system clock, it has no problem keeping up with incoming serial data at 9600 in an inefficient polling loop, or even at 38400 with a tighter loop.