RL02-USB Controller Status/Problem
north at alum.mit.edu
Wed Apr 8 23:34:30 CDT 2015
On 4/8/2015 9:05 PM, John Wilson wrote:
> On Wed, Apr 08, 2015 at 08:55:31PM -0700, Don North wrote:
>> (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.
> DEC std 144 just lists the bad blocks, it doesn't revector them. The RT-11
> (only!!!) DL: driver does revectoring based on its own private table in block
> 1 (so hilarity ensues if the disk you're reading isn't an RT-11 disk). But
> that's important only because RT uses contiguous files -- all the other
> OSes know how to avoid bad blocks cleanly so they don't need to live in
> an error-free utopia.
> I'd think the way to handle dumb host software is to log bad blocks somewhere
> but return all zeros (or real data if that's possible), so at least programs
> won't crap out part way through a copy. But then you have to make sure you
> read the error log before you assume it worked.
> I'd love to hear the results of running this device with E11. E11 does
> pass error status through but other than with floppies, I don't get a lot
> of chances to test those code paths. A while back I added a layer which
> inserts fake bad blocks on purpose, just for testing a wad of PDP-11
> disk drivers I was writing.
> John Wilson
> D Bit
You are 100% correct ... I had it in my mind that '144 not only listed the bad
sectors, but also provided a re-vector to a good replacement sector. My wishful
thinking, I guess. But this is 100% wrong. I stand corrected and suitably red-faced.
More information about the cctech