9 Dec
2018
9 Dec
'18
1:58 p.m.
On Sun, Dec 9, 2018 at 5:47 AM Tony Duell <ard.p850ug1 at gmail.com> wrote:
On Sun, Dec 9, 2018 at 6:50 AM Josh Dersch via cctalk
<cctalk at classiccmp.org> wrote:
Thanks -- that's kind of what I'd gathered from looking at the schematics
and reading the service docs, but I wasn't 100% sure.
If anyone has any insights into the inner
workings of the RK8E (in
particular the CRC circuit, since it's used to compare the on-disk
cylinder
address stored in the header with the cylinder
selected by the RK8E's
address register) please let me know.
I think you can ignore the actual CRC logic here. Just treat the CRC
register as a shift register. It is shifted in-sync with the data coming
off
the disk, in this case the header word that contains the cylinder address.
Look at page 25 of the RK8-E engineering drawings (Oct72) on bitsavers.
It's sheet D04 (Major Registers PCB).
The header word bits (from the disk) are compared with the contents of the
the shift register one bit at a time by E24c. The output of that goes to
E34b
(D input). E34b starts off clear, and remains clear while the bits agree.
If
there is a difference in the bits (cylinder address is not right) then
E34b sets. The Q/ output goes low, pulling the S/ input (pin 10) low. This
forces E34b to remain set (The S/ and R/ direct inputs will override the
D input). So after all the bits have been compared, E34b is set if there
was
an error.
Thanks. So I'm trying to figure out what components in this path could
cause the behavior I'm seeing. To reiterate my original mail:
"On cylinder 128 and 192 and very infrequently on cylinder 64 it will get a
cylinder mismatch when doing the seek. When running the formatter during
the verification pass, on cyls 64 and 128 if I retry the read it'll
continue without issues, but it's never successful on a retry on cylinder
192."
Clearly something with the two MSBs of the cylinder address is amiss. I
had made a guess that the 7496 at E14 might be at fault (some weird
crosstalk between various bits on the SETx signals perhaps) since this
takes in EXT CYL ADDRS and BDATA0 (the top two bits of the cylinder address
when loading the Disk Address Register via an IOT 67x3. I replaced it to
no effect.
It seems clear to me that the shift registers themselves are operating OK
-- otherwise I'd be seeing CRC errors fairly frequently when reading
sectors off the disk, and I'm not.
It seems that the DEC380 bus ICs (E13, E22, etc) for the BDATAx signals
that eventually get fed into the CRC shift registers must be OK or else the
actual data on the disk would end up randomly corrupted, and that's not
happening.
I'm looking for something that could only fail when only bits 6 and/or 7
(or 0 and 1 in DEC parlance) of the cylinder address are set, but I'm not
seeing anything.
Anyway, further debugging is in my future... thanks again for the input.
Thanks,
Josh
-tony