On 10/17/18 1:53 PM, Don Stalkowski via cctalk wrote: Try set cpu 256K set rx disable set ry enable show ry RY??? address=17777170-17777173, vector=264, BR5, 2 units ? RY0??? 512KB, not attached, write enabled ??? double density ? RY1??? 512KB, not attached, write enabled ??? double density 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 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

On Wed Oct 17 19:19:20 2018 cctalk at classiccmp.org (Jerry Weiss via cctalk) wrote: 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. Don

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