fluxengine
fluxengine copied to clipboard
davidgiven
Support for A2R v3 as a flux source and sink
The A2R 3.x format makes several improvements that are desirable for non-Applesauce flux data. These include the following:
Support for solved fluxmaps (see #383); Support for per-RWCP-chunk arbitrary resolution, removing the need for resampling, even when combining flux data from multiple sources; Improved metadata handling
The 3.x format was defined with community input via the Applesauce Discord, and use by other tools was taken into consideration. The specification can be found here: https://applesaucefdc.com/a2r/
Belatedly --- having had a quick look, this looks like it'll be really hard to support (at least for writing). The format's making the same mistake that SCP does and is using a fixed number of revolutions; either 1.25 or 2.25 or more. Given that FluxEngine's default is 1.2, that means that I cannot write legal A2R files. Another issue is that it dictates that reads start at an index marker. What about drives which don't have one?
Other than that the format looks reasonably straightforward and should be easy to read, at least for RWCP chunks.
It might be worth asking at the Applesauce discord — the spec probably can be adjusted to allow for 1.2 reads instead of 1.25. However, it would be good if the default were increased as due to the nature of flux dumping 1 revolution is often not enough. Anyway I passed the question along.
For use of drives without index sensors an add-on index sensor is provided and recommended. Otherwise the images aren’t index aligned, for formats that don’t have an index sensor, this is usually okay but can lead to much more difficulty when dealing with damaged disks.
@davidgiven Applesauce does a 1.25 for a first pass by default, but 1.2 is totally fine. There is no real requirement as to the number of rotations. As there can be multiple reads for a single track, it would want to see those starting at the same rotational position, whether that be a true index or a false one. It doesn't really care. If there is no index signal at all, then just putting a single flux capture (as many rotations as you want) per track is perfectly fine.
It's not so much as wanting specifically 1.2, as for not wanting a requirement for any specific value as the number of rotations can vary arbitrarily, and they can start anywhere --- e.g. for a format which doesn't use the index marker, I don't bother waiting for one but just start reading as soon as the drive reports it's ready. If I can just put arbitrary data in an xtiming chunk, that would be great, but that's not what the spec says.
Looking at the definition of the index signals array: it says that soft-sectored disks 'are not required to have more than one index signal'. What if there aren't any? And, further down it says that if the read is aligned with an index signal then it doesn't get included in the table; is this what the Synchronized field in the INFO chunk conveys? The text is unclear.
There's also a minor issue with the drive types --- I keep track of the drive TPI, but nothing more. This means that I can't distinguish between drive types 3 and 8, or types 2 and 5, so I can't set this accurately (does type 2 include changing the drive speed for each CLV zone?). And there isn't an entry in the table for 3.5" 40 track!
I've added support for reading A2R v2 files (because that was what the sample image I got from Internet Archive was!) and it was straightforward. I don't forsee any problems with v3. Do you know where I can get a sample image? IA doesn't tell me whether they're v2 or v3.
Anything recent (since roughly December 2022) should be A2R3. If you come across an A2R2 that needs to be converted, post here and I can do so — this just needs resaving the image in the Applesauce software on macOS.
A2R2 files should no longer be getting produced.
It's not so much as wanting specifically 1.2, as for not wanting a requirement for any specific value as the number of rotations can vary arbitrarily, and they can start anywhere --- e.g. for a format which doesn't use the index marker, I don't bother waiting for one but just start reading as soon as the drive reports it's ready. If I can just put arbitrary data in an xtiming chunk, that would be great, but that's not what the spec says.
Drive Type stores the type of drive that was connected to the imaging device and used to image the disk. Not the drive used to originally write the disk. This means type 2 would include Apple drives that are capable of varying their speeds, so for a Mac 400K/800K image then the speed would be varied per zone while for a PC 720K or any 1.44MB image it would be constant.
Having this detail on the type of drive used to image the disk is useful metadata (as otherwise there's no way to tell apart 8" vs 5.25" vs 3.5" vs 3" vs whatever else), though it may require some user input as it's not necessarily obvious to tell electronically.
I've added support for reading A2R v2 files (because that was what the sample image I got from Internet Archive was!) and it was straightforward. I don't forsee any problems with v3. Do you know where I can get a sample image? IA doesn't tell me whether they're v2 or v3.
@davidgiven All the Victor 9K disks I upload with both .flux and .a2r images. These recent ones are definitely a2r v3. Here's a few examples for you: SS DOS: https://archive.org/details/supercalc-master DS DOS: https://archive.org/details/40-meg-sys-dos-2-93-7-16-89-v2-11-microsoft-inc SS CP/M-86: https://archive.org/details/victor-cp-m-86-tm-ver-1-1-2-4-v1-1-2-4-victor-technologies-inc DS CP/M-86: https://archive.org/details/cpm-86-voc-editor-voced5-submit-voc
