All you always wanted to know about the WD1772
This may be beneficial for people that tries to emulate the FDC either for emulation or for converting stream to data.
You may want to first have a look at my edited version (V1.3 January 2015) of the WD1772 specification available at http://info-coach.fr/atari/documents/_m ... 72-JLG.pdf
To start I would like to discuss the CRC computation as well as the special sequence reported by Steven Seagal in the dragonflight thread http://www.atari-forum.com/viewtopic.ph ... 33#p251910
Let’s first start with the CRC.
In page 6 of the documentation we find information about the polynomial used and the fact that the CRC register is preset to ones.
In the MFM write track command (page 18) we find indication that “the CRC is initialized by receipt of $F5”.
It is therefore commonly assumed that the CRC is initialized to $FFFF at reception of the first $F5. This works well when reading data with the FDC because normal sector always uses a sequence of 3 x $4489 sync mark.
Note that a sequence of 3 x $4489 sync marks leads to a CRC value of $CDB4.
However in reality during the write track command the FDC presets the CRC register to $CDB4 each time a $F5 character is received.
This can be verified by writing a sequence with more or less than the normal three F5 characters sequence (remember that you won’t be able to read corresponding sectors) and looking at the CRC result.
For example if you use the sequence $F5 $F7 you will see that the WD1772 writes the two bytes $CDB4 after the sync character.
While we are talking about the $F7 character:
It is interesting to note that the byte placed after a $F7 character is written unchanged by the write track command. For example $F7 $F7 is not interpreted as a double checksum each with 2 bytes, but as a 2 bytes checksum followed with $F7.
If you use $F7 $F5, in a WRITE TRACK a two bytes checksum is written on the disk followed by a $F5 byte. So the $F5 is not converted to a sync byte. This also applies to $F6.
Now the special sequence
Usually sync marks are used in sequence of three in front of an address mark (IAM or IDAM).
Several games (Dragonflight, Jupiter Masterdrive see http://www.atari-forum.com/viewtopic.ph ... 25#p265765 or Union demo http://www.atari-forum.com/viewtopic.ph ... 25#p265764) uses a special sequence of sync marks as a protection.
This sequence is read as C2 0B CD B4 F7 … or 14 0B CD B4 F7 with the read track command of the WD1772. If you analyze this sequence at the bit stream level (using for example Kryoflux or SuperCard Pro device) you will find out that the C2/14 character is in fact a 5524 sync character, and that the 0B is a 4489 sync character.
What is interesting is that this sequence can be generated on an Atari. This sound impossible as normally the character F7 is used to indicate the FDC to write the two CRC bytes during the write track (format) command and therefore cannot be written normally. But we have already seen how to do that above.
What is happening is that certain sequence are specially handled by the WD1772 for example if you write F5 F5 F5 FE 00 00 01 02 F7 F7 the second F7 is hidden by the first one as we have seen above
This generates 14 A1 A1 FE 00 00 01 02 CA 6F F7 and you can see that the second F7 is written/read on the track.
To write the C2/14 0B CD B4 F7 sequence on a track we must use the following sequence: 4E 29 F5 F7 F7. (note you can replace the 4E by any even byte)
The important part here is that the first $F5 is preceded by the character $29. This is a nice trick because it uses a weak point of the MFM specification: the poorly chosen$ 5224 sync mark.
It is well know that the $X0 $29 $F5 sequence is incorrectly interpreted by the WD1772 when the address mark decoder is kept active at all time. This sequence is interpreted as a $5224 sync mark followed by a $4489 sync mark.
During the read track command the first sync mark is decoded as $C2 or $14 (depending if the sync mark decoder has started on a clock or data bit) and the second $4489 is decoded as $0B
The next $F7 tells the FDC to produce two CRC bytes ($CDB4) and as we have seen the next character is a $F7 because it is hidden by the first one.
I have tested all values between 00-FF in front of the first F5 and 29 F5 is the only interesting sequence.
You will find attached the sequence used by the write track command (wralll.hex) and the resulting read track result (rdall.hex). The wrall.hex file can be used directly with Panzer if you want to experiment. The track has been sampled using Kryoflux and analyzed with Aufit. The result of the interpreted track is joined in the track.pdf file.
Note that Aufit 0.9 is now capable to detect this hidden sequence reported as the dragonflight protection. Jupiter masterdrive uses an even more complex sequence that I have not been able to generate on an Atari. I am very close but if anyone has idea he/she is welcome.