> On Jan 21, 2016, at 10:48 AM, Mark Pizzolato <[email protected]> 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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
