Kyle22 Posted January 25, 2016 Share Posted January 25, 2016 Here is a link for the FTDI software tool that may be used to replace the VID/PID of any damaged FTDI based SIO2PC devices. It is from FTDI, so it's legit, and there is no need to visit other (questionable) websites. FT_Prog: http://www.ftdichip.com/Support/Utilities.htm#FT_PROG If there is enough interest, I may do a tutorial and make templates. 1 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted January 26, 2016 Share Posted January 26, 2016 For those with Macs interested in the latest and greatest, I've built a new binary from the Master branch on Git. I can confirm that this build does work just fine under OS X 10.11 'El Capitan'. The link is to the compressed binary in my Public Dropbox folder. To distinguish it from prior releases and versions, I called it "r2.9" on the basis that whenever Joey Z. makes a new official release, that would be r3. Anyway, here it is if anyone wants to try it: https://dl.dropboxusercontent.com/u/2197738/RespeQt%20r2.9.zip 1 Quote Link to comment Share on other sites More sharing options...
lemiel Posted January 28, 2016 Share Posted January 28, 2016 With new Ape there is virtual com in driver for Atarimax SIO2USB but I did not have time to test it. And of course it is Windows only. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted January 30, 2016 Share Posted January 30, 2016 For those with Macs interested in the latest and greatest, I've built a new binary from the Master branch on Git. I can confirm that this build does work just fine under OS X 10.11 'El Capitan'. The link is to the compressed binary in my Public Dropbox folder. To distinguish it from prior releases and versions, I called it "r2.9" on the basis that whenever Joey Z. makes a new official release, that would be r3. Anyway, here it is if anyone wants to try it: https://dl.dropboxusercontent.com/u/2197738/RespeQt%20r2.9.zip Thank you very much for compiling this software. Yesterday with help of my colleague (a MAC owner) I was able to test bluetooth communication (SIO2BT) between MAC and ATARI. We loaded a game , however communication was slower than on Windows. I need to take a closer look at the timing (and delays). In the mean time I saw a bug report on the github from our old friend, who seems to be interested in the RespeQt development . Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted January 31, 2016 Share Posted January 31, 2016 The master branch on the Github was updated. Beside "SOFTWARE" handshaking for Bleutooth (19200 only), the "NONE" handshaking from atari8warez is back (since it supports HI-SPEED). I also implemented the "NONE" handshaking for Linux/Mac and provided a small bug fix for all of the above. Playing with RespeQt under Ubuntu (on the i3 machine) and SOFTWARE handshake with no write delay, I realized that from time to time the communication gets stuck. Looking with the logic analyzer I discovered the reason. With the hardware handshake (RI/DSR/CTS), after reading the command frame, RespeQt waits for the command line to go off, before sending ACK/NACK. It takes 0.5ms: With "SOFTWARE" and "NONE" handshake methods, RespeQt was sending ACK just after the command frame was read. It didn't hurt with Bluetooth (because of the BT delays). Also under Windows (with a wired SIO2PC/USB cable) the ACK byte usually arrives at ATARI when the command line is already OFF. However Linux seems to be much faster and the ACK byte was sometimes already sent out, while the command line was still on. In this case this byte was lost, because the ATARI was not yet reading from DATA IN. The sleep (0,5ms) helped The restriction of the "NONE" handshake is, that it should not be used in daisy chain with other SIO devices, since any byte on the DATA OUT is processed as it would the first byte of a command frame (without any de-sync). On the other hand it supports HINDEX=0 (tested under Windows and Ubuntu). "SOFTWARE" handshaking supports only 19200, however the command frame recognition is more intelligent (with de-sync). Have fun Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted January 31, 2016 Share Posted January 31, 2016 I'll build a new binary for OS X from the Master branch tonight and post a link to it in my Dropbox again. Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted January 31, 2016 Share Posted January 31, 2016 Okay, new OS X binary is here. https://dl.dropboxusercontent.com/u/2197738/RespeQt-latest.zip 1 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted January 31, 2016 Share Posted January 31, 2016 Thanks Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 5, 2016 Share Posted February 5, 2016 (edited) I have discovered an interesting bug (tested under Windows). First some background inforamtion: Atari8warez raised an issue (https://github.com/jzatarski/RespeQt/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. test.atr 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 ATARI2) 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 ATARI4) 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 February 5, 2016 by TheMontezuma Quote Link to comment Share on other sites More sharing options...
Joey Z Posted February 6, 2016 Author Share Posted February 6, 2016 (edited) I have discovered an interesting bug (tested under Windows). Have you tried with older versions of RespeQt? It would help us narrow down the issue if we can prove whether it was a preexisting bug from prior to the recent BT updates, or if it was caused by the BT updates. I don't have a windows box setup here, but I suppose I should give it a try on linux and see if the bug takes effect there as well. Also, we should check to see if this bug is absent in the commit without 'NONE' handshaking, and then present again in the commit that added it back. Edited February 6, 2016 by Joey Z Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 6, 2016 Share Posted February 6, 2016 Hi Joey, the bug is related only to the hardware handshake. For "NONE" and for "SOFTWARE" handshake such behaviour is expected. That's why my recommendation not to use these handshake methods with others SIO devices in a daisy chain. As for the hardware handshake, this bug was probably there from the very beginning. I think that we only clear the serial port input buffer, but we don't clear memory buffers. The code uses high level API to read data (like for reading from a file), so we would need to move the file pointer to the "end of the file", before we read a command frame. I will not be able to test anything until 15.2, but of course I'm interested in any findings. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 6, 2016 Share Posted February 6, 2016 BTW The test (and the screenshot) was made with RespeQt rc2, downloaded as a Windows binary from the github. Quote Link to comment Share on other sites More sharing options...
Smokeless Joe Posted February 6, 2016 Share Posted February 6, 2016 I'm really new to RespeQt. When configuring the serial port, what's the difference between the various Handshake methods? Trial and error reveals that some work and some don't, but I'd like to understand it a little better than that. Thanks! Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 7, 2016 Share Posted February 7, 2016 The SIO bus uses 3 lines: - data in - data out - command line These lines are mapped to the RS232 signals. There are 3 types of the SIO2PC cables, where the only difference between them is the mapping between "command line" and RS232 lines: - RI - DSR - CTS Depending on your SIO2PC adapter, you should one of those settings. If your SIO2PC adapter does not support hardware handshake (has only RxD and TxD lines), you may use "none" or "software" handshake. I recommend the "none" handshake for wired connections and "software" handshake for bluetooth connections. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted February 8, 2016 Author Share Posted February 8, 2016 Hi Joey, the bug is related only to the hardware handshake. For "NONE" and for "SOFTWARE" handshake such behaviour is expected. That's why my recommendation not to use these handshake methods with others SIO devices in a daisy chain. As for the hardware handshake, this bug was probably there from the very beginning. I think that we only clear the serial port input buffer, but we don't clear memory buffers. The code uses high level API to read data (like for reading from a file), so we would need to move the file pointer to the "end of the file", before we read a command frame. I will not be able to test anything until 15.2, but of course I'm interested in any findings. OK, but we still have not confirmed the existence of the bug within linux? The procedure for testing this is what, to write data to a real drive? Unfortunately, I cannot test this then. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 8, 2016 Share Posted February 8, 2016 Don't worry Joey, I'll take care. Just wanted to spread this information to the community. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted February 8, 2016 Author Share Posted February 8, 2016 (edited) I have discovered an interesting bug (tested under Windows). First some background inforamtion: Atari8warez raised an issue (https://github.com/jzatarski/RespeQt/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. test.atr 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: respeqt2.jpg Any idea? Is PurgeComm() not working as expected? TheMontezuma, I may have an idea of what is happening. Please make a call to GetCommModemStatus right before the call to PurgeComm, and print the value that it gives you to the debug log. The windows serial routines are not waiting for the handshaking line to go on like the linux version, instead it is waiting for it to change without ever checking the absolute state to make sure that it is actually in the state we are waiting for. I suspect somehow we enter readCommandFrame while the COMMAND line is still asserted, and then wait for it to change, at which point it it goes inactive. The other possibility is that somehow the serial adapter you are using is holding a whole 5 bytes in it's own buffer before they are relayed to the computer, and thus not cleared by PurgeComm. What serial adapter are you using? Edited February 8, 2016 by Joey Z Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 8, 2016 Share Posted February 8, 2016 FTDI Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 24, 2016 Share Posted February 24, 2016 (edited) So I created a PULL request for a bugfix to the Github. Joey was right, Windows triggers events on every state change of the command line (from ON to OFF, too). It helped to add a check for the current command line state and to process data (a command frame) only if the command line is active. If you like you can test it*: RespeQt-r2.X.zip To summarize the status: 1) Using RespeQt with a SIO2PC/USB cable with RI/RTS/CTS handshake under Windows is safe now (it was already safe under Linux/Mac and the bugfix applies only to Windows) 2) Using "NONE" and "SOFTWARE (SIO2BT)" handshake is fully safe only with a 1:1 connection (no other devices on the SIO bus). This is independent of the OS (Windows/Linux/Mac) and it shall be considered as a constraint, not as a bug. Reading from the external SIO device is safe and writing to the external SIO device may cause RespeQt to wrongly interpret data frame as a valid command frame, which would be executed. RespeQt works with a RAMDISK and does not modify a physical ATR file (in case of a format command), so you can always rescue your damaged ATR to the state it was saved last time. Having in mind that the bug existed from the very beginning of the AspeQT project (and nobody complained) means that the probability of the problem occurrence is not that high ------ * edited on 9.3.2016: I replaced the archive, because there was one file missing, which is required to run the RespeQt on the Windows machine without the Qt development environment. Edited March 9, 2016 by TheMontezuma 1 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted March 8, 2016 Share Posted March 8, 2016 FYI: http://www.abbuc.de/community/forum/viewtopic.php?f=7&t=8808 1 Quote Link to comment Share on other sites More sharing options...
greblus Posted March 8, 2016 Share Posted March 8, 2016 It looks that Ray forgot to release the sourcecode. Hopefully he'll do it later on. 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 8, 2016 Share Posted March 8, 2016 Is it really needed? I see few changes that might sensibly be integrated into other versions (such as dropping support for drive # 15 just because SDX arbitrarily defaults to using drive O: for a RAMdisk). Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted March 8, 2016 Share Posted March 8, 2016 There is more: https://sourceforge.net/projects/aspeqt-a8w-edition/files/ Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 8, 2016 Share Posted March 8, 2016 Thanks. So is the objective to port all of that into the open-source version rather than reimplementing things in RespeQt? I understand from a prior announcement that source code is only available to people who have purchased SIO2PC hardware, and then upon written request. Not sure if that policy has silently changed. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted March 8, 2016 Share Posted March 8, 2016 So is the objective to port all of that into the open-source version rather than reimplementing things in RespeQt? Of course I wish AspeQt would remain open source. Every branch (AspeQt, AspeQt A8W, RespeQt, etc.) could benefit of the improvements from other branches. At the end we will end up in several versions with various functionality/bugs, etc. For example I like the idea of the writable folder images and it would be much easier to port the source code to the RespeQt, rather to reimplemented it. On the other hand I'm working on adding PCLINK support to RespeQt (providing similar functionality for Sparta Dos users). 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.