>Ethan Dicks wrote:
> > On Mon, Jan 19, 2004 at 10:26:32PM -0500, Christian Fandt wrote:
> > >And, if I did manage to create a realiable IDE interface, would anyone
> > >else want one?
> > Yes!
> And me!
Jerome Fine replies:
I would also like one!
> 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.
I thought I would respond to both posts at the same time!
>Andreas Holz wrote:
>please have a look at that:
>http://www.chd.dyndns.org/qbus_ide/
>But that is not really preferable solution. We have to replace the
>MFM-discs with a black-box!
>We had a thread how to replace MFM-discs at the end of last year. We
>should continue this thread!
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.
Received on Tue Jan 20 2004 - 09:59:23 GMT