Jump to content

Photo

RespeQt general discussion

questions bug reports feature requests help

222 replies to this topic

#51 Kyle22 ONLINE  

Kyle22

    River Patroller

  • 4,023 posts
  • Call my BBS! telnet://broadway1.lorexddns.net
  • Location:McKees Rocks (Pittsburgh), PA

Posted Mon Jan 25, 2016 12:40 AM

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....ies.htm#FT_PROG

 

 

If there is enough interest, I may do a tutorial and make templates.



#52 DrVenkman OFFLINE  

DrVenkman

    River Patroller

  • 3,960 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Mon Jan 25, 2016 7:04 PM

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.dropboxus...espeQt r2.9.zip



#53 lemiel OFFLINE  

lemiel

    Moonsweeper

  • 279 posts
  • Location:Tychy, Poland

Posted Thu Jan 28, 2016 5:38 AM

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.

#54 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sat Jan 30, 2016 1:50 PM

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.dropboxus...espeQt r2.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 ;).



#55 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sun Jan 31, 2016 1:50 PM

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:

 

handshake.JPG

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



#56 DrVenkman OFFLINE  

DrVenkman

    River Patroller

  • 3,960 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Sun Jan 31, 2016 3:29 PM

I'll build a new binary for OS X from the Master branch tonight and post a link to it in my Dropbox again. 



#57 DrVenkman OFFLINE  

DrVenkman

    River Patroller

  • 3,960 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Sun Jan 31, 2016 5:21 PM

Okay, new OS X binary is here.

 

https://dl.dropboxus...peQt-latest.zip



#58 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sun Jan 31, 2016 5:27 PM

Thanks :)



#59 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Fri Feb 5, 2016 3:36 AM

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.

Attached File  test.atr   90.02KB   179 downloads

 

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?


Edited by TheMontezuma, Fri Feb 5, 2016 3:50 AM.


#60 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 876 posts
  • Location:Hoffman Estates, IL

Posted Fri Feb 5, 2016 7:19 PM

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 by Joey Z, Fri Feb 5, 2016 7:25 PM.


#61 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sat Feb 6, 2016 6:08 AM

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.

#62 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sat Feb 6, 2016 12:35 PM

BTW
The test (and the screenshot) was made with RespeQt rc2, downloaded as a Windows binary from the github.

#63 Smokeless Joe OFFLINE  

Smokeless Joe

    Moonsweeper

  • 289 posts
  • Location:Seattle, WA

Posted Sat Feb 6, 2016 5:08 PM

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!



#64 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sun Feb 7, 2016 4:58 AM

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.

#65 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 876 posts
  • Location:Hoffman Estates, IL

Posted Mon Feb 8, 2016 12:23 AM

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.



#66 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Mon Feb 8, 2016 2:14 AM

Don't worry Joey, I'll take care. Just wanted to spread this information to the community.

#67 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 876 posts
  • Location:Hoffman Estates, IL

Posted Mon Feb 8, 2016 2:36 AM

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.

attachicon.giftest.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:

 

attachicon.gifrespeqt2.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 by Joey Z, Mon Feb 8, 2016 2:41 AM.


#68 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Mon Feb 8, 2016 5:02 AM

FTDI

#69 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Wed Feb 24, 2016 6:33 AM

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*:

Attached File  RespeQt-r2.X.zip   9.06MB   159 downloads

 

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 by TheMontezuma, Wed Mar 9, 2016 7:28 AM.


#70 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Tue Mar 8, 2016 2:48 AM

FYI:

 

http://www.abbuc.de/....php?f=7&t=8808



#71 greblus OFFLINE  

greblus

    Moonsweeper

  • 270 posts

Posted Tue Mar 8, 2016 4:45 AM

It looks that Ray forgot to release the sourcecode. Hopefully he'll do it later on.



#72 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 14,494 posts
  • Location:United Kingdom

Posted Tue Mar 8, 2016 5:37 AM

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).

#73 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Tue Mar 8, 2016 5:55 AM

There is more: https://sourceforge....-edition/files/

 



#74 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 14,494 posts
  • Location:United Kingdom

Posted Tue Mar 8, 2016 6:49 AM

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.

#75 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 674 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Tue Mar 8, 2016 7:23 AM

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).





Reply to this topic



  



Also tagged with one or more of these keywords: questions, bug reports, feature requests, help

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users