RL02-USB Controller Status/Problem

[Don North]

Shouldn't the controller be using the DEC STD 144 bad sector replacement table 
in the last sector to transparently remap bad sectors such that, to the user, 
the -DC packs appear error free? If this were done each RL02 image should appear 
error-free in logical block address space as the hidden remapping of bad sectors 
on -DC drives would not be seen by the user (or O/S).

All the other proposed ways of handling -DC bad sectors have serious 
compatibility issues.

Don

On 4/6/2015 3:54 PM, 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). Of course, this is only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those with identified bad blocks from the factory) are another story.
>
>
> 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.
>
>
> Skipping the sector is a bad idea because the logical address of all sectors after it will shift down by one. This will make the disk image not work correctly with SIMH, or anything else for that matter, because most filesystems address things by physical block (Please correct me if I'm wrong here). Remember, we're at the device level (/dev/sda) not the partition level (/dev/sda1).
>
>
> Returning all zeros for bad sectors will preserve the block numbers of following sectors and work correctly with SIMH, but trying to restore the resulting image to another physical pack will probably be impossible given the destination disk pack has bad sectors of its own in different spots.
>
>
> The usual trick of having the controller re-map the bad sectors will not work because the platters in the RL02 are removable. Writing some mapping index on the disk pack or holding back sectors in reserve will break compatibility with the original systems (PDP8s/11s/VAXes) and all their software (an unacceptable solution).
>
>
> I think I've come to the following conclusions given the restrictions above:
>
>
> - Creating and Restoring images with EF packs is unrestricted
>
> - SIMH operation with EF packs (online and images) will work perfectly
>
> - Creating images of DC packs will work with SIMH if I return zeros for the bad blocks
>
> - Online use of DC packs work with SIMH assuming no new bad blocks have formed since the bad block index was written
>
> - If new bad blocks have formed in a pack, SIMH will have to be modified so its RL(V)11 can receive error information from the drive, otherwise it will incorrectly handle the recovery
>
> - Restoring images on DC packs will require special software that can move data around the bad-blocks (or a linux RT-11 filesystem driver *wink*)
>
> - Using a modern filesystem on EF/DC packs is unrestricted (because they can identify and manage bad blocks on their own)
>
>
> First, does all of this seem reasonable?
>
>
> I vaguely remember reading about a program on RT-11 you would run (before?) backing up the filesystem. What was this program? How did it work? Did it make the data position independent?
>
>
> Christopher
>