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

discuss both original and modern hardware for the bbc micro/electron
User avatar
Diminished
Posts: 566
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 » Mon Aug 31, 2020 5:44 pm

guesser wrote:
Mon Aug 31, 2020 5:34 pm
Right, I've added "alpha", with a small correction where something was connected that shouldn't be again.
Whereabouts?

guesser
Posts: 493
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 » Mon Aug 31, 2020 7:12 pm

Diminished wrote:
Mon Aug 31, 2020 5:44 pm
Whereabouts?
Oh, how odd, I've overlaid mine over your original and can't see a difference. It must have been some other trace that had an error. :oops:

I have hooked up a bit more to "long1" which I'm currently trying to work my way through. Around 2000,960 in your coordinate system hopefully https://temp.zxnet.co.uk/8271/new%20long1.png
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Rich Talbot-Watkins
Posts: 1679
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Mon Aug 31, 2020 10:03 pm

Has anyone yet managed to transcribe the contents of the narrow ROM to the right of the program ROM (bottom left), which may be something to do with the multitasking madness? I'm intrigued by what it might contain.

guesser
Posts: 493
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 » Mon Aug 31, 2020 10:48 pm

Rich Talbot-Watkins wrote:
Mon Aug 31, 2020 10:03 pm
Has anyone yet managed to transcribe the contents of the narrow ROM to the right of the program ROM (bottom left), which may be something to do with the multitasking madness? I'm intrigued by what it might contain.
Until we know where all the output lines go and what the hardware at the other end does, I don't see how having the values helps much.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

guesser
Posts: 493
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 » Tue Sep 01, 2020 12:40 am

guesser wrote:
Mon Aug 31, 2020 7:12 pm
It must have been some other trace that had an error. :oops:
This was embarrassing and highlighted what I knew all along but like an idiot didn't do anything about, that this is a highly complicated project and I should be using version control so that I can track what I've actually done.
Better late than never, I've stuck my vector file in git: https://github.com/ZXGuesser/Intel-8271-reversing
Github can even do visual diffs of svg, but you'd need an extremely large monitor to see any actual detail in this image :lol:
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Diminished
Posts: 566
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 » Tue Sep 01, 2020 1:05 am

Made some notes on Fig. 1 in the patent while trying to get my head round it.

Talking mainly about the byte processor rather than the bit processor here.
8271-patent-fig-1.jpg
The main thing I took away is that the PLA address generator -- which is used to load the program counter with a new value when a task switch occurs -- builds the new PC value from three pieces: 4 bits from the encoder (33) to pick a routine; 4 bits from the currently selected case register (32) to pick a segment within that routine; and 2 bits which apparently have something to do with picking a case register to update, which I'll need to study the discussion of Fig. 2 in order to understand properly. But it's late and I'm tired.

Code: Select all

- ROM programmed with multiple routines
- bit processing unit talks via 8-bit bus (20) to register file (19)
- register file then talks to 6502 via external 8-bit bus (12)
- 6502 talks back to bit processor via command (37) and parameter buffers (38), in same block as register file (19)
- 8-bit/10-bit internal bus (20)
- 10-bit instruction storage (22); that's our big ROM, 8-bit instructions
  - contains multiple routines
  - big ROM sends instructions to instruction register & decoder (25) over internal bus (20, 8-bit mode)
    - instruction decoder:
      - talks directly to timing & control block (26) via dedicated means
      - also contains the "address register" (35), which has something to do with choosing a case register to be updated??
- program counter (28) can either be loaded via the internal bus (20, 10-bit) or incremented
  - PC block (28) also includes stack and stack pointer
  - addresses loaded into PC via internal bus (10-bit mode) from task dispatcher
- task dispatcher:
  - picks highest priority routine
  - is able to determine status of routine
  - contains (4-bit?) case register (32), and PLA-based address generator (30), both connected to internal bus
  - also contains address encoder, latch, and priority resolver (33)
  - priority resolver:
    - based on "novel logic tree"
    - resolves multiple request input signals, each representing a routine
    - information on status of routines is stored in memory in the resolver
    - there is a means for updating status info stored in this memory to pick correct segment of each routine
    - encoder generates 4-bit signal which is sent over *half* of 8-bit mode internal bus to PLA address generator (30)
      - these 4 bits choose a routine to be run
    - meanwhile, resolver may generate separate 4-bit signal via dedicated 4-bit link which picks a case register
    - case registers:
      - store info on status of tasks
      - used to select a segment of a particular routine to run
      - chosen case register is coupled to the internal bus and forms the *other half* of the signal to the PLA (4-bit)
        - these 4 bits choose a *segment* of the routine that was picked by the other 4-bit signal from the encoder
    - PLA *also* receives a 2-bit signal from the instruction register (25) via dedicated 2-bit link (43)
      - this has something to do with choosing a case register to be updated???

User avatar
scarybeasts
Posts: 577
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 » Tue Sep 01, 2020 7:22 am

Hi,

Here's one other thing Ken shared with me -- his annotation of where the high-level blocks likely are:

image (2).png

Probably no huge surprises?


Cheers
Chris

User avatar
scarybeasts
Posts: 577
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 » Tue Sep 01, 2020 7:58 am

Diminished wrote:
Tue Sep 01, 2020 1:05 am
The main thing I took away is that the PLA address generator -- which is used to load the program counter with a new value when a task switch occurs -- builds the new PC value from three pieces: 4 bits from the encoder (33) to pick a routine; 4 bits from the currently selected case register (32) to pick a segment within that routine; and 2 bits which apparently have something to do with picking a case register to update, which I'll need to study the discussion of Fig. 2 in order to understand properly. But it's late and I'm tired.
If we could somehow get a list of routine start addresses, that would be very helpful. I'm working with Rich to try and work out the opcodes from the ROM. We do have some good leads but deciphering an unknown ISA isn't easy.


Cheers
Chris

User avatar
Rich Talbot-Watkins
Posts: 1679
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Tue Sep 01, 2020 8:46 am

scarybeasts wrote:
Tue Sep 01, 2020 7:58 am
If we could somehow get a list of routine start addresses, that would be very helpful. I'm working with Rich to try and work out the opcodes from the ROM. We do have some good leads but deciphering an unknown ISA isn't easy.
I figured the best thing at this point is just to share what we've got so far and see if it inspires anyone!

Chris started all of this about a week ago when he observed that guesser's ROM dump yielded some familiar constants (like E5) if all the bits were inverted. When he discovered further interesting stuff like the clock and data bytes for address marks, all close together in the ROM, it seemed like there might be something in it.

A few hours of analysis, and we ended up with this:

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

As you can see, it's mostly a big block of unknown data, but there is structure there, and what could even be described as snippets of code which make sense!

We quickly determined that clock bytes and data bytes seem to be specified with opcodes F4 and F5 (e.g. at address 18B). There are other frequently used opcodes like F3 and F0, and the current theory is that they write to an output port which is connected to the bit processor.

We were seeing a lot of FC...FF, and at first I assumed that this was also writing to ports, but I'm now fairly sure that this is some kind of JMP instruction to a 10-bit address. There are bits of code which really make sense with that idea in place, e.g. at address 2AB. Obviously we don't know what kind of jump it is, whether it's a subroutine call, something conditional... who knows?

There are plenty of places with these JMP opcodes one after the other, which doesn't make sense unless it's a subroutine call (but being a subroutine call doesn't make sense in other contexts).

Anyway, we can see snippets of logic which seem to form the guts of the 'format' command. We can also see specific values being loaded into a register (we're thinking the accumulator) which represent the result code from reading sectors. How this arrives in the result register is unknown.

Does anyone have any ideas if we can go any further with this, without reverse engineering more of the die logic? Do the few opcodes we have discovered seem familiar from any previous Intel ISA, or is this something Brand New (in 1978)? :lol:

I think a big piece of the puzzle we're missing is the whole multitasking/code segments thing from the other narrow ROM. Perhaps this code is not supposed to be read as a continuous thing, but more as discrete blocks of code which can be executed in whichever order the dispatcher decides. It would be good to know if there's some sort of RET or YIELD opcode which marks the end of a segment. If anyone has any ideas or comments, please leave them either in this thread or in the doc itself!

User avatar
BigEd
Posts: 3542
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 » Tue Sep 01, 2020 9:32 am

Marvellous! I would expect to see a YIELD kind of opcode at the end of a routine. Maybe to see some opcodes which stall waiting for something to happen? That being quicker and shorter than a loop. Or possibly yielding will always make more sense - let the scheduler react to events, no need for code to do it.

As we're told routines can stop half way and be resumed, I'd expect there would need to be some kind of register windowing to allow for multiple contexts. And I can't quite see how a single stack would serve, unless execution is always nested.

Great to see Ken's annotations on the floorplan BTW. Sounds like he must be doing a bit of investigating of his own.

User avatar
Diminished
Posts: 566
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 » Tue Sep 01, 2020 10:51 am

Haha, nice. You boys have been busy.

The same thought occurred to me -- that it works a bit like a set of ISRs? I've encountered no mention of multiple stacks either. Maybe one "segment" means a short callback routine which is run quickly in one shot, and which is obliged to leave the stack empty when it's done.

User avatar
Diminished
Posts: 566
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 » Tue Sep 01, 2020 11:02 am

BigEd wrote:
Tue Sep 01, 2020 9:32 am
Marvellous! I would expect to see a YIELD kind of opcode at the end of a routine.
Yeah, I now notice that's actually explicit in the patent.
Screenshot 2020-09-01 at 11.02.10.png
edit: one more thing:
Screenshot 2020-09-01 at 11.34.07.png
So in multi-segment routines, you might expect some instruction which updates the currently selected case register to pick the next segment to be executed; and then maybe there will be a "priority check" (yield) instruction shortly afterwards. So, maybe 2 bytes, with the successive segment number encoded in the first byte, and the second performing a yield? Or maybe 3 bytes, with the first and last ones constant, but the middle one choosing the next segment?

Of course there's a chance that the 8271 application doesn't make use of segments at all, in which case you'd never need to update the case register.

User avatar
Diminished
Posts: 566
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 » Tue Sep 01, 2020 2:42 pm

Rich Talbot-Watkins wrote:
Tue Sep 01, 2020 8:46 am
Perhaps this code is not supposed to be read as a continuous thing, but more as discrete blocks of code which can be executed in whichever order the dispatcher decides. It would be good to know if there's some sort of RET or YIELD opcode which marks the end of a segment. If anyone has any ideas or comments, please leave them either in this thread or in the doc itself!
One more piece of evidence ("event driven"):
Screenshot 2020-09-01 at 14.39.43.png
It does seem like maybe the whole thing resembles an interrupt system.

User avatar
Diminished
Posts: 566
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 » Tue Sep 01, 2020 3:04 pm

Looking at this now, in terms of working out how many distinct "routines" exist:
Screenshot 2020-09-01 at 14.55.17.png
Hypothesising: there's one routine in ROM per dispatcher request input ("interrupt line"). The above piece of circuitry's location might be betrayed by a unique feature it seems to have -- that four bits go directly to the 8-bit bus, but the other four are passed through the case register block. If we can find a structure with this 4/4 split property somewhere on the die, then we might be able to see through inspection how many request inputs there are. And that might tell us how many separate routines are in the ROM.

User avatar
Rich Talbot-Watkins
Posts: 1679
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Tue Sep 01, 2020 3:19 pm

That's great! And now we have some good guesses as to where separate routines might be in the ROM, which will help with corroborating observations from the die. I'm now a bit lost on whether we still think the narrow ROM is responsible for holding these addresses, and what its inputs and outputs are (weren't there "don't cares" in there?), but sounds like you have some idea what you're looking for :)

User avatar
Diminished
Posts: 566
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 » Tue Sep 01, 2020 5:18 pm

I'm no expert, as this thread verbosely documents, but the first thing is I've noticed is I think we might have been reading the address generator the wrong way round.

I think the inputs arrive to the bigger table on the left, and the outputs leave via the smaller one on the right. At least, the top of the right-hand table pretty explicitly seems to end up feeding a load of FET gates, and I ain't heard of gates producing outputs before.

guesser
Posts: 493
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 » Tue Sep 01, 2020 5:47 pm

The columns on the right seem to go up to outputs on the bus to me, but they're rather hard to follow.

Like the ROM the outputs pull the bus lines down to ground.

That's the next thing I was going to trace as Rich wanted the data read out from that too.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.


guesser
Posts: 493
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 » Tue Sep 01, 2020 6:09 pm

yes, it's the same as what the ROM (and everything else) does to drive the bus. See the schematic I posted.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

guesser
Posts: 493
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 » Tue Sep 01, 2020 6:14 pm

Wait, I think we're agreeing aren't we? Your first post has confused me. Sorry I'm feeling under the weather this afternoon and waiting until I can take another dose of paracetamol.

8 complicated somethings provide signals to the inputs of the wide left hand table, to generate row select lines, and the resulting data goes up the coloumns of the right table out onto the bus.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Diminished
Posts: 566
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 » Tue Sep 01, 2020 6:16 pm

guesser wrote:
Tue Sep 01, 2020 6:14 pm
Wait, I think we're agreeing aren't we?
Yeah. I thought you originally read the tables the other way round, but maybe not.

guesser
Posts: 493
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 » Tue Sep 01, 2020 6:29 pm

Diminished wrote:
Tue Sep 01, 2020 6:16 pm
Yeah. I thought you originally read the tables the other way round, but maybe not.
Ah sorry. Yeah I've only posted up the "address" side with the don't care states etc, and not read out the output bits yet.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Diminished
Posts: 566
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 » Tue Sep 01, 2020 6:36 pm

guesser wrote:
Tue Sep 01, 2020 6:29 pm
Diminished wrote:
Tue Sep 01, 2020 6:16 pm
Yeah. I thought you originally read the tables the other way round, but maybe not.
Ah sorry. Yeah I've only posted up the "address" side with the don't care states etc, and not read out the output bits yet.
Ah right, I thought you'd done both halves. Sorry.

So the don't care stuff makes more sense now, because we know from the patent that the address inputs are split 4/4/2, for the routine ID, the segment ID, and ... the something-else ID.

The something-else ID is in the rightmost two columns; they're the ones that don't come off the bus.

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 » Tue Sep 01, 2020 8:34 pm

The patent is an amazing finding, congratulations. And the complexity and the size of this chip it is also amazing. It is a true behemoth. No wonder it was so expensive and consumes so much power.

I'll try later to post a die shot of the first WD FDC, tiny in comparison. To give you an idea of the difference, it doesn't have a full ALU because it isn't really needed.

User avatar
Diminished
Posts: 566
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 » Wed Sep 02, 2020 12:02 am

Well I tried to read out the table of program counter values.

The results make absolutely no sense whatsoever.

I am officially declaring myself insane.

guesser
Posts: 493
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 » Wed Sep 02, 2020 12:10 am

Ok, here's the small ROM or PLA or whatever we're calling it.
X in the input are don't care.

The first 8 inputs come off the bus, and the other two come from somewhere else.

The input bits are in the reverse order to the large ROM inputs and outputs. I think the first 8 bits of the output are in the same order as the main ROM, but I've not fully traced them out yet.

In the bus line "colours" scheme, the input bits are: W G Y O C R B P (last two bits from elswhere).

The last two bits on the output go to the two extra lines that follow part of the bus and the first two bits of the main ROM address.
Attachments
small-rom.txt
corrected rows 35 and 70
(3.56 KiB) Downloaded 19 times
Last edited by guesser on Wed Sep 02, 2020 2:40 am, edited 1 time in total.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Diminished
Posts: 566
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 » Wed Sep 02, 2020 12:22 am

My effort had bit 9 on the right and bit 0 (white) on the left, so the reverse of the "reg10" block, but I've really no idea any more.

I got this load of nonsense (bits are reversed).

Code: Select all

27a
66
a7
a7
8e
a7
2af
2ab
2c1
27f
97
97
87
7e
32e
30e
30f
2ed
190
30c
30e
314
30e
30f
19d
1ad
205
307
30b
13
76
58
1bd
1fc
2aa
29c
2a4
17d
2ed
ce
c3
178
06
53
192
c9
5d
de
283
25a
58
21c
336
30f
288
a6
32
278
14
30b
30
35
6c
2ce
233
2d0
271
2e8
274
bc
30b
ac
31a
1b8
30b
13
318
7a
218
31a
32a
202

guesser
Posts: 493
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 » Wed Sep 02, 2020 12:32 am

Yep I've looked again, you're quite right.
So both parts have reversed bit order to the large ROM 👍
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Diminished
Posts: 566
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 » Wed Sep 02, 2020 12:39 am

The results make no sense!

At least they do all seem to live within the 864 bytes of program, at least with the way I transposed them ... but they make no sense!

User avatar
Diminished
Posts: 566
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 » Wed Sep 02, 2020 1:04 am

Here's guesser's readout with the bits reversed, and converted to hex. (edit: to clarify, that's the output table -- the one that the patent claims loads the PC). Four values differ from my attempt but I took no real care, so I don't doubt that his are more accurate.

Code: Select all

27a
66
a7
a7
8e
a7
2af
2ab
2c1
27f
97
97
87
7e
32e
30e
30f
2ed
190
30c
30e
314
30e
30f
19d
1ac
205
307
30b
13
76
58
1bd
1fc
2be
29c
2a4
17d
2ed
ce
d3
178
6
53
192
c9
5d
de
283
25a
58
21c
336
30f
288
a6
32
278
14
30b
30
35
6c
2ce
233
2d0
271
2e8
274
2bc
30b
ac
31a
1b8
30b
13
318
7a
218
31a
32a
202
If you sort them, you find this popular range of values:

30b
30b
30b
30b
30c
30e
30e
30e
30f
30f
30f

I dunno.

/tmp/transpo$ hexdump -C 8271bigrom__invert-bits | grep 300
00000300 36 03 7f 38 06 0f ee 02 25 04 35 ff f4 ff ff f0 |6..8....%.5.....|

None of it makes a lot of sense to me.

Post Reply

Return to “8-bit acorn hardware”