RL02-USB Controller Status/Problem
north at alum.mit.edu
Wed Apr 8 22:55:31 CDT 2015
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
>>>>>> 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. :-)
>> 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
>> 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
> 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.
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).
More information about the cctalk