WDC1772 Type Commands

15 November 2004

Implemented Type 4 (Forced Interrupt) FDC commands. Type 1..3 left to be done.

Started implementing Type 1 commands. Remember, this is a cycle exact FDC emulator. Developing some FDC commands could be made very easy by doing an “everything command in one step” approach to the implementation, but once it is cycle-exact and you start sharing results with other emulator components, things start to get... interesting.

Moved all the generic (that is, not Atari ST related) FDC emulation code to the IPF library since it is a complete emulator itself that exchanges data with a host emulator. The two can be updated independently now.

It is also a welcome change since the Atari ST emulator was difficult to debug in this configuration. The existing functionality of the FDC emulation parts in the IPF Library has now been tested. The ability to do this was only now made convenient by the transition to the IPF library.

In WinSTon, what is referred to as “FDC emulation” is actually two things mixed together that are quite independent in reality.

1. The DMAC chip. Since this is Atari emulator specific, the emulation code for the DMAC stays in WinSTon. It has been actually been rewritten from scratch since the original version was never designed to communicate with a “real” FDC. The file is still named “fdc.cpp”, but should really be named to “dmac.cpp” or similar.
2. The FDC emulation.. This was originally developed in WinSTon, but after reaching critical mass it could not be maintained there anymore, so disk drive and FDC emulation is abstracted completely into another entity, the IPF library. This library should perhaps be renamed to something that more reflects its operation as a virtual mastering device and now an FDC emulator.

The reasons for this are:

1. It could not be maintained in WinSTon after reaching critical mass. Also debugging was really needed as it is a complete emulator itself.

2. There are many systems using a generic FDC or one of its clones (NEC, SMC, Intel, and probably tons of other clones exist for NEC and WDC derived controllers). It is very hard to emulate once real data and cycle timing is properly involved and we are fairly positive this would scare a lot of people away from even trying to add a real disk system to their emulator.

Now that complete FDC emulation is available as a service from the library and only a few call-backs have to be supplied by the emulator, it is a trivial task to use, even for someone who is not really into hardware and the programming of it. Also, it could be scary to convert the sector dumps commonly available for emulators (not only for the ST, but pretty much any system) to proper disk signals, so that will be an available and simple to use service too.

3. It is inevitable that new features will be introduced to the FDC and signal converter components as they needed and/or improved. Therefore it would be foolish to have them compiled into every emulator as that would mean each emulator author would have to keep up with the latest libraries. This way they do not have to. Since the library is loaded dynamically, authors only need to be aware of changes if they are interested in them or any new services that are introduced. As a case in point, the library is still 100% API and binary compatible with the very first version ever produced, although it has had many vital changes during its lifetime.

Implemented all Type 1 commands, including every minor detail followed to the letter of the design documentation (minus the obvious mistakes and typos in the datasheets). Now even bizarre programming techniques should work as expected.

We then tested a few special cases on the real hardware where behaviour was questionable - this turned out to be a good idea. For example, what happens when the track register overflows or underflows? Not what anyone would think, overflow past 255 becomes 1, underflow past 0 becomes 254... This is clearly the result of an additive logic with carry implemented.

The only unimplemented part is the V flag (Verify) since that requires reading from the disk surface. For that, related routines must be implemented first.