WDC1772 Type 3 Track Read

22 November 2004

Finished the complete implementation of the Type 3 track read command, and this gets Copylock ST (non-density based version) working! The problem games from the previous WIP update now also work.

We certainly did not expect any Copylock titles to work in the current state, mostly because they probably have very advanced encryption like on the Amiga, and when support for Copylock Amiga was added in UAE, it required tons of CPU core fixes. This is certainly a testament to how good an emulator WinSTon was. The success rate we now have for running games on it is pretty high.

Disk access with WinSTon and our new FDC emulation is now real. That is, real speed, real glitches and real errors(!). It is the same speed as our testbed ST, correct to about 1 microsecond, which is fairly accurate.

Atari emulators did not use real disk access - there is no point. The reason for that is that the FDC is a “black box” that takes commands, reports its status and gets/writes data according to its state. This approach works well for cracks, since they probably never asked for anything more complex then reading a block. The read block command is intercepted by the emulation core, you seek in the ST file to the correct position in memory, read 512 bytes and signal back the CPU that the command completed. Obviously moving 512 bytes of memory as “emulation” is extremely fast.

The new FDC core we have written is a complete cycle-exact emulator itself, it communicates with a host emulator through defined call-backs. The “CPU” (the WD1772) runs at 8 MHz, it has complete IO, data bus, address bus, interrupt and other capabilities, all now implemented. While not directly related, the disk drive(s) attached to the emulator are emulated as well as all signal lines so the FDC can control it, read line, selection, reading the disk surface, disk rotation, slight random changes and so on... The FDC core obviously does not have sound and video output, but otherwise it is a pretty much complete emulation engine in itself.

It is possible to make it faster by changing clock components. The easiest way is to change the calculation of how many clock cycles one disk revolution is. However, this is not a good a good idea because changing real speed causes incompatibility in some titles, like if one expects to fill a buffer with data in a certain amount of time, etc. Problems would also occur where sound or video synced to the disk access, this would likely mean missing a title screen and so on. In theory, software that relies on such timing is broken, however it works on the real hardware so it is better to keep it that way.

Of course, none of this means that WinSTon has suddenly become a slow emulator by any means. It is just slower.