Jerome Fine replies: I agree that MSCP would provide the best overall solution. There were 4 reasons I suggested the HD: interface from Ersatz-11: (a) The code to implement is much less complicated (b) My testing indicates twice the throughput due to so many fewer instructions required in the device driver. (c) For RT-11, the MSCP device driver is simple only up to devices of 8 GB. For larger devices, the code still needs to be modified. (d) My still incomplete HD(X).SYS test device driver under RT-11 is able to handle devices up to 2 TB and contains boot code as well (although ROM boot code would obviously be required with a real hardware Qbus controller which all 3rd party controllers had no difficulty including in the past - and which Ersatz-11 obviously includes as well). I agree that the throughput with other OSs than RT-11 will likely differ depending on the system overhead. For example, under RT-11, it is quite simple to bypass the device driver and use code right within the user application, including NOT using interrupts - the DOS version of Ersatz-11 does not have asynchronous I/O so interrupts are actually unnecessary in any case. It takes about 20 instructions even for a mapped monitor. It also doubles the I/O throughput. Which means that the RT-11 request using the device driver must just about equal all of the code within Ersatz-11 plus those extra few instructions in PDP-11 code. Every 3rd party controller that I ever used always included boot rom code for the device it handled - as opposed to DEC which I found never included device handler boot rom code on the controller. So I don't think it would be ugly at all, just a very small additional detail. For RT-11, the situation is essentially the same. As with all other OSs, the DEC boot ROM reads a ONE block boot program from block zero of the device that is being booted. The code for that ONE block boot program must be included in the device driver as a separate piece - and updated when the CSR (and VECTOR) are modified. RT-11 has a separate command: COPY/BOOT DU0:RT11XM.SYS DU0: to copy that separate ONE block boot program to block zero of the device so that the DEC hardware boot program in the boot ROM is able to then read block zero and start the boot operation. However, for the HD: device, the necessary code is probably about a dozen instructions - much less than for MSCP and very easy to enter in via hardware ODT by hand. In fact, it would probably be even easier to just set up the 6 hardware I/O registers and read in block zero that way since many of the values are zero (i.e. number of bytes, block zero, address zero, zero extended address, zero extended block number - then the CSR value with the GO bit set and the read request). Obviously using the DEC boot ROM is much easier, but not ugly for HD: as compared with the code needed for an MSCP boot. As I stated above, I agree. But the fellow who is implementing the MSCP interface for a Qbus to CF might not agree. However, since I do not have the information required to produce the Qbus to anything controller, I really can't comment. Certainly back in the 1980s when Qbus host adapters were more than $ US 1000 and it would have been easy to find someone to write the device drivers for an HD: interface, this might have been a very useful alternative to MSCP. In fact, considering how many Qbus host adapters that CMD sold, the advantages that I noted for an HD: interface might have forced DEC to offer it as well. But not today! Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.