updated documentation, added initial DolphinDOS protocol description

STATUS.md

@@ -52,16 +52,23 @@ The following ROM features are currently missing:
 | :-----------: | :------: | :------------------------------------------------: |
 | C64           | DONE     |                                                    |
 | C128          | DONE     |                                                    |
-| C65 / Mega65  | NOT DONE | code should be complete, but is not tested yet     |
+| Mega65        | NOT DONE | code should be complete, but is not tested yet     |
+
+## Screen
+
+| Driver        | Status   |  Remarks                                           |
+| :-----------: | :------: | :------------------------------------------------: |
+| VIC-II        | PARTIAL  | 80 chars in logical line support is very buggy     |
+| VDC 80 col.   | NOT DONE |                                                    |
 
 ## Tape storage (LOAD only!)
 
 | Driver        | Status   |  Remarks                                           |
 | :-----------: | :------: | :------------------------------------------------: |
-| normal        | PARITAL  | works, but needs improvements, no error correction |
-| turbo         | PARTIAL  | works, to do: use sync to calibrate read speed     |
+| normal        | PARITAL  | no error correction, no tape speed calibratrion    |
+| turbo         | PARTIAL  | up to 250 blocks, no tape speed calibratrion yet   |
 
-## IEC bus (disk drives, etc.)
+## IEC bus (disk drives, printers, some hard drives)
 
 | Driver        | Status   |  Remarks                                           |
 | :-----------: | :------: | :------------------------------------------------: |
@@ -69,13 +76,20 @@ The following ROM features are currently missing:
 | JiffyDOS      | DONE     |                                                    |
 | DolphinDOS    | PARTIAL  | for now only LOAD is accelerated                   |
 | CIA burst mod | NOT DONE |                                                    |
+| Mega65 burst  | NOT DONE | pure software implementation should be feasible    |
+
+## IEEE-488 bus (scientific equipment, PET era disk drives and printers)
+
+| Driver        | Status   |  Remarks                                           |
+| :-----------: | :------: | :------------------------------------------------: |
+| CBM cartridge | NOT DONE |                                                    |
 
 ## RS-232
 
 | Driver        | Status   |  Remarks                                           |
 | :-----------: | :------: | :------------------------------------------------: |
 | UP2400        | NOT DONE |                                                    |
-| UP9600        | NOT DONE | work in progress, not functional yet               |
+| UP9600        | NOT DONE | work started, not functional yet                   |
 | ACIA 6551     | NOT DONE |                                                    |
 
 

doc/Protocol-DolphinDOS.md

@@ -0,0 +1,42 @@
+
+# DolphinDOS fast protocol description
+
+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!
+
+## Documents, samples
+
+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.
+
+## 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. 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 information
+
+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.
+
+## Protocol detection
+
+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, countdoown 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!
+
+## Sending a command
+
+IEC commands are sent normally, with the additional protocol detection flow after some of them (see above).
+
+## Turnover
+
+Turnover (both to listener and to back to talker) is performed as usual.
+
+## Sending a byte
+
+XXX TODO
+
+## Receiving a byte
+
+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.

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