[Simh] Overwrite last track and set badblocks

[Paul Koning]

> On Jan 21, 2016, at 10:48 AM, Mark Pizzolato <Mark at infocomm.com> wrote:
> 
> Hi Will,
> 
> On Thursday, January 21, 2016 at 7:01 AM, Will Senn wrote:
>> A quick couple of questions...
>> 
>> 1. Why does SimH prompt to overwrite the last track on some images every
>> time it runs, even if I let it, it will ask on the next run.
>> 
>> 2. What is a use case for setting bad blocks and is it a one shot deal or does it
>> need to stay in the .ini?
> 
> DEC shipped disk devices which were formatted at the factory.  Almost all
> disk media had a very small percentage of the media which didn't perfectly 
> store data.  Certain modern, disk devices (MSCP) had spare sectors built into 
> the internal format information on the drives and they presented a full disk 
> of clean blocks to the system.  Older disks shipped with factory with a defect
> table written in the last track of the device.  

This is sometimes referred to as the "DEC Std 144" format.  That's a DEC internal standard that describes the format of the table in question.  It applies to many but not all pre-MSCP drives.  Some drives (RK05, RP03) predate this standard; these would normally be shipped from the factory as flaw free packs.  Judging by some tables in the RSTS disk formatting code, RK06/07 and RL01/02 have DEC Std 144 tables; RP07, RM02/03/05 also (but not RP04/5/6).

I saw this message recently, and it repeated itself when I told it no.  When I said yes, the next time the message did not appear.  It might be that you get it repeatedly if your host OS overwrites the table.  DEC OSs should not do so. 

	paul