Pete Turnbull wrote:
On Jul 1,
13:42, Megan wrote:
Somewhere I have a set of the sources for the RQDX1/2 boards. They
were designed to recognize certain disks from certain vendors. The
code does not make much attempt to truly determine geometry, it
uses hard-wired values, which is why only certain ones work.
I have no doubt that when the RQDX3 was done it was implemented in
the same way... that only certain disks from certain vendors would
be recognized. To have it recognize another disk, you would have
to add an entry to the disk characteristics table in the source
for the firmware and blast a new set of ROMs.
Actually, you wouldn't,
that's one of the big differences between the
RQDX1/2 and RQDX3. The 1/2 perform various tricks to try to work out what
disk is connected, especially when formatting. The tricks vary between
versions of the firmware, so I have a 10MB Rodime disk which one RQDX2
version will "recognise" and format but other versions won't. Several
years ago, I had an interesting email conversation with Chuck O'Toole who
wrote the sniffer code (and most of the MSCP, geometry, and access code)
for the RQDX1, which is part of the DUP utilities in the firmware. It was
intended to autosize certain known drive types that DEC would/might sell,
to differentiate between them, and it was known that the succesor
(eventually, the RQDX3) would be along later, so there was no great
incentive to make it fully general.
Jerome Fine replies:
A long time ago in a galaxy far, far away, I took two Micropolis 1325
Hard drives (one also had a bit of sticky material with the letters "RD53")
plus two MFM controllers, an RQDX2 and an Emulex DM01. I also
managed to locate the micronote about the Micropolis 1325 in respect
of the jumper "R7".
To make a very long story a bit shorter, while both drives worked perfectly
with the Emulex DM01 before I added the "R7" jumper to the drive without
that bit of sticky material and only one drive worked with the RQDX2, after
I added the "R7" jumper, that drive also worked with the RQDX2.
This story is no longer very helpful since almost all RD53 and plain vanilla
Micropolis 1325 drives no longer function in a reliable manner - I think
someone suggested that they could be relied upon to be used as a scratch
drive if you could write on them in the first place and then kept the power
on. However, can anyone enlighten us as to how DEC managed to use
"R7" on a Micropolis 1325 so as to tell the RQDX2 that an RD53 was
present if "R7" was jumpered?
However, the RQDX3 doesn't depend on the tricks.
The formatter doesn't
rely on DUP utilities built into the RQDX firmware but uses tables in the
formatter software (XXDP ZRQC??.BIN). It only uses the DUP utilities to
perform the actual track formatting. There's an option to force it to use
a table entry of your choice (including entries for common drives like
ST-251 and ST225) and even an option to bypass the tables and enter all the
necessary values by hand, though it takes a bit of effort to work out what
they all should be for any given drive. Tim Shoppa posted some information
to the list in 1997 about the makeup of the various numbers, and I have
some more in some manuals which I might be persuaded to dig out if anyone
is really enthusiastic. It would still take a bit of exprimentation and
guesswork, though.
DEC's patent describes the basic ideas and the TLAs:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p…
Pete Peter Turnbull
Network Manager
University of York
Thank you for the patent number and the URL to look at it!!!
Based on the granting data (February 28th, 1984), it would seem that
it is now in the public domain and that the MSCP "invention" can now
be used by anyone. Is this true or does HP now control the MSCP
patent?
It is my understanding that a number of individuals were considering
a Qbus MSCP controller for IDE drives. Is there anyone on the list
who is still actively considering this option?
At one time, I understand that one other option for this Qbus controller
for IDE drives would have been to use the HD.SYS hard disk interface
defined in the Ersatz-11 emulator. If anyone ever does that, I will complete
the demo version I produced of the HDX.SYS device driver that handles
a 256 MByte "device" as HD0: => HD7: in RT-11. In theory, there
is no reason why the code should not be extended to allow drives up
to 65536 RT-11 partitions or 2 TerraBytes of hard drive capacity.
That same extension could also be done for DU(X).SYS in RT-11
although it should be recognized that the same basic limitation of
64 active RT-11 partitions would still apply unless some eager
beaver (again probably myself) used the ability to tie multiple
device drivers together (which has already been done - hopefully
I could obtain the code) and extended those device drivers.
However, due to lack of commercial interest in such a project, there
is little probability it will be done. Hobby users rarely use large
data bases and I don't know of any commercial applications that
have a requirement greater than 2 GBytes of storage - which is
already 64 RT-11 partitions.
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.