A wild bug: 1970s Intel 8271 disc chip ate my data!

If you must suffer data loss then at least make sure you collect a good story from the experience!

I believe I have such a story.

Recently, I've been enjoying keeping my inner engineer sharp by playing around with retro software and hardware. I've taken a particular interest in floppy disc drives and old-school floppy disc protection on the BBC Micro. The BBC Micro had a couple of different popular floppy drive controllers: the older Intel 8271 and the newer Western Digital 1770/1772. Both controllers have different capabilities, and quirks by the bucketload!

My data loss occurred while experimenting with the Intel 8271, a 1970s chip and design. It's a good size and runs a little hot.

Intel 8271 (left) in a BBC Micro model B

There is not a lot about this chip on the internet, but there's a pretty good datasheet, which includes this description regarding the reset register:

It is no doubt my security background that caused me to read this description and then promptly write the value 100 (not 1 or 0) to this register.

It is at this point that my drive became possessed. Re-trying showed that setting bit D2 alone by writing the value 4 is sufficient to cause the demonic infestation:

Different drives behave differently. This drive, an older single head Chinon F-051MD seems to activate all of its widgets: the head wobbles wildly and the motor sometimes spins. My newer Mitsubishi drive makes a terrible, awful high pitch screech. It is my favorite drive and I do not wish to hear that sound ever again so there is no video.

Here is where it gets crazy: when I first did this, there was a disc in my Chinon drive and the data on that drive became toast... despite the hardware write protect tab being present.

What?

Indeed. This is sufficiently bizarre that it is worth investigation! What signals is the floppy drive receiving when the poltergeist is present? As a reminder, the BBC Micro uses a Shugart style (not PC style!) connection to the drive:

From the controller to the drive, we have Select 0, Select 1, notDIR (step direction), pin 20 (step; not labeled in the service manual diagram above), Write/DATA, WRite/ENable, Side/SELect. To sample a couple of these:

Pin 16, MOTOR

Pin 24, WRite/ENable

There are similar signals on other pins from the controller to the drive -- and they are not normal! Flipping the motor on and off at 375kHz is not an expected controller behavior and it may even be bad for a motor; I don't know.

The disc corruption comes from the abnormal signal above on the write enable pin. This is how the controller requests the drive to power up its write head, and the drive is being asked to do so at 300+kHz. There's also one of these crazy signals on the step and step direction pins, so the drive is seeking all over a range of tracks while being asked to activate the write head. Not good.

It is probably reasonable for us to fault the controller here. Under the heading "Write Protect" on page 8-124 of the data sheet, it says "The 8271 will not write to a disk when this input pin is active". This contract is clearly being violated as the write protect is being signaled by the drive.

It takes two to tango

But there is more to this! Most floppy drives also have a last-line-of-defense. For example, the application notes for my Mitubishi MF503B drive clearly state "This signal goes to ‘0’ when a write protected disk is inserted into the drive. Writing is inhibited even if the write gate is active." My Chinon drive seems to get this right most of the time, but not in the presence of wild oscillating signals. There appears to be a race condition -- perhaps if the drive is selected while the write enable gate is already active -- where a bit of current will go through the write head before the write protect condition is noticed.

Looks like I got unlucky -- wrong controller, wrong drive.

Two of my more colorful BBC Micro original discs, silver write protect tabs on display. Luckily neither of these is the disc I trashed!

Intel 8271 speculation

There isn't a whole lot on the internet about the Intel 8271. It's a slightly older floppy controller chip from the 1970s. Some of its capabilities hint of design tastes and directions that were retired in the 80s. For example, the chip is able to use host memory DMA to asynchronously scan within disc sectors for arbitrary byte strings. Perhaps a relic from the mainframe era? It wasn't used on the BBC Micro. The DMA capability wasn't wired up at all.

No other 1980s home computer that I'm aware of used the 8271. There were good reasons not to. Probably most significantly, the 8271 doesn't support double density aka. MFM, which the Western Digital 1770/1772 did. So using the 8271 carried a hit on storage capacity. The BBC Micro lived with this hit even as 1770 based machines became common. Commercial software needed to work on all machines, including 8271 based ones.

One suspicion I have is that the 8271 could be based on the Intel MCS-48 microcontroller. A few things line up, such as dates of design and manufacture. But there are also clues in the API offered. The "Read/Write Special Registers" commands is of particular interest:

As you can see there are a lot of special registers, with a fairly sparse few documented. The highest documented index is 0x22, or 34 in decimal.

One theory would be that the read/write special register simply reads or writes one of the 64 bytes of RAM present in an 8048 (or variant). There's plenty of evidence that most special register indexes seem to do something. For example, the seek and settle timing parameters end up in special registers 0x0D and 0x0E even though it is not documented anywhere. Also undocumented, 0x1D appears to mirror the formal data register. And so on.

And if the 8048 theory holds water, perhaps the undocumented and crazy bits of the reset register correspond to one of the test modes, single step mode, or external memory access mode?

From the archived MCS-48 users' manual

Summary

This is the most fun I've had while sustaining serious data corruption.

If you have any knowledge or memories of how the 8271 is actually architected, or details of undocumented behaviors, please get in touch!