RL02-USB Controller Status/Problem

[Johnny Billquist]

On 2015-04-07 21:58, Paul Koning wrote:
>
>> On Apr 7, 2015, at 3:25 PM, Johnny Billquist <bqt at update.uu.se> 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.
>
> Not necessarily.  I don’t know the RT11 details, but suppose it works this way: a few blocks at the end are spares.  All good blocks have their native address.  All bad blocks are redirected to one of the spares.
>
> If so, some other file system, one that avoids the bad blocks, will work fine.  All good blocks are where expected.  The bad blocks aren’t, but those aren’t in use.  The only trouble would be if the spare region is actually used for data.  If it’s free, then you’re basically ok.

Heh! Yeah, well, I guess you could get lucky if someone did that scheme. 
But then you would also need to mainain a map of replacement blocks 
somewhere, and all accesses would have to lookup that table before doing 
any access to a block, which would be rather costly...

MSCP essentially does this, but it has special provisions for it, to 
make it more effective. In essence, you normally do not lookup into that 
table for a block access. Instead you do the lookup only if a read/write 
actually fails, or if the bad block bit is set in the sector header, 
marking that this block actually have a replacement.
And in that case, you might also not need to go through the lookup 
table, if in fact you did manage to get data out of the block, as the 
block contents will also have the replacement block information written 
there.

So, while your scenario is totally possible, it is unlikely to have been 
implemented.

I don't know exactly how RT-11 do it, but in OS/8 it is pretty simple. 
You have a block # you want to read, and a sorted bad block list. You 
run through the list, and for every entry, if your block # if greater 
than the bad block #, you increment your block # by one. It is rather 
costly, but on a PDP-8, you don't really care. All code runs without 
interrupts, and the badblock list is limited to what can fit in a table 
inside the device driver. And PDP-8s have such a simple system that this 
extra overhead isn't hurting much. (In essence, OS/8 code don't care 
about cycles, they care about words used.)
And on average, I would guess you only need to search half the list.

	Johnny