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

[guesser]

Which four values?

[guesser]

Checked them, and we each had two errors.
Your 35th and 70th values were the correct ones.

I've corrected the file on my previous post.

[Rich Talbot-Watkins]

Thanks both!

These addresses make considerably more sense when entered into the ROM "disassembly"!

In particular, it marks out some specific addresses which I already had earmarked as entry points.

https://docs.google.com/document/d/1bQT ... WWCyQ4lFVM

I've revised some ideas - I no longer think FC...FF are 10-bit JMPs. I think more likely that FC is a call within the same page, and FD may be RET. I think FE is a JMP within the same page, and no idea what FF is any more, but I have it down as a 1 byte opcode, as it makes more sense given the new context from the entry points.

An example of this working out nicely is at 1A8, where it reuses the code to set the clock bits (and the order it assigns the F4, F5 registers is reversed to be able to jump into the middle of them).

The next question is what determines the flow from segment to segment? Something encoded in the yield opcode? Or something hardcoded in the ROM? What do the input lines of the ROM represent (as opposed to the output lines you've transcribed)?

[guesser]

I thought the suggestion was four of the bits coming off the bus into the address decoder are from the case register and four from a segment address generator whatever those are. With the last two bits (page?) coming from somewhere else. Vague I know!

[Diminished]

Sorry guesser -- went to bed, didn't see your post.

Have a gawk at the patent if you get the chance, Rich, but yeah -- the input to the thing is supposed to be four bits of routine ID, four bits of segment ID, and two bits of something else (which are the rightmost two bits on the die, but we think they're the MSBs in codespace).

[Diminished]

The next question is what determines the flow from segment to segment? Something encoded in the yield opcode? Or something hardcoded in the ROM?

I had a go at addressing this (ho ho) earlier in this post.

Basically the patent seems to state that "yield" and "declare next segment ID" are distinct instructions. I'd expect they did implement it that way, but who knows? So "declare next segment" could be one byte, could be two.

I'd thought "next segment" would immediately precede "yield", but there's no reason why that would be the case. I think I'd just tend to code it that way.

[Rich Talbot-Watkins]

Interesting... it's very common for routines to contain sequences like this:

Code: Select all

; ** entry point 19 **
1AC   F5 E5		; sector fill byte data
1AE   F4 FF		; sector fill byte clock

1B0   FC D1		; CALL 1D1?
1B2   98 E5		; LD A,#E5
1B4   FC EF		; CALL 1EF? Add byte to CRC?
1B6   0D  <------- (segment?)
1B7   EE  <------- (yield?)

Maybe you're on to something...

[Diminished]

Well ...

I took a shot at writing up the relationships between the inputs to the PLA and its outputs based on what we think we know about how the bus is split. The outputs are in die order.

The results are weird, but there's one encouragement, which is that the ID1 + ID2 + ID3 tuple does seem to form a unique key, as you'd expect. I didn't see any instances of multiple rows which have the same set of IDs.

ID1, 2 and 3 are all in decimal here, but I left the PC in hex. IDs 2 and 3 should be the routine and segment IDs, but which way around they are is unknown.

I might also be missing an input-side inversion.

Code: Select all

ID1 ID2 ID3 (decimal)         PC (hex)
----------------------------------
0   3   4                     27a

0   2   13                    66
0   2   4                     a7
0   2   5                     a7
0   2   6                     8e
0   2   7                     a7
0   2   2                     2af
0   2   3                     2ab
0   2   8                     2c1
0   2   10                    27f
0   2   0                     97
0   2   1                     97
0   2   11                    87
0   2   14                    7e
0   2   15                    32e

0   1   0                     30e
0   1   1                     30f
0   1   2                     2ed
0   1   3                     190
0   1   4                     30c
0   1   5                     30e
0   1   6                     314
0   1   7                     30e
0   1   8                     30f
0   1   9                     19d
0   1   10                    1ac
0   1   11                    205

1   1   8-15                  307
1   1   0-7                   30b

1   2   8                     13
1   2   3                     76
1   2   5                     58
1   2   10                    1bd
1   2   11                    1fc

1   3   0,8                   2aa
1   3   1,9                   29c
1   3   2,10                  2a4
1   3   3,11                  17d
1   3   4,12                  2ed
1   3   5,13                  ce

2   0   *                     d3
2   1   *                     178
2   2   *                     6
2   3   *                     53
2   4   *                     192
2   5   *                     c9
2   6   *                     5d
2   7   *                     de
2   8   *                     283
2   9   *                     25a
2   10  *                     58
2   11  *                     21c
2   12  *                     336
2   13  *                     30f
2   14  *                     288
2   15  *                     a6

3   2   *                     32
3   3   *                     278
3   8   *                     14
3   13  *                     30b
3   9   0,2,8,10              30
3   9   1,3,9,11              35
3   9   4,5,6,7,12,13,14,15   6c
3   4   0                     2ce
3   4   1                     233
3   4   2                     2d0
3   4   3                     271
3   4   4                     2e8
3   4   5                     274
3   4   8                     bc
3   5   0                     30b
3   5   1                     ac
3   5   5                     31a
3   5   10,11                 1b8
3   7   0                     30b
3   7   1                     13
3   7   3                     318
3   7   5                     7a
3   7   6                     218
3   7   8                     31a
3   11  *                     32a
3   12  *                     202

[scarybeasts]

I took a shot at writing up the relationships between the inputs to the PLA and its outputs based on what we think we know about how the bus is split. The outputs are in die order.

This is great work. The actual addresses are all very plausible routine addresses within the ROM, and all within bounds -- with the caveat we still haven't got much of an idea of the instruction set.

The organization is anyone's guess though. It seems like the multi-tasking core provides lots of new ways for control flow to be expressed, on top of the traditional call / jump / branch. We don't know what opcodes exist to control program / segment / address / case registers etc., and to yield. What a complexity

What would be amazing would be if we could start tracing the bits of the instruction register into the PLA -> registers and ALU.


Cheers
Chris

[Diminished]

I wish there were better photographs. Having two chips is very useful but the precipitate (if that's what it is) always seems to collect in the same places on whichever die is being looked at, so there are always parts of the chip that are obscured. I'd really like to give Degate a try, if I can convince it to build.

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.

Do you think you could ask Sean how, in an ideal world, he proposes cutting the package? Not in terms of tools used, but simply in terms of where the cuts should be made? I'm almost tempted to have a crack on one of my spare 8271s.

It sounds like he's going to have a look at the 8273, so it would be cool if we can get the ROMs out of that too.

[BeebMaster]

Could a logic analyser be attached to an 8271 in-situ to try to understand the instruction set?

[Diminished]

Could a logic analyser be attached to an 8271 in-situ to try to understand the instruction set?

Not "officially". As far as we know, you'd need to tap the thing's internal bus. If that could be done, the effort would be over very quickly.

I've briefly thought about this possibility before, but maybe the internal bus state could be persuaded to leak, either via the internal registers, or via the external pins. It's even possible that it leaks under certain conditions already, but we just haven't noticed. Security wasn't a thing back then.

Clock glitching, VCC glitching? Maybe it could be done. Somebody would need to build a test harness for the thing.

[Rich Talbot-Watkins]

What would be amazing would be if we could start tracing the bits of the instruction register into the PLA -> registers and ALU.

Yes! Assuming that the decode PLAs are the two things left and right of centre, it'd be great to start trying to get a broad overview of how the opcodes are structured. One thing I'm not understanding right now is how two byte opcodes are handled. There's compelling evidence for two byte opcodes in the ROM, but there only looks like 8 pairs of lines to the PLA (opcode bits and their complements). Without an additional bit of timing state, I'm not really clear how this would be decoded.

In addition, the number of bytes for an opcode isn't clearly discerned from the value, e.g. from guesswork and intuition by looking at the ROM, it seems that:

FC 11111100 = CALL (2 bytes)
FD 11111101 = RET or similar (1 byte)
FE 11111110 = JMP (2 bytes)
FF 11111111 = unknown (1 byte)

but also:

88-8F 10001xxx = conditional branch (2 bytes)
A0-A7 10100xxx = some ALU op (1 byte)
B8-BF 10111xxx = some different kind of register/port load (2 bytes)
Ex 1110x000 = (2 bytes)
Ex 1110xxxx = (1 byte; EE = yield/wait)
F0-F7 11110xxx = register/port load (2 bytes)

No kind of obvious pattern there for ease of decoding.

[scarybeasts]

Not "officially". As far as we know, you'd need to tap the thing's internal bus. If that could be done, the effort would be over very quickly.

What about the crazy mode I found that kicked this whole thing off? It's probably some form of test mode; the 8273 data sheet has a "TEST MODE" box as part of the external registers.

I don't know what signals it's putting out on the external pins. Perhaps internal bus -- what else would make sense?


Cheers
Chris

[1024MAK]

Really need to hook a spare chip up to a logic analyser, best if it was on a breadboard rather than in a existing system. Then all the relevant lines can easily be monitored.

Mark

[BigEd]

> crazy mode
> test mode

and from your blog:
> Flipping the motor on and off at 375kHz is not an expected controller behavior and it may even be bad for a motor

Certainly sounds to me like it's worth capturing this output, in parallel: do you have a 40 pin clip to take traces with?

Also, in the blog comments we see that a microcontroller or two has a test mode activated when a particular input pad is taken to an extra-high voltage. I wonder if one could see this kind of three-level input by studying the circuitry immediately inboard of the various input pads?

[scarybeasts]

> crazy mode
> test mode

and from your blog:
> Flipping the motor on and off at 375kHz is not an expected controller behavior and it may even be bad for a motor

Certainly sounds to me like it's worth capturing this output, in parallel: do you have a 40 pin clip to take traces with?

I'm not set up to capture this unfortunately. Do you have anyone who is?

As per earlier suggestion, I'd second setting up an 8271 in isolation on a breadboard. This avoids extra circuitry between the 8271 and the beeb's external port. There were at least two different modes: setting bit 1 or bit 2 on the data pins with address 2 selected.


Cheers
Chris

[hoglet]

I'm not set up to capture this unfortunately. Do you have anyone who is?

I'll have a play with this tomorrow.

[BigEd]

Excellent!

[Diminished]

I agree it's worth doing. I'm glad someone else volunteered. I can capture 8 parallel bits but that's all you'll get out of me.

Has anyone tried inspecting what happens to the 8271 registers with either 2 or 4 written to the reset register? Does the chip even respond at that point? I don't have a Beeb set up to check. Shameful, I know.

More incoherent drivel, not worth reading:

Another thing that struck me is that 375 KHz is weird, as it isn't an integer factor of the 4 MHz clock supplied. Maybe the internal clock runs at 12 MHz -- the 8273 sheet mentions a PLL. (How fast could NMOS even go in the late 70s?) One other thing I noticed though is that if it were 400 KHz instead of 375, that would be 10 cycles, which coincidentally is the length of time the data sheet tells you that you need to hold the RESET pin for in order to reset the chip. Shrug.

Regarding leaking bus state -- I was thinking it would be most useful if you could find a way to make it happen at an arbitrary point in time. Clock glitching might not be as successful as I'd hoped if the thing has a PLL -- you'd really prefer a direct drive there. I don't really even know what would happen to a PLL's output if you just stopped the input clock dead.

Maybe VCC glitching would yield something, if you can introduce very short powerless pulses, you might be able to get parts of the chip to stop but other parts to carry on working for one cycle or something? Perhaps if you start an operation that will end up updating the on-board registers, then glitch during the operation, you might end up with something in the registers which wasn't supposed to be there? The thing will have some power line capacitance on board though, which will mess with this.

Oh, and I found this in the AUG today:

It [the 8271] is an exceptionally complex chip ...

Yes

[hoglet]

Another thing that struck me is that 375 KHz is weird, as it isn't an integer factor of the 4 MHz clock supplied. Maybe the internal clock runs at 12 MHz -- the 8273 sheet mentions a PLL. (How fast could NMOS even go in the late 70s?) One other thing I noticed though is that if it were 400 KHz instead of 375, that would be 10 cycles, which coincidentally is the length of time the data sheet tells you that you need to hold the RESET pin for in order to reset the chip. Shrug.

Here's Chris's scope shot showing 375KHz:

It's a mix of two frequencies, both of which are likely to be a integer factor of 4MHz.

What I was planning to do was to try to get a syncronous capture (using the 4MHz clock), and see if it's a repeating sequence, and try to work out what the length of that sequence is.

Dave

[scarybeasts]

Another thing that struck me is that 375 KHz is weird,

I wouldn't read too much into the 375 kHz figure. That's as reported by a terrible scope. And the signals weren't clean square waves (which gives hope these could be internal bus lines), so 375 kHz is more of a lower bound.

The conference paper says the byte processor does its simple instructions in 1.25us. This is 800000 instructions a second, or 1 every 5 ticks of the incoming 4MHz clock.


Cheers
Chris

[scarybeasts]

What I was planning to do was to try to get a syncronous capture (using the 4MHz clock), and see if it's a repeating sequence, and try to work out what the length of that sequence is.

That sounds great. Just to recap what I remember; I don't think all of this is in the post:

- Setting bit 2 (0x04) in the reset register causes the behavior described in the post, where multiple drive-facing lines go wild. The lines all looked different. I attach another image I found of the write enable (omg!) line.
- Setting bit 1 (0x02) in the reset register caused a different set of host-facing lines to go wild. I think including the NMI line? The beeb certainly wedges if you do ?&FE82=2.

Maybe a different set of useful information is offered in these two modes.

Capturing the first addresses would be very useful. Hopefully that will happen if you activate reset (bit 0, 0x01) at the same time as one of the test bits, then lower reset?


Cheers
Chris

[hoglet]

With an Intel 8271 as your disc chip:
?&FE82=4

It makes my drive go crazy: https://www.youtube.com/watch?v=sRcb3goLbZI

I've just hooked the scope up, and I'm not seeing quite the same behaviour.

(This is with no disk drive connected, for obvious reasons....)

What I'm seeing is a series of perfect square waves:
- Pin 35 (WREN) - 200KHz
- Pin 36 (STEP) - 100KHz
- Pin 37 (DIR) - 50KHz
- Pin 38 (LOAD HEAD) - 25KHz
- Pin 39 (LOW CURRENT) - 12.5KHz
- Pin 1 (FAULT RESET) - 6.25KHz
- Pin 2 (SEL 0) - 3.125KHz
- Pin 6 (SEL 1) - 1.5625KHz

This I guess establishes a logical ordering for the test outputs.

(On pins 1 and 2 there are some additional frequences superimposed at 400KHz and 4MHz at low levels, almost like cross-talk).

The part is marked:

Code: Select all

P8271
V3520013
Intel '78

I don't have a DFS or ADFS ROM fitted, so no other writes to the FDC are occurring.

This is quite different to what Chris saw, which seemed far more chaotic.

It could be the lack of a DFS ROM (maybe some of it's reset behaviour is significant)

It could be that it needs a drive attached to enable this behaviour (i.e. the inputs need to be in a certain state)

Any thoughts anyone?

Dave

[BeebMaster]

Is the Disc NMI enabled? (ie. link S9 open)?

[hoglet]

Is the Disc NMI enabled? (ie. link S9 open)?

Yes, link S9 is open, and the disk interface works correctly when a drive is connected.

I'm measuring NMI on pin 11 of the 8271.

I don't ever see NMI asserted, no matter what value I write to &FE82, and I haven't yet has the machine hang.

Dave

[scarybeasts]

What I'm seeing is a series of perfect square waves:
- Pin 35 (WREN) - 200KHz
- Pin 36 (STEP) - 100KHz
- Pin 37 (DIR) - 50KHz
- Pin 38 (LOAD HEAD) - 25KHz
- Pin 39 (LOW CURRENT) - 12.5KHz
- Pin 1 (FAULT RESET) - 6.25KHz
- Pin 2 (SEL 0) - 3.125KHz
- Pin 6 (SEL 1) - 1.5625KHz

This I guess establishes a logical ordering for the test outputs.

Maybe try raising other higher bits as well as 0x04? We don't know how to program this test register; maybe it'll show us something else useful if we fiddle with its bits.


Cheers
Chris

[scarybeasts]

I don't ever see NMI asserted, no matter what value I write to &FE82, and I haven't yet has the machine hang.

That's interesting. ?&FE82=2 wedged my machine.

[Diminished]

Dug the Beeb out.

With DFS 0.98, and no drive:

Press BREAK, then ?&FE82=2 crashes the machine.

However:

Press BREAK, then ?&FE82=1:?&FE82=0:?&FE82=2 does not crash the machine. (?!)

edit: Maybe it only works after the RESET pin is asserted? (Does BREAK do that?)

edit2: Now ... I've dug the 'scope out.

Values like xxxx0x10 (2, 6, 18, 22 ...) seem to produce a 400 KHz square wave on the INT pin.
Values like xxxx1x10 (10, 14, 26, 30 ...) seem just to pull the INT pin high and leave it there!

[Coeus]

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?