updated documentation, added initial DolphinDOS protocol description

doc/Protocol-JiffyDOS.md

@@ -3,7 +3,7 @@
 
 Here is a description of the JiffyDOS protocol, as implemented in Open ROMs, from the perspective of IEC bus controller. It is partially based on the documentation found on the internet, and partially reverse engineered by observing IEC logs generated by VICE emulator.
 
-For legal reasons, no disassembling of the JiffyDOS ROMs was performed (only IEC transmission logs were checked), I also refrained myself from checking non-commercial 6502 JiffyDOS implementations (as they might be based on disassembled ROMs) - this, unfortunately, ruled out most of the documentation from www.nlq.de page, as it mostly shows the commented original source code.
+For legal reasons, no disassembling of the JiffyDOS ROMs was performed (only IEC transmission logs were checked), I also refrained myself from checking non-commercial 6502 JiffyDOS implementations (as they might be based on disassembled ROMs) - this, unfortunately, ruled out most of the documentation from www.nlq.de page, as it mostly shows the commented original source code. Thus, the information provided here might be incomplete or not fully accurate!
 
 ## Documents, samples
 
@@ -11,6 +11,8 @@ For legal reasons, no disassembling of the JiffyDOS ROMs was performed (only IEC
 - [2] SD2IEC source code - see https://github.com/rkrajnc/sd2iec/blob/master/src/ especially files: [lpc17xx/fastloader-ll.c](https://github.com/rkrajnc/sd2iec/blob/master/src/lpc17xx/fastloader-ll.c), [avr/fastloader-ll.S](https://github.com/rkrajnc/sd2iec/blob/master/src/avr/fastloader-ll.S) and [iec.c](https://github.com/rkrajnc/sd2iec/blob/master/src/iec.c)
 - [3] Fast loader idea and sample code - https://www.pagetable.com/?p=568
 
+Also 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.
+
 ## Tools
 
 - for experimentation and debugging VICE emulator was used - you'll need a custom compilation with `--enable-debug`, either from SVN or release >= 3.4
@@ -19,8 +21,8 @@ For legal reasons, no disassembling of the JiffyDOS ROMs was performed (only IEC
 
 When sending/receiving a byte, the JiffyDOS protocol timing is much more strict than the standard IEC. It is not enough to mask the interrupts - one has to make sure nothing will steal the CPU cycles. There are two ways to achieve this:
 
-- disable the screen completely for the duration of transmission; since VIC-II checks the bit in SCROLY register once per frame only, the code has to wait till the beginning of the next frame
-- disable the sprites for the duration of transmission and synchronize with VIC-II RASTER/SCROLY registers to avoid badlines. Current implementation simply avoids transmission two lines before the badline; I suspect it can be reduced to one line, but it would need even more careful timing and would definitely mean inlining some subroutines - probably not worth the effort and increased code size
+- disable the screen completely for the duration of transmission; since VIC-II checks the bit in `SCROLY` register once per frame only, the code has to wait till the beginning of the next frame
+- disable the sprites for the duration of transmission and synchronize with VIC-II `RASTER` ($D012) / `SCROLY` ($D011) registers to avoid badlines. Current implementation simply avoids transmission two lines before the badline; I suspect it can be reduced to one line, but it would need even more careful timing and would definitely mean inlining some subroutines - probably not worth the effort and increased code size
 
 Timing details are omitted by purpose - they are already described in [2], besides most of the time it was determined by observing VICE IEC logs and (for example) adding NOPs when necessary. The protocool is not cycle-exact, so our implementation probably behaves slightly differently than the original one.
 
@@ -33,7 +35,7 @@ Protocol detection happens when the IEC bus controller sends a command (under AT
 
 ## Sending a command
 
-IEC commands are sent from the normally (with the additional protocol detection flow before the last bit). Althought it would be enough to perform detection within the TALK and LISTEN commands only, the original JiffyDOS ROMs tries to detect it every time. Omitting the detection is definitely not safe (depending on the command, it migh even cause the communication with device to fail, at least the 1541 JiffyDOS ROM shows such behavior). Moreover, it seems that only TALK/LISTEN commands cause the device to respond by pulling DATA; the controller side implementation has to be prepared for this.
+IEC commands are sent normally (with the additional protocol detection flow before the last bit). Althought it would be enough to perform detection within the TALK and LISTEN commands only, the original JiffyDOS ROMs tries to detect it every time. Omitting the detection is definitely not safe (depending on the command, it migh even cause the communication with device to fail, at least the 1541 JiffyDOS ROM shows such behavior). Moreover, it seems that only TALK/LISTEN commands cause the device to respond by pulling DATA; the controller side implementation has to be prepared for this.
 
 ## Turnover