All you always wanted to know about the WD1772

[DrCoolZic]

In this thread I would like to discuss technical information 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.

[DrCoolZic]

Forgot to mention that in some F5 F7 sequences the F7 is not always interpreted as generate CRC
For example the sequence 4E 00 F5 F7 F7 00 41 F6 4E produces 4E 00 14 9B 69 EE 00 83 C2 4E
See the readall.hex file for more info

[Maartau]

for your job ( again)...

[DrCoolZic]

Did not remember but already talked about the 29 sync seq http://info-coach.fr/atari/hardware/FD- ... te_Pattern

[DrCoolZic]

I might have talk to quickly about the reason why the F7 sometimes does not generate the CRC
I said, based on some input, that this was happening because the CRC register was equal to 0 but in fact this really does not make any sense

The real reason again seems to lie in the 5524 sync mark. So for example F7 F7 does not generate checksum because second F7 is hidden by first one.
I need to think about this again and probably correct my first post

stay tuned

[DrCoolZic]

Just want to confirm that F5 definitively initialize CRC to CDB4 this is clearly specified in Scheiben kleister II de Claus brod
Hum this is written in German and I do not speak German but I think I interpret correctly

[Maartau]

http://www.clausbrod.de/cgi-bin/view.pl ... enkleister

My German is limited too, if somebody is also interested by the subject, there's one on eBay :

http://www.ebay.com/itm/Scheibenkleiste ... 4ae245796c

[DrCoolZic]

For fun look here http://www.atari-forum.com/viewtopic.ph ... ilit=+brod
I have translated chapter 12-13 but unfortunately the information about read/write time are in chapter 7
even had feedback from clausb http://www.atari-forum.com/memberlist.p ... ile&u=1575

[JimDrew]

Jean, did you ever create a disk with numerous bitcell patterns that go through all of the various sync combinations when using the WD177x FDCs? There are dozens of combinations that generate unexpected results, similiar to Juipter's Master Drive. The results are predictable though if you use the correct state table logic. I spent some time on SCP's analyzer and can now provide raw MFM or MFM as the WD1772 sees it, and from either of those formats decode hex level data.

[DrCoolZic]

I started to do this but unfortunately at the time I did the test it was pretty hard to use SCP editor to write test patterns at the bit level.
I do not remember exactly but I think you had to enter the transition as timing information (did not work as MFM bit) in order to write them to disk

Is it easier now?
Would be nice to have a bit more information about the SCP editor

[DrCoolZic]

TADA

I succeeded to produce the special Jupiter Masterdrive sequence on a real Atari
Based on the fact that it was possible to write the magic C2 0B CD B4 F7 sequence directly on an Atari using strange input I was suspecting that it was possible to also write the Jupiter Masterdrive sequence

The resulting sequence that we are trying to get is the following 14 00 1C 92 10 90 C2 0B CD B4 F7 00 DE AD C0 DE 00 00 00 00 00 00
Where the first the 14 and C2 bytes are 0x5524 sync byte and the 0B is an 4489 sync byte
We already know how to produce C2 0B CD B4 F7 sequence and the "dead code" poses no problem
But how do we produce 14 00 1C 92 10 90 C2 0B with three sync bytes inside ....

Well the answer is not so obvious but here it is : 28 29 55 42 49 4E 4E 29 F5 F7 F7 00 DE AD C0 DE 00 00 ....
The significant part are:

• 28 29 55 is a magic sequence 28 (even byte) followed by 29 will produce the sequence xx 14 00
• 4E (even byte) followed by 29 F5 will produce the sequence 90 (due to preceding sync seq) C2 0B

The rest is obvious

I have tested the sequence using Panzer / read the result / and analyzed the disk using Kryoflux to check the sync byte with new Aufit ....
What is fun is that this sequence created by UBISOFT contains in ASCII form ... ()UBI

jpmd-hex-format.PNG

Here the result analyzed by Aufit

jpmd-track.PNG

Here is the transitions with blue line = 5524 sync mark and red line = 4489 sync mark

jpmd-clock.PNG

Fun [smilie=greencolorz4_pdt_01.gif]

Now I understand why smart copiers were able to copy things that were supposed not to be producible on Atari. But this has to be hard coded to hard to guess on the fly ...

[JimDrew]

I started to do this but unfortunately at the time I did the test it was pretty hard to use SCP editor to write test patterns at the bit level.
I do not remember exactly but I think you had to enter the transition as timing information (did not work as MFM bit) in order to write them to disk

Is it easier now?
Would be nice to have a bit more information about the SCP editor

I never thought it was difficult, so nothing has changed. You can modify the flux length for any bitcell. For testing the WD1772 I just wrote numerous bitcell combinations with SCP and read them back under Panzer. You have to do this at the flux level though, there is no magic conversion process that is really possible via MFM.

What info did you need about the editor?

[DrCoolZic]

I started to do this but unfortunately at the time I did the test it was pretty hard to use SCP editor to write test patterns at the bit level.
I do not remember exactly but I think you had to enter the transition as timing information (did not work as MFM bit) in order to write them to disk

Is it easier now?
Would be nice to have a bit more information about the SCP editor

I never thought it was difficult, so nothing has changed. You can modify the flux length for any bitcell. For testing the WD1772 I just wrote numerous bitcell combinations with SCP and read them back under Panzer. You have to do this at the flux level though, there is no magic conversion process that is really possible via MFM.

What info did you need about the editor?

I do not remember the details exactly but I was trying to work at list at the binary level so to be able to specify something like 010010001000...
If I remember correctly the editor allow that but if you write it does not use this information and if you return to the timing data nothing has been changed. So you need to specify the bit pattern as timing values and this is really a pain

[JimDrew]

You have to change the timing for each bitcell entry. So, you need to know that 4us (%10) = 00A0, 6us (%100) = 00F0, and 8us (%1000) = 0140. If you wanted to write 4489 that would need to be converted from MFM to flux first (in your head like I do, or on paper), and then the values representing each bitcell manually entered. Yes, it is a pain, but no other device allows you to edit at the flux level like this. I need to make a conversion routine where MFM can be converted back to flux. Right now, conversions are one direction only flux-->MFM-->hex.

Example flux encoding from MFM:

Code: Select all

A1A1FE = 448944895554                                                             << hex to MFM

448944895554 = 10001001000100101000100100010010101010101010100                    << MFM to flux

1000  100  1000  100  10  1000  100  1000  100  10  10  10  10  10  10  10  100   << MFM bits
 8     6    8     6   4    8     6    8     6    4   4   4   4   4   4   4   6    << bitcell time

You are using to seeing the 44894489554 as A1A1FE. Until SCP, I had never really looked at the decoded MFM before. I never needed it for anything.

You will find that outputting certain patterns of flux transitions will overflow or reset the clocking mechanism, both before and while a sync is being compared. You should be able to create many (I doubt all) of these situations with the WD1772 by using non-standard values during a write, just like you have discovered with Jupiter's Master Drive. You can easily generate every possible pattern at the the flux level, but it does take some time. When we chatted about Jupiter's Master Drive last year I spent quite a few days tinkering with the DEADC0DE and Panzer.

[sarnau]

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.

BTW: I used that for my Atari copy protection in the 80s/90s to write long tracks on an Atari drive.

[DrCoolZic]

Continuing on the WD1772 description here is what I call the WD1772 track language ...

WD1772 MFM track format language

During the write track command (format) the WD1772 needs to be told to perform specific actions: write special sync marks with invalid MFM encoding, write special address marks that identifies the beginning of ID/Data fields, and write the content of the CRC register.

During the read sector, and read address commands the WD1772 needs to detect special address mark to identify the beginning of ID/Data fields.

Therefore a range of values from $F5 to $FF has been defined as having special meaning (what I call track format language) for the FDC. We review these special bytes:

• $00-$F4
  Are not interpreted by the WD1772. This means that during all read or write commands (including read/write track) nothing special is done on these MFM bytes and are therefore transferred directly.
• $F5
  - During read track, read sector, read address, write sector commands this byte as no special meaning.
  - During a write track command this byte (unless escaped by a $F7 byte) is written as an $A1 byte with partially missing clock bit ($4489) and the FDC internal CRC register is preset to the value $CDB4.
• $F6
  - During read track, read sector, read address, and write sector commands this byte as no special meaning.
  - During a write track command this byte (unless escaped by a $F7 byte) is written as a $C2 byte with partially missing clock bit ($5224).
• $F7
  - During read track, read sector, read address, and write sector commands this byte as no special meaning.
  - During a write track command this byte (unless escaped by a $F7 byte) forces the FDC to write the content of the CRC register. Any byte received after a $F7 byte is not interpret (escaped). In other word byte $F5 through $F7 are considered as normal byte when placed after a $F7 byte.
• $F8, $F9 Deleted Data Address Mark (DDAM) – Normally $F8
  - During a read track, read address, write track, and write sector command this byte as no special meaning.
  - During a read sector command if this byte is located after three $A1 sync mark it indicates the start of the sector “deleted data field”. Therefore the FDC sync mark detector is switched off after reception of this byte.
• $FA, $FB Data Address Mark (DAM) – Normally $FB
  - During a read track, read address, write track, and write sector command this byte as no special meaning.
  - During a read sector command if this byte is located after three $A1 sync mark it indicates the start of the sector “data field”. Therefore the FDC sync mark detector is switched off after reception of this byte.
• $FC-$FF ID Address Mark (IAM) – Normally $FE
  - During a read track, read sector, write track, and write sector command this byte as no special meaning.
  - During a read address command if this byte is located after three $A1 sync mark it indicates the start of the sector “ID field”. Therefore the FDC sync mark detector is switched off after reception of this byte.
  Note that for FD formatted on IBM machine a sequence of 3 x $C2 $FC is used in the post index gap. It is not interpreted by the WD1772

[IFW]

You should test what happens with the CRC after writing $F6...

[DrCoolZic]

You should test what happens with the CRC after writing $F6...

not sure if this is what you expect ...
"nothing special"

tested
f5f6f7 => 200b c2 45ef
f5f7f6f7 => a1 cdb4 f6 8fd9
f5f7f6f6f7 => a1 cdb4 f6 c2 40 6f

They all gives the expected result

[DrCoolZic]

To check CRC you may want to use my WD1772-CRC-CALCULATOR

starts the program and enter in the input window the hex bytes for example a1f7f6 or to be easier to read a1 f7 f6 (space ignored)
below this window you will find the number of hexa bytes (characters >> 1)
note that result is updated after multiple of 2 digits are entred and the CRC is displayed

to mode of computation for crc
normal: the crc is initialized to FFFF on the first a1
WD1772: the crc is initialized to CDB4 each time an a1 is received
changing from normal to wd1772 and vice versa restart computation
you can use all Windows features (e.g. copy bytes from one window to input, insert, delete, copy, blablabla)

only 13k but require .net

[DrCoolZic]

anyone has feed back on
"the FDC sync mark detector is switched off after reception of address mark"
not sure if this switch off happen after 3 sync or after 3 sync + AM

One od the key sequence to understand this is a1a1a1a1a1a1a1fe (7 a1) that can be read with a read address where a1a1a1a1a1a1fe (6 a1) cant be read

[AtariZoll]

......
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 wonder about that such or similar trick is used in Acopy . It can partially copy protected Dungeon Master - actually, one Polish guy said that it perfectly copied Dungeon Master, but I'm sure that was not able to create fuzzy bytes. Just could create sector with ID #F7, so game can be started from copy, but later protection check, activating randomly will fail .

[IFW]

You should test what happens with the CRC after writing $F6...

not sure if this is what you expect ...
"nothing special"

tested
f5f6f7 => 200b c2 45ef
f5f7f6f7 => a1 cdb4 f6 8fd9
f5f7f6f6f7 => a1 cdb4 f6 c2 40 6f

They all gives the expected result

Did not expect anything, just wanted to see if it is linked to CRC logic or not.

[DrCoolZic]

You should test what happens with the CRC after writing $F6...

not sure if this is what you expect ...
"nothing special"

tested
f5f6f7 => 200b c2 45ef
f5f7f6f7 => a1 cdb4 f6 8fd9
f5f7f6f6f7 => a1 cdb4 f6 c2 40 6f

They all gives the expected result

Did not expect anything, just wanted to see if it is linked to CRC logic or not.

As far as I can tell $F6 does nor seems to perform any magic!

But I found an intriguing sequence F5 F5 F5 FE F5 00 01 F7
Result is not what I expected ... still investigating ... I am documenting CRC with WD1772 ...

Do you have information about problem of the WD1772 with sync byte over index (huge track - timeout - etc. ) like using F7

[DrCoolZic]

OK now it is time to talk about one of the strangest behavior of the WD1772
Not 100% sure about the explanation so feedback is welcome.

When you read a track you expect to get a number of bytes around 6250 bytes. So on a slow track you may get 6500, 6600 at max. Right?
Well under certain circumstances you may get much much more, in fact you might even get an infinite number of bytes. So a program reading track should be aware of this for example in Panzer during read track I set the number of DMA “block” to 40. This correspond to 40 * 512 = 20480 and indeed I sometimes get 20480 bytes …

How is this possible and when does this happen?

Apparently this happen when reading a track that have sync mark over the index pulse. The explanation that I am aware of is the following: Normally during read track the FDC start on a first index pulse signal and stops when it receive this signal again. But if the FDC is busy processing a sync byte the index pulse is no longer recognized.
So when reading this kind of track (i.e. with sync over index) the FDC does not properly detect the index pulse and therefore lots of extra bytes are send to the DMA until usually memory overflows.

Some known condition is if you are reading a long sequence of $4489 or $5224 placed over the index pulse. It is said (by I did not try) that this also happen in the write track if you pass a sequence of $F5 or $F6 over the index.
This is a known condition that for example caused Pasti imager to fail (latest version at least don’t crash because they are ready for this condition). For example this happen with the game Turrican (reported by Ijor long time ago) – just tested few minutes ago.
Note that this does not happen systematically so you can read a track well several times and then it breaks.