On Mon, Jan 19, 2004 at 10:26:32PM -0500, Christian Fandt wrote: And me! I used to build Qbus and Unibus (and VAXBI!) boards at Software Results Corp. ISTR we spent >$100 per Qbus blank board because we never made orders larger than q. 100. They are large boards (by today's standards) and with that much gold, aren't cheap to make. Here's a suggestion: lay out the board with the bus drivers (and grants) for *both* Qbus _and_ Unibus, and only populate the variety you wish to make. At least that way, you'd have a chance to boost the quantity of boards made, and bring down the price a little. For me, at least, the hard part of designing a modern Qbus and/or Unibus interface would be what to select for bus drivers. I happen to have a small handful of real DEC Qbus chips (from my Q-BOARD days), and a large quantity of 8641 chips. It's choosing the other stuff that gets hard. It's not so bad in a small backplane, but if you use your Unibus boxes like we used to (11/750 w/internal DD11DK + BA-11 + 3 x DD11DK...), adhering to the spec becomes important. -ethan -- Ethan Dicks, A-130-S Current South Pole Weather at 20-Jan-2004 04:20 Z South Pole Station PSC 468 Box 400 Temp -13 F (-25.0 C) Windchill -48.7 F (-44.8 C) APO AP 96598 Wind 12.7 kts Grid 342 Barometer 687.8 mb (10333. ft) Ethan.Dicks(a)amanda.spole.gov http://penguincentral.com/penguincentral.html

A generic XBUS <-> Centronics/USB/Firewire interface attached to modern hardware running a device emulator would be even more useful. The device emulator would keep track of interface settings (device addresses, interrupt priority levels, etc.) and the actual devices, which could be real peripherals or files on your disk. Include three sets of bus drivers and the interface could be made to work on the (physically compatible) UNI-, Q- and OMNIBUS. Sincerely, Erik.

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.

I have two opinions on the Subject: It depends on whether functionality is the prime goal, or actual 'form, fit and layout' is to be maintained. If I was going to make Unibus (or any legacy bus) modules, I'd use a card-edge-to-Eurocard adapter, then make all my designs on the standard connector layout... the object being that one leaves the adapter in the buss connector and and just works with the Eurocard format module. Of course there are any number of interface connecting schemes that would fulfill this idea. On the Other Hand - if the goal was a 'real' Unibus module, then the actual legacy layout would be the order of the day... that being said - I am wondering if companies like Vector made blank and 'prototype' cards for the various Mimis, like they did for S100, and later, PC cards...? Cheers John