11 Feb
2019
11 Feb
'19
8:04 a.m.
From: Fritz Mueller
If, as you are suspecting, we find damning evidence
pointing
specifically to the RK11
I got an update from Fritz. As you all will recall, the problem seemed to be
a corrupted 'pure text'. So the question was 'when was it damaged, and
how'.
After some confusion caused by different OS images (the 'Ritchie' and
'Wellsch' distros), he managed to get a look at the text in main memory after
it was first read in from the file system, and before it was swapped out (it
was showing up damaged after a swap out/in cycle); it looked good at that
point. The copy written out to the swap disk however, not so good.
A look at the RK11 registers after the swap-out showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.
We also need to characterize exactly what the fault is, because the DEC RK11
diagnostics weren't finding it, so it seems the diagnostic suite could use an
enhancement....
Noel
11 Feb
11 Feb
11:12 a.m.
On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
A look at the RK11 registers after the swap-out showed
an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.
OH, BOY! I think you may have found it. Likely some disk
controllers did NOT SUPPORT crossing 64K boundaries! The
diags would not detect that, as it was likely expected
behavior. I would suspect the driver would need to break up
these operations.
Jon
12:34 p.m.
On Mon, Feb 11, 2019 at 4:13 PM Jon Elson via cctalk
<cctalk at classiccmp.org> wrote:
On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
I _think_ the RK11-C should cross a 64K boundary correctly. There's
an output from the low 16 bits bus address module (M795) on pin BP2
'D15 RKBA=ALL 1 L' (page 27 of the schematic on Bitsavers) that
goes to the counter that holds the 2 extended bits, pin C1 of the M239
in slot A17 (page 13 of the same .pdf)
[I am working from 'RK11-C_schemFeb1971.pdf' from bitsavers]
Of course if there is a fault in this area then it will not correctly increment
the top 2 bits, but that might give you somewhere to check.
-tony
A look at the RK11 registers after the swap-out
showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.
OH, BOY! I think you may have found it. Likely some disk
controllers did NOT SUPPORT crossing 64K boundaries! The
diags would not detect that, as it was likely expected
behavior. I would suspect the driver would need to break up
these operations. 
12:50 p.m.
On Feb 11, 2019, at 11:12 AM, Jon Elson via cctalk
<cctalk at classiccmp.org> wrote:
On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
You may be thinking about PC controllers like the floppy controller. I can't remember
ANY DEC DMA device controller that had boundary crossing limits of any kind. It certainly
isn't a restriction in the RK11.
paul
A look at the RK11 registers after the swap-out
showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.
OH, BOY! I think you may have found it. Likely some disk controllers did NOT
SUPPORT crossing 64K boundaries! The diags would not detect that, as it was likely
expected behavior. I would suspect the driver would need to break up these operations.
1:13 p.m.
On 2/11/19 11:50 AM, Paul Koning via cctalk wrote:
Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K
boundaries.
I did however via a single chip "dead bug" modification, modify one to
accomplish this.
??? Jerry
On Feb 11,
2019, at 11:12 AM, Jon Elson via cctalk <cctalk at classiccmp.org> wrote:
On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
You may be thinking about PC controllers like the floppy controller. I can't
remember ANY DEC DMA device controller that had boundary crossing limits of any kind. It
certainly isn't a restriction in the RK11.
paul
A look at the RK11 registers after the swap-out
showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.
OH, BOY! I think you may have found it. Likely some disk controllers did NOT
SUPPORT crossing 64K boundaries! The diags would not detect that, as it was likely
expected behavior. I would suspect the driver would need to break up these operations.
1:29 p.m.
On Feb 11, 2019, at 1:13 PM, Jerry Weiss <jsw at
ieee.org> wrote:
On 2/11/19 11:50 AM, Paul Koning via cctalk wrote:
Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K
boundaries.
I did however via a single chip "dead bug" modification, modify one to
accomplish this.
Jerry
That's rather shocking. I meant my comment to apply to every DMA controller, not just
disks. I never used the DR11-B, though. Perhaps there are other obscure devices that get
this wrong. But, for example, even devices like DMC-11 and TS-11 got it right.
There are of course Q-bus devices that only do a partial address space, but my point is
that whatever the number of address bits implemented, address arithmetic is as a matter of
normal design done across all of them, not across a subset.
paul
...
You may be thinking about PC controllers like the floppy controller. I can't
remember ANY DEC DMA device controller that had boundary crossing limits of any kind. It
certainly isn't a restriction in the RK11.
paul
1969
days inactive
1969
days old
5 comments
5 participants
participants (5)
-
ard.p850ug1＠gmail.com -
elson＠pico-systems.com -
jnc＠mercury.lcs.mit.edu -
jsw＠ieee.org -
paulkoning＠comcast.net