8271 disc controller de-cap and craziness -- do not try this at home!

[ijor]

Hi,

I'm not an Acorn user. Ed (BigEd here) commented about this thread on some mailing list we participate. I don't have much experience with this specific FDC, the Intel 8271. But I have considerable expertise reverse engineering other FDCs, mainly from the WD family.

Again, I am not familiar with the 8271. But I know how an FDC works internally, and what kind of logic it usually requires. I doubt this FDC is based on a standard MCU. No FDC that I know is based on a standard MCU, they are all full custom. They do use microcode, as seen on the die. But microcode structure is quite different from standard firmware.

I'm afraid chances are you are wasting your time trying to understand the microcode bits alone. You would need to reverse engineer the whole die logic, or at least most of it, if you want to understand the behavior. OTOH, this could be a lot of fun. Good luck!

[BigEd]

(Hi Ijor!)

It is quite surprising to see the simplicity of the 1772... perhaps the 8271 has more moving parts because it's built as a customisation and an adaptation of something else. That regular structure at top right must be a clue, as it uses up a lot of space but it not fully used. As it's not a ROM I'd have to guess it's a PLA, but not with a great deal of confidence.

We know the 8271 was earlier, and was expensive. Perhaps Intel were motivated to get something out early and were able to charge a premium, until WD came along with a simpler and cheaper chip. Being early is consistent with re-using design they already had - but evidently not re-using rectangles of layout, so re-using logic level design.

I tend to agree with Ijor, that if nothing looking like microcontroller code comes out, then much more of the logic would need to be captured to make sense of the machinery.

[Diminished]

I doubt this FDC is based on a standard MCU. No FDC that I know is based on a standard MCU, they are all full custom. They do use microcode, as seen on the die. But microcode structure is quite different from standard firmware.

I'm afraid chances are you are wasting your time trying to understand the microcode bits alone. You would need to reverse engineer the whole die logic, or at least most of it, if you want to understand the behavior. OTOH, this could be a lot of fun. Good luck!

Thanks for stopping by and taking a look.

This was my suspicion all along, unfortunately. This is likely not due to any great intuition on my part, but rather my endless reservoir of pessimism.

[guesser]

This has been my feeling since we saw the first die shot and it was clearly not just a mask programmed micro like the couple of chips someone pointed out that explicitly say so in their datasheets, just holding on to the possibility that it was cobbled together out of some existing blocks from something else so may have some subset of an existing architecture
Your seventh day microcontrollerists comment made me chuckle

[scarybeasts]

This has been my feeling since we saw the first die shot

Actually.... just found some really fascinating evidence. Head over to http://archive.computerhistory.org/reso ... .05.01.pdf and read page 16 and 17. It's a couple of early Intel employees who worked on the 8271, briefly digressing into its high level story.

The long and short of it is that it is _not_ a fully custom FDC. It's based on a common core with the 8273 that is designed to be a serial bit I/O powerhouse. There's talk of a specialized byte engine and bit engine with PLAs. There's no real summary of how those engines are orchestrated though, other than a reference to a development kit and a description of it as "another computer" and "somewhat general".

Also, they remember the chip being large and late, and perhaps regret going the generic engine route!

Anyway, the big ROM may still be a program we could usefully try and understand. There are various possible paths forward. One interesting one would be to find an 8273 and decap it for comparative analysis.


Cheers
Chris

[Diminished]

This has been my feeling since we saw the first die shot

Actually.... just found some really fascinating evidence. Head over to http://archive.computerhistory.org/reso ... .05.01.pdf and read page 16 and 17. It's a couple of early Intel employees who worked on the 8271, briefly digressing into its high level story.

The long and short of it is that it is _not_ a fully custom FDC. It's based on a common core with the 8273 that is designed to be a serial bit I/O powerhouse. There's talk of a specialized byte engine and bit engine with PLAs. There's no real summary of how those engines are orchestrated though, other than a reference to a development kit and a description of it as "another computer" and "somewhat general".

Also, they remember the chip being large and late, and perhaps regret going the generic engine route!

Anyway, the big ROM may still be a program we could usefully try and understand. There are various possible paths forward. One interesting one would be to find an 8273 and decap it for comparative analysis.


Cheers
Chris

Oh wow. Epic find.

chip being large and late

And hot!

I wonder how much power it consumes compared to the WD ones?

[BigEd]

Great find Chris with that Oral History.

So we learn that Olivetti was a prime customer, and that we expect to see both a bit engine and a byte engine, and the PLA is indeed a PLA, and the design is a dual-purpose one which explains in part why it's a bit big and also why the PLA is under-used.

Let me paste a bit for the record, we have Dave House of the CHM, and a bunch from Intel including Steve Bisset and Hal Feeney:

Bisset: Yes, we certainly cranked through the spec [specification] phase of those pretty quickly. Then it got really interesting. We got engaged with a real customer, which was kind of thrilling to me, because we had people who were building systems and you could ask questions about what it should do. They actually had examples they could cite to answer these questions, as opposed to the previous process, which was sort of imagining what it might do and trying to anticipate that. So we got heavily involved with these guys from Olivetti. They wanted a floppy disk controller, and a serial communications controller: SDLC, HDLC.
House: Yes, the 8271 and the 8273. The 8271 was the communications controller, and 8273 was the disk controller, I think. One or the other.
Bisset: Yes, and what we decided there—and in a way, I'm not really sure what the architectural lesson was, but it's kind of a possible misapplication of good lessons—but we decided instead of doing two separate custom chips, that these were both chips that had a lot of interface to 8 bit processors, but they were all manipulating serial bit streams in I/O. So we thought, "Why do two custom chips?" “Let's save time and do a general purpose chip that could do very sophisticated things with any serial I/O data streams and convert them internally into a group of 8 bit registers, and interface in an intelligent way with the processor.” So we had this thing called a bit processor and a byte processor, and we used the architecture that Carver [Carver Mead] inspired us with at Caltech using PLAs to control all this—so it’s, you know, fast, using parallel logic to make quick decisions. You could get the speed out of it that you needed to do these things.
I think the interesting lesson—again that was another one that was a set of chips that was defined, and then I left but I kind of kept a little bit in touch on that. I think that took a long time to get done, because we were saving time, in theory, taking two custom layouts and converting them into one general purpose task. But it turned out you had to kind of have a development kit and development software and all the bits and pieces that went around it, and that caused the project to drag out.
Feeney: Another computer.
Bisset: It was another computer, and whereas that paid off enormously for something like the CPUs, which were fully general, something like these, where they were somewhat general, but serial bit manipulation was I think too narrow [of a market] for that to pay off. Probably in retrospect, that was a lesson mis-learned or misapplied. That was a learning experience.
House: As I recall, those two chips were fairly large.
Bisset: Yeah. Too general.
House: And fairly late—
Bisset: Yes.
House: —to the marketplace. We had lots of issues with them.
Bisset: Yes. I think, in retrospect, it would have been easier just to crank them out in a fully dedicated, custom manner, just to be done with it.

[guesser]

Very Interesting!

[Coeus]

I'm not an Acorn user. Ed (BigEd here) commented about this thread on some mailing list we participate. I don't have much experience with this specific FDC, the Intel 8271. But I have considerable expertise reverse engineering other FDCs, mainly from the WD family.

Thanks. What can you tell us about the WD FDCs. Not necessarily here but have you written up your reverse engineering somewhere?

I think that could be interesting for a couple of different reasons. Firstly the BBC Micro also used the WD1170, first because third party vendors produced cheaper disc interfaces using it as an alternative to the 8271, both cheaper and capable of MFM, then subsequently adopted by Acorn so it would be interesting in its own right. Secondly, a general understanding of FDCs and how one might microcode some logic that is not a full MCU to produce one would probably be useful to understanding the 8271.

[ijor]

It is quite surprising to see the simplicity of the 1772... perhaps the 8271 has more moving parts because it's built as a customisation and an adaptation of something else ...
We know the 8271 was earlier, and was expensive. Perhaps Intel were motivated to get something out early and were able to charge a premium, until WD came along with a simpler and cheaper chip.

WD was actually first. Not with the WD1772, which is one of their latest FDC models, but with the FD1771 and a couple other models that they even used enhanced mode pullups (requires 5V and 12V).

Anyway, the big ROM may still be a program we could usefully try and understand. There are various possible paths forward. One interesting one would be to find an 8273 and decap it for comparative analysis.

The main ROM is microcode, of course. My humble suggestion, considering that you seem to work quite well as a team, is to do a collaborative effort and vectorize the whole die layout.

Thanks. What can you tell us about the WD FDCs. Not necessarily here but have you written up your reverse engineering somewhere?
...
Secondly, a general understanding of FDCs and how one might microcode some logic that is not a full MCU to produce one would probably be useful to understanding the 8271.

I'm afraid I don't have a comprehensive document detailing the full reverse engineering. I addressed specific issues in several places, but I'm not good at producing documentation, or write blogs, as some other people are.

In general microcode enables specific tasks. E.g., one microcode bit asserts the WRITE GATE signal. Other bits enable the sync detector and so on. Sometimes dedicated bits are used, other times some kind of encoding is used. There is, of course, some conditional sequencing that depend on many conditions, not on the result of some ALU as in a generic processor.

The microcode also processes the actual FDC command bits. But I suspect this might be different on Intel chips and they might use a PLA for this purpose. In general WD approach is to use simple and slow logic. To give you an idea, the main byte comparator is serial, not parallel. This, of course, is very slow. But it is perfect for the task and matches more closely the disk interface that is serial anyway.

[Diminished]

8273 datasheet is here (to save you from the horrors of dodgy datasheet sites):

https://drive.google.com/file/d/10QiA8p ... sp=sharing

I glanced at it. I'll have a proper look at some point.

Very Interesting!

Did you spot my earlier post? There's another SVG there for you.

In terms of crowdsourcing vectorising the chip, there's one danger which I should stress right from the start, which is that the photos we have don't always perfectly line up. In fact there's enough skew in the photographs we've seen so far that things on one layer can have moved into the position of adjacent components on other layers. This is clearly a problem.

I have tried so far to keep all my vectorisations relative to one chip and one layer, namely the 8271-6metal2. This is really just a function of the fact that this was the layer I marked out the VCC and GND polygons on, but jitter between the photographs is a problem that needs to be kept in mind going forwards, and a plan to deal with that would be needed. There is an argument for picking a polysilicon layer as the origin layer, although that's not what I've used so far.

I did have a go and trying to install that Degate software that sbadger mentioned, although it wouldn't quite build cleanly on my current Linux setup.

[guesser]

Did you spot my earlier post? There's another SVG there for you.

I did, and then forgot about it this morning, thanks for reminding me

In terms of crowdsourcing vectorising the chip, there's one danger which I should stress right from the start, which is that the photos we have don't always perfectly line up. In fact there's enough skew in the photographs we've seen so far that things on one layer can have moved into the position of adjacent components on other layers. This is clearly a problem.

I have tried so far to keep all my vectorisations relative to one chip and one layer, namely the 8271-6metal2. This is really just a function of the fact that this was the layer I marked out the VCC and GND polygons on, but jitter between the photographs is a problem that needs to be kept in mind going forwards, and a plan to deal with that would be needed.

Yeah misalignment is a nuisance, and there's obviously issues in the source images, cause I thought I'd got them well aligned in the corners of the die, but things are wonky in the middle
I decided to just plough on regardless as the exact position can be adjusted easily enough later on without the general shape of things changing. I don't know that any layer makes sense as the reference because whatever has caused the non-linearity in one presumably affects all the images to some degree, but I too have been treating the metal layer as the fixed reference for the same reason.

A bit of misalignment doesn't matter so long as transistors and vias are unambiguous IMO, so I've been fudging things where necessary to maintain this. It's not like we're going to convert the vectors into lithography to fabricate chips

If we all work from the same image our vectors should at least meet up. (I re-aligned the scaled images on my server. I think the metal layer was scaled only and I warped the other two).

We should probably announce what major structure we're working on so as not to duplicate effort, or mess with each other's vectors.
I'm happy to keep integrating exported layers into my file manually if that's the simplest workflow (but if it's not from the same file there's bound to be alignment issues so I end up cleaning up a lot of it, though again I don't really mind doing this), or I can stick it on github and we can see what a mess a merge makes of the svg.

[guesser]

A separate post for a separate thought I had earlier.

Do you think we should try to do some schematic capture of structures as we go. I'm figuring out what it's doing as I go along but imagine I'll forget what I worked out in a few days as my mental cache is overwritten with new findings.
Not a full schematic obviously, as so much is repeated 8 or more times, but describe the building blocks.

[guesser]

I did, and then forgot about it this morning, thanks for reminding me

Right, I've imported that and checked it all while re-aligning and cleaning up the path a bit. There isn't a connection to SELECT0, so I've just called it "unknown" for now, and removed the bits connected to that bond pad from the metal layer path.

I'm happy to keep integrating exported layers into my file manually if that's the simplest workflow (but if it's not from the same file there's bound to be alignment issues so I end up cleaning up a lot of it, though again I don't really mind doing this), or I can stick it on github and we can see what a mess a merge makes of the svg.

I was thinking about this some more while re-aligning the imported paths, and doing it manually has its benefits.
It puts a second pair of eyes on things (besides my own additions of course!) and gives me the chance to be a bit anal retentive about squaring up paths and de-featuring them (taking out extraneous nodes and splines etc), and adding the vias, and also to maintain a more consistent "house style" without the boring job of actually defining one formally

This approach of me fiddling about with everyone's work as it's submitted obviously doesn't scale well, but unless we have an influx of volunteers that's not something I'm going to worry about right now

[Diminished]

There isn't a connection to SELECT0

There isn't?

What does the metal connect to, then? It clearly isn't the polysilicon underneath.

[BigEd]

I'd agree - there's a connection at the arrow. The reason for the bold black lines is the contact mask: there are large irregular contacts around here, for low-resistance connections. You're actually seeing a step in the Z direction.

(Once got into trouble for one of the T9000 revisions in which we'd aggressively increased the size of a lot of contact cuts, resulting in a design which was legal according to the design rules but unmanufacturable. The rules had to be updated and a lot of the layout re-done.)

[Coeus]

WD was actually first. Not with the WD1772, which is one of their latest FDC models, but with the FD1771 and a couple other models that they even used enhanced mode pullups (requires 5V and 12V).

Now that's interesting. How successful was the 8271? Trying to find more background information, like dates etc. i.e. things that are not in the datasheet, I did a search and most the results that came back seem to relate to the BBC Micro. I could be, of course, that given the other things I have searched for these results are just weighted higher but I am now starting to wonder if, with WD first, many computer manufacturers took up the 8271.

In general microcode enables specific tasks. E.g., one microcode bit asserts the WRITE GATE signal. Other bits enable the sync detector and so on. Sometimes dedicated bits are used, other times some kind of encoding is used. There is, of course, some conditional sequencing that depend on many conditions, not on the result of some ALU as in a generic processor.

So very much like microcoding a CPU except that the bit of the chip enabled are different. What about loops, though? I can see that a purely sequential set of codes could be used for a task such as reading a sector, but then there's a multi-sector read that then repeats that (on the 1770 at least) until the end of the track or interrupted.

[guesser]

huh... I thought the connection I decided wasn't real was on the polysilicon... Now I'm confused lol.

Edit: ah yes, I see, what you're pointing to is indeed fine, but it's not connected to the poly trace coming down the outside of the die. There's just a gate that goes near to it.

[Diminished]

huh... I thought the connection I decided wasn't real was on the polysilicon... Now I'm confused lol.

Edit: ah yes, I see, what you're pointing to is indeed fine, but it's not connected to the poly trace coming down the outside of the die. There's just a gate that goes near to it.

Yeah, I gotcha. Photo is mucky just there.

[guesser]

I could be, of course, that given the other things I have searched for these results are just weighted higher but I am now starting to wonder if, with WD first, many computer manufacturers took up the 8271.

That could easily be because the BBC micro has a large collector community, while expensive business computers from the 70s that hardly anyone has heard of don't so no-one posts about their disk controller cards though.

[Diminished]

Need an opinion on this.

unsure.jpg (4.88 KiB) Viewed 869 times

unsure2.jpg (4.89 KiB) Viewed 869 times

What I think I have here is a resistor. The white arrow is a horizontal metal track. I think this is a via going into diffusion, and then there's another via up to the polysilicon, which heads south? Is that right?

Incidentally, I'm currently dealing with this monstrosity:

This goes everywhere. It's important, whatever it is. Wonder if it's the clock.

[BigEd]

I think you're right about the connectivity, but I'd say it's only a connection, not specifically a resistor. A resistor will usually be quite a large serpentine structure.

Sometimes diffusion rather than polysilicon might be used for connections because of which layer is going to use the signal, and sometimes because the allowable spacing between poly and diffusion is less than between poly and poly, or between diffusion and diffusion.

BTW, as to terminology, in my experience: in a single layer metal process like this, connections from metal down are usually called contacts, whereas connections between poly and diffusion are called buried contacts. (When there are more layers of metal, the connections between metal layers are called vias.)

[Diminished]

...

Brilliant as always, thanks.

[Pernod]

I could be, of course, that given the other things I have searched for these results are just weighted higher but I am now starting to wonder if, with WD first, many computer manufacturers took up the 8271.

That could easily be because the BBC micro has a large collector community, while expensive business computers from the 70s that hardly anyone has heard of don't so no-one posts about their disk controller cards though.

Of all the machines that MAME emulates only the BBC, Atom, System, mythical Le Box for Electron, Intellec MDS-II, and something called M-Disk Comp.-A use the 8271. So not widely used at all!

[scarybeasts]

I could be, of course, that given the other things I have searched for these results are just weighted higher but I am now starting to wonder if, with WD first, many computer manufacturers took up the 8271.

That could easily be because the BBC micro has a large collector community, while expensive business computers from the 70s that hardly anyone has heard of don't so no-one posts about their disk controller cards though.

Of all the machines that MAME emulates only the BBC, Atom, System, mythical Le Box for Electron, Intellec MDS-II, and something called M-Disk Comp.-A use the 8271. So not widely used at all!

Perhaps because it was late, expensive, ran hot, and AFAIK had supply chain issues


Cheers
Chris

[Diminished]

I wonder if Olivetti ever ended up using it for anything.

This might be everything, finally:

It touches a few interesting things, like the vertically arranged 8-block (registers?) in the south, and the big ROM thing in the far north-east. It might be part of the clock (maybe there's one or more gated or phased versions which are used elsewhere). Could be a reset signal or something.

I know there is a mistake or two, since I didn't figure out the diffusion silicon thing until BigEd explained it, and I definitely marked one or two similar connections up wrongly (not that it really makes too much difference). I may also still be missing sections. I'll cast another look over it tomorrow.

[guesser]

This might be everything, finally:

[ijor]

.. but I am now starting to wonder if, with WD first, many computer manufacturers took up the 8271.

I can't say if the early WD ones were much more popular, may be, I don't really know. But if the 8271 was late and expensive, and according to you it used to run very hot, then that might explain it. I also think that the 8271 software interface is too overcomplicated. May be it is fine for 16-bit systems and its DMA interface is probably better than the WD one. But for smaller 8-bit platforms, the simpler WD design is probably more suitable.

This also might explain why the original PC used a Nec FDC and not an Intel one. Either the Nec one was cheaper, or the competitive Intel product (8272) wasn't ready yet, may be because they had to ditch the 8271 concept and start a new internal design from scratch (just speculating).

This is not say that WD FDCs were perfect. Of course not. They have quite some nasty quirks (and even a few bugs) that we learnt to hate. And most of them were never fixed because I guess they wanted to maintain backwards compatibility as much as possible. Presumably because otherwise some copy protections might break.

What about loops, though? I can see that a purely sequential set of codes could be used for a task such as reading a sector, but then there's a multi-sector read that then repeats that (on the 1770 at least) until the end of the track or interrupted.

It is some sort of loop. Not exactly because sequencing is not fully linear. The concept of current PC is rather loose and the ucode address register is separated in two, sometimes three, more or less independent sections that can be updated separately. This allows for very powerful multiway conditional branching. Btw, in some CPUs there is no concept of ucode PC at all. In the case of the 68000, e.g., each ucode instruction must specify the next one, one way or the other.

But yes, it is more or less a loop, even for multisector operations. After the current sector read (or write) is completed, the multi sector bit is checked, and if it is, the sector register is incremented and the ucode branches to perform another read or write again. This continues until being interrupted (or hitting an error). There is no concept of end of track when reading or writing sectors. Again, simplicity.

Btw, speaking about quirks, the multisector design has a problem. If the last sector read before being interrupted happens to have a CRC error, depending on the timing, it might be possible to miss the error. A little long to elaborate about this, but this quirk actually affected the first version of the Atari ST BIOS. Later BIOS releases didn't use the multisector feature anymore.

[guesser]

A couple of minor discoveries from tracing further out down the bus lines, your mystery signal that seems like something to do with !READY1 gates an input to the blue bus line, and the pink bus line goes down to the bottom left and gets involved in the SELECT1 output.

[scarybeasts]

Ok, I have a confession to make -- I did chat to Ken (http://righto.com blog owner) and we exchanged some notes and ideas.

And then Ken found a couple of extremely enlightening documents, which are attached:

- A paper abstract from a 1977 conference. You will recognize the photo in it.
- A patent application for the core.

Across the two documents there's a fabulous wealth of detail. What nuggets do you all find most interesting? For me:
- I'm quite pleased with the confirmation that the "byte engine" does seem to be a little 8-bit CPU with stack, PC, registers and program ROM. There's the specific claim of "46 instructions".
- The on-silicon multi-tasking support is very eyebrow raising and it hasn't sunk in for me yet.
- 22,000 transistors! Goodness me. They really could have just strapped a CRC16 and pulse shifter to the side of an 8080 and used less?


Cheers
Chris