I quite like them myself for various reasons - most notably being very useful for development - so they are here to stay for those who want to use them.
However, for archival you may not want to have 168 files per disk and files can possibly be smaller by shifting the domain representing the data in a lossless way - the entire pipeline of how KryoFlux samples is lossless so I won't introduce any kind of data loss for the sake of saving a few bytes... and of course the complexity of stream decoding can be completely eliminated as the hardware and communication efficiency specific solutions are not needed.
Draft would address those concerns specifically (ie 1 or 2 files per disk, compact, hardware/communication agnostic), although I have no problems whatsoever just using Stream files and zipping them up
Depends on what you want to do with the result. For dumping, I completely agree it's necessary to detect unformatted zones and just reduce possible noise. Not really fuzzy bits though, since they seem to more often be perfectly stable flux transitions that just happen to be put in the right places. But for the preservation/emulation format, you only want one definite revolution.DrCoolZic wrote:I do not consider multiple revolution as an annoyance but as a mandatory feature. This is a must to find out things like fuzzy bits. If you do not want multiple revolutions to be stored just ask the DTC program to only record one.
This is the beauty of the fuzzy bitsgalibert wrote:DrCoolZic wrote: Not really fuzzy bits though, since they seem to more often be perfectly stable flux transitions that just happen to be put in the right places.
perfectly positioned and stable bits placed at critical position will results to different read value <== this is inspection window border bit as for Dungeon Master
For fuzzy bits due to timing violation the result is the same but explanation is a bit more complex
Many thanks again for the tools you build around kryoflux!
I have almost completed the next tool KFPanzer : KryoFlux Protection ANAlyZER which automatically analyzes all (almost) the protection mechanisms that I am aware of on Atari FD (currently 29 protections).
I am in final testing and I should be able to release it soon. Quite interesting! I have tested it on about 1/4 of the 90+ FD (about 60 games) streams files that I have uploaded to SPS and I have found quite interesting protections! These protections were already categorized in my protection document (new version to come soon) but were actually applied in very creative ways (e.g. track 79 of Nigth Shift) ...
I still find minor problems on the KryoFlux project code but I believe the core (the KFEmul library) is now fully functional.
After cleanup I will publish if any interest.
PS As said before I have added the capability the produce .st file on KFPanzer (not very interesting?) and I was also thinking of producing either .stt or .stx but I am not sure if this is interesting to people?
As I already said I have been trying to understand what is the problem you are talking about? But I cannot see any problem related to write splice with Stream file.galibert wrote:... stream files have two annoyances: ... they don't have a track write splice information so you're not sure from where to start writing when you're reproducing a disk.
Write splice is certainly not well defined on the WD1772 (it is not on any floppy format I am aware of) The only information is that when writing sector the write gate is turn on 22 bytes after the end of the ID field. This is exactly at end the ID postamble (that I call GAP3a in my document) and at the beginning of the DATA preamble (that I call GAP3b). Once the gate has been turned on the WD1772 start by writing 12x00 and 3xA1(exactly the DATA preamble) then the data field ... of course due to disk variation this can cause problems that result in short desynchro of the PLL when reading back this sector...
But when reproducing a disk I do not see what is the problem??? If you are working with a non tempered disk you should not even see this problem, and if the disk to reproduce has been already re-written then the copy should have the same problem as the original. And in fact if you are clever you might even be able to fix this
Let me know if I have missed something.
Again I believe that Stream files contains all you need to have to do whatever you need to do!
You may find that it contains some extra information (I don't) but so far I cannot think of any missing information. Thanks to KryoFlux / SPS
When you write a whole track, you start writing at a given point on the disk, then do it for 0.2s. Problem is, floppy drives do not run exactly at 300rpm all the time, so there's pretty much no chance you'll get an exact joining once you've done a complete revolution. So you'll either have some leftover noise just before your starting point, or some overwriting there. That's the track splice. So the question is _where_ the starting point should be.DrCoolZic wrote:But when reproducing a disk I do not see what is the problem??? If you are working with a non tempered disk you should not even see this problem, and if the disk to reproduce has been already re-written then the copy should have the same problem as the original. And in fact if you are clever you might even be able to fix this
For the ST, you can most of the time start at the index. It will often work, because normal formatting on a wd starts at the index. But if you try to write Silent Service for instance, your copy won't work because sector data is present under the index.
The IPF format includes track splice information indirectly. It's defined to always be in the last block's gap, either at the index position if it falls in there, or in the middle otherwise (between the two gap streams in their terminology). Any preservation format should include that information in some way.