#assembly programming

More Speed, More Power, Pretty Pictures

I added some crude functions to the ROM monitor on my Wrap030 project to read the root directory of a FAT16-fomatted disk and load binary files into memory to execute. This opens up a new option for developing programs and running them on the computer, and makes it easier to keep programs on-hand for loading when I demonstrate the computer.

So what new program do I build first for running from disk? The same Mandelbrot renderer I've been using all along, of course! All I needed to do to get it running from disk was adjust a few load instructions to use PC-relative addressing and then change the vasm output to raw binary.

It ran without issue ... mostly. I had been noticing some instability with the system in general. It's not really related to the programming work I've been doing, it just tended to show itself more when doing the kind of FPU-intensive processing required for the Mandelbrot program. Sometimes the system wouldn't boot at all, sometimes it would continually reset. Other times it would run fine for a while, but randomly throw a coprocessor protocol exception (especially when using double- or extended-precision floating point values).

I had a pretty good idea of where this instability was coming from ...

As someone on Discord put it, that's a pretty little antenna I've got there.

High speed computers don't like excessively-long wiring between components. I made the ribbon cables long because there were other boards I developed for this system. But, I'm only using the CPU board, the FPU + IDE mezzanine board, and the video generator board. All that extra wire is just making things more difficult.

A year ago, when I first put these three boards together, I had to bump the bus speed down to 25MHz to get it to run. I could run the CPU board up to 56MHz by itself, and I could get it to run with one expansion board or the other up to 40MHz, but with all three boards, 25MHz was the best I could do (out of the oscillators I had on hand). I have some 33MHz oscillators now, and while I could get it to run sometimes, it was obviously far more unstable.

It was time to trim those pretty little antennas.

I left room for one more card, in case I can get my DRAM card working later, but trimmed a few inches off. The result? Rock solid at 25MHz now.

... and at 32MHz.

... but 40MHz still doesn't run.

I am quite pleased with that result. My target for this system in the beginning was 25MHz. That extra 30% speed increase is very noticeable, especially when running a program like the Mandelbrot renderer.

But I had a thought.

My FPU is rated for 25MHz, and here it's running solid at 32MHz along with the rest of the system. But my FPU board was designed to support the FPU running at a separate clock speed from the rest of the system (the 68881/68882 FPU is actually designed to support this, so I implemented it when I built my mezzanine board).

What would happen if I tried running the FPU even faster? Perhaps using that 40MHz oscillator that I couldn't use for the complete system?

Surprisingly, not a problem running the CPU at 32MHz and the FPU at 40MHz.

... or 50MHz

... or 55MHz

... or 67MHz!

Once again, I've run out of faster oscillators. This computer is running stable with its FPU clocked at over two and a half times its rated speed.

The video above is a real-time capture of the VGA output of this machine running that Mandelbrot renderer (now modified to use 96-bit extended-precision floating-point arithmetic!) with the CPU & main bus clocked at 32MHz and the FPU clocked at 67MHz. Some frames take minutes to render. Some complete in as little as seven seconds.

I am in awe. While I had big dreams when I first started working on this project six years ago, I never could have imagined it running this well at that kind of speed. I am very happy with how this project has turned out so far, and can't quite believe I actually built something like this.

I typically wrap up these posts with a plan of where to take the project next, but the project has already exceeded my expectations. There is so much it is already capable of now that I have a permanent storage option available. I guess I could try getting that DRAM card running to expand the main memory beyond 2MB, or try adding a keyboard and some text routines to complement the video card. Both are good options towards getting a proper operating system running, which has always been a goal of the project.

Either way, I'm sure I'll have fun with it.

ZippOS is an alternate operating system for stand alone “spacial computing” devices. The goal of this project is to provide end users, who at their own discression, void their warranties to replace pre-packaged software bundled with their hardware. As the lead developer of ZippOS, and as an end user of a “spacial computer”, I am displeased with the current operating software, and the decisions of parent companies that distribute these products are inheriently unstable, brown-nosing share holders and consumers, and completely unaligned with the end users. As these devices are marketed as computers, I want to provide software for said computers as a choice for the end-users who feel the same as I do.

No general-purpose computer will do much without a good amount of Random Access Memory for transient storage of code and data. Now that I have confirmed basic operation of CPU, bus controller, ROM, and serial, it's time to turn my attention to main system memory.

Every homebrew computer I've built to date, including previous iterations of the Wrap030 project, has used Static RAM. Static RAM is nearly as simple as peripherals can be — give it an address, assert a Chip Enable and a Read or Write strobe signal, wait a bit, and release. Done, cycle complete. If you don't need to retrieve some data for a good long while, it's no matter so long as the chip still has power. For a small system, SRAM is reliable and dead simple to use.

The problem with SRAM is it is also very expensive. The 2MB of SRAM I had on the previous iteration of Wrap030 cost over $20 — and it's still far from enough to run an operating system like Unix System V, NetBSD, Linux, etc. This is the reason computers generally use Dynamic RAM for primary system memory.

The difference is SRAM uses several transistors to create a flip-flop for storing each and every bit of memory, whereas DRAM uses a capacitor to store each bit of memory. This reduces manufacturing costs and increases storage density, but does come with some trade-offs. Most notably, the capacitors that store bits in DRAM will lose their charge — and the stored data with it — after a rather brief period of time. This means the DRAM capacitors need to be topped off regularly in a process known as a refresh cycle.

Another complication of using DRAM is the bus interface has been changed to allow much larger storage capacities without the physical chip package growing to absurd sizes. Instead of the chip accepting the entire address at once, it expects to be given a Row address (along with a Row Address Strobe [RAS#]) then a Column address (along with a Column Address Strobe [CAS#]), with myriad specific timing requirements for when each signal should be asserted and deasserted.

In short, DRAM is much more difficult to interface with compared to SRAM, so I've never really gotten around to it.

With one of the long term goals of this project being running a *nix operating system though, I'm going to need the larger memory that DRAM affords. So i made provision for a CPLD to serve as a dedicated DRAM controller on the Wrap030-ATX motherboard and added a couple 72-pin SIMM slots. In theory this setup should be able to support up to 256MB of RAM (if rare 128MB SIMMs should fall into my hands...).

So where do we turn when dealing with complicated timing with multiple modes and a bunch of I/O? Why, Finite State Machines, of course! That bit where the DRAM expects a row address for a little while, that's a state. And the following bit where the DRAM expects a column address is another state. And then another state to make sure the DRAM has enough time to write or fetch the data. The round it out with one last state to tell the CPU data is ready.

What about that weird refresh timing? Well, that's just few more states for the state machine. And then one last "idle" state that waits for a refresh timing counter to hit 0 or for the CPU to start a bus cycle. Laid out like that, the DRAM controller became a state machine with 7 or 8 states, a counter, and an address multiplexer.

The logic actually came together easier than expected. Not completely without bugs of course.

There's this note in the datasheets about startup initialization where the DRAM should not be accessed 200μs after power on, and there should be 8 refresh cycles before the first access. Initially I had built this entire sequence into my logic. It consumed a ton of resources and didn't really work right.

I realized that my reset circuit held the CPU in reset for longer than 200μs on power on, so I was guaranteed that first initialization time. So I removed that startup delay from my DRAM controller logic, and made a few tweaks to the state machine so it could do 8 back-to-back refresh cycles after reset.

I was able to successfully write to DRAM and read that data back!

That much proved to be the easy part. The next steps were confirming DRAM accesses worked reliably, that I had the order of my byte select signals correct, that I could identify the amount of installed memory, and that all of the installed memory was working. These are programming problems, not logic problems, and I am not a strong programmer. On top of that, not only am I working with unproven DRAM logic, but I'm also using untested SIMMs that I had picked up from Computer Reset.

I quickly ran into errors, but was it a problem with my logic? A problem with my timing? A problem with the SIMMs?

I had a large back of 72-pin SIMMs, split fairly evenly between Fast Page Mode (FPM) and Extended Data Output (EDO) types. I tried them all. Some would pass the tests for nearly all addresses but fail at the end. Some seemed to have a stuck bit. Some were just plain bad and gave errors everywhere. It didn't really answer the question about whether my logic was bad, but results were consistent enough for me to think that maybe the logic might be ok.

And then finally I came across a pair of HP-branded 8MB EDO SIMMs that passed a simple write-read test without error ...

... right around the time my serial port stopped working. But the memory test was passing, and I could at least see the serial output on the logic analyzer.

The serial port problem was a bit setback. It had been working but suddenly wasn't. Clearly the UART itself was working, I just wasn't getting anything past the level shifter. Well that at least gave me a starting point of where to look. Sure enough, one of the 12V supply pins was not well soldered. Thankfully a quick fix.

Back to testing memory, I started writing a program to identify the size of the installed SIMM and write a register I added to the DRAM controller to configure the specific geometry of the installed memory. See, DRAM has another lovely quirk — chips of the same size may have a different configuration of Row and Column sizes. For instance one chip may have a 9-bit Column and a 10-bit Row, but the next may have a 10-bit Column and a 9-bit Row, and both are the same size. If the DRAM controller just assumes 12-bit Row and Column (the largest supported by 72-pin SIMMs), then there will be gaps in the memory map that will need to be accounted for in software (using MMU, for example). If the DRAM controller knows the geometry of the installed memory, then it can present the memory to the CPU as one contiguous block of memory.

And that's where I found my next bug. The system would just hang when trying to write to that DRAM controller configuration register.

... because I had forgotten to complete that part of the state machine. The result was the state machine would end up in a state for writing to the configuration register, but then it couldn't get out of it. Once I added the missing condition to the state machine logic I was able to correctly identify the geometry and size for my installed memory!

Wow that was long. This has been the biggest, most involved step in the process of bringing up this computer yet. It turns out there are a lot of moving pieces that have to all work together to get the computer running code from ROM and reading/writing DRAM.

This is it. This is was my goal, where I was hoping to be in time for VCF-Southwest at the end of this month — my Wrap030-ATX project is running the TSMON monitor from ROM; the monitor is loading BASIC from ROM into RAM; and BASIC is running programs.

I did run into a few problems getting BASIC running because of all the modifications I've made to it over the years for my 68000 project and the earlier iterations of the Wrap030 project (most problematic being my attempt to modify it to use the FPU).

So I went back and grabbed a fresh copy of the source to work from. I converted the syntax from VASM to GNU AS, swapped out the M6850 ACIA UART routines for new ones using the 16c550 UART, and updated the addresses in the program and my linker script for the Wrap030-ATX memory map. It took a few tries to get it running, but I think the results really speak for themselves.

This is a big step forward — Wrap030-ATX, my microATX form factor 68030-based homebrew computer, is running code from ROM. Externally, all it's doing is blinking an LED, but that LED is software-controlled, with a sizable delay loop between blinks to make it something that is human-visible.

Getting to this point took quite a bit of work after the free run tests. Nearly all of the logic on this project is in CPLDs. Of note here is the primary bus controller, which handles access timing, bus cycle termination, and a settings register.

For the computer to run code, it has to be able to read from ROM. Reading from ROM requires the bus controller to decode the CPU address, assert the ROM's Chip Enable (CE#) and Output Enable (OE#) signals, wait the appropriate length of time for the ROM to output stable data on the bus, and then assert the appropriate bus cycle termination signal for an 8-bit peripheral (DSACK0#).

Once I had the minimal functionality for ROM access cycles, I was able to repeat the free run test, but this time with only the to 8 bits of the data bus (D[31:24]) pulled low.

Once I confirmed the ROM access cycle logic was working, I added the bus controller register access cycle logic. The bus controller has a single settings register that will control the Debug LED, startup ROM overlay, and ATX soft power. The CPU will need to be able to write to this register, and reading from it is helpful as well.

The bus controller logic is fully synchronous and managed by a state machine, so all that was needed to add the settings register was a couple new states for the state machine — one for read and one for write.

Put all that together, and we have a computer that can run the most basic of programs, with just a single LED for output.