26 Nov
2015
26 Nov
'15
9:22 a.m.
On Nov 26, 2015, at 6:29 AM, Jerome H. Fine <jhfinedp3k at compsys.to> wrote:
This a nice summary of the state of affairs for DEC/RT-11 8 inches Floppies.
I have a idle RXV31 controller and a DSDD 8 inch floppy drive on the list of
devices to restore. Need to scramble up a 24 V supply. The Dilog DQ419
looks to be identical to the Sigma controller, including 22 bit support.
In my collection of handlers, I don?t see any with extra code to support 22 bits.
Thinking back, I?m not sure why I never noticed this before.
We had DSD 440, 480?s and both 880?s, Sigma Information Systems or
whatever was cheapest when we ordered it. We used floppies
as long term storage and often from INMAC. So media quality and
consistency was not high on our list. We collect quite a lot of
patched and tweaked handlers along the way.
The Sigma SDC RXV31 controller supported 22 bit
DMA. See 400255-C SDC-RXV31 Floppy Ctrl Man Aug86
I saw that model at one point. It was the only one I ever saw, so I
did not bother to include 22-bit support in the DYX.SYS device
handler - mostly because I would not have been able to test the code. I used both, but double sided compatibility
between the two products was
occasionally spotty. Never did determine if it was a controller, floppy drive or media
issue.
Both the DSD 880/8 and the DSD 880/30 supported double-sided
media for the RX03 floppy drive. A check of the DSD 880/30 manual
from 1981 includes directions to modify the DYX.SYS device driver
to support double sided operation with V04.00 of RT-11. Inspection
of the file, DY.MAC from V04.00 of RT-11, confirms that DEC had
code which supported double-sided media and even the CSR specs
in the DEC RXV21 controller specifies, as far as I can remember, a
bit to determine if the RX03 floppy drive has detected a double-sided
floppy in the drive. Note that the DEC RX02 floppy drive did not have
that electronics or hardware to detect double-sided media. It is possible
that DEC did produce an in-house RX03 drive, but I am not aware of
DEC actually selling RX03 drives to customers. PLUS, the code in the
file, DY.MAC from V04.00 of RT-11, has bugs (at least in the distribution
copy released with V04.00 of RT-11) which would prevent the correct
operation of a double-sided media. One other point of interest is that
by 1983 when DEC released V05.00 of RT-11, the extra code with
support for double-sided media had been removed from DY.MAC.
It probably should be mentioned that a different
position is used for
the index hole for double-sided media (about 1/2" more to the right)
as opposed to the location of the index hole for single-sided media.
The DSD 880/30 RX03 floppy drive has TWO detection circuits
in the two possible positions to determine which media was present
in the drive. Because every floppy media that I ever saw has been
coated on both sides and could support double-sided operation
even if the index hole was in the single-sided location within the
cardboard jacket, I experimented with adding the index holes
required for double-sided operation and covered up the single-sided
index holes. After that worked successfully, I became disappointed
that I had to deface the floppy media with the extra holes. The
simple solution was to use a DPDT switch and flip the detection
circuits so that the RX03 drive would signal a double-sided media
what there was a single-sided index hole and the DPDT switch was
in the alternate position. To add to the success of that extra switch,
the DSD 880/30 supported an off-line LLF (Low Level Format)
which, of course, no DEC controller ever supported for 8" floppy
media.
I found the LLF was the most frustrating feature of the DSD 880 line.
I never could trust a floppy so treated. Some of the other non-DEC
controllers also had the feature. Given that we were sourcing media
from sources that just stamped their brand on the
floppy, I never got a
handle on how to use the feature consistently.
In answer to the question of support for double-sided media, there
are two methods of using both sides of the floppy. One method
is to read all of one side, then read all of the other side of the floppy
media. The second method is to read both sides of the media for
each cylinder, then increment to the next cylinder. Based on the
code for DY.MAC which was present in V04.00 of RT-11, DEC
choose the former method. It seems possible that if you were using
floppy media written via one method and read by the opposite
method, there would obviously be some confusion. The SMS-1000
(I hope I have remembered the part number correctly) includes
an 8" RX03 type of drive which can handle both single-sided and
double-sided media - although the built-in controller is MSCP based
and both the internal hard drive and the single RX03 floppy drive are
considered DU: or MSCP devices under RT-11. When single-sided
floppy media are used, there is no difficulty. However, if an 8" media
that is double-sided is inserted and files are written to that floppy,
the results can'r be read on the DSD 880/30 using a modified DYX.SYS
device driver which supports double-sided operation since it is quite
obvious that the MSCP controller in the SMS-1000 wrote both sides
of the floppy before changing cylinders. This might have been the
cause of the problem between the two floppy drives. I agree it is
doubtful, but I can't think of anything else.
in our case, 99% of floppies were read on the same drive that wrote them, so it
generally wasn?t a problem. When we moved code and data between
systems, we stuck to RX02 formats to avoid all the compatibility
hassles. Didn?t have any SMS-1000 in our shop, but we often collaborated
with other researchers who had them and the same rule applied.
FINALLY, due to the 18-bit address restriction with
all DYX.SYS
device drivers under RT-11, I added code to support a bounce buffer
that allows the user buffer to be in a 22-bit location, but still be able
to support DMA to the silo on the controller. The bounce buffer must
be in the first 256 KB of memory, but the device driver performs
the extra transfer one word at a time between the bounce buffer and
the user buffer if the latter is above the 256 KB boundary.
We depended on the TSX+ feature to do the bounce automatically
for the 18 bit controllers for the RK,DY, DL or DM. We never threw out
anything working. On faster drives there was obviously a performance hit,
dependent on the processor speed. For the RX02?/3?s I?m sure I measured
it at one point, but on an 11/73 it never seemed to be perceptible on a
daily basis. Our systems did data acquisition and floppies
were used only apr?s experiment.