01-04-2014, 11:13 AM
OK, the specs file has been updated. Please download the new version. There were several corrections made.
Please also note that there is a new definition for a read/write type image. If a disk is image is read/write capable, then the flux space allocated for the revolution (only 1) is defined in long word at 0x40 in the TDH. 0x40 was defined as a checksum, but that was not actually be used. So, it has been re-purposed for this. The flux space will typically be 125,000 to represent 125,000 bit cell entries available. The actual flux data is contained in this space (starting at the beginning). The unused space will be 0's. So, if the number of bit cells for a track was 72,000, then the remaining space afterwards (53000 entries) would all be 0's for each bit cell entry.
I also made it clear that all revolutions are stored sequentially together and can not be broken up. This eliminates your concerns about data having to be copied in chunks located at various offsets.
Please also note that there is a new definition for a read/write type image. If a disk is image is read/write capable, then the flux space allocated for the revolution (only 1) is defined in long word at 0x40 in the TDH. 0x40 was defined as a checksum, but that was not actually be used. So, it has been re-purposed for this. The flux space will typically be 125,000 to represent 125,000 bit cell entries available. The actual flux data is contained in this space (starting at the beginning). The unused space will be 0's. So, if the number of bit cells for a track was 72,000, then the remaining space afterwards (53000 entries) would all be 0's for each bit cell entry.
I also made it clear that all revolutions are stored sequentially together and can not be broken up. This eliminates your concerns about data having to be copied in chunks located at various offsets.