DrCoolZic wrote:Hello sorry for the late reply I am travelling and it would have been tough to reply from the boat to Niagara Falls
Several replies explain exactly what's happening. Good or Bad depends on what you are trying to achieve and how you process the data.
If you take a tool like CTA, the goal is to produce an IPF file that contains the exact data that where used to originally create the floppy disk. In order to do that you better work from almost perfect dump data. By design CTA is not very tolerant, for example CTA detects if a disk has been "tempered" (modified on an Atari) and if this is the case it wont let you write the IPF file ...
Current Aufit main goal is to produce images (mainly stx) to be used for emulation. Therefore the only constrain is to verify that we are reading information correctly as this would be done on a real Atari (and even better than on a real Atari). For example on a real Atari the tolerance on MFM transitions is about 10% of the nominal values and there is also automatic read retries performed by the TOS (up to 5 times using so called shoe-shine technique). Without DPLL and retries a large percentage of your floppies wont be read correctly. Aufit has an even more tolerant DPLL and has automatic "read retries" equivalent by reading data from different revolution (one of the good reason o sample at least 5 revolutions -- means 5 retrys).
On top of this main goal Aufit produces different graphs and text outputs that allow to "visualize" the quality of the image, but this interpretation currently has to be done manually by interpreting the outputs (CRC, out of band transitions, histograms, etc...)
To summarize: Current Aufit privileged production of correct stx images rather than perform quality analysis like CTA.
If you want to play a game Aufit should be able to generate correct stx images of relatively bad dumps.
If you want to reproduce a perfect image of the original disk use CTA and produce IPF files but the input quality has to be good.
SCP is in the middle of this two solutions has it just records/writes transitions. So if input transitions are good it will produce a good image but if they are bad it will produce a "not so good" image.
I am thinking of modifying Aufit to try to generate good IPF file from bad input! This should be feasible in many cases has the "layout" for protected and non protected disks are known in most cases... but this is only plans
so good or bad only means something if you define your goal
kodak80 wrote:So AUFIT is not suitable for checking how good a Kryoflux or SCP dump is then if it is not showing real errors! Great that it can recover from the errors but it would be nice to see the raw track information and any possible errors with my dumps.
I guess HxC Floppy Emulator provides a better image of the disk data and layout (once converted to CTR) as it doesn't correct the errors like AUFIT seems to be.
HxC also shows no errors with the Kryoflux raw dump which makes it very difficult to test how good a dump is. I guess we have to convert to CTRaw to test a Kryoflux dump as this shows the error on track 27?
DrCoolZic wrote:Other problem hard to detect is whether or not a FD has been modified. I am working on this topic currently but it is hard.
DrCoolZic wrote:Turrican ... This one does not seems to have any "serious" protection. Only a strange MFM format 1x512 + 1x128 + 5x1024
Note that CTA from SPS report all track as modified? With my current version of Aufit (not sure if released) that have an experimental write splice detector I find 2 sector splices (front of id and between id/data) for almost all sectors. Are you sure this is an original?
ijor wrote:DrCoolZic wrote:Turrican ... This one does not seems to have any "serious" protection. Only a strange MFM format 1x512 + 1x128 + 5x1024
And this certainly IS a protection. Don't know what exactly you mean by "serious", but you can't copy that format with standard hardware..
Ijor wrote:Note that CTA from SPS report all track as modified? With my current version of Aufit (not sure if released) that have an experimental write splice detector I find 2 sector splices (front of id and between id/data) for almost all sectors. Are you sure this is an original?
Multiple write splices doesn't necessarily mean that the disk was modified. Many original disks were recorded with two passes, or what seems to have multiple write splices. And of course that a single write splice doesn't guarantee that the disk was not modified or it's original.
DrCoolZic wrote:1x512 + 1x128 + 5x1024
...WD1772 supports 128/256/512/1024 bytes/sect so I think it should be possible to copy these tracks with std Atari HW? In other word I do not see anything that WD1772 cant do?
Users browsing this forum: No registered users and 2 guests