Ijor as usual you raise some very interesting questions about fuzzy bits.
I am currently working in Aufit for adding the capability to retrieve “mastering information” from the flux transitions (similar to what CTA from SPS is doing). Basically the idea is that as long as the quality of the floppy disk is good enough to retrieve the mastering information, we should be able to regenerate a perfect image. This would allow Aufit to write perfect image for simulation using STX format, or to generate a perfect floppy using IPF or SCP format. Of course fuzzy bits is an important part of this process (I will use the term fuzzy bits for bit transitions that decode sometimes as 0 and sometimes as 1).
First I have identified several type of fuzzy bits that are either created intentionally (usually tested for protection) or unintentional (usually not tested). Here is a list of all the type of fuzzy bits that I am aware of:
• Random fuzzy bits
• Dungeon master fuzzy bits
• DrT fuzzy bits
• Unplanned fuzzy bits
For each of these types of fuzzy bits I am trying to understand:
- How are they created on a master machine?
- How are they read by the Atari FDC?
- How can they be emulated?
- How can they be copied?Random fuzzy bits:
This type of fuzzy bits is the result of unformatted areas on a track and is widely used for protection. Creating unformatted areas on a track is not possible with the Atari FDC and therefore the usage of special hardware is required (i.e. Kryoflux) as explained here http://forum.kryoflux.com/viewtopic.php ... t=20#p6586
When reading from an unformatted area, the floppy drive returns random flux transitions that are decoded as fuzzy bits (the durations and therefore the positions of the flux transitions differ from one revolution to the next). For more details please look at http://forum.kryoflux.com/viewtopic.php?f=3&t=749#p6551
Detecting that a cluster of fuzzy bits belongs to the “random” type is not obvious. Several techniques have been used by programs that have direct access to flux transitions information. For example the HxC software uses some sort of correlation analysis between revolutions (see http://forum.kryoflux.com/viewtopic.php ... 9&start=10
) that provides very accurate detection, Aufit uses Shannon entropy functions (less accurate but faster), and I do not know the technique used by CTA. For a program that only have access to decoded data like the Pasti imager, it is even more complex to detect this kind of information.
A perfect emulation of fuzzy bits resulting from unformatted area is not really possible. This is due to the fact that the durations of the flux transitions should follow a pseudo-random repartition that vary with floppy disks and floppy drives vendors. If you look here http://forum.kryoflux.com/viewtopic.php ... t=20#p6590
you can see that the probability reach a peak around 2.75 µs then decrease regularly.
But in practice it does not really matter as the protection only tests that subsequent reads of the bits in the unformatted area returns different results. For example the program checks that the content of a sector with an unformatted area in the data segment differ for each read.
Performing a perfect copy requires to detect the presence and position of the unformatted area and to recreate it on the backup disk. For example with the Kryoflux hardware it is possible to specify a weak sector in the IPF mastering file and that will result in an unformatted area. I do not know if it is possible to specify an unformatted area with SCP.
However, as mentioned for emulation, it is perfectly acceptable to directly copy the flux transitions from the source to the destination floppy as this is done for example with SCP. This will result in pseudo random transitions that are good enough to pass the game protection check. But making copy of copy should be avoided.
This type of protection is primarily used on sectors. In that case we talk of a fuzzy sector protection.
For example the track 79.0 of Atari Arcade Classic FD contains an unformatted area in sector 9 (6th sector). The unformatted area starts only after few bytes inside the sector’s data segment and extend few bytes after the end of this segment. This ensure that the data sector is correctly read and that all the bytes until the end of the segments return random values. You can see at the end of the track that we have another unformatted area. Actually it is very common to find unformatted areas at the end of all the tracks of a FD. This is due to the fact that sometimes only “meaningful” track content is written on the mastering machine (probably to speed up the creation of the floppy) and non-meaningful area at the end of the track is not written and therefore left unformatted.
Radom fuzzy bits can also be used outside of a sector. In that case we talk of a fuzzy track protection (note that fuzzy track protection is not supported by Pasti format).
For example in Vroom track 78.0: we have a very small unformatted area (about 120 µs) located at position 179.7 ms shortly after three $A1 sync mark.
Another example is found in Power Drift track 01.0: we have a small unformatted area (about 250 µs) located at position 4.7 ms shortly after four $A1 sync mark. Dungeon Master fuzzy bits
The fuzzy bits used in Dungeon Master have been already described in many places and therefore I just present a short description of the protection here. To create this kind of fuzzy bit on a mastering machine a specific flux transition located between two adjacent flux transitions is slowly moved.
We can see that the sliding transitions follow a triangular pattern.
When this kind of fuzzy bits is read, we have at some unpredictable point (when the transition crosses the 5 µs boundary) a decoded bit that changes from 0 to 1. The position where the bit flip from 0 to 1 vary between revolution due to flux drift (ISV and MSV).
The sector is filled of $68 bytes but due to the sliding transition some of these bytes get transformed to $E8 (upper bit changing from 0 to 1) when reading.
Therefore for emulation we use a byte mask array that looks like this:
Code: Select all
Sector 7 Fuzzy Bytes Mask array
3817 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3833 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3849 80 00 80 80 00 00 00 80 00 00 00 00 00 00 00 00
3865 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
All the bytes in the mask array are $00 (no variation) except in some places they become $80 (random generation of 0 or 1). The program checks that subsequent reads of this sector returns different values and that only bytes $68 or $E8 are found.
Copying DM fuzzy bits is easy because the exact positions of the transitions is not critical as long as the “sliding transitions” crosses the 5µs border. Therefore copying DM fuzzy bits works perfectly with SCP, but unfortunately there is currently no support in Kryoflux.DrT fuzzy bits
Most programs (except early ones) created by DrT uses fuzzy bits that are a sort of combination of DM fuzzy bits and unformatted area.
They first start with an area with sliding transitions that follow a pattern different from DM (probably not to violate the patent) that I refer to as a fishbone pattern. We have sliding transitions in the 4 to 5 µs range that are compensated (not to disturb the DPLL) with sliding transitions in the 3 to 4 µs range. This area (about 5 ms) is followed by an unformatted area.
When reading the first part, at some unpredictable point (due to ISV and MSV), some of the transitions crosses the 5 µs border resulting in bits read as 0 or 1. The sector is filled with $00 bytes but due to the sliding transition some of these bytes get transformed to $01 (lower bit changing from 0 to 1). Reading the second part of the sector return random fuzzy bits.
Therefore for emulation we use a byte mask array that looks like this:
Code: Select all
Sector 10 Fuzzy Bytes Mask array
5650 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01
5666 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 01
5682 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01
5698 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01
5714 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
All the bytes in the mask array are $00 (no variation) except in some places they become $01 (random generation of 0 or 1).
Copying DrT fuzzy bits first part is easy because the exact positions of the transitions is not critical as long as the “sliding transitions” crosses the 5µs border. Copying the second part (unformatted area) has already been explained. Therefore copying DrT fuzzy bits works perfectly with SCP, but unfortunately there is currently no support in Kryoflux.Unplanned fuzzy bits
Unplanned fuzzy bits do not happen on purpose and therefore are not tested. In general they are the result of long flux transitions like in the case of No Flux Areas. This kind of flux transitions violates the MFM rules causing the desynchronization of the FDC DPLL and this results in unplanned fuzzy bits due to small flux drift (ISV & MSV).
Here an example of an NFA with unplanned fuzzy bits
Unplanned fuzzy bits also appears with tracks that contains several tens of overlapping sectors like in Au Nom de l’Hermine (70 sectors) Other type of fuzzy bits
I am not aware of other kind of fuzzy bits, but I am open to learning.Question about Kryoflux capabilities
Questions about SCP capabilities
- For “random fuzzy bits” I know that the weak sector definition exist in IPF format. Are fuzzy bits on a track (outside of sectors) supported? In that case how.
- Is it correct to say that Dungeon Master and DrT type of fuzzy bits are not supported?
- Is there any other type of fuzzy bits supported by KF?
- When specifying unformatted track in IPF format does that results in keeping the write data line negated for the duration of the track?
- Currently, as far as I understand, SCP copy random fuzzy bits directly from source to destination. Is there a way to indicate in SCP format that an area is unformatted? In other word having SCP that keep the Write Data line negated for the duration of the unformatted area.
- Is this possible for an entire track (equivalent to completely unformatted, factory new track).
You do not have the required permissions to view the files attached to this post.