Atari ST Developments

29 October 2004

Authenticity Checks: Disk Modification on the ST

The Atari ST FDC is a much higher quality device than the Amiga’s, so detecting modified disks is not quite as easy, though it is certainly possible. Initially, we will get the analyser to complain if it finds a suspect image, and do the real work “manually”. We will then add automatic detection at a later date.1) Of course, there are images that simply cannot be written on an ST, which are relatively simple to detect.

Draft Atari ST Descriptor Logic

The draft of the descriptor logic is now complete. All the “rules” have been documented, like recursion, etc. - basically the complete process. It is possible to do this now since the on-the-fly descriptor generation work was the main bottleneck holding it up, and that was a major pain to implement. But you can read more about that in a previous WIP.

It is now possible to plug any sort of generator logic into the system without worrying about how it works. This is what is going to happen with “hardware MFM” - the term we use here for hardware based mfm floppy controller readable formats such as nec765 and wdc 1772 derivatives used in the ST and many other systems. The framework is done and now known to be reliable and working. Speaking in a general sense, the “business logic” is not there. However implementing business logic is normally much simpler (once the framework supporting it is complete and tested) than the logic driving it, in this case coupling format elements together based on arbitrary data sampled from key points of a floppy disk.

Data Header/Body Organisation

It seems to be more convenient to store data header and body parts together since there are protections where two or more body and/or header pairs are encapsulated within a single body part, which would go completely unnoticed unless you know what you are reading, or you can read the raw signals to detect the sync’s. This will likely add a few hundred bytes per track to a disk image, probably about 30 KiB for a whole disk compared to about 1 KiB that it could be if (much) more work was invested.

Not only that, but by storing them separately there would be a very remote risk of mis-mapping data. Since bodies never contain the header they belong to (it is simply determined by the previous header), and the analyser is able to assemble a track from tiny fragments, there is a chance that an unrelated block body would have been mapped into the place of a really badly damaged one. If the headers are grouped with the bodies together (again, this is very necessary for “encapsulated data” protections anyway) this simply cannot happen. This has never been a problem with the Commodore Amiga since headers are always grouped with the data content.

For these reasons we decided to stick with the simplistic solution that is known to be correct. Having separated descriptors and saving a few kilobytes is not worth the hassle or the risk.

Note on Analysation Speed

The most costly operation of the analysation is filtering out irrelevant data, and then probing the different formats against this filtered data. With the shear amount of formats that are now supported, analysation without filtering could take minutes to process, perhaps even hours - for just one track. From some of the previous WIP’s you will find that we did recognise this would happen, and did a large amount of work to make sure we had comprehensive filtering functionality so the system would scale into litereally vast amounts of supported formats.

So now we can practically eliminate all impossible cases before processing and re-adapt the system for the latest conditions. This was initially costly in that it was hard to implement, but if the processing is very complex it pays off all that work very quickly indeed.

1) This has since been resolved.