> > Actually, the RD disk shouldn't use BAD144 but another way of bad block
> > forwarding; the same as RA disks use. In that case a RD disk from a
> > MV2000 can be put directly into a MVII with RQDX3, otherwise it won't
> > work if there are bad blocks on it.
>    I'm assuming that by "RA disks" you have really meant MSCP, right? (It's
> very unfortunate that in all VAX Unices that I have seen MSCP disks are
> called ra...) But I have thought that MSCP disks use bad144, don't they?

No, they generally don't.  bad144 traditionally is used on "last-track"
devices, such as Massbus disks.  To quote from the 2.11BSD man pages:

     The bad sector information is located in the first 5 even
     numbered sectors of the last track of the disk pack.  There
     are five identical copies of the information, described by
     the dkbad structure.  Only the first of these copies is
     used.
     ...
     The bad sector structure is as follows:

     struct dkbad {
            long    bt_csn;             /* cartridge serial number */
            u_short bt_mbz;             /* unused; should be 0 */
            u_short bt_flag;            /* -1 => alignment cartridge */
            struct bt_bad {
                    u_short bt_cyl;     /* cylinder number of bad sector */
                    u_short bt_trksec;  /* track and sector number */
            } bt_bad[MAXBAD];
     };

     Unused slots in the bt_bad array are filled with all bits
     set, a putatively illegal value.  MAXBAD (in <sys/dkbad.h>)
     may be tuned locally to reduce the space required to hold
     the bad-sector file in memory.  It may not be greater than
     126, which uses the whole disk sector.  Bad sectors past
     MAXBAD may be included by the formatter, but replacement
     sectors will not be used until MAXBAD is increased.

Note that it would be possible to use bad144 on a MFM hard disk connectes
to a VS2K, but you have to create the bad sector information in the
correct format first.  Then support would have to be added to the
driver to support bad144-style bad block forwarding.

The formatting routine in the VS2K does write
bad block information, but in MSCP format rather than last-track.
The MSCP approach to bad block forwarding is much more complicated,
but also much more versatile, than the simple "bad144" style.  If
a block begins going flaky on a MSCP disk, the controller (with
possible help from the OS) reads the block off while it still can,
marks it as bad, and replaces it with a "spare" block.  There are
also out-of-band codes for "good block with bad data", in the case
where a block went bad and the OS/controller wasn't able to salvage
the data before replacement.

> And who does the bad block forwarding in this case anyway? Is it the
> intelligent MSCP controller or the OS?

It depends on how intelligent the MSCP controller is.  Some controllers
such as the UDA50 require assistance from the OS's device driver to actually
replace a block.  Most Q-bus controllers (in particular, the RQDX3)
do bad block replacement
automatically without any assistance from the OS.

NetBSD lacks the ability to help UDA50 controllers do
bad block replacement, just as it is lacking the ability to have
the VS2K MFM driver do the replacement.

It's rather easy to tell whether a controller does bad-block replacement
on its own or not: look at the sign bit of the word that is returned
as "controller flags" when you issue the SET CONTROLLER CHARACTERISTICS
command to a MSCP controller.  If the sign bit is set, the controller
does bad block replacment on its own without any help from the OS.
If the sign bit is clear, the controller needs help.

Currently, this information is thrown away by NetBSD's MSCP driver,
which doesn't matter much as the driver is incapable of initiating
bad block replacement by itself.  The process is actually quite complicated,
because it is done in an arcane series of steps to insure that a power
failure in the middle of a step won't wipe data from the disk.  The
process is outlined in the UDA50 Programmer's Kit.

For an example of how to issue the MSCP SET CONTROLLER CHARACTERICSTICS and
interpret much of the information that comes back, look at the RT-11
program DUSTAT.MAC which I posted to vmsnet.pdp-11 today.

Tim. (shoppa@triumf.ca)