Tuesday, June 23, 2020

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.


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


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!


Mac Folklore Radio said...

Steve Furber talking about undocumented behaviour at the motherboard level: he misinterpreted the 8271 datasheet and flubbed the gap between the first and last sector of each track. :-)


Anonymous said...

I have a copy of Intel Peripheral Design Handbook from February 1979. Let me know if you want it. I am in Maryland.

armadillo said...

Interesting theory that the 8271 might be based on the 8048. In fact, also some of the pins seem to line up, e.g. pin 3 (4 MHz CLK/XTAL2 - the 8048 data sheet mentions it's possible to run the 8048 with a TTL clock input at XTAL1, maybe this also works with XTAL2?), 4 (RESET), 10 (WR) and 12-19 (DB0-DB7).

However, the 8{1,3,7}55 2048 byte RAM/ROM/EPROM+PIO also have a similar pinout, so this might be just a coincidence.

Time for a decapsulation? :)

armadillo said...

...and an update. The German wikipedia page on the 8048 gives a hint (albeit without a source):

"Programmierbarer Floppy-Disk-Steuerbaustein (festprogrammierter Schnittstellenbaustein auf Basis 8041)" - "programmable floppy disk controller (fixed program interface IC based on the 8041)".

Now if there was a simple way to read the ROM contents...

armadillo said...

It seems there is a way to read the ROM, though it's not quite that simple. See p. 111 ff. in https://pdfs.semanticscholar.org/fea2/c8f68bd8cf8046b3e40938e594e087490c3a.pdf

Chris Evans said...

@armadillo reading the ROM would be epic! I bet there's some interesting flags and special register settings that will do useful things but are not documented.

armadillo said...

@Chris The description to read the ROM I mentioned above was for a real 8041, of course. This involves applying 12V to pin 7 (EA = external access) to gain access to the ROM contents.

For other peripheral chips, such as the 8292 GPIB controller and the 8294 data encryption unit, intel officially states that these are preprogrammed 8041A's (see e.g. http://www.emuverse.ru/downloads/datasheets/other/intel/8292.pdf). On the 8292 and 8294, pin 7 is marked as a GND pin. This is correct for normal operation, i.e. EA is not used to access the internal ROM.

On the 8271, pin 7 is an input, DACK. So either the 8271 is not a relabeled 8041 or some pins have been reassigned, e.g. using a different bonding configuration. So I'm afraid one would need to take a look inside a real 8271 - a defective one would work for this. The 8271 has a variant that comes in a ceramic package, which is easier to open than plastic DIP packages, but the problem remains to find one...

armadillo said...

Some more information on the 8271 - https://twitter.com/kenshirriff/status/1300900070414413824 and a thread at https://stardot.org.uk/forums/viewtopic.php?f=3&t=19762&start=300

It seems the 8271 contains two distinct processors and two ALUs: a fast bit processor and a byte processor with hardware task switching.

Perry Harrington said...

Those signals are 300Khz, I wonder what would happen if you hooked them up to an amplifier and played them through a speaker?

High frequency PWM is very common on microcontrollers to output low bitrate audio.

Unknown said...

The 8271 was also used in the acorn atom disk pack. I am trying to revive one. Thx for the info.

Louis.m said...

Hello 0010 all,

Let me first state I'm no expert on all this !

But having read several articles about the 8271 FDC de-cap on StarDot and elsewhere (as well as studying Intel's data sheets and Acorn's System, Atom, Beep and other diagrams), I have a few questions on the matter.

To me it seems possible to have the registers write/read at A1-A0 being 00, 01, 10 (Command and Status, Parameter and Result, Reset respectively) and use address 11 for the data exchange (must CS and DACK be activated separately ?).

The 8271 is used in an odd way in the Acorn System, the Atom and the Beeb (and where else ?), both CS and DACK inputs are activated (low) at the same time when there is a data exchange between the 6502 ┬ÁP and the 8271 FDC, in spite of this being "Not Allowed" according to Intel's data, I wonder if this will give any problems ?

At first I thought both CS and DACK being low simultaneously was no issue here but some replies on StarDot rased some doubt on this.
Has this been tested or shed the reverse engineering any light on this all ?

It would be so nice to have a 8271 FDC fit in a four Byte space in the Atom, similar to other I/O like the 8522 (PIA) and 6821 (Big Benny, RTC) !

Gr����tings, Louis

May your wires be long and your nerves be strong❗

Anonymous said...

About your suggestion in this article the 8271 is based on the 8048 – you later worked out that is not true, per your blog post from a few months later – https://scarybeastsecurity.blogspot.com/2020/11/reverse-engineering-forgotten-1970s.html – but it is probably worth mentioning here in the comments, for the sake of any readers who stumble upon this.