RL02-USB Controller Status/Problem

Paul Koning paulkoning at comcast.net
Tue Apr 7 10:25:03 CDT 2015

> On Apr 7, 2015, at 8:41 AM, Pete Turnbull <pete at dunnington.plus.com> wrote:
> On 06/04/2015 23:54, Christopher Parish wrote:
>> Progress is good on the RL02-USB controller. I've gotten complete
>> operation working as expected with the usual tools for disk access
>> (badblocks, dd, etc.), and SIMH can access the real packs via the
>> controller's block device (i.e. attach rl0 /dev/sdX).
> Very good!  I want one :-)
>> The issue is most obvious when backing up and restoring disk images.
>> Suppose I backup a pack with 1 bad sector. I have two choices of what
>> to do with the bad sector (specifically if it's a bad header), I
>> could skip the sector (reporting an IO error), or I could report all
>> zeros for the sector.
> > The usual trick of having the controller re-map the bad sectors will
> > not work because the platters in the RL02 are removable.
> DEC does it by having the driver software remap sectors.

No, DEC does not do that.  At least not in RSX, as Johnny described, nor in RSTS.

In RSTS, creating a file system on a pack is done with the “dskint” utility.  One of its functions is to perform a drive scan, writing and verifying all sectors with several data patterns.  If a sector is found to be bad, it is handled simply by allocating it to the reserved file [0,1]badb.sys.  This scheme works for all drive types, including those that predate DEC Std 144.  On packs that have a bad block table, the blocks listed in that table are includes in the bad block list that dskint determines (I don’t remember if they are checked anyway, or bypassed in the check).

I also don’t remember if there was a way to handle blocks going bad later.  In principle, yes; they could be allocated to badb.sys also.  If so, a file system check (“onlcln”) would find a double allocated block and let you delete the file that was affected.

The first drive type I know of that had anything resembling remapping is the RM80, with the “skip sector” feature, where each track had an extra sector, and a flag in the sector header could be used to mark that sector as “skip me and use the spare sector instead”.  The first real remapping appeared in MSCP, which makes sense because that is the first time that DEC drives used logical addressing instead of hard cylinder/track/head addressing.  At first (UDA50), remapping was done largely in the driver, requiring a quantity of code way larger than any other disk driver.  In subsequent MSCP controllers, it moved entirely into the controller and the host simply saw an error free logical block space.

Given all this, an image copy of a disk is not valid, unless the destination disk is error free.  (Early packs usually were, which is why early PDP11 backup programs like ROLLIN did use image copy.)  If the destination disk has errors, the copying has to be at the file system level, either by just copying all files one by one, or by doing an image copy that works around destination flaws.  The RSTS standalone backup program SAVRES is an example of the latter.


More information about the cctalk mailing list