Disk images in Atirra

[pfeuh]

Hello,

 

I've got an unexpected problem using Altirra. I attach 2 disk images of 92160 bytes (720 * 128). With the first one (containing a DOS 2.0), I format the second one and I quit Altirra... Then I see that the second one's size has grown! it is now 16 bytes bigger. I suppose that there is now a 16 bytes header to switch to ATR format. But... The disk names didn't change, they are always "disk1".xfd and "disk2".xfd. Does anybody has such an experience?

 

Pfeuh

[flashjazzcat]

I did, but I can't recall the cause or solution. Try the Altirra threads in the main A8 forum. I'm certain Avery explained things there.

[Rybags]

I'd just use ATR to begin with especially if you're creating new images. The XFD format is outdated, ATR is much better to use as it has proper descriptors and support for various sector length and image sizes. Plus, all of the SIO2xx type emulators support it as well so it's much more portable.

[flashjazzcat]

I think the issue I asked Avery about was actually ATRs which changed their size after formatting. I'll try to find the post later.

[+JAC!]

The file extension does not matter. ATR files are identified by the magic byte sequence in their header and their integrity is given by the header, the geometry (#sectors/sector size) and the file size. You can name ATR files whatever you want. File extensions are just a convenient way of naming things and Windows happens to bind them with suitable application.

 

Why you format a disk image (represented by a single image file) from within an emulator, the emulator will create the file content matching to the density you format. If you format in single density you will get a file with an ATR header and 720 sectors of 128 bytes each. If you format enhanced or double density you'll get a file with more / larger sectors correspondingly. You can even format with MYDOS in harddisk mode and get a 16 MB image (not tested, but should work).

 

EDIT: As mentioned above you should not use XFD format files, they have no header and are therefore not safe. Esp. with regard to non-standard disk &sector sizes.

Edited October 30, 2014 by JAC!

[flashjazzcat]

Thanks Peter. That's exactly what had me foxed at the time for some reason. I was using MyDOS and since it didn't issue a percom query prior to formatting, the emulator was changing the ATR file size to match my bad formatting parameters.

[phaeron]

This is a bug in Altirra -- it should not be rewriting the XFD to ATR when you reformat as a single-density disk.

 

It does raise some interesting questions, though, such as what should happen if you have an XFD image mounted as read/write and then reformat it as double-density or another format that isn't XFD compatible. I suppose it could remount the disk as virtual read/write and then flag a write error (flashing disk indicator).

[ricortes]

A bit of drift. Some of the earliest DD XFD images used a different format for the first three sectors. Something like only allocated 128 bytes for the first three sectors on a double density disk which causes problems with file offsets to data. To be fair, XFD did come first. I think it was a problem with the ST and early DOS versions. I'm pretty sure it was made compatible by Xformer 2000.

 

I've stepped all over some disks by mixing images: Very dangerous practice. If for some reason you get a lot of file errors on older XFDs, it could be you need to transfer them to a single density format using one of the old copies of the emulator. Stick with ATR is the best advice with a corollary of watch out from double density XFD images you may find floating around different archives.

[+JAC!]

> if you have an XFD image mounted as read/write and then reformat it as double-density or another format that isn't XFD compatible

That sounds like the best solution to me as it will avoid confusion without losing any feature.

 

> Something like only allocated 128 bytes for the first three sectors on a double density

That's because the Atari OS always uses the first 128 bytes from the boot sectors. It the same in the ATR format.

There were some ATRs which are used incorrect $100 bytes for them. They can be fixed with the ATR tools.

[ricortes]

> if you have an XFD image mounted as read/write and then reformat it as double-density or another format that isn't XFD compatible

That sounds like the best solution to me as it will avoid confusion without losing any feature.

 

> Something like only allocated 128 bytes for the first three sectors on a double density

That's because the Atari OS always uses the first 128 bytes from the boot sectors. It the same in the ATR format.

There were some ATRs which are used incorrect $100 bytes for them. They can be fixed with the ATR tools.

 

Have you ever checked what the actual length of the first three sectors of a double density disk are with a tool like 22disks? I'm curious if the actual length is 128 or 256 bytes with only 128 bytes returned. Something like: Are there are 18 256 byte sectors on the first track with partial reads on the first 3, or 3 128 byte sectors mixed with 15 256 byte ones. Sheesh, I think it would take less time for me to test it myself then type this out!

[HiassofT]

I'm curious if the actual length is 128 or 256 bytes with only 128 bytes returned.

The physical size of the first three sectors on a DD disk is 256 bytes. The drive firmware truncates reads to the first half of the sector and pads writes with 128 bytes.

 

But this is irrelevant when it comes to ATR/XFD images, you can't access the full physical sector with the standard SIO read/write commands $50/$52/$57.

 

so long,

 

Hias

[ricortes]

The physical size of the first three sectors on a DD disk is 256 bytes. The drive firmware truncates reads to the first half of the sector and pads writes with 128 bytes.

 

But this is irrelevant when it comes to ATR/XFD images, you can't access the full physical sector with the standard SIO read/write commands $50/$52/$57.

 

so long,

 

Hias

 

True but there is a possibility of using them for a purpose as yet to be determined. Something like burn a new ROM for an existing drive or added feature to a new drive like one of the sio2sd types. If you know there is an extra 368 bytes of bullet proof storage on the emulated or real floppy like a USD 1050, you could add everything from a bit of code to time/date stamping. If you were desperate, you could just tack the storage onto the end of the existing sectors i.e. read sector 721 on a DD floppy to return the second 128 bytes of sector 1.

[flashjazzcat]

This is why it was probably a mistake to make the first three sectors of a DD ATR short in the first place. However, it's perfectly simple to deduce whether the first three sectors are 128 or 256 bytes by analysing the size of the file. Thankfully all this nonsense was done away with in 512bps ATRs.

[ricortes]

DOH! 3x128 = 384.