I'm currently implementing support for the VAPI "format" in Atari++ - things are working good for what I have been able to test, but there are a couple of files that are just bizarre and do not quite fit to the documentation; besides, the format seems to be pretty under-documented - and seems to lack quite a bit of information.
Here's a list of questions I came up, probably somebody is able to answer this:
*) The format doesn't seem to have an indicator of whether the disk is in SD,ED or DD formatted, that is, whether there are 18 or 26 sectors per track or whether a sector is 128 or 256 bytes large. However, this information is needed to step the "virtual head" and create the correct timing for the head movement. I'm currently trying to "reverse engineer" the format, though there files where even the first track contains corrupted sectors, and hence just extracting the tracks/sector from the first track does not work.
*) Since the sizes of the "track list header" etc.. are only "usually nn bytes", but not guaranteed to be "nn" bytes, there is no robust way to find the "extended sector data". I'm currently seeking backwards from the end of the track, and everything that "looks like" an extended sector data field and fits to a sector in the sector list is assumed to be one, but there seem to be exceptions. One of the images I found ("Ballblazer") seems to have an extended sector data without a sector indiciating that there actually is extended sector data. So what is this? This is for IIRC sector 2 of track 39, though according to the sector list, this sector is just regular.
*) The end of the track, just behind the extended sector data, seems to be always a sector list header, but without any sectors in it. Is this intentionally and can I depend on this? This does not seem to be documented.
*) There are some files (again, "Ballblazer", different version), where additional data of invalid structure seems to be behind the last track. I'm unclear what do to about it. Apparently, I could ignore it if I could assume that every disk has exactly 40 tracks, but given the ingenuity of some copy protections, this assumption seems to be not on very solid grounds. So what is this data behind the last track in the "UK" version of Ballblazer? Its "record type" does not fit to the track list header.
Thanks,
Thomas
Here's a list of questions I came up, probably somebody is able to answer this:
*) The format doesn't seem to have an indicator of whether the disk is in SD,ED or DD formatted, that is, whether there are 18 or 26 sectors per track or whether a sector is 128 or 256 bytes large. However, this information is needed to step the "virtual head" and create the correct timing for the head movement. I'm currently trying to "reverse engineer" the format, though there files where even the first track contains corrupted sectors, and hence just extracting the tracks/sector from the first track does not work.
*) Since the sizes of the "track list header" etc.. are only "usually nn bytes", but not guaranteed to be "nn" bytes, there is no robust way to find the "extended sector data". I'm currently seeking backwards from the end of the track, and everything that "looks like" an extended sector data field and fits to a sector in the sector list is assumed to be one, but there seem to be exceptions. One of the images I found ("Ballblazer") seems to have an extended sector data without a sector indiciating that there actually is extended sector data. So what is this? This is for IIRC sector 2 of track 39, though according to the sector list, this sector is just regular.
*) The end of the track, just behind the extended sector data, seems to be always a sector list header, but without any sectors in it. Is this intentionally and can I depend on this? This does not seem to be documented.
*) There are some files (again, "Ballblazer", different version), where additional data of invalid structure seems to be behind the last track. I'm unclear what do to about it. Apparently, I could ignore it if I could assume that every disk has exactly 40 tracks, but given the ingenuity of some copy protections, this assumption seems to be not on very solid grounds. So what is this data behind the last track in the "UK" version of Ballblazer? Its "record type" does not fit to the track list header.
Thanks,
Thomas