#68k assembly

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.

First Code for 68030

Another blinking light test, but this time rather than free-running the 68030 CPU and using an address line to blink an LED, it's running a small program from ROM. The CPU is clocked at 12.5MHz — the minimum for this 25MHz model — and it is counting down in a loop from 4000 between each blink.

I've wired a register to the uppermost nybble of the data bus, and I'm using the chip enable signal that will be used for the UART to select it. Anything written to the UART's address space will show up on the LEDs.

It took a long time to get to this point because I am using a CPLD for glue logic instead of discrete logic chips. This means I needed to have most of my glue logic programmed and tested in simulation before burning it to the CPLD. But that is one of the strengths of this approach — instead of blind trial-and-error debugging or poring over limited logic analyzer captures, the logic can be simulated. Logic errors are easy to spot when an entire timing diagram is laid out.

I've already wired bus signals to the RAM to begin testing it as well. I'm taking advantage of the 68030's support for various bus sizes and bus termination styles. The RAM and ROM share read/write strobes, but the ROM is on an 8-bit asynchronous bus and the RAM is on a 32-bit synchronous bus. There are a lot of parallel signals (mostly address) shared between RAM and ROM, so it was easy enough to wire them at the same time.

The flash ROM I have is rated for 120ns, which means I had to add in four wait states for proper access timing at 25MHz. What amazed me was two wait states were required for the RAM. I'm using 70ns SRAM, which still would have been fast when this processor was released, and indeed is quite a bit faster than the 100ns DRAM that Apple used in 68030 computers. It makes me wonder if there was ever a zero wait state '030 machine. Thankfully, with a CPLD driving all my logic, wait states are easy to implement with just a handful of registers.

Adding Serial

I've finished wiring in the UART and its companion MAX232 level shifter. Initial tests with the UART are promising, if a bit … strange.

At least I know that the ACIA is initializing properly, its baud rate generator is working properly, and it's outputting data.

Defective Silicon

I have had no luck getting an old Rockwell R6551 UART to actually receive data over serial. I suspect it's the chip itself, since I've confirmed my initialization program matches known working examples, and logic analyzer confirmed valid data on that pin. So I need a new one.

Turns out Western Design Center still makes a CMOS variant of the 6551, the W65C51. It's available as new stock from the usual legitimate retailers. I figured rather than risk picking up another defective unit from surplus, I'd get a new one. Besides, a newer model is sure to work better, right?

Right?

No. There are some serious flaws in the WDC implementation of the 6551. Most obvious is the Transmit Data Register Empty bit in the Status register is stuck and does not indicate that the TDR actually is empty. There is another bug that stops transmission if the chip is accessed while it is transmitting data. So interrupts are out, and polling status is out.

Members of the 6502.org forums discovered these bugs back in 2013, but the same manufacturing lot the plagued them is still the same lot available for purchase now. WDC has no interest or motivation to fix the bugs.

I thought I could work around this. Instead of checking TDRE bit and idle looping until it's set before transmitting, I could just transmit and idle loop for a millisecond(!) waiting for the chip to finish transmitting.

Sounded good at least. I never could get it to work. The first byte would transmit and then nothing else after that.

On to the Next Problem

I finally have RAM working properly. I had to remove support for interrupts from the UART to free up enough I/O pins in my glue CPLD, but byte- or word-length writes to RAM no longer overwrite adjacent bytes. Both BASIC and TSMON are now able to initialize completely and reach their first user prompts.

Unfortunately, that is all they do. The system does not respond to user input.

I double-checked my wiring and ACIA initialization data. I even removed the MAX232 level-shifter and used a USB-TTL serial adapter. When I send serial to the UART Rx pin, it never sets the Receive Data Register Full bit in the status register.

I threw together a quick test program to read and output the values of all of the ACIA registers. The Command and Control registers always report back their correct values, the Status register never changes, and the Rx Data register is always $00.

I reread the R6551 data sheet over and over, trying to see what I might have missed. Eventually I did notice a small note:

NOTE: The specified maximum cycle time for the signal on [Phi2] is 40µs. This specification must be observed to prevent loss of data

When I was building out my glue logic, I couldn't think of a way to synchronize a bus cycle with a 1MHz Phi2 clock, so I decided to not have a running Phi2 clock. Instead, I used Phi2 like a data strobe, only asserted when the CPU read from or wrote to the ACIA. Based on that note however, it is possible that the 6551 uses the Phi2 clock for more than just bus transactions. So I sat down and finally figured out how to synchronize a bus transaction with a running Phi2 clock.

I started with a clock divider that divides the 25MHz system clock by 32 to produce a Phi2 clock that's just under 1MHz. I used the falling edge of the Phi2 clock to latch the internal ACIA-enable signal and start up a state machine that handles proper timing for the ACIA chip-select and CPU !DSACK0 signals. This ensures that no matter what point in the Phi2 cycle the CPU starts a bus transaction with the ACIA, the ACIA will be activated with proper setup time before the next falling edge of Phi2, and the CPU will not end the bus transaction too early due to receiving !DSACK0 before the ACIA can produce or latch data.

I started by solving the K-maps for the state machine, then built it out in Logisim to make sure it would work like I expected. Then I moved into Quartus to program it for the CPLD. Running the simulations in Quartus I was able to see that I was activating !DSACK0 too early, and the CPU would have ended the bus cycle some 120ns before the falling edge of Phi2. Update the state tables, re-solve the K-maps, update the logic, recompile, re-run the simulation. Everything looks good, time to re-program the CPLD.

The new logic works! Phi2 runs its constant sub-1MHz cycle, and the UART transmits serial data just like it should.

But still nothing from the Rx Data Register.

At this point, there really is only one thing I haven't tested. I pulled out the logic analyzer and attached it directly to the Tx/Rx pins on the UART.

The logic analyzer confirmed that valid serial data was making its way from the terminal, through the MAX232 level shifter, and on to the UART'S Rx pin.

And somehow the UART still doesn't pick it up.

Start with the BASICs

I adjusted the addresses and UART handler routines for Enhanced BASIC to run it on my 68030. This BASIC runs well on my 68000 build and I really want to be able to compare the 6MHz 68000 with the 25MHz 68030 side-by-side.

But first I've got to get it running. Clearly something strange is going on here, with all the extra newlines in the header. It's also restarting itself before BASIC even gets too its Ready prompt.

I started adding some exception handlers to catch and report errors. Somehow BASIC is trying to access an illegal address. I can't figure out why though. This code runs just fine on my 68000 and in a simulator.

I suspect there might be a problem with my RAM, so I've started putting together some memory tests to see what's wrong with it.

Well, nothing, it would appear. Every memory test I throw at the thing passes without issue. Every actual program, however, will start out fine and then shortly after its initialization run off somewhere it shouldn't be.

I do know that my memory tests are working properly though, because I can probe data pins with a grounded wire and intentionally introduce errors.

I just can't figure out why it won't run any actual programs. In addition to BASIC I've tried a couple of monitors, and some other small test programs. All exhibit the same symptoms.

Fun with sprites

Threw together a simple program to output sprite data from ROM to the LED display. I was mistaken about the supported addressing modes for the MOVEP instruction though. It does not appear to support post increment, but it does support static offsets: MOVEP.L D0,(8,A1)

MOVEP.L will output four bytes to four consecutive odd addresses starting at the address stored in A1, plus the specified offset. The offset between each MOVEP instruction has to increment by 8 to continue outputting to consecutive odd addresses. This is what it looks like in the EASy68K emulator, with each long word highlighted: