Sector Dumping and Editing, revisited

Entry posted by Atari_Ace July 26, 2018

527 views

So we've managed to write a simple tool that can dump and patch sectors for standard 90K disks. What about dual and double density disks?

A little bit of history first. The Atari computers first disk drive, the 810, was capable of supporting 18 128-byte sectors per track, leading to 720 sectors on a 40 track disk, or 90K. To get more data onto a disk, you can change the sector size, the number of sectors per track, or the number of tracks. When the 815 drive was designed, it changed the sector size to 256 bytes to increase the density, but because the OS boot routine was designed to read 128 byte sectors, the drive only returned 128 bytes for the first three sectors. The later 1050 drive took a different approach, instead putting 26 128-bytes sectors per track. So the 1050 could store less data than the 815 design. But third party drives initially followed the design the 815 implemented, returning truncated sectors for sectors 1-3.

The ATR disk format recognizes this distinction, and thus places the sector size in the file header, and always stores the first three sectors as 128-bytes.

So let's write a tool that can handle all three formats. We can keep the read_file, write_file, dump_buffer, and dump_sector routines from previous posts unchanged. To that, we first add read_disk:

sub read_disk {
  my ($file) = @_;
  my $buff = read_file($file);
  my ($sig, $imageSize, $sectorSize, $imageSizeHigh)
    = unpack "vvvv", substr($buff, 0, 8);
  die if $sig != 0x296;
  my $disk = { buff => $buff, sectorSize => $sectorSize };
  $disk;
}

Read disk reads the file, and examines the header by unpacking the data from the first 8 bytes. First it verifies the first two bytes are the the ATR signature. If then creates an "associative array", or hash containing the buffer and the sector size and returns it.

We can now pass this around to allow our code to make different decisions depending on whether it has 128-byte or 256 byte sectors.

In fact, for our purposes, the main change now is to make sector_offset sector size aware.

sub sector_offset {
  my ($disk, $sector) = @_;
  if ($sector < 4) {
    (0x10 + ($sector - 1) * 0x80, 0x80);
  }
  else {
    my $sectorSize = $disk->{sectorSize};
    (0x10 + 3 * 0x80 + ($sector - 4) * $sectorSize, $sectorSize);
  }
}

The old sector_offset only returned the offset, sector offset now returns both the offset and the size of the sector requested.

Let's rewrite dump_file now to handle the different style of disks.

sub dump_file {
  my ($file) = @_;
  my $disk = read_disk($file);
  my $buff = $disk->{buff};
  for (my $sectorNum = 1; {
    my ($pos, $sectorSize) = sector_offset($disk, $sectorNum);
    last if $pos + $sectorSize > length($buff);
    my $sector = substr($buff, $pos, $sectorSize);
    print dump_sector($sector, $sectorNum++, $pos, '');
  }
}

The old dump_file hard coded 128 bytes and 720 sectors. Now we just dump sectors until we run out of buffer, and we rely on the sector size value returned by sector_offset so that with double density disks we dump short sectors first and then the larger sectors.

The changes to copy_sector are simpler in fact, since it's only assumption was the sector size.

sub copy_sector {
  my ($srcFile, $srcSector, $dstFile, $dstSector) = @_;
  my ($dst, $src) = (read_disk($dstFile), read_disk($srcFile));
  my ($dstBuff, $srcBuff) = ($dst->{buff}, $src->{buff});
  my ($srcOffset, undef, $dstOffset, $sectorSize) = (sector_offset($src, $srcSector), sector_offset($dst, $dstSector));
  substr($dstBuff, $dstOffset, $sectorSize) = substr($srcBuff, $srcOffset, $sectorSize);
  write_file($dstFile, $dstBuff);
}

We use the destination disk sector size to determine how much data to copy. This utility is really only designed to handle copying when the sector sizes are the same, but if they are different the routine does do something sensible.

Anyhow, we know have a still fairly small utility (a little over a hundred lines) that we can use to examine and repair disk images when we have multiple copies of the data available. Over the coming months this will be our go to tool to fix disks, so let's find some disks to repair!