> On Jan 22, 2016, at 10:29 AM, Will Senn <will.s...@gmail.com> wrote:
>
> ...
> OK. I figured some of this out...
>
> In RT-11v5.3 if I have the following ini section for a disk:
> set rl1 writeenabled
> attach rl1 storage.dsk
>
> And I say no initially to the prompt:
> Overwrite last track? [N]N
>
> When I try to initialize the disk in RT-11, I get an error:
> .initialize dl1:
> DL1:/Initialize; Are you sure? Y
> ?DUP-F-Bad block in system area DL1:
>
> But, if I answer Y:
> Overwrite last track? [N]Y
>
> All is good in the world. I get no errors initializing and I no longer get
> prompted at startup:
> .initialize dl1:
> DL1:/Initialize; Are you sure? Y
>
> .dir vol:
>
> 0 Files, 0 Blocks
> 10172 Free blocks
That all makes sense. Since you were initialing an RL01 or RL02, the system
expects a DEC Std 144 bad block table. In the first try, it wasn't there.
What may have happened is that initialize used what it found and mistook it for
valid, and ended up believing it was told that block 0 is bad. That would
certainly make initialize unhappy.
> This being the case, it appears that set badblock does not appear to be
> required. For the sake of discussion, if there is a case when it is required,
> is it a one-shot deal where the command is run in simh and then left out of
> the ini file after the bad block is created?
The bad block table lives on the disk, i.e., in the disk image file. Unless
it's overwritten, or you recreate the file, it will persist. So yes, it is a
one-shot deal.
paul
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
