>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=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=pall&s1=''4,434,487''.WKU.&OS=PN/"4,434,487"&RS=PN/"4,434,487"
>
> 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.
Received on Mon Jul 01 2002 - 22:26:30 BST