Atari ST Disk System - Data Access & Timing

16 November 2004

Work has started on the actual data access (read/write) related framework. Some existing functionality was changed to make sure changes that may affect a data access in progress happen only at the exact FDC clock cycle where they should.

The emulation core always runs from the point of the last FDC clock cycle elapsed until a particular point - “now” (here on referred to as NOW). This point can be triggered by any access to the FDC, like reading / writing registers, changes on any of the related lines, as well as running regular update rounds like calling from the horizontal blanking time. This ensures that any internal processing of the FDC is complete up to the current cycle, and only then changes are made (if required) to ensure that the next update will run with the proper context changes if any.

Naturally, internal changes (like changes in the status register) are available at the NOW point, so they reflect the expected and exact values at any time when returning from the emulation core.

The processing is as follows:

• Running clock cycles since the last call, NOW, update context
• Running clock cycles since the last call, NOW, update context, reading a register, update context
• Running clock cycles since the last call, NOW, update context, writing a register, update context

...plus a few special emulator commands accessed with the same API, but not related.

Drive and select changes are indirectly linked to the FDC (well... on a WD1772 anyway as it does not have direct control over these). They occurred immediately when processing started, but in reality they should happen at the first update context (NOW) since that was the clock cycle in emulation time when the change happened. This drive / side context delay is taken care of now as well.

This is not normally a matter of interest (since you would not want to change drive side during an on-going read/write access...) but there are protections on the Amiga that do just this in order to prevent copying without specialised writing programs that create (for example) data that continues from one side to another.

A fun side effect is that the method that is probably used by a certain disk imaging program on the PC (i.e. changing drives once reading is triggered) would work on this emulator.