8 Apr
2015
8 Apr
'15
9:34 p.m.
On 4/8/2015 9:05 PM, John Wilson wrote:
On Wed, Apr 08, 2015 at 08:55:31PM -0700, Don North
wrote:
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.
Don
(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