Jerome Fine replies: I am replying to Johnny's response, but I had also read the other replies as well. Thank you all for your help. The first point is that using a PEEK/POKE SYSTEM (EMT? - RT-11 has such a call) is so high in overhead that it becomes almost useless. In fact, the key point about the use of the EMEM.DLL under RT-11 is the efficiency. While it is possible to access normal "emulated PDP-11" memory (using E11 on a 750 MHz Pentium III) in about 0.3 micro-seconds, it takes about 1.2 micro-seconds to reference an IOPAGE address in some sort of way - including the PSW or the EMEM.DLL values or about 4 times as long. Since this is a huge improvement over using a PEEK/POKE, it is even worth giving up 8192 bytes of address space to a dedicated APR (of the IOPAGE) for that purpose. On the other hand, with RT-11, it is possible and easy to set the PREVIOUS DATA space in the PSW to KERNEL even when VBGEXE is used - more to the point, it is actually unnecessary since that is the default for a so-called privileged job (which all programs are by default). This allows the instruction: Mov @#BaseReg,R0 ;Get the current value from PC memory to be replaced by: MTPD @#BaseReg ;Get the current value Mov (SP)+,R0 ; from PC memory with almost the same time for execution. It also avoids losing that 8192 bytes for APR7 being available just for the IOPAGE registers. Obviously, a SYSTEM request avoids all of the problems at a heavy cost in overhead estimated at between 50 and 500 times the above two examples. That was sort of what I was thinking about when I asked if there was an "fast method (only a few instructions)" to access an IOPAGE register. By the way, a first version of a set of FORTRAN IV/77 interface subroutines are available for use under RT-11 and any other program that has access to IOPAGE registers either in CURRENT DATA space or PREVIOUS DATA space. This seems to be the answer if it is allowed. Obviously it does require giving up that 8192 bytes the have APR7 mapped to user space. There is also another option with E11 that I will make use of when I have finished with the HD(X).SYS device driver for RT-11. It turns out that if the memory is being accessed sequentially, the average time to reference a single 16 bit value in the file under: MOUNT HD: FOOBAR.DSK is actually less than the time to get/store a single value under EMEM.DLL when as few as 8 blocks (2048 words at a time) are being referenced. Consequently, setting up a small 4096 byte buffer and the associated code to handle to calls to the HD: device driver (all standard calls to .ReadF and .WritF in RT-11) is actually more efficient since after the values are in the buffer inside the program, the values can be referenced and modified at "emulated PDP-11" memory speeds. Of course, the above solution for sequential references does not work when the references are random or when references are at regular but very large intervals (thousands and even millions of successive values). For this latter situation, it may be possible to modify EMEM.DLL so that a single reference to the IOPAGE register modifies all of the specified values (over a range of up to many billions of values). Of course, the result would no longer really be a PDP-11 except for the controlling code which would still be 99% of the required code since the EMEM.DLL changes are really quite trivial, yet consume 99% of the time to execute. In case anyone does not appreciate what I refer to, it is back to my other addiction - sieving for prime numbers. I realize that I should probably switch to native Pentium code, but is seems more of a challenge and much more fun to run as if a PDP-11 is being used with a few GB of memory somewhere out there that can be easily fiddled with as if there is a very fast additional CPU similar to those that used to be available for special math applications - anyone remember SKYMNK for FFTs? Sincerely yours, Jerome Fine