RT-11 DY install

[Jerome H. Fine]

The long delay in making a response is because I rarely check 
classiccmp.  Please accept
my apology.  If anyone asks a question, I will probably not see the 
question until the end
of November, 2018.

 >Pete Turnbull via cctalk wrote:

> On 18/10/2018 13:22, Don Stalkowski via cctalk wrote:
>
>> On Wed Oct 17 19:19:20 2018 cctalk at classiccmp.org (Jerry Weiss via
>> cctalk) wrote:
>
>>> Note: Apparently the RY emulation won't load if more than 256K
>>> memory is specified as the DEC hardware did not support DMA in a
>>> 22bit box. I'm=20 entirely not sure why SIMH has to
>>> enforce this as its possible to work around (e.g. TSX+ supports
>>> buffering the IO). Anyone know how to override and load in
>>> SIMH?
>>>
>>> Jerry
>>
>> Thanks Jerry. That's "fixed" it. Since simh didn't complain about my
>> "set ry enabled" I assumed (wrongly) that that wasn't the issue.
>>
>> Thanks to all the other's who replied.
>
> As Noel pointed out, real PDP-11s definitely work with RX02 subsystems 
> in 22-bit systems. SIMH really ought to be able to do so regardless of 
> 18-bit or 22-bit memory.  The DY driver in RT-11, for example, simply 
> knows to only use the bottom 256K for DMA I/O.

As a long time RT-11 user, I often found it useful to enhance the 
software which DEC produced.
Since I found that the Unibus PDP-11 hardware was almost always much 
more difficult to
obtain in addition to being MUCH too heavy and much too large as 
compared with Qbus
PDP-11 hardware, I focused all of my software enhancements which were 
hardware
specific on the Qbus side of the fence.  So what I have written in this 
reply is only for
Qbus PDP-11 systems.  As a consequence, a Unibus  focused enhancement which
supports 22 bit memory availability still needs to be produced.

ALSO, I use SIMH so rarely that I never ran across the problem of using 
more that 256K
on a Qbus (emulated of course) system with the RX02 device.  Whenever I 
used the
RX02 device on an emulated Qbus PDP-11 system (almost always with a full 
4 Meg
of emulated memory), I used the E11 emulation from Dbit by John Wilson.  
In addition,
whenever I used the RX02 on a real DEC PDP-11 Qbus system, 4 Meg of memory
was almost always available.

It is ALSO essential to distinguish between an UnMapped RT-11 monitor 
such as
RT11FB and a Mapped RT-11 monitor such as RT11XM.  With RT11FB, the name
of the device driver is DY.SYS and ONLY 64 K bytes of memory are 
available for
standard use which means that all I/O on the RX02 is performed with the 
lower
64K of memory at all times.  With RT11XM and a 22-bit Qbus PDP-11 with 4 Meg
of memory (both real hardware or emulated under E11), the name of the device
driver is DYX.SYS and, as stated above, the code in DYX.SYS knows that any
I/O transfer between the floppy media and memory can use ONLY the lower
256K of memory.  As a very minor addition to what is stated above as why 
only
the lower 256K is used, that is because the DEC Qbus RX02 hardware 
controller
is restricted to memory addresses which are in the lower 256K (as 
opposed to other
DEC hardware controllers which have the hardware to address all 4 Meg of 
Qbus
memory) OR a 3rd party RX02 Qbus controller (there is at least one - 
unfortunately
I no longer remember the name of the manufacturer) which also supports 
22 bit
memory addresses for a 4 Meg Qbus system.

HOWEVER, that does not mean that the DYX.SYS device driver is unable to
accept I/O requests between the floppy media and user buffers which reside
in physical memory above 256K.  It does mean that the DEC version of DYX.SYS
can't perform the request since it does NOT have the additional code 
which is able
to accommodate a transfer to or from a user buffer above 256K.  It is 
also possible
to add the additional code to the DYX.SYS device driver which can accomplish
an I/O transfer to or from the floppy media using memory above 256K if 
DYX.SYS
has a bounce buffer which is in the lower 256K.  In the past, I have 
mentioned that
I have such a version of DYX.SYS which I wrote more than a decade ago, so I
know from practical experience exactly what is required.  The version I 
wrote is
a memory hog of the 64K memory since I never made the additional effort to
use extended memory (such as DUX.SYS and SLX.SYS).  I seem to remember
that the enhancements to DYX.SYS were made before I made enhancements to
both DUX.SYS and SLX.SYS, so I did not know enough at that time what was
possible.  In addition, I also had not modified the code which supported 
requests
from device drivers and system jobs for extended memory from the top of the
available buffer - which means that the lower 256K could have been allocated
before DYX.SYS could make its request.  I now have a program, AXHIGH.SAV,
which does that.  AXLOW.SAV supports requests from device drivers for memory
from the bottom of the available buffer and AXSHOW.SAV displays the current
setting.

In summary, if SIMH will not function with an RX02 Qbus emulated system when
there is more than 256K of emulated memory, I strongly recommend that the
situation be fixed since that is NOT how a real Qbus PDP-11 functions.

In short, the reason the DEC version of the RX02 DYX.SYS device driver is
unable to access a user buffer address above 256K is because DEC decided
to not update both the hardware in the controller and the software in 
the DYX.SYS
device driver.  Since the RX02 is a very old 8" floppy media, the 
decision was
probably reasonable from a cost benefit point of view.  Since other 
operating systems,
(such as TSX-Plus and I suspect RSX-11) do support access to user 
buffers in memory
locations above 256K and it was not very difficult to add the extra code 
to DYX.SYS
to do so (although it did take a bit more effort to support the 
PDP-11/23 CPU in addition
the the PDP-11/73), it probably would have been reasonable for DEC to 
add the
additional; code by 1992 when V05.06 of RT-11 was released.

If anyone still has any questions, please ask.  If anyone needs a 
DYX.SYS device
driver which supports user buffers in Qbus memory above 256K, please 
contact me.

Jerome Fine