Bits:30009717

Fra DDHFwiki
Spring til navigation Spring til søgning

Download Link

Comet32_harddisk.BIN

Metadata

   BitStore.Metadata_version:
   	1.0
  
   BitStore.Access:
   	public
  
   BitStore.Filename:
   	Comet32_harddisk.BIN
  
   BitStore.Size:
   	60116480
  
   BitStore.Format:
   	BINARY
  
   BitStore.Ident:
   	30009717:1
  
   BitStore.Digest:
   	sha256:26887b7e050a8801faf86df7cb3915adb41852a8465a5ef4bbf57da364a38288
  
   BitStore.Last_edit:
   	20260202 phk
  
   DDHF.Keyword:
   	COMPANY/ICL/COMET/DISK
   	ARTIFACTS
  
   DDHF.Genstand:
   	Genstand:11000898
  
   DDHF.QR:
   	50005879
  
   Media.Summary:
   	Comet 32 harddisk image
  
   Media.Geometry:
   	117415s 512b
  
   Media.Type:
   	ST506 Disk
  
   Media.Model:
   	Vertex V170
  
   Media.Serial:
   	44000
  
   Media.Description:
   	In the Comet 32 this disk is attached to a Shugart 1610
   	"ICU" SCSI-to-ST506 controller, which evidently hides the
   	bad sectors found during formatting, from the host computer.
   	
   	The first physical sector on the drive is hidden from the
   	host, and contains the drive geometry, a table of bad sector
   	offsets, and other information we have not figured out.
   	
   	The only documentation we have for the controller, is for a
   	variant named "1610-3", and it contains no mention of this
   	bad sector handling, and requires that the host to configure
   	the ST506 geometry for the physical drive, so we conclude
   	the Comet 32 uses a later and more advanced version of the
   	controller.
   	
   	With help from David Gesswein, we figured how the bad sectors
   	found at formatting time are marked and handled, and the
   	bad sectors thus found matches the "ERROR MAP" sticker on the
   	disk drive perfectly one to one.
   	
   	Like the documented variant, this latter controller probably
   	supports assigning alternate tracks as with SCSI command
   	0x0E, but we found no evidence of that, nor any other dynamic
   	reassignments, on the drive.
   	
   	We have chosen to archive the drive contents, as the SCSI
   	host computer would have seen it, and corresponding to the
   	content we would have gotten, if we had dumped the disk
   	through the SCSI interface of the Shugart controller.
   	
   	We do not know if the controller supports SCSI command 0x25
   	(READ CAPACITY), conveys the size of the drive to the host
   	in some other way, or if the host is supposed to "just know"
   	that, for instance from a disk-label of some kind.
   	
   	The first hidden sector contains several bytes which might
   	or might not record the number of sectors reported to the
   	host, but we have chosen to include in this image all sectors
   	we could read from the drive, likely including, sectors
   	the controller reserved for dynamic bad sector handling.
   	
   	When examined with the AutoArchaeologist, this image gives
   	rise to no inconsistencies or other indications of trouble.
  
   *END*

Links hertil