Jump to content
IGNORED

ATX file format additions and enhacements


ijor

Recommended Posts

We implemented the following additions and enhancements to the ATX file format.

 

  • Define additional densities at the file header
  • Implement recording bitrate at the track header
  • Support full content for long sectors
  • Support double density, double sided and other densities

 

Include in the attached zip file is a short document and an updated .H header file. I wanted to polish a bit more the document and build some few more samples but currently I'm short of time. I decided it's better not to wait and post an update if necessary.

 

Thanks to Phaeron and other people for their invaluable contribution.

 

 

AtxSpecsNews-Set-2020.zip

Edited by ijor
  • Like 8
Link to comment
Share on other sites

Attached an ATX image of disk 1 of Atari Accountant. This is a software designed for the Atari 815 disk drive and it is the only known copy protected title in double density.

 

Note that this is a reconstructed image; we don't have a full image of the original disks.  Please see this for more information about how the data was recovered:

https://atariwiki.org/wiki/Wiki.jsp?page=The Atari Accountant Series

 

Note also that we don't know the exact copy protection that was present on the original disk. We only know that the software attempts to read a specific sector and expects the drive to return an error. I just crafted an image with a track layout that would produce that behavior.

 

The 815 drive, contrary to any other Atari 8-bit drive doesn't invert the disk data. But in this image the data is inverted so that it could be run on other Atari double density drives such as the Us Doubler.

 

The software requires Basic and I've been told it also requires OS-B. I didn't test it thoroughly, only confirmed that the copy protection check passes and the software loads correctly.

 

For running under emulation it requires Altirra version 4.00-test16 or later and with current versions it might also require to enable the config option "image.disk.atx.full_sector_support". This option will probably not be required in future versions.

 

Edit: The image posted at this post has been deleted because it was built with wrong sector timing. An updated image was posted below at post #6 in this thread:

https://atariage.com/forums/topic/312312-atx-file-format-additions-and-enhacements/?do=findComment&comment=4652404

 

Thanks to @jaybird3rd for allowing this edition.

Edited by ijor
Deleted bad image
  • Like 3
Link to comment
Share on other sites

1 hour ago, ijor said:

Attached an ATX image of disk 1 of Atari Accountant. This is a software designed for the Atari 815 disk drive and it is the only known copy protected title in double density.

AtariAccountant-Atx.zip 63.37 kB · 3 downloads

 

Sure the timing information in this disk image is correct? The sectors on track 0 only have timing values up to $2D78 (11640), which is only up to half what ATX images normally use for a full revolution. This is causing boot to fail in Altirra with 815 emulation enabled as the track materialization routine is overlapping sectors.

 

Link to comment
Share on other sites

10 minutes ago, phaeron said:

Sure the timing information in this disk image is correct? The sectors on track 0 only have timing values up to $2D78 (11640), which is only up to half what ATX images normally use for a full revolution.

 

Oops, you are right! I will post a fixed image later. Sorry about that.

Link to comment
Share on other sites

Hi @ijor

 

   Thanks very much for extending the ATX spec, I'm guessing it should cover almost all situations, but is there any way to handle data stored between sectors, as used by Disk-Master 1050, described here:

 

  

 

   I appreciate that having some sort of "Gap-Data" record would probably bloat the file as it would almost always be noise, but I can't see a simple way of recording this info, so perhaps include it as an extension to the ATX format, but assume it is optional during the imaging process, e.g. very rarely used, so not a default choice.

 

 Unfortunately I have my hands full at the moment, so can't be of much help, but if the ATX format is going to be revised, it would be nice if some mechanism for capturing this info could be included, just for the sake of completeness.

 

   Thanks again, and hope this helps!

Link to comment
Share on other sites

4 hours ago, ijor said:

Attached an ATX image of disk 1 of Atari Accountant. This is a software designed for the Atari 815 disk drive and it is the only known copy protected title in double density.

 

That image I posted earlier has bad sectors timing. It worked emulating a US Doubler, which is what I tested, but as Phaeron explained it fails if emulating an 815. Attached fixed image. May be a moderator can give me permission to edit post #2?

 

AtariAccountant-Atx-FixedTiming.zip

 

 

Attached also an image of the Archiver Editor by Spartan for the Happy 810. One of the very few titles that requires full data stored for long sectors. For testing on Altirra enable Happy 810 full disk drive emulation. Again, it requires Altirra version 4.00-test16 or later and and might also require the config option "image.disk.atx.full_sector_support".

 

ArchiverHappy810-Atx.zip

 

Edited by ijor
  • Like 1
Link to comment
Share on other sites

17 hours ago, E474 said:

Thanks very much for extending the ATX spec, I'm guessing it should cover almost all situations, but is there any way to handle data stored between sectors, as used by Disk-Master 1050, described here:

 

 

There is still no support for the FDC read track command and data outside the sectors. Note that as I commented already, this is not strictly required for running DiskMaster 1050. It doesn't use it as a copy protection but only for hiding part of the protection when using the program to analyze its own disk.

 

Adding support for gap data at ATX images is not very difficult. But there are significant complications for emulating the read track command accurately, especially at MFM. The extra size required to store all the track data shouldn't be a big problem. Not only that this would be, of course, optional, but also it is possible to store full track data on specific tracks only.

 

It's not top priority for me anyway. There are a few other issues that IMHO, are more important. E.g., we need to add support for weak bits at the header (a weak sector header). This is required for running SuperArchiver.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...