IFW wrote:If you sample an unformatted track with a scope you will get no (or almost none) flux reversals.
Everything from that point is up to the drive electronics.
Therefore, when you try to find distribution etc. in the sampled data from unformatted areas, basically what you do is to profile/fingerprint the drive instead of the disk - which is probably not what you want
Consequently, the test will eventually fail, just by using a different drive type/model/head etc or simply switching the density mode on drives where that is possible.
This is the consensus on the subject and therefore it should be true. However this does not explain why we get different “random profile” from disk to disk and the larger differences when switching from DD to HD. I believe that there is a combination of noise generated by the read channel pushed to maximum amplification and the head picking up small flux reversal. In fact in this case we should probably not talk about reversal but variation. Something similar to what you hear when listening to a blank tape with the volume pushed very high.
Anyway this is more a rhetorical than practical discussion about reading data on a “real unformatted track” because the end result is that we are getting more or less random noise from the drive! More interesting is what we do to “unformat a track” (discussed below).
IFW wrote:You simply cannot be 100% sure whether a track is unformatted without very thorough analysis and that's the reason DTC does not omit tracks from stream dumps even if they are almost certainly unformatted.
Some protections may use as little as just a few bytes of data and leave the rest of the track unformatted... good luck with finding that properly, unless you know exactly what you are looking for. Usually duplicator info is being stored on unformatted tracks normally somewhere from track 80 and use very small formatted areas.
This is probably true generally speaking. However the only interest of writing hidden data is to be able to read/check them. In the case of Atari the MFM FD controller provides 3 read commands (address, sector, and track). In this case your best bet to hide a small chunk of bytes is to use an address segment which result in 7 bytes preceded by three sync and these is very easy to check. An other alternative would be to hide data that you access with a read track, and in that case you need at least one sync (in order to get meaningful data) and a sequence of bytes to check. In this later case it is slightly more difficult to detect but still not that difficult because of the presence of the sync byte(s).
IFW wrote:Testing for consistency in behaviour of the flux reversals and the legibility of the flux reversals in the affected area is what you want.
Now, the complexity comes from drive speed wobble, various reading artefacts and shifts, and index signal jitter - so unless you want to run such a test for a really long time, you should find ways of reducing the behaviour test and allow for some variance.
Actually it is easy to handle the “variance” as this is exactly what the DPLL algorithm do
Based on input from this thread, I have generated a new version of my prototype yesterday that now includes a sync detector and this allow me to check the presence of sync in unformatted track.
FYI I have some “bad diskettes” with very very distorded signals and I was surprise to find that the DPLL is good enough to recover data from this messy transitions
The sync are the red lines.
Below is the same view on 5 revolutions (separated by the black line)
IFW wrote:As for what KryoFlux does during write/remastering: depends on user settings, but the default is to "unformat" all tracks (no flux reversals), so no, it does not write patterns or anything like that.
Sorry I do not understand: “The default is to unformat all track”? How
“so no, it does not write patterns” so does it unformat or not???
The IPF library generates a fairly safe unformatted pattern that so far works with any software emulated on any platform; the reason for this is that it has to simulate the randomness observed when an unformatted track is being read on a real drive - but in an emulated environment, where randomness can only be generated.
It is possible to disable the generation of "unformatted noise" in the IPF library; DTC does that when it writes a disk as it relies on the physical properties of the real disk being written to
“as it relies on the physical properties of the real disk being written to” meaning what? Unformat? Do nothing?
What user setting?
Again remember that there is no such a thing as unformatted diskettes available from manufacturer!