5 ms·

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

97 points by scarybeast 6y ago

rkagerer 6y ago
So that's how those Mission Impossible messages to James Bond would self destruct!
- csin 6y ago
  Forgive me for being pedantic. The agent's name in Mission Impossibles is Ethan Hunt.
  - rbanffy 6y ago
    Forgive me for being even more pedantic, but the person who received the self-destructing messages was Dan Briggs, who was replaced by Jim Phelps on season 2. Ethan Hunt only got the job on the first movie of the series.
    - rkagerer 6y ago
      Good catch. And yes, I intentionally conflated the two series, which might be unforgivable.
      - rbanffy 6y ago
        The fastest way to get an answer on the internet is to post a wrong answer.
  - rasz 6y ago
    Dan Briggs https://www.youtube.com/watch?v=QhPwhv2aRZc https://www.youtube.com/watch?v=QhPwhv2aRZc
tyingq 6y ago
Good reason to get a Gotek floppy emulator and work with copies instead. With the open source FlashFloppy software, they work great, and are pretty cheap.
nynyny7 6y ago
Fascinating read, although I take issue with its title that implies that it's a bug in the chip. Maybe a bug in the author's code (when he wrote wrong values to the register), definitely not a bug in the chip but a feature. If you write undocumented values into a register, undocumented stuff happens. A lot of ICs have undocumented test modes that are used by the manufacturer.
hyperman1 6y ago
Pretty interesting behaviour, but I don't think you can claim this is a fault in the controller. The contract was being invalidated when he wrote invalid data to a register. After that, anything may happen. Today, most hardware has some protection against abuse, but in the days of the BBC micro it was common for hardware and os to completely trust the software. There were plenty of storys of damaged monitors because of invalid timing parameters. One of my own storys, and I'm a bit hazy so some details are probably wrong: We found an old computer in a university dumpster some night, and decided to mess with the floppy drive. More beer than common sense around. There was some way to tell the hardware which track to read/write, with sane values from 0 to 79. But it was a byte , we could go to 255, so we decided to go up up up! Well, the drive did exactly as commanded. 80 - 85 worked quite well, except the floppy wasn't guaranteed to be magnetically coated. But once we pushed it too far, the read head went literally over the edge: It jumped off the axle, dropped on the spinning disk below, got a serious yank, and the tiny wires got snapped off. All of this with a single x86 out instruction, I think in dos 3.x debug. The OS was not stopping you if you did something stupid, there was no hardware protection or anything.
- nynyny7 6y ago
  At least the drive I accidentally tried the same had a mechanical stop. Although banging the head against it 170 times or so wasn't exactly beneficial for its alignment. Even today, one is better off not to write undocumented values to registers. True story: I had to investigate a SW bug report concerning a modern, fairly popular microcontroller. (I won't name which.) Sometimes data in RAM changed without our code writing to it. Turns out that our startup code accidentally wrote to a 'reserved' bit in a register, activating some kind of internal RAM test mode. This was confirmed by the µC's manufacturer.
  - rbanffy 6y ago
    > Although banging the head against it This was how an Apple II made sure you were in track zero - by banging the head against the stop. This is why it makes that typical noise when booting up.
  - 6y ago

97 points by scarybeast 6y ago

rkagerer 6y ago

So that's how those Mission Impossible messages to James Bond would self destruct!

csin 6y ago
Forgive me for being pedantic. The agent's name in Mission Impossibles is Ethan Hunt.
- rbanffy 6y ago
  Forgive me for being even more pedantic, but the person who received the self-destructing messages was Dan Briggs, who was replaced by Jim Phelps on season 2. Ethan Hunt only got the job on the first movie of the series.
  - rkagerer 6y ago
    Good catch. And yes, I intentionally conflated the two series, which might be unforgivable.
    - rbanffy 6y ago
      The fastest way to get an answer on the internet is to post a wrong answer.
- rasz 6y ago
  Dan Briggs https://www.youtube.com/watch?v=QhPwhv2aRZc https://www.youtube.com/watch?v=QhPwhv2aRZc

tyingq 6y ago

Good reason to get a Gotek floppy emulator and work with copies instead. With the open source FlashFloppy software, they work great, and are pretty cheap.

nynyny7 6y ago

Fascinating read, although I take issue with its title that implies that it's a bug in the chip. Maybe a bug in the author's code (when he wrote wrong values to the register), definitely not a bug in the chip but a feature. If you write undocumented values into a register, undocumented stuff happens. A lot of ICs have undocumented test modes that are used by the manufacturer.

hyperman1 6y ago

Pretty interesting behaviour, but I don't think you can claim this is a fault in the controller. The contract was being invalidated when he wrote invalid data to a register. After that, anything may happen. Today, most hardware has some protection against abuse, but in the days of the BBC micro it was common for hardware and os to completely trust the software. There were plenty of storys of damaged monitors because of invalid timing parameters. One of my own storys, and I'm a bit hazy so some details are probably wrong: We found an old computer in a university dumpster some night, and decided to mess with the floppy drive. More beer than common sense around. There was some way to tell the hardware which track to read/write, with sane values from 0 to 79. But it was a byte , we could go to 255, so we decided to go up up up! Well, the drive did exactly as commanded. 80 - 85 worked quite well, except the floppy wasn't guaranteed to be magnetically coated. But once we pushed it too far, the read head went literally over the edge: It jumped off the axle, dropped on the spinning disk below, got a serious yank, and the tiny wires got snapped off. All of this with a single x86 out instruction, I think in dos 3.x debug. The OS was not stopping you if you did something stupid, there was no hardware protection or anything.

nynyny7 6y ago
At least the drive I accidentally tried the same had a mechanical stop. Although banging the head against it 170 times or so wasn't exactly beneficial for its alignment. Even today, one is better off not to write undocumented values to registers. True story: I had to investigate a SW bug report concerning a modern, fairly popular microcontroller. (I won't name which.) Sometimes data in RAM changed without our code writing to it. Turns out that our startup code accidentally wrote to a 'reserved' bit in a register, activating some kind of internal RAM test mode. This was confirmed by the µC's manufacturer.
- rbanffy 6y ago
  > Although banging the head against it This was how an Apple II made sure you were in track zero - by banging the head against the stop. This is why it makes that typical noise when booting up.
- 6y ago