Turning a £400 BBC Micro (1981) into a $40,000 disc writer (1987)

The reason for the hefty price tag is likely the timing precision required to create fuzzy bits reliably. The required precision is measured in nanoseconds at a time when much of the world was still chugging along in microseconds.

The BBC Micro had a 2MHz 6502 CPU and its simplest instructions took 2 cycles, which is 1 microsecond. Is there any hope of writing fuzzy bits with such a constraint? We will see how far we can get. This work is called project Oiled Otter.

To get us in the mood, and close out the introduction, here's a picture of a 3.5" floppy disc duplicator machine. I'm amused by how much it looks like a photocopier, except the hopper takes discs instead of paper! It looks like Advanced World Products might even still sell you one.

The BBC Micro was known for excellent expandability, including the so-called user port. This port is driven by a 6522 Versatile Interface Adapter running at 1MHz. The port itself offers 8 data pins and 2 control pins. There's a lot of control offered over these pins. The data pins can individually be configured as inputs or outputs and the output logic levels can be set as high or low as needed.

Why are we looking at the user port? Well, we're going to attempt to drive a disc drive directly from the user port. By removing the floppy disc controller from the equation, we hope to get it out of the way and achieve more direct control of the disc drive and the data streams to and from it.

The above image is my lovely cable connecting the user port to a disc drive. The connectors are standard and the wires between them are just jumper wires. In a genuine attempt to create something that could have been done simply "back in day", I'm not allowing any extra electronics.

The cable wiring is as follows:

The main take away I'd encourage from this wiring setup is that the disc drive interface is probably simpler than you thought. We can drive the disc drive and query its important state with just 8 pins. It's very simple. Say you want to spin up the drive, you set the logic level to low on PB0 and PB1. Say you want to wait for the disc to rotate to the start of the track, you query the logic level on PB6 until you see a high->low transition. Stepping is just setting a logic level for "step in" vs. "step out" and then pulsing low the "step" pin.

So far so good. We have basic control of the drive but have yet to write anything.

A brief digression into electrical headaches is warranted, because I hit some. Wiring together random pairs of components might sometimes work and sometimes it may need finessing. Here's a scope view of voltages initially seen on the W/DATA pin, at the drive:

The logic 1 voltage is about 3.4v and the logic 0 voltage is about 1.5v. This is a significant problem! Acceptable TTL voltage levels are well defined:

This resolves the voltage levels perfectly and everything then works. It appears than many of the BBC Micro's ports other than the disc port don't have the oomph to drive a terminated cable. But hang on -- presumably the resistor was there for a reason in the first place? Yes. Removing it has two caveats:

The elephant in the room is: how do we provide a signal to the W/DATA pin? This is the "hard" pin. It is high bandwidth and has precise timing requirements. Let's stop dreaming about nanoseconds-level precision fuzzy bits for a moment and try and write basic FM pulses to the drive.

Most BBC Micro discs are FM (aka. DFM aka. single denisty) encoded at 250kHz. To write a FM track is actually pretty simple. Make sure drive is spinning and the write gate is open. Now, every 4 microseconds, either pulse W/DATA low then back to high (a 1 bit) or do not (a 0 bit). Most of the time, every other bit must be a 1 (a clock bit to maintain timing and synchronization).

Driving W/DATA using the CPU is hopeless. 4 microseconds is 8 CPU cycles -- certainly not enough to perhaps load a byte, shift it, and write a 0 then a 1 to the user port logic levels. A simple loop is likely to be 12+ microseconds which is way out of range. Instead, to hope to drive W/DATA fast enough, we must look to facilities of the 6522 VIA chip.

The most obvious candidate for our task is the shift register. The shift register is an 8-bit register. When in the appropriate mode, loading the shift register will cause the chip to sequentially emit the 8 bits over one of the pins of the user port. This is great -- the bits are being dealt with in parallel with the main CPU's execution, so the CPU is free to spend its time working out the next set of bits to start shifting.

Unfortunately, I was unable to get it to work. The only shift mode that has the potential to be fast enough is "shift out at system clock rate". The Western Design Center 6522 datasheet has a good diagram:

The VIA system clock is 1MHz so the shift clock will be a 500kHz signal and the resolution of the bits we can output is 250kHz. That's just enough. However, I did not work out how to get the shift clock running continuously and smoothly. Even with attempts at precise timing for shift register reloading, the scope output for the shift clock pin always looked like this:

It would appear that in the only shift mode fast enough to have a shot, reloading the shift register incurs a delay before shifting resumes. This is not suitable.

It's fortunate I hang out with clever people such as the Bitshifters Collective. (Please go and watch the latest demo, Evil Influences, immediately!) In a Slack conversation, Tom Seddon (author of the b2 emulator) suggested... using the output of the RGB port??

A video-to-disc cable... you don't see those on Amazon every day.

It's an idea I may have chuckled at initially but the more I reflected on it, the more it seemed that it might be possible. The BBC Micro uses the 6845 video chip for timing. Like the 6522, it's a quirky beast but at least the quirks are well understood on account of Bitshifters' demos which abuse the 6845. I also did some reversing work to make the jsbeeb emulator correctly emulate the Hitachi 6845. Let's see Oiled Otter working in this video and then describe what we saw:

[Inline video not showing? Direct link: https://www.youtube.com/watch?v=mdvwFpZ_G2U]

It works by configuring the 6845 chip unusually. The 6845 is run at 1MHz and frame timing is set to be a single 32 microsecond / 32 byte scanline per "frame". While every frame is being output, the 6845's video memory registers are rewritten to fetch the next 32 bytes from a potentially different location. So every 32 microseconds, a different output pattern is selected from a table of output patterns. We have configured the RGB pins to emit 8 pixels per microsecond, which is 256 pixels per output pattern. This gives a huge number of different possible output patterns. But since we're writing a 32 microsecond chunk of disc FM encodings, only a few patterns make sense. In 32 microseconds, we can fit 8 FM pulses / bits. 4 bits will be clock bits, which are usually all 1. 4 bits will be data bits, of which there are just 16 combinations.

For example, if we're writing the data nibble 0x5, the 32 microsecond output needs to look like this:

The video data bytes would be 00FFFFFFFFFFFFFF00FFFFFF00FFFFFF00FFFFFFFFFFFFFF00FFFFFF00FFFFFF. The 1st, 2nd, 4th and 5th 00s are the clock bits. In between the clock bits is the data bit pattern 0101, or 0x5.

The CPU and memory constraints balance out nicely. In the end, it's a similar setup to as if the VIA shift register had worked: some little co-processor (the video chip) is busy emitting a bunch of FM bits while the CPU is freed up to load and provide the next pattern. The memory requirements are very reasonable. The table of necessary 32 microsecond output chunks fits comfortably within 1024 bytes, thanks to the use of a special linear addressing mode. The list of look up indexes for an entire track is around 12kB, so everything is fitting nicely in the BBC Micro's 32kB of RAM.

Of course, getting this working didn't come without tripping over some "fun" quirks. The first of these is the 6845's quirk whereby it outputs black for the last character of every scanline. It is the bane of demo writers as well as disc pioneers, it seems. Here's a slide from a recent talk I gave showing the issue:

On the left, there's a demo effect plagued by vertical black stripes caused by the "last character / column is black" issue. Multiple 6845 scanlines were placed inside a single raster beam scanline and unfortunately, the black stripes are unwanted. When used to drive a disc, the effect is arguably worse: the black stripes represent unwanted pulses written to the disc.

On the right, there's an image of the solution: the waveform submitted to the disc is simply inverted. It is now ok for the last column to be black (shown in orange outline) because a zero value is always required there. Technically, this is a violation of some disc drives' timing requirements for pulsing W/DATA low. Here's a timing diagram for a drive from the era, a Mitsubishi M4852/M4853:

According to this diagram, logic 0 should be held for up to 2100ns. With an inverted waveform, 3000ns+ is to be expected. However, the drives I have only care about negative-going data pulses and not the hold time. This is not surprising. It would be possible to jiggle a few things around to avoid the 6845 quirk and also submit in-spec hold timings but this has not proven necessary so it has not been undertaken.

DRAM decay is a horror. It is what happens when you fail to refresh DRAM. From the Wikipedia article on memory refresh:

On a modern system yes, but on a BBC Micro not so much. On the BBC Micro, DRAM refresh is a side effect of the video subsystem. It relies on the fact that standard screen modes iterate across all DRAM rows within a short period of time. Perhaps you can see where this is going.... our special video mode used to output 32 microsecond frames is very much not a standard screen mode. It does not guarantee to visit all DRAM rows so DRAM decay will occur! DRAM decay is no joke. I lost various programs and disc contents due to unplanned DRAM decay. For a laugh, here's a BASIC program that inflicted DRAM decay on itself for a fraction of a second:

The bad news with DRAM decay is that if you are bitten by it, you can easily lose data.

The good news with DRAM decay is that if you are expecting it, you can usually easily work around it. In the case of the Oiled Otter, there are various critical loops with the 6845 video chip in an unusual state. For each of these, a manual incrementing memory fetch is worked in to maintain DRAM refresh.