Jump to content
IGNORED

RespeQt general discussion


Joey Z

Recommended Posts

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.

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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:

 

post-29824-0-59797200-1454267470_thumb.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

Link to comment
Share on other sites

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:

 

post-29824-0-58706500-1454665548_thumb.jpg

 

Any idea? Is PurgeComm() not working as expected?

Edited by TheMontezuma
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

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
Link to comment
Share on other sites

  • 3 weeks later...

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 by TheMontezuma
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...