Strange sizes in ATR file formats

[gpounce]

I'm moving forward with the linux back end of my SIO networking idea;

 

 

For test media I downloaded the Holmes CD collection (7,000+ titles), comprising a huge variety of disk sizes.   My software is able to index & allow convenient searches of them, all but a hundred or so are bootable via my software on my 800 and 800XL, the exceptions having invalid signature words or hard disk images.  I had to work through a variety of unexpected format details.   I understand the ATR header format, but there are many of the images that use values of the Size field that do not correspond to the length of the disk image.   In some cases the interpretation is obvious- a disk image being smaller than the Size*16/sectorsize implies the sectors not supplied by the image file should be presented as zero fill when read by the Atari- and this method is working so far.

 

However in many others the computed sector count is very strange- I see cases of 512 secors, 718 (on 720 sector images), some have less than an extra sector of data appended to the image which makes the image portion of the file slightly larger than it should be.   In such cases I ignore the surplus bytes, which seems to work but I wonder if there is a better method.

 

My approach so far is to round the sector count up to the next valid size eg 718 is rounded to 720, adding 2 zero filled sectors.   I was wondering if some of the very small images should be handled that way as well- and if computed sector counts over 720 should round up to 1040 or 1140.   Perhaps there is a general rule for this?

 

There are a number of cases where the disk image portion of the file is 2* the size given by the ATR header, is there a standard method for handling these files?   I was wondering if this might be a double-sided image, but don't have an idea of how to handle that.

 

The XFD format is a bit more straightforward, my impression is that the disk parameters are deduced from the filesize- since there is no header.   Are there cases of odd-sized xfd files like in the ATR case?

 

I do have per-image overrides for sector count and size so I can force particular parameters if the software deduces incorrectly but this seems like a mess to get right.

 

Once the disk support is where I want it, then I'll release via GPL and git, then start in on the peer-to-peer network driver which is why I'm doing this.   Might be good to add a TNFS server so a3s can serve sectors to the SIO wifimodem which looks pretty cool

 

 

[E474]

Hi,

 

   512 sector ATR images are 64K, which are mentioned in the following link as possibly RAM disk images. Also, I vaguely remember reading that some utilities create ATR images that are also shorter than 90K, I think the disks that boot with k! (as in Ken Siders, RIP), might do this, but I'm really not certain. This would be for converting a single DOS executable or a program on a menu disk into a standalone bootable disk.

 

   I think the general rule is to pad with empty sectors to the next disk size if the ATR is using a non-standard size, though you're unlikely to run into issues unless it is something like a DOS disk that you're updating.

 

   Not sure about 1140 sectors, I thought it was 720 * 128 bytes, 1040 * 128 bytes, then Percom block values starting with 720 * 256 bytes upwards.

 

   One of the copy modes in ATR Maker Deluxe is to skip bad (missing) sectors without retrying them, so that 64K images could be copied to a standard sized ATR image reasonably easily.

 

   Hope this helps!

 

 

 

 

[gpounce]

The Holmes collection has a bunch of 1040x128  and a few 1140x128- at least the ATR header is authoritative with respect to sector size.   Sounds like nonstandard counts above 720 should probably round up to 1040.    As far as 1040 and 1140, I just load them in and permit the respective sector counts- the 800 and 800XL process them fine.   

 

I <think> a small number of the 256 byte sector images have the 1st 3 sectors also 256- a documented error case.   Closer checks of disk size does allow deducing this case at least some of the time.

 

At the moment I am not honoring ATR4 bad sector parms- I've not put any work into trying to deduce ATR revision from the image but probably should.    I did see a number of them with sector counts 90 or less- so the rule at the moment is to assume 0 fill sectors up to 720 for those.

 

I still have a dozen or so old floppies to archive, at least those will go into the usual 720x128 ATR1 format.

 

 

[Guest]

4 hours ago, E474 said:

Hi,

 

   512 sector ATR images are 64K, which are mentioned in the following link as possibly RAM disk images. Also, I vaguely remember reading that some utilities create ATR images that are also shorter than 90K, I think the disks that boot with k! (as in Ken Siders, RIP), might do this, but I'm really not certain. This would be for converting a single DOS executable or a program on a menu disk into a standalone bootable disk.

 

   I think the general rule is to pad with empty sectors to the next disk size if the ATR is using a non-standard size, though you're unlikely to run into issues unless it is something like a DOS disk that you're updating.

 

   Not sure about 1140 sectors, I thought it was 720 * 128 bytes, 1040 * 128 bytes, then Percom block values starting with 720 * 256 bytes upwards.

 

   One of the copy modes in ATR Maker Deluxe is to skip bad (missing) sectors without retrying them, so that 64K images could be copied to a standard sized ATR image reasonably easily.

 

   Hope this helps!

 

 

 

 

thanks. that's really helpful. just searched for "ATR Maker Deluxe" but can't find a copy.

[E474]

Hi,

 

   Sources and ATR image are here: https://github.com/e474/ATRMaker/tree/master/ATRMaker

 

   I am working on a newer version, but I switched from screen memory writes to using the S: device, and the code is still in flux, but it should be ready in the next week or so.