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

[scarybeasts]

These two different test modes driving a different set of output pins. Is this a case of one test mode for the byte processor, driving the host facing pins, and one test mode for the bit processor, driving the drive facing pins?

I wonder if the poor little chip might achieve the AI singularity if we.... wrote 6 to the register

[Diminished]

Yeah, I can't trivially reproduce what you did, Chris. I can find values which put a 25 KHz square wave on LOAD HEAD and a 400 KHz square wave on INT, and I can find values which pull either or both of those pins high, but I'm not seeing the crazy superposition that you reported.

I haven't tried other pins because I only have 2 channels to play with.

[scarybeasts]

Yeah, I can't trivially reproduce what you did, Chris. I can find values which put a 25 KHz square wave on LOAD HEAD and a 400 KHz square wave on INT, and I can find values which pull either or both of those pins high, but I'm not seeing the crazy superposition that you reported.

It's possible that I had different electrical properties because at the time of my tests, I had a Chinon F-051MD drive attached.

After all we've discussed, it's fairly amusing to note this this older drive handles the I/O pins via a.... NEC D8048-C.... that part number sounds familiar!


Cheers
Chris

[hoglet]

I've spent a bit more time trying to reproduce the crazy mode this morning.

I've connected up a real 5.25" floppy drive (that works, but not very well, so I don't really care if it's damaged), and fitted Acorn DFS 0.90.

I've not been able to reproduce the crazy mode.

What I typically see (doing ?&FE82=4 after power up) is this:

Where:
D0 - Pin 35 (WREN)
D1 - Pin 36 (STEP)
D2 - Pin 37 (DIR)
D3 - Pin 38 (LOAD HEAD)
D4 - Pin 39 (LOW CURRENT)
D5 - Pin 1 (FAULT RESET)
D6 - Pin 2 (SEL 0)
D7 - Pin 6 (SEL 1)

(D3 corresponds to the Motor On signal that Chris originally observed the crazy behaviour on.)

This is all with a disk in the drive, and the door closed.

However, it's clearly dependent (in a stateful way) on some of the FDC inputs as if I remove and re-insert the disk, the base frequency seems to increase a bit, and there is a little more irregularity:

(The audo tone the drive is making also increases in pitch).

The HF transitions on D5 and D6 are the result of higher frequency signals being superimposed at a lower amplitude. I think this is intentional, rather than simply being crosstalk.

Dave

[BeebMaster]

I'm tempted to try it...I've a manky Cumana drive with misaligned heads that could be sacrificed if necessary.

[Diminished]

I wouldn't go risking more vintage hardware just for the sake of it... unless you really want to

So I'm just thinking again about this glitching idea.

The thing closest to the power supply is the presumed core of the byte processor -- its PC, stack, ROM, etc, so perhaps that will continue to run longer than anything else under a power failure scenario, owing to the resistance of the metal causing slightly lower voltages to the right of the die. This might be a good thing, since that's what we want to steal information from?

According to Ken's guess, the registers (which presumably include at least the special registers, if not all of them), are on the right of the die, furthest away from the power supply, which means maybe they're likely to fail under a power glitch:

viewtopic.php?p=286419#p286419

I keep second-guessing what is likely to happen to the registers when they're powered down and powered back up, and I've come to no conclusion. It seems like you'd at the very least need the gates from the bus to be open in order to get anything meaningful into the regs, so it does seem to me like you'd have to run an operation which normally updates the registers, then glitch during it, in the hope that the byte processor opens the gates at the end of the operation as it normally would. Also, I don't think this method is likely to be usable at an arbitrary point in time. The best you might get is stealing some byte processor state right at the end of the operation you started.

I kind of doubt it will work. Although I think I do have all the parts I would need to try it.

[Pernod]

More from Sean:

I think the problem I’m having cleaning this die is because it’s glued to the bottom of the ceramic package, so I have to put the whole thing into acid, not just the die. With a plastic package, I could get to just the die (maybe still attached to the metal paddle, but that’s something I’m used to).

I hate to destroy another chip unless someone thinks it would help. Cole seems to think there’s enough detail in my pics to vectorize it, so maybe we wait and see if there’s an issue.

I also uploaded a top metal die shot of the 8273: www.seanriddle.com/8271/8273metal.jpg

[guesser]

I'm not having any real difficulty vectorising from the existing photos. Between the two chips I'm managing to identify what goes where.

[Diminished]

This is as expected I think.

The chip isn't quite the same as the 8271 though! There are differences here and there.

[scarybeasts]

The chip isn't quite the same as the 8271 though! There are differences here and there.

I see it says (c) 1979... maybe there were some fixes in later chips.


Cheers
Chris

[scarybeasts]

I'm not having any real difficulty vectorising from the existing photos. Between the two chips I'm managing to identify what goes where.

It's great to hear that people are still working on this. I'm also still regularly looking at the opcodes to try and make something fit, but it is a royal PITA.

Is there any hope of tracing the opcode bits through the PLA so see which opcode bit combinations activate what? Even identifying just a few critical opcodes could be enough to cause a cascade of successful opcode inference.

For example, we suppose there might be a MOV A,Rx and MOV Rx,A opcode in a similar manner to the 8048. But what is the opcode range for those? How many different registers can be encoded in the opcode range? How are registers outside that range selected -- some form of bank select, indirect indexing opcodes, or both?


Cheers
Chris

[guesser]

Is there any hope of tracing the opcode bits through the PLA so see which opcode bit combinations activate what? Even identifying just a few critical opcodes could be enough to cause a cascade of successful opcode inference.

Eventually! I keep picking away at it like a scab, but there's a whole lot of logic to dig into between the bus and the PLAs

I'm trying to understand how things function somewhat before I move on even if I don't know what the circuit is for, and while I can get the overall gist of the latest part that's because it's obvious what the circuit does (driving the small ROM decoder columns from the bits on main bus), but not sure how the control inputs work and only 95% sure I've identified the contacts correctly on the pull ups(?)

It's a boring part of the chip and doesn't give any new insight to get excited about, but my feeling is if I can't understand the implementation of something fairly obvious I'll have no hope of figuring out the function of something totally unknown elsewhere.

Here's a single input bit, the inputs and outputs are marked in green (input bit coming down from the top and Q/!Q column signals going off the bottom)

[Diminished]

The bit ordering into the PLA looks to be the same as it is everywhere else. Which is both good, and bad.

The 8273 ROMs will hopefully help, although maybe we'll have to wait another week for those.

[BigEd]

Here's a single input bit, ...

Are you happy with how that works? It's not too hard to decode.
- spot the pullups
- find the pulldowns
- other transistors are pass transistors (probably)

The control input which pulls both outputs low is moderately interesting. It does a bit more, just off the picture.

Inputs which control pass transistors are interesting: could be clocks, or control signals.

[guesser]

I couldn't figure out the logic of the top pair of inputs as it seemed more complicated than just enabling/disabling the whole thing.
The lower input apparently pulling down both column lines at the same time as turning on the pull up for all the rows puzzles me too.
There's obviously something I'm missing about how the geometry affects how they work.

Off the top and right of the image is just more copies of the same thing for other bits, with common control inputs. The poly off the bottom of the third input line crosses the all rows of the decoder ROM to Vcc.

I assume everything has different geometry-related internal resistance and leakage that's a little beyond the scope of a 20 year old circuit simulator for secondary school students

[Diminished]

Here's the left-hand decode table, modulo any errors I made.

I may have been the last to spot these things, but anyway:

There are 41 columns. The marketing document claims 46 instructions; it's not a million miles away.

Bit 7 and 6 row pairs appear to work as exact complements of one another. The other bits also tend to follow this pattern, but they become less complementary as you get closer to bit 0. Not sure exactly what it means -- that instruction bits 7 and 6 define four "classes" of instructions, and the other bits evaluate "instances" of instructions of these four types?

Edit: and the right-hand one. I draw no conclusions about this one. There are some complementary parts in places, but it's less clear than for the left-hand table.

[BigEd]

Let me see...

I couldn't figure out the logic of the top pair of inputs as it seemed more complicated than just enabling/disabling the whole thing.

What I'm seeing is a load and a recirculate control: the two inverters which capture the input value are in a broken loop. This is a commonly seen 'register' circuit.

The lower input apparently pulling down both column lines at the same time as turning on the pull up for all the rows puzzles me too.

Aha! So what we probably have is a clock, which precharges the rows, and then they are conditionally discharged. An actively switched pullup is not so common, but they are seen. Because pullups are a bit rubbish compared to pulldowns, sometimes it makes sense to pull up unconditionally and then pull down conditionally.

I've seen both of the above in the 6502. (As far as that goes, there isn't any special care about transistor sizing. A purely binary switch-level simulator can simulate the 6502.)

(Sorry if I'm not managing a good wording of the above: it's coming out sounding a bit too strident for my liking.)

[guesser]

Precharge and discharge in the sense of it being a dynamic circuit? If so that would explain why my DC analysis with no thought given to capacitance made no sense.

[Rich Talbot-Watkins]

Great job!

Here's my interpretation of this table in terms of opcode ranges:

Code: Select all

111x xxxx   E0-FF
0001 xxxx   10-1F

1111 1100   FC
1111 1101   FD
01xx xxxx   40-7F
1111 1110   FE
1000 1xxx   88-8F
1110 11xx   EC-EF
1111 1111   FF
0001 xxxx   10-1F

1111 1000   F8
1010 1xxx   A8-AF
1001 1011   9B
1001 01xx   94-97
1001 1100   9C
1100 xxxx   C0-CF
0111 xxxx   70-7F
111? 10xx   E8-EB, F8-FB ??

1001 1101   9D
1101 xxxx   D0-DF
1110 1001   E9
1111 1001   F9
1001 1011   9B
100x 01xx   84-87, 94-97
10xx 0xxx   80-87, 90-97, A0-A7, B0-B7
0010 xxxx   20-2F

1010 1xxx   A8-AF
1111 1000   F8
1001 1000   98
11xx 0xxx   C0-C7, D0-D7, E0-E7, F0-F7
1111 0xxx   F0-F7
1001 110x   9C-9D
101x 0xxx   A0-A7, B0-B7
1111 1001   F9

1110 1100   EC
0011 xxxx   30-3F
1110 1000   E8
110x 1xxx   C8-CF, D8-DF
01xx xxxx   40-7F
10xx 0xxx   80-87, 90-97, A0-A7, B0-B7

001x xxxx   20-3F

I haven't been rigorous about this, and I might have it wrong, but it fits with observed opcodes in the ROM, particularly special case ones. For example, FC amongst others gets special treatment, and this is the one I have down as CALL from the dumped ROM.

I've been treating any X,!X line with nothing in it as a "don't care", but I don't know what the last column of the second block of 8 means, where both X and !X are present.

Anyway we can assume that the cases without don't cares fire signals for very specific functionality; the lines with multiple ranges will be some kind of generic signal which controls some kind of broad ALU functionality or whatever; lines with small ranges will be a particular family of opcodes, accessing different registers or something.

Going to transcribe the other PLA and see if we learn anything else.

[Rich Talbot-Watkins]

Incidentally, one mystery I'd like to solve is how 2 byte opcodes are described. There doesn't seem to be much of a pattern in that, and I imagine that, of all those signals, some of them will be OR'd together to specify 2 byte opcodes. (I guess the signal is then latched, and causes the subsequent instruction to be fetched to a temporary register instead of the instruction register, given the apparent absence of any timing signal to the PLA).

[guesser]

Oh, now I understand it I think!

The two inputs at the top are latching the value from the bus when switched on and off in the correct sequence. The first one to let the bit in, and the second one holds it in (holds it low when the bus pulls up again)

The bottom input makes sure that no columns are selected and the rows are all pulled up ready to be discharged by the transistor bits when the columns are energised again?

[Diminished]

Incidentally, one mystery I'd like to solve is how 2 byte opcodes are described. There doesn't seem to be much of a pattern in that, and I imagine that, of all those signals, some of them will be OR'd together to specify 2 byte opcodes. (I guess the signal is then latched, and causes the subsequent instruction to be fetched to a temporary register instead of the instruction register, given the apparent absence of any timing signal to the PLA).

Here's one interesting thing, Rich -- there are fourteen columns in the left table which don't have any don't care-looking thingies in them.
And the number of columns in the right table which don't have any don't care-looking thingies in them is ... also fourteen.

Money's on them being the same opcodes.

I'm concerned a bit about those three columns in the right table which don't appear to be connected to anything whatsoever. I might trace those lines later and see if they actually go anywhere.

[Rich Talbot-Watkins]

Here's one interesting thing, Rich -- there are fourteen columns in the left table which don't have any don't care-looking thingies in them.
And the number of columns in the right table which don't have any don't care-looking thingies in them is ... also fourteen.

Money's on them being the same opcodes.

I'm concerned a bit about those three columns in the right table which don't appear to be connected to anything whatsoever. I might trace those lines later and see if they actually go anywhere.

They're not quite the same opcodes (although there is overlap) but I don't think they need be.

The left hand PLA is probably to do with ALU, PC and stack stuff, and the right hand PLA is probably to do with registers and the interface with the bit processor (as we can see lines bridging the horizontal gap). If an opcode has to perform functions in both areas, it'll be in both.

We can see that CALL (FC) and JMP (FE) only appear on the left hand PLA, because they have nothing to do with registers or the bit processor. However FC-FF does appear in the right hand PLA, presumably to perform some generic function (maybe to do with tasks, who knows?).

I need to study this a bit now and see if things make more sense with reference to the ROM dump - maybe some instructions which I'd assumed were part of the same family are not.

I'd still like to know how the number of bytes per opcode is determined though.

Here's the right hand PLA:

Code: Select all

1001 1010   9A
1110 1101   ED
1011 1xxx   B8-BF

1010 1xxx   A8-AF
1111 1111   FF
1110 1001   E9
1000 10x1   89, 8B
01x1 xxxx   50-5F, 70-7F
1000 1100   8C
01xx xxxx   40-7F
1000 100x   88, 89

xxxx xxxx   00-FF
xxxx xxxx   00-FF
xxxx xxxx   00-FF
1000 101x   8A, 8B
110x 1xxx   C8-CF, D8-DF
100x 110x   8C, 8D, 9C, 9D
100x 1011   8B, 9B
1110 1011   EB

1001 01xx   94-97
101x 0xxx   A0-A7, B0-B7
100x 01xx   84-87, 94-97
1011 0xxx   B0-B7
1001 00xx   90-93
1110 1010   EA
1111 1001   F9
10xx 0xxx   80-87, 90-97, A0-A7, B0-B7

1110 0xxx   E0-E7
110x 0xxx   C0-C7, D0-D7
1011 1xxx   B8-BF
0001 xxxx   10-1F
1111 1111   FF
xxxx xxxx   00-FF
0xxx xxxx   00-7F
011x xxxx   60-7F

1001 1100   9C
1000 00xx   80-83
1100 xxxx   C0-CF
1001 110x   9C, 9D
1001 1000   98
1111 0xxx   F0-F7
1000 1xxx   88-8F
1111 11xx   FC-FF

10xx 0xxx   80-87, 90-97, A0-A7, B0-B7
0011 xxxx   30-3F
11xx 0xxx   C0-C7, D0-D7, E0-E7, F0-F7
0000 xxxx   00-0F
1110 11xx   EC-EF
1010 1xxx   A8-AF
0001 xxxx   10-1F
1110 1000   E8

1111 1000   F8
1001 1011   9B
100x 01xx   84-87, 94-97
1111 0xxx   F0-F7
110x xxxx   C0-DF
0010 xxxx   20-2F
01xx xxxx   40-7F

[Rich Talbot-Watkins]

By the way, I really don't know that FC is CALL or FE is JMP. I've just been assuming that because it makes most sense in the context of the ROM dump, and we can see if it helps make sense of things as we carry on tracing lines. But let's not be surprised if it turns out to be completely wrong.

[BigEd]

Oh, now I understand it I think!

Yep!

[Diminished]

Hey, BigEd (or anyone), what are these things?

[BigEd]

Are they pullups? They look like they could be.

[Diminished]

I'm concerned a bit about those three columns in the right table which don't appear to be connected to anything whatsoever. I might trace those lines later and see if they actually go anywhere.

Checked them, and indeed, they don't seem to be!

So I think these three can just be disregarded:

xxxx xxxx 00-FF
xxxx xxxx 00-FF
xxxx xxxx 00-FF

They're not connected on the 8273 either.

Are they pullups? They look like they could be.

Thanks, yes, it seems likely, but I have zero IC design experience!

[guesser]

Yes I believe those are pull ups, to the big Vcc off the top of the screen, hidden under the ground metal but with no connection to it. I recognise where that is

[Diminished]

They're transistors, yes? Not resistors?

edit: One more I missed, Rich, in the right-hand PLA:

1111 1111 FF
xxxx xxxx 00-FF <- this one
0xxx xxxx 00-7F

This one doesn't involve a transistor, but the column is just connected directly to one of the row feeds.

pla_2_miss.jpg (32.49 KiB) Viewed 901 times

I don't know whether this makes it a 1 or a 0, but either way it's only affected by bit 3, so this should either read

xxxx 1xxx 08-FF

or

xxxx 0xxx 00-F7