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

discuss both original and modern hardware for the bbc micro/electron
Post Reply
guesser
Posts: 485
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser » Tue Aug 25, 2020 9:08 pm

Diminished wrote:
Tue Aug 25, 2020 9:00 pm
I think there is at least one clue that the bit ordering is right, which is the 2/8 split in the structure that feeds the ROM's address lines. I could be wrong but I feel like that does reflect the A[1:0]/D[7:0] nature of the internal register block mentioned in the data sheet.

I was hoping we could get a cleaner image of the polysilicon layer.
Having two chips helps. I overlaid them and made the top one semi transparent. Stuff is usually clear on one or the other, at least it was clear enough to read the 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
leenew
Posts: 4230
Joined: Wed Jul 04, 2012 4:27 pm
Location: Doncaster, Yorkshire
Contact:

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

Post by leenew » Tue Aug 25, 2020 9:40 pm

I am mightily impressed by all of this so far.
It reminds me of a man I once saw on TV who could look at an LP record and identify it by the grooves :o

Lee.

User avatar
Diminished
Posts: 523
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished » Wed Aug 26, 2020 1:19 am

BeebMaster wrote:
Sun Aug 23, 2020 12:35 pm
Has anyone spotted any differences between the 8271 and the 8271-6? Only difference according to the datasheet is the operating temperature range, so maybe it only comes about at the testing/certification stage after manufacture. I think there was a -8 once upon a time as well, haven't seen one of those.
I haven't seen any differences.

I spent a bit longer staring at the chip tonight but I didn't make any progress. Based on the size of the output transistors, I'm fairly sure the external data bus D0:D7 is in the bottom right corner of the die. You can also make some pretty accurate inferences about which other pads are inputs and which are outputs based on the sizes of the transistors around the pads. I did try to trace what might be A0 and A1 in the top right corner, but I'm finding it next to impossible to follow signals accurately through weirdly-shaped FETs with all the muck on the photographs.

It's a real shame we don't know for sure to which pins the bond wires were attached. I wish we could take another 8271 and X-ray it.

User avatar
Pernod
Posts: 2234
Joined: Fri Jun 08, 2012 11:01 pm
Location: Croydon, UK
Contact:

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

Post by Pernod » Wed Aug 26, 2020 2:15 am

Diminished wrote:
Wed Aug 26, 2020 1:19 am
but I'm finding it next to impossible to follow signals accurately through weirdly-shaped FETs with all the muck on the photographs.
Weren't the latest sulphuric images much clearer?
Diminished wrote:
Wed Aug 26, 2020 1:19 am
It's a real shame we don't know for sure to which pins the bond wires were attached. I wish we could take another 8271 and X-ray it.
The pads have to be in the same order as the pins so isn't it clear from the topless image?

I can forward any questions to Sean if anything needs clarifying.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

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

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

Post by Rich Talbot-Watkins » Wed Aug 26, 2020 11:41 am

Chris (scarybeasts) did a bunch of tests with an 8271 a few months back, and came up with some interesting findings, which I'm going to share here on his behalf! Hopefully he can add anything I've forgotten.

First of all, the special registers.

Directly after reset, uninitialized:
8271reset.jpg
After being initialized by DFS:
8271init.jpg
As we can see, registers &00...&1F look to be distinct and presumably reference 32 bytes of internal RAM or a register file. Addresses &20...&3F are only partially decoded, hence the repeats. We know that registers &22/&23 are drive control input/output ports, so maybe this range of register addresses is directly mapped to I/O pins somehow. The question of what could be in the other registers in this range is intriguing!

Chris mentioned that parameters to 8271 commands seem to end up in register 0 onwards. We also know that command &35 ("specify"), which takes 4 parameters, just writes three consecutive special registers from the address in the first parameter. So we have the following (incomplete) list of special registers:

Code: Select all

00  (Undocumented: Command parameter 0?)
01  (Undocumented: Command parameter 1?)
02  (Undocumented: Command parameter 2?)
03  (Undocumented: Command parameter 3?)
04  (Undocumented: Command parameter 4?)
05
06  Scan sector number
07
08
09
0A  (Undocumented: after a read command, appears to contain the last sector ID seen, regardless of whether or not it was read)
0B
0C
0D  Step rate
0E  Head settling time
0F  Index count / head load time
10  Surface 0 bad track 1
11  Surface 0 bad track 2
12  Surface 0 current track
13  Scan LSB of count
14  Scan MSB of count
15  (Undocumented: Possible mirror of result register?)
16
17  Mode register
18  Surface 1 bad track 1
19  Surface 1 bad track 2
1A  Surface 1 current track
1B  (Undocumented: Possible mirror of result register?)
1C
1D  (Undocumented: Mirror of data register?)
1E
1F

20
21
22  Drive control input port
23  Drive control output port
24
25
26
27
Another interesting question is what all the undocumented commands do, and how does the 8271 'know' how many parameters to expect? Here's a tabulated list of all the commands: in binary, in hex, parameter count and description:

Code: Select all

0000 00   &00   5   Scan data
0001 00   &04   5   Scan deleted data

0010 10   &0A   2   Write data (128 byte)
0010 11   &0B   3   Write data
0011 10   &0E   2   Write deleted data (128 byte)
0011 11   &0F   3   Write deleted data

0100 10   &12   2   Read data (128 byte)
0100 11   &13   3   Read data
0101 10   &16   2   Read deleted data (128 byte)
0101 11   &17   3   Read deleted data

0110 11   &1B   3   Read ID
0111 10   &1E   2   Verify data

1000 11   &23   5   Format track

1010 01   &29   1   Seek

1011 00   &2C   0   Read drive status

1100 00   &30   0   (Undocumented: unknown)
1100 01   &31   1   (Undocumented: unknown)
1100 10   &32   2   (Undocumented: unknown)
1100 11   &33   3   (Undocumented: unknown)

1101 00   &34   -   (Undocumented: takes an infinite number of parameters)
1101 01   &35   4   Specify
1101 10   &36   5   (Undocumented: specify, discard last parameter)
1101 11   &37   6   (Undocumented: specify, discard last two parameters)

1110 10   &3A   2   Write special register

1111 00   &3C   0   (Undocumented: read [i]a[/i] special register, not sure which)
1111 01   &3D   1   Read special register
1111 10   &3E   2   (Undocumented: read special register, discard last parameter)
The parameter count is often encoded by the last two binary bits, and in many cases, 'missing' commands where just the last two bits change correspond to the same operation but requiring fewer or extra parameters. I think this was true of the special register commands and the various read/write commands. Scan and format, on the other hand, seem to be hardcoded. There was something funny about 'specify' with different bits 0 and 1, and I don't remember the details any more - the parameter count doesn't obviously correspond to the command bits, but there was some correlation.

Anyway I hope collating as much information about the known behaviour of the chip as possible can help a bit with the reverse engineering effort. It's always easier to make sense of things when you know what you're expecting!

And fantastic job so far with the ROM decoding =D>

Coeus
Posts: 1837
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

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

Post by Coeus » Wed Aug 26, 2020 11:51 am

Diminished wrote:
Wed Aug 26, 2020 1:19 am
It's a real shame we don't know for sure to which pins the bond wires were attached. I wish we could take another 8271 and X-ray it.
I think the clue is that the pads are not evenly spread around the outside - there is an area without any pads. Looking at the picture of the chip topless:
topless1.jpg
I believe this is the area I have marked in blue. Then looking at the picture of the metal layer:
8271-6metal.jpg
I believe the area I have again highlighted in blue is the same one. Then, going back to the topless picture, but looking at a little more of it:
8271topless.jpg
Again I have highlighted the same area, though it is hard to see, but this is the same orientation as the first picture and the notch is on the right.

Coeus
Posts: 1837
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

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

Post by Coeus » Wed Aug 26, 2020 12:02 pm

So working from that, in the this picture:
8271-6metal2.jpg
The red pan should be pin 8 and the yellow pad pin 9. Does that line up with deductions from transistor sizes if we then assume the numbering increments anti-clockwise, i.e. none of the bond wires cross.

Coeus
Posts: 1837
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

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

Post by Coeus » Wed Aug 26, 2020 12:23 pm

So following that round we get this:
8271-6metal3.jpg
Do we believe that or might it be off by one?
I got pin 8 by assuming there is a connection here, marked in red:
topless2.jpg

dp11
Posts: 1199
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

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

Post by dp11 » Wed Aug 26, 2020 12:28 pm

As I have said before the pad below vcc is a pin that doesn't come out of the package. So you are off by one. GND is also a give away being on the right of the die images.

Coeus
Posts: 1837
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

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

Post by Coeus » Wed Aug 26, 2020 1:31 pm

dp11 wrote:
Wed Aug 26, 2020 12:28 pm
As I have said before the pad below vcc is a pin that doesn't come out of the package. So you are off by one. GND is also a give away being on the right of the die images.
Ok, so this should be correct, then:
Attachments
8271-labelled.jpg

Coeus
Posts: 1837
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

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

Post by Coeus » Wed Aug 26, 2020 2:01 pm

Rich Talbot-Watkins wrote:
Wed Aug 26, 2020 11:41 am
...Scan and format, on the other hand, seem to be hardcoded. There was something funny about 'specify' with different bits 0 and 1, and I don't remember the details any more - the parameter count doesn't obviously correspond to the command bits, but there was some correlation....
Or is it "read drive status" that is odd rather than scan? That would mean all those command who number of parameters is not encoded in the bottom two bits have the top bit set.

guesser
Posts: 485
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser » Wed Aug 26, 2020 2:04 pm

Yep this was pretty much what I concluded.
I got a bit lost around the top left corner, but the inputs and outputs seem to line up, and data bus all have big drivers.
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.

dp11
Posts: 1199
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

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

Post by dp11 » Wed Aug 26, 2020 2:06 pm

Coeus wrote:
Wed Aug 26, 2020 1:31 pm
Ok, so this should be correct, then:
Looks good to me.

guesser
Posts: 485
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser » Wed Aug 26, 2020 2:07 pm

Rich Talbot-Watkins wrote:
Wed Aug 26, 2020 11:41 am
Anyway I hope collating as much information about the known behaviour of the chip as possible can help a bit with the reverse engineering effort. It's always easier to make sense of things when you know what you're expecting!
It's very helpful, I was going to ask if anyone had a summary of the commans etc as the datasheet is annoying to read :)

Armed with that lot I shall have another puzzle over the small ROM today.
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: 1662
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

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

Post by Rich Talbot-Watkins » Wed Aug 26, 2020 2:47 pm

Coeus wrote:
Wed Aug 26, 2020 2:01 pm
Or is it "read drive status" that is odd rather than scan? That would mean all those command who number of parameters is not encoded in the bottom two bits have the top bit set.
I can't make that work, because scan doesn't have the top bit set but expects 5 parameters, and the special register commands do have the top bit set, but respond predictably to different bottom bits (as far as I remember).

Fairly sure that there were variants of 'specify' which took different numbers of parameters (and wrote different numbers of special registers accordingly!), but here the relationship is not as straightforward as "bottom two bits = number of parameters". I also think there was a command in this area which required infinite parameters! I wonder if scarybeasts Chris remembers?

guesser wrote:
Wed Aug 26, 2020 2:07 pm
It's very helpful, I was going to ask if anyone had a summary of the commans etc as the datasheet is annoying to read :)

Armed with that lot I shall have another puzzle over the small ROM today.
Great! I'll try to keep that post updated as we learn new things about the special registers or command numbers.

Just by observation, it seems reasonable to postulate that either register &15 or &1B (or both) are a mirror of the result register. Chris also wrote on his blog that &1D appeared to mirror the data register. So there are a few more gaps we can probably fill in as we do more tests!

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

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

Post by Rich Talbot-Watkins » Wed Aug 26, 2020 3:44 pm

I found an old conversation between Chris and me on the subject of undocumented commands. Here's what he discovered.

Read special register variants:
&3D (%111101) is the normal "read special register" command, taking 1 parameter.
&3E (%111110) is "read special register", taking 2 parameters, and discarding the second.
&3C (%111100) is "read special register", taking 0 parameters. Not sure which register it reads.

Unknown block of commands:
&30 (%110000) takes 0 parameters. Returned something, and something different to &2C (drive status).
&31 (%110001) takes 1 parameter...
&32 (%110010) takes 2 parameters...
&33 (%110011) takes 3 parameters...

Specify variants:
&35 (%110101) is normal "specify", taking 4 params.
&34 (%110100) takes an infinite number of parameters! It never stops asking for more.
&36 (%110110) is 'specify', taking 5 params, and discarding the last.
&37 (%110111) is 'specify', taking 6 (!) params, and discarding the last two.

There's a compelling correlation between the last two bits and the number of expected parameters, but 'specify', 'format' and 'scan' do something a bit different. Not sure if Chris ever tried variants on format (scan is harder to test I guess).

User avatar
Diminished
Posts: 523
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished » Wed Aug 26, 2020 3:53 pm

I had a go at vectorising the entirety of the metal layer VCC and GND connections. This was not fun but it should make things a lot easier.

Here are the results at 25%.

https://drive.google.com/file/d/1773TmX ... sp=sharing

I'll add the pad naming and get a new set of proper GIMP vectors and layers uploaded later. Errors and omissions are more than likely, so let me know if you spot anything I missed.

Coeus
Posts: 1837
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

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

Post by Coeus » Wed Aug 26, 2020 4:31 pm

Rich Talbot-Watkins wrote:
Wed Aug 26, 2020 3:44 pm
There's a compelling correlation between the last two bits and the number of expected parameters, but 'specify', 'format' and 'scan' do something a bit different. Not sure if Chris ever tried variants on format (scan is harder to test I guess).
Looking at the data sheet I wonder if there is a generic way to test, i.e. not relying on it obviously starting to do something when the final parameter is received. In the description of the status register, the data sheet says of "Command Reg Full": "The command full bit is set on writing to the command buffer and cleared when the FDC begins processing the command"

I wonder what they mean by processing. Do they mean collecting the parameters? Or starting to execute the command. Might it be worth testing if this bit does tell us whether the FDC is expecting more parameters or has had enough?

User avatar
scarybeasts
Posts: 560
Joined: Tue Feb 06, 2018 7:44 am
Contact:

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

Post by scarybeasts » Wed Aug 26, 2020 5:05 pm

Coeus wrote:
Wed Aug 26, 2020 4:31 pm
Looking at the data sheet I wonder if there is a generic way to test, i.e. not relying on it obviously starting to do something when the final parameter is received. In the description of the status register, the data sheet says of "Command Reg Full": "The command full bit is set on writing to the command buffer and cleared when the FDC begins processing the command"

I wonder what they mean by processing. Do they mean collecting the parameters? Or starting to execute the command. Might it be worth testing if this bit does tell us whether the FDC is expecting more parameters or has had enough?
From the discbeast 8271 driver:

.intel_do_cmd
ORA var_zp_drive_bits
STA &FE80
.intel_do_cmd_loop
LDA &FE80
AND #&40
BNE intel_do_cmd_loop
RTS

.intel_do_param
STA &FE81
.intel_do_param_loop
LDA &FE80
AND #&20
BNE intel_do_param_loop
RTS


Looks like you write the command, wait for bit value &40 to go low, then proceed with the parameters. I seem to remember you get problems if you don't wait for these command / parameter status bits to be ready.


Cheers
Chris

User avatar
scarybeasts
Posts: 560
Joined: Tue Feb 06, 2018 7:44 am
Contact:

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

Post by scarybeasts » Wed Aug 26, 2020 5:21 pm

Rich Talbot-Watkins wrote:
Wed Aug 26, 2020 11:41 am
Hopefully he can add anything I've forgotten.
I checked my old, rough notes and here are a few extra things that might be interesting / useful:

1) Specify fun:
SPECIFY, command &35, appears to be the same as three WRITE SPECIAL REGISTER calls, where the three register numbers are sequential and start from the first parameter. The other three parameters are the register values to write.
SPEC 0 0 0 0 hangs whereas writing registers 0, 1, 2 to 0 individually does not. Neither does SPEC 0 1 1 1 hang. This suggests some form of internal register corruption during the command?

--> One guess here is that one of the memory values is used as an iterator count for writing the three special registers. But writing special registers is writing memory and trashing the iterator count?


2) Another usage of a special register:
&0A [undocumented]: after a read command, appears to contain the last sector ID seen, regardless of whether or not it was read

--> Could be used as the basis of a sneaky 8271 copy protection scheme.


3) Undocumented reads of external addresses &FE82 / &FE83
&12 [documented]: scan MSB of count. Appears to be generally maintained during sector operations and can also be read at &FE82.
&13 [documented]: scan LSB of count. Appears to be generally maintained during sector operations and can also be read at &FE83.


Cheers
Chris

guesser
Posts: 485
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser » Wed Aug 26, 2020 5:31 pm

Diminished wrote:
Sat Aug 22, 2020 9:46 pm
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. [-X
GIMP really feels like the wrong tool for the job, and my PC (i7, 16 gigs of RAM) is really struggling anyway...

I've taken the liberty of converting your paths into an svg file in inkscape, and set it up to use linked images of the die shots which are 25% scaled and indexed pngs. I think they're an acceptable trade off of size against readability.
The resolution of the svg is set to the original size of the 8271-6metal.jpg.

I've aligned 8271sulfuric1.jpg with the 8271-6 images too as I find having a "second opinion" on the silicon useful.

The files are here: https://temp.zxnet.co.uk/8271/
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: 485
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser » Wed Aug 26, 2020 5:32 pm

Diminished wrote:
Wed Aug 26, 2020 3:53 pm
I had a go at vectorising the entirety of the metal layer VCC and GND connections. This was not fun but it should make things a lot easier.

Here are the results at 25%.

https://drive.google.com/file/d/1773TmX ... sp=sharing

I'll add the pad naming and get a new set of proper GIMP vectors and layers uploaded later. Errors and omissions are more than likely, so let me know if you spot anything I missed.
Oh balls! :D

Still could have been worse, I could have vectorised all the vcc and gnd metal myself :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.

guesser
Posts: 485
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

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

Post by guesser » Wed Aug 26, 2020 5:34 pm

Are you on the stardot Discord diminished?
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: 523
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished » Wed Aug 26, 2020 6:03 pm

guesser wrote:
Wed Aug 26, 2020 5:34 pm
Are you on the stardot Discord diminished?
I'm afraid not. (Discord stores and sells every single thing you say. I don't have a Facebook or Twitter account either. I'm not a fan of the modern corporate Internet.)

Here are my latest GIMP files. As before, there aren't any actual 8271 snaps included.

100%:
https://drive.google.com/file/d/1G6qDJp ... sp=sharing

50%:
https://drive.google.com/file/d/1BCXOjm ... sp=sharing

25%:
https://drive.google.com/file/d/1cxJNFV ... sp=sharing

One word of warning about the VCC and GND paths: I did the GND one the "wrong way round", so either clockwise instead of anticlockwise, or anticlockwise instead of clockwise, whichever it is. When I came to fill it, it filled everything except the GND line. I couldn't find a way to reverse the path in GIMP so I had to create a selection from the path and then invert the selection in order to get it to fill correctly.

It's just two paths so it shouldn't be too difficult to export them to something else.

User avatar
BigEd
Posts: 3454
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Wed Aug 26, 2020 6:07 pm

Diminished wrote:
Wed Aug 26, 2020 3:53 pm
I had a go at vectorising the entirety of the metal layer VCC and GND connections.
Splendid!
Errors and omissions are more than likely, so let me know if you spot anything I missed.
Spotted some omissions!

That thick rail with 4 big contact cuts is connected by a very wide crossunder on the right to the red rail. It also wiggles left and down to connect to some single gate, between the yellow and orange bus wires.

The thick rail that's 3 rails north, with 13 medium contacts is connected directly to the blue rail on the right by a vertical connection, and also goes off to the left and then south, to become a rail above one of the regular structures.
Attachments
Screenshot 2020-08-26 at 18.02.16.png

User avatar
BigEd
Posts: 3454
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Wed Aug 26, 2020 6:09 pm

BTW zoomable image files on a google drive link are great for me: I can pan and zoom even on my under-powered laptops. No need to download.

User avatar
Diminished
Posts: 523
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished » Wed Aug 26, 2020 6:10 pm

BigEd wrote:
Wed Aug 26, 2020 6:07 pm
The thick rail that's 3 rails north, with 13 medium contacts is connected directly to the blue rail on the right by a vertical connection, and also goes off to the left and then south, to become a rail above one of the regular structures.
Ah, that's irritating. Thanks. I'll tackle that now. Keep em coming if you spot any others.

Here's a 25% image with the pads labelled (orange = output, purple = input, black = I/O).

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

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

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

Post by Rich Talbot-Watkins » Wed Aug 26, 2020 6:11 pm

scarybeasts wrote:
Wed Aug 26, 2020 5:21 pm
1) Specify fun:
SPECIFY, command &35, appears to be the same as three WRITE SPECIAL REGISTER calls, where the three register numbers are sequential and start from the first parameter. The other three parameters are the register values to write.
SPEC 0 0 0 0 hangs whereas writing registers 0, 1, 2 to 0 individually does not. Neither does SPEC 0 1 1 1 hang. This suggests some form of internal register corruption during the command?
If we go with the theory that command parameters get stuffed in registers 0 onwards, and we suppose that commands are implemented in ROM and executed by an as-yet unknown microcontroller, this is the sort of logic which would lead to the former hanging, but the latter not:

Code: Select all

end = reg[0] + 3;
param = 1;
do
{
    dest = reg[0];
    reg[0]++;
    reg[dest] = reg[param];
    param++;
}
while (reg[0] != end);
Clutching at straws, because it's an odd way to write it (you'd expect that just maintaining a counter would work better). Maybe something equally weird could happen if that counter were in register 0!

User avatar
BigEd
Posts: 3454
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Wed Aug 26, 2020 6:16 pm

Diminished wrote:
Wed Aug 26, 2020 6:10 pm
Keep em coming if you spot any others.
The thick vertical rail to the right of a regular structure has a diagonal crossunder to the red tail.

(In general, any thick tracks with large contact cuts are probably rails. Just possibly clocks.)
Attachments
Screenshot 2020-08-26 at 18.15.00.png
Screenshot 2020-08-26 at 18.15.00.png (374.59 KiB) Viewed 634 times

User avatar
Diminished
Posts: 523
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

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

Post by Diminished » Wed Aug 26, 2020 6:27 pm

BigEd wrote:
Wed Aug 26, 2020 6:07 pm
That thick rail with 4 big contact cuts is connected by a very wide crossunder on the right to the red rail. It also wiggles left and down to connect to some single gate, between the yellow and orange bus wires.
I think you mean this one? That will have been left out because I was only concerning myself with the metal.
missed_vcc_rail.jpg
missed_vcc_rail.jpg (41.56 KiB) Viewed 628 times
Do we want that one included? If I include all the polysilicon and silicon then we could be here all week. :lol:

Also I might end up with RSI.

Post Reply

Return to “8-bit acorn hardware”