RL02-USB Controller Status/Problem
bqt at update.uu.se
Tue Apr 7 15:08:09 CDT 2015
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
So, while your scenario is totally possible, it is unlikely to have been
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.
More information about the cctalk