I have discovered an interesting bug (tested under Windows).
First some background inforamtion:
Atari8warez raised an issue (https://github.com/j...speQt/issues/21) about the "SOFTWARE" handshake (lack of HI-SPEED support).
I provided a solution and documented my changes (see post #55) in a Github.
Atari8warez was not happy about my comment saying that "SOFTWARE" and "NONE" handshakes should better not be used with other SIO devices on the bus (in a daisy chain).
He argued that his "NONE" hanshake works perfectly with other SIO devices and he has never seen any problems.
So I created an ATR file with the ATARI DOS 2.0 file system, containing a single file, which I named COPYME.BIN.
The content of the file is: $32 $21 $00 $00 $53
(a valid command frame, which ATARI could send to a D2 floppy to format a disk)
I defined the following scenario:
1) Connect a real floppy (as D1) to your ATARI
2) Connect a RespeQt/AspeQt emulation to your ATARI and mount the test.atr as D2
3) Insert a DOS (2.0 or 2.5) diskette into the real floppy and power on the ATARI
4) Try to copy with DOS a file COPYME.BIN from D2 to D1
What happens is:
1) The Atari sends a command frame to (emulated) D2 to read data, which is answered with a DATA FRAME (containing COPYME.BIN)
2) The Atari sends a command frame to (real) D1 to write data, followed by a DATA frame (containing COPYME.BIN)
3) DATA frame sent from ATARI (mentioned above) is received at the AspeQt/RespeQt, which is (after point 1) awaiting the next command frame.
4) Since "SOFTWARE" and "NONE" handhakes do not rely on a "COMMAND LINE", data in a buffer is interpreted as a command frame and executed (emulated disk is formatted and the fictive "command frame" is acknowledged possibly breaking the communication with D1 (writing data to a real disk may fail).
I don't want to discuss or comment the answer from Atari8warez:
"But what does that prove?, I've already said that it is possible, the real question is how likely something like this will happen?"
However this scenario should never happen with a hardware handshake (RI/DSR/CTS).
After detecting that the command line was raised, the serial port input buffer is cleared (the content of the COPYME.BIN).
So I was very surprised when I saw the following:
Any idea? Is PurgeComm() not working as expected?
Edited by TheMontezuma, Fri Feb 5, 2016 3:50 AM.