Another Datasheet Needed (and Found)

6 November 2004

A bit of a challenge this one. We needed the datasheet for a WD 1100-03 (address mark detector). We contacted Western Digital who were very helpful, but no longer have copies of their old datasheets. Even info of the clone chip of the WD 1100-03, as getting info on that could have been used as well.

Huge thanks go to Ingo Sangmeister and F.J. Kraan for helping us get hold of these datasheets.

But what does this have to do with Atari ST FDC emulation?

The WD1691 datasheet was very useful since the FDC1792 is an integrated and advanced chip for its time, and contains the logic of several ICs rolled into one.

The problem is that some of the internal operations are impossible to guess from the FDC documentation. For example, the FDDs are just represented as a single logic block and that is it. In some cases, it would be good to know how that block behaves internally. Our guess would be that the components of the FDC1792 were previously available separately before it became the complex IO device it is. We then went looking the components made by Western Digital at the same time, which are the logical choices to save on engineering and probably manufacturing costs.

What we did not know

Without the datasheet we did not have any idea how the AM in the FDC worked, it was certainly not the same as the Commodore Amiga where it is a simple comparator. It seemed to detect missing clock cycles from the serial shifter that contains deserialised clock/data, but we did not know if any cycles could be missing, exactly what happened when this was detected, what other requirements of detection were (such as matching a direct value otherwise or matching an exact pattern), and so on.

We saw recurring patterns happen on the real thing, like first $A1 (4489) producing 14. This is impossible if it worked like we expected (just adjusting the shifter), since the pattern would be wildly different. We could have just produced known patterns for known conditions (probably 3 lines of code) but the point is getting 100% perfect emulation.

Basically we needed the exact algorithm that is used. We did not see how the address mark values are skewed by the AM (or which ones are detected quite possibly not just C2 and A1), and were sure some protections rely heavily on this undocumented behaviour. Since it is very hard to guess unless they had docs on the AM, game authors likely played around with the FDC and found out what it could produce for different values, but we preferred not to make specific cases. Certainly the hardware itself is generic and uses a simple algorithm, there was just way too many variables to consider for an educated guess... For all we knew, it may see a bigger window than the DSR (shifter), maybe it saw upcoming data, it may mark off bits or not, basically anything could happen....

What the datasheets tell us

The datasheets are okay, but it is still a mystery why the above mentioned values are output by the FDC. At least now it is clear that it is exact matches, and the results are probably just the data bits somehow skewed, without the clock bits. We will have to ask around for more information, maybe some application/design notes regarding this device are available.

Thinking aloud

Without clock cycles the sync is $A1, which is 1010 0001 in binary. From that, 101 can be read as 14 if it is 0001 0100, and the zero can come from the lead 0s. Once this is output, 3 bits are missing to complete $A1 which are the 3 leading 0s. But this could be purely random, and we were just unlucky to find it very deterministic.

In summary, we now have a valid explanation, but we still do not know why it happens at that bit position, (if it really does, if not somewhat random), and not someplace else. More tests are needed at some point, but this can be amended later.