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

[Diminished]

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

Oh, man.

I'm only awake because I can't sleep, but I'm looking forward to reading these tomorrow.

Would a microcontroller of the era have been fast enough? I'm not sure it would? The 8271 had a DMA controller and stuff.

I wondered how many transistors there were. 22k? Ridiculous. I ain't tracing all those.

Also good news that there is some code involved.

Great work.

[Diminished]

Man, this document is amazing.

Two ALUs. >_<

The real irony is that I think everyone was right about the thing's nature. I said 8-bit bus and a state machine. Others suggested a microcontroller. I don't think any of us thought it would have both of those and a couple of kitchen sinks on-die as well.

You're right, the multitasking thing is crazy, too. What do you think that means? It has multiple shadow program counters? How on earth would the stack work?

Five times the number of transistors in the 6502.

What a beast of a chip.

[BigEd]

Wow - thanks Chris, and thanks Ken!

[guesser]

Neat!

[guesser]

I wondered how many transistors there were. 22k? Ridiculous. I ain't tracing all those.

A lot of them are copy and paste though

[Pernod]

Another update from Sean:

I cleaned the dies in Whink twice more, then in sulfuric acid again. I think something must be dissolving and precipitating on the die. The top and bottom of the package were “glued” together to hermetically seal the die, so I used a Dremel cutoff wheel to grind the residue off, but it didn’t seem to help. I tried to release the die from the ceramic package with a heat gun, but it wouldn’t budge and I was afraid I’d crack it. I’m unable to cut the package with anything I’ve got. A tile saw might work, but I don’t know how I’d control it on such a small object.

I found a guy on ebay selling 8273s for cheap so I picked up a few. It’ll be interesting to compare to the 8271, and it’ll give me more practice on ceramic packages.

I’ll keep trying to clean these, but I’m afraid things are going to start getting etched off. If I figure out something with the 8273s, I’ll see if I can get another 8271.

I uploaded 2 more pics.

[BigEd]

Noteworthy:
"One function [of the byte-level processor] is a mode used to simplify chip testing"

[Coeus]

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

Is this something that hugin or similar could help with. It sounds like what is needed is to be able to mark some control points across the image, i.e. positions of known structure, and then have the software work out a more complex transform to align then.

[Coeus]

Noteworthy:
"One function [of the byte-level processor] is a mode used to simplify chip testing"

But is doesn't say is this needs access to the unbonded pin or can be accessed from the host interface.

[BigEd]

Here's a thing. The decoder for the narrower of the two ROMs at bottom left is much more close to a binary decoder in the photo in the published paper than it is in Sean's photos:

[Diminished]

Noteworthy:
"One function [of the byte-level processor] is a mode used to simplify chip testing"

This is actually explicitly mentioned in the 8273 sheet, but not in the 8271 one. (One one). Very first page, in the register block.

Here's a thing. The decoder for the narrower of the two ROMs at bottom left is much more close to a binary decoder in the photo in the published paper than it is in Sean's photos:

I don't know. It looks the same to me?

I think the big ROM is different though. Hard to tell, really.

[guesser]

Here's a thing. The decoder for the narrower of the two ROMs at bottom left is much more close to a binary decoder in the photo in the published paper than it is in Sean's photos:

Interesting. Presumably that's synchronous data link controller chip.

[BigEd]

Ahem, yes, good point. And indeed we see the PLA controller for the bit level processor is full - so yes, indeed, it's the other application.

[Coeus]

They really could have just strapped a CRC16 and pulse shifter to the side of an 8080 and used less?

Or use the 8080 or other standard microprocessor that it was attached to. Intel's documents of the time make a big thing about these chips being able to carry out functions independent of the host processor but how many systems did something useful with the host processor while the operation was in progress?

Intelligent I/O that can work independently of the main CPU and generate the least number of interrupts is part of the reason mainframes are capable of such high throughput but that relies on having the main CPU running a multi-tasking operating system to take advantage of that. It seems to me there was a period of time for which Intel over-estimated the appetite to do the same on microprocessors. Another example is the 8086 with multiple 64K segments as if what people really wanted to do is run multiple small programs at once on it when actually they wanted to run one bigger program that could handle more data.

So back to an FDC, perhaps all it needs to do is the bit level rather than byte level operations: FM/MFM encode and decode, address mark detection, CRC generation etc. The host CPU could do the rest: checking the ID header against the one required, counting the data bytes in the sector etc.

[Diminished]

Another update from Sean:

These are definitely worth having, although he's right, they're still not perfect, sadly.

It's hard to visualise exactly how he suggests cutting the chip. It's slightly frustrating because I have one of these in the cupboard, which strikes me as the sort of thing that might work (unless he's talking about slicing it open lengthwise). I have a couple of spare 8271s as well ... but I can see myself very quickly ending up with zero 8271s.

[guesser]

If we cut up lots of chips to gain a full understanding of the logic, which then makes it possible implement a drop in replacement on an FPGA to solve the shortage of working 8271s it all becomes a bit of a circular process

I think we're making decent progress with the die shots we have, despite the imperfections.

[Diminished]

Here's that long path I traced yesterday.

long1.zip

(33.64 KiB) Downloaded 14 times

[Coeus]

If we cut up lots of chips to gain a full understanding of the logic, which then makes it possible implement a drop in replacement on an FPGA to solve the shortage of working 8271s it all becomes a bit of a circular process

But would you want to implement the Intel design exact as-is? We have the data sheet detailing the interface and we have software emulations. Also, while a general purpose microcontroller of the day may have been two slow, probably the same is not true now.

[Diminished]

Another one I did a couple of days ago.

alpha.zip

(7.59 KiB) Downloaded 16 times

[guesser]

Oh those new images are much nicer. I've aligned them to the metal layer and linked shrinkified versions into the svg again. https://temp.zxnet.co.uk/8271/

I've done a better job of aligning them this time I think. I'd better move all my vectors to line up properly now

[BigEd]

... the narrower of the two ROMs at bottom left ...

Rather looks like this "narrow ROM" is in fact a PLA which delivers the appropriate entry point, or resumption point, when the priority encoder tells the machine to dispatch to a new task. See the patent:

In general, priority resolver, encoder and latch receives a plurality of dispatcher request inputs from the processor, or from external sources. The priority resolver examines these inputs to determine the highest priority request. The encoder portion of this means then generates a 4-bit signal which is communicated to the PLA address generator. These 4-bits are employed by the PLA address generator to generate a portion of an address which portion is used to identify one of the routines. The 4-bits generated by the priority resolver are also communicated to a case register (with exceptions which will be discussed). These 4-bits couple one of the registers within case registers to bus 20 and provide an additional 4-bits of information to the PLA address generator. These 4-bits are employed by the address generator to generate another portion of the address, which portion identifies a segment of the selected routine. That is, as will be seen, routines are not necessarily completed when selected, and thus when a particular routine is again selected it is continued at the beginning of the appropriate segment. The PLA address generator also receives 2-bits of information from the instruction register. The address register (which is part of the instruction register and decoder) provides a means for selecting case registers in order that the information in the case registers may be updated.

[Rich Talbot-Watkins]

Ahem, yes, good point. And indeed we see the PLA controller for the bit level processor is full - so yes, indeed, it's the other application.

What's still slightly surprising about this is that if the photo from the paper is an 8273, I'd still expect the decode PLA for the byte processor to be the same (if they are both based on the same generic components). So either the 3rd and 4th ROMs from the left are nothing to do with decoding, or the byte processor doesn't use the same instruction encoding in each chip.

[BeebMaster]

If we cut up lots of chips to gain a full understanding of the logic, which then makes it possible implement a drop in replacement on an FPGA to solve the shortage of working 8271s it all becomes a bit of a circular process :lol:

What shortage? I think I've got the world's supply...at least 50 at the last count.

[Rich Talbot-Watkins]

Ed, I think you're right about offsets into the ROM for entry points. So where's the decode PLA? Surely there must be one?

[BigEd]

3rd and 4th ROMs? I wonder if we have a terminology difference... A ROM will appear as a pair of regular circuitry.

This is, I believe, the microcode ROM, with the address decoder on the left and the contents on the right:

And this is, I now believe, not a "narrow ROM" but a PLA which returns the entry points and resumption points for the various routines in the microcode ROM:

Screen Shot 2020-08-31 at 13.30.29.png (116.48 KiB) Viewed 741 times

[BigEd]

BTW, also: when we say "microcode" we just mean here the program which the byte machine executes. If it were an 8041 or similar, it would be recognisable as a program. It's not microcode in the 68000 sense.

And also also, I don't think there will necessarily be a decode PLA such as we see in the 6800 or 6502 or z80. That's just a way to build some logic, and that might in this case be random. Having said which, there are two regular patches of logic which are not yet identified, just south of the big horizontal power rail.

[guesser]

And this is, I now believe, not a "narrow ROM" but a PLA which returns the entry points and resumption points for the various routines in the microcode ROM

Does having "don't care" bits make sense in that context?

[guesser]

I've re-aligned a lot of my polysilicon using the new photos and things are looking much better now, so I must have just done a horrible job of aligning the images first time around somehow.

Got to go and smash up a rotten shed next, but I've saved those two new traces to look at later

[BigEd]

And this is, I now believe, not a "narrow ROM" but a PLA which returns the entry points and resumption points for the various routines in the microcode ROM

Does having "don't care" bits make sense in that context?

Yes, it can do.

[guesser]

Right, I've added "alpha", with a small correction where something was connected that shouldn't be again. "long1" terrifies me slightly