Here is a description of the DolphinDOS protocol, as implemented in Open ROMs, from the perspective of IEC bus controller. It is reverse engineered by observing IEC logs generated by VICE emulator.
For legal reasons, no disassembling of the DolphinDOS ROMs was performed (only IEC transmission logs and hardware register usage was checked, using specially prepared emulator). Thus, the information provided here might be incomplete or not fully accurate!
None, I’m afraid - AFAIK this is the first attempt to document the protocol. Please make sure you are familiar with the IEC protocol in general, I highly recommend studying a guide by Michael Steil, available here: https://www.pagetable.com/?p=1135.
--enable-debug, either from SVN or release >= 3.4. Additionally, you will need the logs from CIA access - I have added mine in c64cia.c file - you’ll need to know access to $DD01 (CIA2 port B - for data transfer), $DD03 (it’s direction register), and $DD0D (CIA2 ICR - interrupt control register).Timing is no more strict than standard IEC protocol - I have checked using VICE monitor (added watches), that DolphinDOS ROM does not touch VIC-II registers to disable sprites (SPENA - $D015) or observe incoming badlines (RASTER - $D012, SCROLY - $D011), one can observe that it does not blank the screen either. It’s enoguh to just mask the interrupts, like with a standard IEC protocol.
Detection happens after OPEN (0xF0 - 0xFF) or REOPEN (0x60 - 0x6F) IEC command is sent from the controller and is very simple.
The CIA2 port B has to be set for reading (interrupts for the port are disabled by writing $7F to $DD0D). The controller constantly reads (not sure if there is a countdown or timeout in the original DolphinDOS ROM, countdown started from $20 seems more than enough) the CIA2 interrupt control and port B registers; when ICR reads $10 (again - not sure if just the bit is checked, or the whole register), bus controller assumes the receiver talks the DolphinDOS protocol.
Note: detection only works under ATN, should be performed before the controller performs a turnover to listener!
IEC commands are sent normally, with the additional protocol detection flow after some of them (see above).
Turnover (both to listener and to back to talker) is performed as usual.
Byte transmission reuses quite some part of the standard IEC byte transmission mechanism. At the moment where EOI has been possibly signalled, controller using the standard protocol pulls CLK to indicate invalid DATA - but when DolphinDOS is in use, the C64 instead puts the byte in CIA2 port B (has to be set for output) and pulls the CLK to indicate data is now valid. Afterwards, the reader can pull DATA to indicate it’s busy - everything continues the standard way.
Byte reception works almost exactly like with the original IEC protocol, with one notable exception, saving immense amount of time: just after checking for EOI, when talker already pulled CLK line, the C64 retrieves a byte by simply reading CIA2 port B register (after protocol detection flow it’s direction should already be set accordingly). Afterwards, C64 acknowledges the byte by pulling DATA line - like with a standard IEC communication flow.