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

discuss both original and modern hardware for the bbc micro/electron
ijor
Posts: 4
Joined: Sun Aug 30, 2020 4:31 am
Contact:

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

Post by 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!
User avatar
BigEd
Posts: 3744
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

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

Post by 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.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished »

ijor wrote:
Sun Aug 30, 2020 6:54 am
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. :lol:
guesser
Posts: 512
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by 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 :)
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
User avatar
scarybeasts
Posts: 605
Joined: Tue Feb 06, 2018 7:44 am
Contact:

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

Post by scarybeasts »

guesser wrote:
Sun Aug 30, 2020 11:30 am
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
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished »

scarybeasts wrote:
Sun Aug 30, 2020 11:58 am
guesser wrote:
Sun Aug 30, 2020 11:30 am
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?
User avatar
BigEd
Posts: 3744
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

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

Post by 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
Posts: 512
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser »

Very Interesting! :D
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
Coeus
Posts: 1946
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

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

Post by Coeus »

ijor wrote:
Sun Aug 30, 2020 6:54 am
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
Posts: 4
Joined: Sun Aug 30, 2020 4:31 am
Contact:

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

Post by ijor »

BigEd wrote:
Sun Aug 30, 2020 8:08 am
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).
scarybeasts wrote:
Sun Aug 30, 2020 11:58 am
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.
Coeus wrote:
Sun Aug 30, 2020 2:07 pm
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.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by 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.
guesser wrote:
Sun Aug 30, 2020 12:41 pm
Very Interesting! :D
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
Posts: 512
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser »

Diminished wrote:
Sun Aug 30, 2020 4:02 pm
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 :)
Diminished wrote:
Sun Aug 30, 2020 4:02 pm
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.
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
guesser
Posts: 512
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by 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.
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
guesser
Posts: 512
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser »

guesser wrote:
Sun Aug 30, 2020 5:07 pm
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.
guesser wrote:
Sun Aug 30, 2020 5:07 pm
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 :lol:

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 :)
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished »

guesser wrote:
Sun Aug 30, 2020 6:15 pm
There isn't a connection to SELECT0
There isn't?
select0_what_1.jpg
select0_what_2.jpg
What does the metal connect to, then? It clearly isn't the polysilicon underneath.
User avatar
BigEd
Posts: 3744
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

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

Post by 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
Posts: 1946
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

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

Post by Coeus »

ijor wrote:
Sun Aug 30, 2020 3:15 pm
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.
ijor wrote:
Sun Aug 30, 2020 3:15 pm
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
Posts: 512
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by 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.
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished »

guesser wrote:
Sun Aug 30, 2020 8:02 pm
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
Posts: 512
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser »

Coeus wrote:
Sun Aug 30, 2020 7:53 pm
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.
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished »

Need an opinion on this.
unsure.jpg
unsure.jpg (4.88 KiB) Viewed 869 times
unsure2.jpg
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:
nightmare.jpg
This goes everywhere. It's important, whatever it is. Wonder if it's the clock.
User avatar
BigEd
Posts: 3744
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

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

Post by 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.)
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished »

BigEd wrote:
Sun Aug 30, 2020 8:55 pm
...
Brilliant as always, thanks.
User avatar
Pernod
Posts: 2382
Joined: Fri Jun 08, 2012 11:01 pm
Location: Croydon, UK
Contact:

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

Post by Pernod »

guesser wrote:
Sun Aug 30, 2020 8:12 pm
Coeus wrote:
Sun Aug 30, 2020 7:53 pm
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!
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.
User avatar
scarybeasts
Posts: 605
Joined: Tue Feb 06, 2018 7:44 am
Contact:

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

Post by scarybeasts »

Pernod wrote:
Sun Aug 30, 2020 10:22 pm
guesser wrote:
Sun Aug 30, 2020 8:12 pm
Coeus wrote:
Sun Aug 30, 2020 7:53 pm
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 :D


Cheers
Chris
User avatar
Diminished
Posts: 598
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished »

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

This might be everything, finally:
phew.jpg
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
Posts: 512
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser »

Diminished wrote:
Sun Aug 30, 2020 10:41 pm
This might be everything, finally:
:o
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
ijor
Posts: 4
Joined: Sun Aug 30, 2020 4:31 am
Contact:

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

Post by ijor »

Coeus wrote:
Sun Aug 30, 2020 7:53 pm
.. 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
Posts: 512
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by 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.
Various teletext things including a web based teletext editor which can export as mode 7 screens.
Join the Teletext Discord for teletext chat.
User avatar
scarybeasts
Posts: 605
Joined: Tue Feb 06, 2018 7:44 am
Contact:

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

Post by 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
Attachments
US4152761.pdf
(996.76 KiB) Downloaded 57 times
louie1977.pdf
(590.16 KiB) Downloaded 56 times
Post Reply

Return to “8-bit acorn hardware”