flash (or ide) storage for unibus 11?

Jerry Weiss jsw at ieee.org
Thu Nov 26 11:22:43 CST 2015


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.   

> 
>> 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 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.

> 
>> 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.
> 

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.

> 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.



More information about the cctalk mailing list