brew-your-own-unibus boards?

Jerome Fine replies: I would also like one! I thought I would respond to both posts at the same time! As probably those of you who are interested in RT-11 know, I am interested in the software end. If anyone should manage to produce a Qbus version which allows an IDE drive of more than 8 GBytes (sort of hard NOT to have these days), then RT-11 will need modifications to the MSCP (DU.SYS) device driver to accommodate that size of drive. I have been thinking about how to accomplish that for the past 10 years, in actual fact, so it would not be a technical difficulty as far as I can see. And as well, probably most other MSCP device drivers will also need to be modified. For RT-11, the basic hooks are already there, just that DEC mangled them during implementation. In RT-11, there is a 2 word entry for each mapping entry for each physical RT-11 partition: word 1 => Physical Unit Number from 0 to 255 byte 3 => Physical Partition Number from 0 to 255 byte 4 => Controller (or Host Adapter) Number from 0 to 3 Probably the most straight forward way would be to swap the Physical Unit Number word and the Physical Partition Number byte. That way the RT-11 Physical Partition Number can have a range from 0 to 65535 and the Physical Unit Number can retain its range from 0 to 255. I will not address the problem of keeping track of 65536 RT-11 partitions on a 2 TerraByte hard drive. If it was suggested that more than 256 Physical Unit Numbers should also be allowed, there are ample bits left to be used from the 6 left over from the Controller Number. If an additional field of 2 bits is used to allow two more format definitions for a total of 4 format definitions, then 4 more bits could be allocated to the Physical Unit Numbers for a total of 12 bits would would allow for unit numbers to range from 0 to 4095. The code changes needed would be in the DU(X).SYS device drivers and RESORC.SAV which displays the table for the user of the mapping entries. Neither should be a big problem. Indeed, I would probably shift the code from RESORC.SAV to the device driver in the form of a command: SET DU SHOW and have RESORC.SAV check the device driver for that capability during the: SHOW DEVICE:DU command execution, then exit RESORC.SAV with that request to RT-11 to perform the needed command. In fact, in my opinion, that is how RT-11 should be able to support the display of the mapping entries, i.e. have all the code within the device driver. That would also allow the mapping entries to be displayed for MSCP device drives which could not be installed because they did not have the correct attributes for that version of the RT-11 operating system that was being used. There are already DECUS programs which allow that. 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.