RL02-USB Controller Status/Problem

[Don North]

On 4/7/2015 1:11 PM, Johnny Billquist wrote:
> On 2015-04-07 22:06, Don North wrote:
>> On 4/7/2015 12:25 PM, Johnny Billquist wrote:
>>> On 2015-04-07 20:54, Pete Turnbull wrote:
>>>> On 07/04/2015 19:26, Johnny Billquist wrote:
>>>>>> Well, yes, it's still bad, and still there, but all the RT-11
>>>>>> utilities
>>>>>> use the substitute block.
>>>>>
>>>>> So COPY/DEV is essentially only usable for opying RT-11 disks on RT-11
>>>>> systems. :-)
>>>>> Nothing wrong with that, mind you.
>>>>
>>>> Well, no, actually; I've been using it (under RT-11 V5.7) to copy other
>>>> OS disks (mainly 7th Edition Unix) because it does that perfectly well
>>>> :-)  When the DL.SYS driver sees a disk changed, it reads the
>>>> manufacturing defect list so it's still good to copy most disks.
>>>
>>> But since the 7th edition Unix most likely do not treat the bad blocks
>>> the same way as RT-11 does (skipping bad blocks), that means blocks
>>> will get renumbered, and 7th edition will end up with a very corrupt
>>> and broken file system.
>>> Essentially, this will only work well if you don't have any bad blocks
>>> on the device.
>>>
>>> Just because you have a manufacturer bad block list on the disk, that
>>> does not mean that different OSes handle the disk the same way.
>>>
>>> Let me give you a very silly example.
>>> Let's say we have a file system where each disk block points to the
>>> next disk block in a file, and that the OS address each disk block in
>>> an absolute manner. Bad blocks do not affect the block numbering.
>>>
>>> Let's then say that we have the following 5 blocks:
>>>
>>> Block #        Content
>>> n:        n+1
>>> n+1:        n+3
>>> n+2:        <bad block>
>>> n+3:        n+4
>>> n+4:        0 (EOF)
>>>
>>> Now, if RT treats this as skipping over the bad blocks, it would skip
>>> n+2, while n+3 would on the target device become n+2. However, block
>>> n+1 still points to n+3, so now we skip over one block of the file.
>>> Which means we corrupted the disk.
>>>
>>> I could create a whole bunch of similar scenarios, but I'm sure you
>>> can too. :-)
>>>
>>>     Johnny
>>>
>>
>> I don't see any way that bad blocks can just be skipped over in the
>> numbering system. This would mean you had no reasonable way of doing
>> random block access to the RL0x device without some type of lookup table.
>>
>> RL0x does head/cylinder/sector addressing, so a direct block address
>> could be decomposed into a specific H/C/S by a simple set of equations.
>> If you throw skipping arbitrary bad sectors in the mix this no longer
>> works.
>>
>> So I see that replacement of bad sectors inline (using the '144 mapping
>> table and data) as the only reasonable approach.
>>
>> My opinion of course.
>
> I just posted an answer to Paul explaining how OS/8 does exactly this: skip 
> over bad blocks. It's actually not hard at all, and less costly than a lookup 
> table.
> But anyway, this is all theoretical. Unix do not have any such schemes. It 
> essentially do the same things we've been talking about. When you find a bad 
> block, you actually create a file containing that block, so that nothing else 
> will accidentally use it later.
> So it's not hidden or remapped in any way.
>
>     Johnny

I would think that there should be two operating modes:

(1) Physical mode, real all sectors as is. Return error on reads of bad sectors. 
Host software will have to deal with the error. Reread and /or parse the DEC STD 
144 table itself to resolve the error.

(2) Logical mode. Your USB interface reads/parses the DEC STD 144 bad block 
table and does the appropriate revectoring of known bad blocks. On the host side 
you end up presenting what amounts to an RL02K-EF drive image.

Some users will want (1), most users will probably want to use (2) (ie, with SIMH).