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

[BigEd]

This is more of an Acorn community than a MAME community - it's of interest to those of us who find it interesting, as to what's inside the chips, how they do what they do, and what unexpected things they can be made to do.

[BigEd]

It wouldn't be too hard for two or three individuals to divvy up the work of creating polygons, and share what they'd done. There was, well back in the early visual6502 days, the beginnings of an effort to capture the polygons for the 68000, but AFAIR it foundered (lack of enthusiasm or time.)

[guesser]

Furthermore, these look like the connections from the bus to the big ROM looking thing in the bottom left. 8 bits seem to be tapped off the bus, and each bit makes four connections to the top of that structure, making it some sort of 8x4 thing:

Looking more closely, there's 8x8 columns, with alternate ones apparently being connected to the commoned group of 4 or not. (though again it's hard to see what's connected to what with the metal layer in the way.

[Kazzie]

I'm a complete amateur at analysing thse things, but here we go...

Working from the outside in, and looking at the pads.

The pads on the left and right for power and ground are quite distinctive; they have large pads and two wires attached to each of them, and the traces taking the power supply throughout the chip is quite easy to see.

The pads on the eight pins in the top-left have a similar structure around them, and there is evidence of eight connections diving under the power connection to the main structure in the top-left (plus ten crossunders at the bottom of the structure, near the left-hand power connection - extra lines for directional control / tri-stating?). On that basis, I reckon these are the pads for the data bus (pins 12-19), which would make the left power connection ground (pin 20), and the right power connection Vcc (pin 40).

Counting around the chip there are 41 pads (on both the 8271 and 8271-6). They all have evidence of a wire being fitted to them at some point, so the extra one must have been involved in testing or programming at some point. There are 19 pins between Ground and Vcc along the top, but 20 along the bottom, so the extra one's down there somewhere.

With regards to the big ROM-like structure in the lower-left:

The portion on the left is connected in 54 locations, each of these links corresponding to two lines. That makes for a structure with 108 rows, and 8 columns. The first and last columns have a circle (indicating a connection?) on every row, so they're not very interesting. The others however, all have a regular pattern of connection marks and spaces. From right to left, we have:

• Three marks, one space, repeat
• Six marks, two spaces, repeat
• Twelve marks, four spaces, repeat
• Twenty-four marks, eight spaces
• Forty-eight marks, sixteen spaces
• Ninety-six marks, thirty-two spaces (I didn't actually count this one)

(Note that the pattern begins mid-cycle.)

That pattern smells like addressing for the ROM area to me.

The area to the right of the ROM (above the "(c) intel 1978 ucode") has 41 pairs (82) of rows, and eleven columns. There's a similar set of "connections" to an area with 41 rows and 10 columns. This time, there's no clear pattern to either side of the connection that would look like standard address decoding.

[guesser]

That pattern smells like addressing for the ROM area to me.

This is the part I'm struggling with as however I look at it there are repeated values so I think there's some trick to squeeze out an extra couple of bits of addressing.
I think they must work in pairs as they're twice the density of the big block.

[Diminished]

Had a go at seeing how far I could trace some of those bus lines. They seem to go right across the middle of the chip, and presumably hook up to the D0-D7 buffering circuitry theorised by Kazzie in the top left.

(updated, see below)

[dp11]

I think GND and VCC are swapped the Databus I think is bottom right as it has bigger transistors than standard IO pins according to the datasheet . You also get a better fit between Input only pins and Output pins.

[Diminished]

updated bus trace, now with 8 bits

(updated again, see below)

I'm inching towards the block in the top-left being registers...

speculation is fun

[Diminished]

Something I found encouraging here about these bus traces ... if you look at the taps in the top left:

And the taps in the mid-left:

... the colours come out in the same order, suggesting a) those two structures are placed in the same bit order, and b) I didn't completely screw up the traces.

[Diminished]

Did a bit more gawping and noticed the bus turning south, right in the middle of the die.

These lines are really hard to follow but I tried as best I could to trace them. I lost half of them, but the other half seemed tentatively to end up at the points denoted by the question marks. With respect to the 8-way repeating structure to the right of the ROMish thing in the bottom-left, the colours once again match the bit ordering already found.

Updated the bus trace again:

https://drive.google.com/file/d/1UDOM4w ... sp=sharing

[Diminished]

So I have my suspicions about this structure.

It seems to be 10 bits wide, but only 8 bits are attached to the bus.

Could these be the one or more of the command / parameter / status / result registers, with two bits A0 and A1 coming in from the outside world?

I dunno.

[dp11]

A0 A1 do come from the outside world , but I don't understand why they would go into a structure like the databus does .

[guesser]

I think you have your Vcc and Gnd backwards. On the topless.jpg it looks like the notch is to the right of the screen.

Rotated to match the die photos:

[Diminished]

A0 A1 do come from the outside world , but I don't understand why they would go into a structure like the databus does .

Well, I'm thinking this would be normal digital logic practice? A0 and A1 would have to be clocked into a register somewhere ("sampled and held") to make sure the 8271 didn't experience changes in their values while it performed whatever operation was requested. I mean, the data sheet explicitly seems to call the command register a 10-bit register.

Maybe that's not strictly necessary if the CPU supplying the signals is behaving itself, but perhaps you'd also run into issues with timing, so that D and A arrived with slightly different timings relative to each other if you didn't run them all through the same signal path.

I don't know.

I think you have your Vcc and Gnd backwards. On the topless.jpg it looks like the notch is to the right of the screen.

I was going off what Kazzie said, but yeah, I meant to see if I could correlate it with the topless photo. I think you're right.

[guesser]

The pads around the top left hand corner are a bit confusing, but going around the other three quarters they seem to mostly make sense correlating to the chip pinout, in terms of what is an input and what has a big output driver.

[dp11]

I've just been comparing the pinout with the datasheet . I think the spare pin is the one on the left just below VCC

[guesser]

I've just been comparing the pinout with the datasheet . I think the spare pin is the one on the left just below VCC

It's really strange, it buggers off a eighth of the way round the die before reaching anything
Does it go to that absolutely massive rectangle of red?

[dp11]

It looks like an input only pad so it could enable some sort of test mode.

[BigEd]

Chance that it's the output of a substrate bias generator - the big red (diffusion) area is a capacitor, and the bond wire will go not to a post (and thence to a pin) but to the substrate. (It's advantageous to put a negative voltage on the back of the chip.)

[guesser]

Yep, what I was just going to post

Was just re-reading Ken's article about it first to avoid sounding like an idiot

[Diminished]

The data sheet says it has a 16bit CRC generator. I haven't yet spotted a 16bit structure.

Looking at where my bus traces finished up, and the fact that they terminate in the same bit order as the other 8-bit connections to the bus, I assume these make another vertical leap downwards.

There's a section just below each bus line endpoint which has 8 repeating parts for the 8 bus lines. Below that is a clear 16-wide structure. This might be the CRC generator, and the 8-wide part above it could be a 2-to-1 multiplex to load the data onto the bus in two separate chunks.

I think I was expecting a CRC generator to involve a ROM, but this Microchip application note from 2000 points out that in hardware it's usually done with a 16-bit shift register:

This is potentially nice because it might provide a clue on how much silicon area it takes with this process to store one bit in a flip-flop (which is basically a 1-bit register), but I don't know which bits of this structure are the flip-flops, and which might be other things like the XOR gates or other ancillary circuitry.

[guesser]

that top part of that 16 bit wide stuff all looks very regular to me, like more registers or RAM, and I couldn't find any taps off bits back around to the input if it was a CRC generator.
Could be something at the bottom. It all gets so dense with metal traces it's almost impossible to see where anything goes underneath.

[BigEd]

A disc controller has to have a shift register or two for the serialisation - that's a good place to put an XOR gate.

[Diminished]

Something interesting with these suspected 10 bit registers:

I started trying to follow the traces within this structure. The vertical red and blue ones are VCC and GND.

Then I added in the horizontal ones in yellow, and I noticed something about the bottom one (nearest the connections to the bus); the 8-bit, bus-connected portion on the right seems to take a common signal which comes in from the east, and then there is a gap. The 2-bit section on the left that doesn't seem to be connected to the bus receives a separate corresponding signal which comes in from the west, but connects to the same points in the structures as the common right-fed signal does.

[Pernod]

I appreciate all the interest here, and hope something worthwhile comes of it.

Received another note from Sean:

I cleaned both dies in MEK substitute in an ultrasonic cleaner for 3 minutes, then rinsed them with alcohol and took more pics. They are generally cleaner, but there is some dirt. At least among the 4 pics there should be a clear view of everything. I loaded both images into ImageGlass and flipped between them and I don’t see any differences, but it looks like they might have been made on different production lines.

This weekend I’ll see if I can remove the top metal layer.

So there's another couple of images available at www.seanriddle.com/8271

[Diminished]

With the arrival of the cleaner metal photos, I took the new 8271-6metal2 and used it as the basis for another attempt, this time properly vectorising everything I've looked at so far.

Here is an improved trace at 25%:

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

If anyone wants my GIMP source file, I can certainly provide that, but it's currently 1.5 GB in size (!) and it will presumably continue to be updated, so that might not be the most expedient way of sharing my vectors. Perhaps if I deleted the layer that actually contains the photograph and uploaded it without that, it might turn out smaller; then the recipient could just add that layer back in. Or I could shrink it to 50% and upload that, or something.

My PC is not a slouch (overclocked to 4.5 GHz with 16 GB RAM) but it's looking pretty sore even now dealing with this mammoth, so a machine of lesser spec might really struggle. I keep making sure to back up my GIMP file regularly in case I finally push it beyond its capabilities and it just refuses to load it.

[dp11]

The white/grey trace has a reasonable chance of being D0

[BigEd]

Nice! The images are way too large for my laptop, but google's slippy-map photo viewer does a good job.

The structured area at top right being only 3/4 populated would support the idea that this is a customised version of something, rather than being fully custom. But it doesn't look like very much program.

Segher Boessenkool has found the copyright registration record, but it's only metadata so far as I can tell:

Type of Work: Computer File
Registration Number / Date: TX0000805556 / 1978-05-12
Title: 8271 microprogram.
Description: Printout.
Copyright Claimant: Intel Corporation
Date of Creation: 1977
Date of Publication: 1977-10-01
Date in Notice: notice: 1978
Names: Intel Corporation

[guesser]

If anyone wants my GIMP source file, I can certainly provide that, but it's currently 1.5 GB in size (!) and it will presumably continue to be updated, so that might not be the most expedient way of sharing my vectors. Perhaps if I deleted the layer that actually contains the photograph and uploaded it without that, it might turn out smaller; then the recipient could just add that layer back in. Or I could shrink it to 50% and upload that, or something.

Yeah exporting just the vector layers would make the most sense imo.

[Diminished]

OK

Here's the 531 megapixel GIMP file at 70 MB:

https://drive.google.com/file/d/1R9aTZR ... sp=sharing

And a 133 megapixel one at 19 MB:

https://drive.google.com/file/d/1cyrigX ... sp=sharing

Neither of these contains the actual die photo. I used 8271-6metal2 for this. If you grab the 133 MP one, you'll need to find a way of shrinking the original JPEG to half size. Either way you want to load the die shot into GIMP as a layer.

All the paths (vectors) should be present, along with some layers, some of them inside layer groups for things like the main bus, and taps off the main bus.

I'm using GIMP 2.10.18. Apparently you'll need at least GIMP 2.10.xx to open these.

I accept no responsibility for anyone's computer being reduced to a puddle of molten metal by opening these files.