On 12/08/2011
03:04, Dave Caroline wrote:
I just searched for RQDX1 seems there were 4
versions
http://manx.archivist.info/search.php?search=rqdx1&errlev=0&company…
371121
Digital Equipment Corporation
RQDX1-EP
2B
RQDX1
EP
DEC INTEGRATED RQDX1-E W/INTERNAL CABLE
H
RQDX1-E
371122
Digital Equipment Corporation
RQDX1-E
2B
RQDX1
E
ADD-ON DISK ADAPTOR FOR RD52,RD51,RX50 (M7512 + BC
H
RQDX1
The last two aren't RQDX1 controllers, they're the RQDX1E extender
(M7512), which is a passive card that breaks out signals in order to
use drives in a BA23 expansion box. Similar to an RQDXE, but
specifically designed for RQDX1.
There were three versions of the RQDX1 board. The original, RQDX1
M8369, got a firmware update that made it an M8639-YA, to handle more
drive types. The only difference is the firmware, and there were a
few versions of that. Then there's an M8639-YB, which is called RQDX2,
and which has some ECOs to remove some of the restrictions on bus
position (it handles BIAK and BDMG). The RQDX2 firmware versions use
slightly different error codes on the LEDs and handle at least one of
the drive interface signals differently. Different firmware again
(more drive types) but you can mix and match the firmware between
boards, including putting RQDX2 firmware in RQDX1 to get more drive
support (that was officially supported by DEC).
However there are some restrictions. Later firmware changed the
structure of the RCT/FCT tables that keep drive config info, and which
are written to the drive. If you take a drive formatted on an early
version, and put it on a later version, the controller should in most
cases cope. Unfortunately going the other way doesn't work in every
case, because the later firmwares write slightly larger tables to the
drive, and then early firmware doesn't understand it. One of the
"RQDX1/2 Survival Tips" on STARS listed the first 6 versions of
firmware, and mentions that some firmware will rewrite the tables if
you move a drive from old to new. So a drive that used to work on one
controller gets moved, still works, but then won't work if moved back.
If you have a look at my ROMlist page
http://www.dunnington.u-net.com/public/DECROMs/ROMlist
you'll find some very brief notes.
23-188E5 23-189E5 M8639-YB RQDX2, issue 2
RD51,RD52,RD53,RX50 support
Firmware V10.0E
23-178E5 23-179E5 M8639-YB RQDX2, issue 1
RD51,RD52,RD53,RX50 support
Firmware V10.0D
23-172E5 23-173E5 M8639-YA RQDX1, issue 3
RD51,RD52,RX50 support
Firmware V9.4E
23-042E5 23-043E5 M8639-YA RQDX1, issue 2
RD51,RD52,RX50 support
Firmware V9.0
23-264E4 23-265E4 M8639 RQDX1, issue 1a
RD51,RX50 support only
Firmware V8.0
23-238E4 23-239E4 M8639 listed as RQDX1 V7.0,
but apparently a misprint?
those numbers used for KDJ11-BE
The different versions of firmware also use different sniffer boots to
try to work out what drive is attached. Pain in the proverbial, that
was. I have drives that will work and format on one version but not
another (later versions are more picky about what they'll recognise as
an RD51, for example).
I spent quite a while around 1990 playing with firmware and different
(non-DEC) drives (HDD and floppy), and I have several versions in my
ROM list page. I even exchanged some email with one of the firmware
designers, but I can't remember the details -- just that the sniffer
boots got more complex as time went on.
As an aside, while digging through old notes and archives to check
what I wrote, I found Note 93 on EISNER from 1988 that describes how
to jumper two RD5x drives in a BA23. Note 526 as well. Two RD31/RD32
was actually a supported config.
To perhaps clarify the situation a bit (and maybe also add to the
confusion, I have additional information. I found a third M8639 YA
controller which acts somewhat differently. I list all three boards:
(a) Has three additional serial numbers and / or stickers on the non-
components side which might lead me to believe that this board
has been upgraded (field or otherwise)
(b) A visual inspection suggests that boards (b) ...
(c) and (c) are the same
HOWEVER:
(a) An RD51 drive formatted on this board can't be used by (b) or (c)
(b) An RD51 drive formatted on this board can't be used by (a), BUT
runs on (c)
(c) An RD51 drive formatted on this board can't be used by (a) or (b)
In addition, I formatted an RD52 drive on (c) which I will not try to format
again on (a) or (b) AND which does not run on (a) or (b). That was expected
in any case since the RD51 formatted on (c) will not run on (a) or (b).
In short, without the ability to read the EPROMs and figure out which
version, the likely conclusion, based on the testing and the above
information,
is that:
(a) Issue 1a
(b) Issue 2
(c) Issue 3
The key point in all of the testing and the information very kindly supplied
by Pete Turnbull is that it is not possible to depend on being able to use
an M8639 YA with an RD51 drive formatted on a different M8639 YA.
If it does run, great. BUT, before you test the drive, WRITE PROTECT
the drive so that it can't be damaged. BETTER, make a backup of the
drive and VERIFY the contents against the backup BEFORE you make
any changes.
As for using two RD5n drives on a BA23 box, there is my own version of
a short 10-pin cable that I inserted in the 10-pin cable which leads to a
4 button front panel on a BA23 box. The DEC upgrade is the 6 button
front panel on the BA23 which specifically supports 2 RD5n drives along
with 2 floppy drives (although the LEDs for WRITE PROTECT status
on the floppy media are no longer present).
My version of the 10-pin cable to the front panel is inserted as a female
10-pin header into the backplane and the male 10-pin header receives
the 10-pin female header normally inserted into the backplane. This allows
the fix to be temporary and removed without damage to the original
wiring. The short 10-pin cable has wires 5 and 6 cut at the male header.
On the female side of the header, wire 5 is connected to wire 1 (red wire)
and wire 6 is connected to wire 2. This allows BOTH drives to be
handled in the same manner. Usually, both drives are SELECTED.
It is possible to WRITE PROTECT both drives from the non-protected
state (as far as I can remember - but there may be a delay of a read or
two before that happens). Going from WRITE PROTECT to non-protected
might require a boot - I can't remember at this point. Since I have ONE
6 button front panel, I no longer have to experiment.
Pete, it would be interesting if you could provide a copy of Notes 93
and 526
or at least a valid link to that information.
If there are any additional questions, please ask. If there is any
additional
information, it would be appreciated.
Jerome Fine