Atari ST Disk Images + FDC Implementation Notes

24 November 2004

Updated WinSTon and Atari ST IPF Images

If you did not realise yet, yes, we are using IPF images of original disks for testing, hence the reference to Copylock ST in a previous WIP update.

Since we started the FDC emulation, the updated WinSTon has only been able to run IPF‘s. There is no point changing anything else until everything is fully working since ST, MSA and other routines will have to be changed too. Once everything else is complete, we will add facilities to the IPF library (which should perhaps be renamed to something that more reflects its operation as a virtual mastering device and now an FDC emulator) as to generate disk signals from sector-based images so the FDC emulator can read the data as real disks.

When this is done, the FDC emulator part of the library will be open to any source of input. It does not rely on any kind of IPF support by design. As long as we feed it with proper disk signals (meaning the hardware interface signals as well as the generated and properly encoded disk data) the FDC emulator part runs completely independently from the IPF services. It is just more convenient to have only one library. Technically speaking, the FDC emulator provides an interface for call-backs on the host emulator whenever new track data is needed for this very purpose. It does not use any IPF services, unless the host emulator wants to use them to supply the data needed for the FDC. Therefore any kind of disk format can be hooked up, after some conversion.

The conversion itself is not trivial to implement, so we will add it to the library as a new service when we have time. After that WinSTon should be changed so whenever a disk is inserted or removed, the FDC emulator is informed as well as add real file support for the track change call-back for the various formats.

FDC Emulator Implementation Notes

The FDC emulator is designed to have a serialiseable state so all the data it uses is within the public structures. They contain many internal definitions that shouldn’t be touched; only the fields that are really input/output variables and state information will be documented in the developer manual. Changing anything else will surely crash the FDC emulator sooner or later.

This is done on purpose, its use is completely different from the IPF services.

The IPF library is very robust. You simply cannot crash it with anything you can possibly send it. One of the reasons is that the structures available to a third party are just very small subsets of their originals for convenience and safety. They all represent costly operations, so the cost of marshalling the data forth and back is minimal.

This is not the case with the FDC emulator. It is an emulator engine that is potentially called hundreds of times by just one emulation frame to keep tight synchronization with the host emulator. Safety is not a concern, but speed certainly is. The only point where values are safety checked (in fact anything that should not be accessed by a host emulator), is the initialisation of the FDC engine where they are cleared. After that you either only change what you are allowed/required to, or it will crash in remarkable ways.

This different approach makes sense for the FDC emulator. While we could keep every internal data and state safely locked away from the host data, marshalling might cost more than the time the emulator finishes its duty in an update call and this data would have to be imported/exported anyway later if state persistance (save/restore) is needed.