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.
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