Performance issue with Software handshaking, using wired SIO2PC
atari8warez opened this issue · comments
When an .xex file is loaded with "Use high-speed loader" option selected, and with SOFTWARE Handshaking ON, Write Delay 0, using a wired SIO2PC, the loader performance suffers. In fact the speed is actually much lower compared to when "Use high-speed loader" option is de-selected.
Which Atari OS is used does not matter.
The test has been done on Marcin's BT enhanced AspeQt v0.8.8, but also applies to Respeqt unless the problem has already been found and dealt with.
Thanks for reporting the issue. I could reproduce it with RespeQt.
A problem occurs only with the HI-SPEED SIO procedures executed in the ATARI and is not related only to the xex files. It looks like that my Software Handshaking method generally supports only the standard SIO Speed 19200 (which is fine for Bluetooth, but confusing if the user tries higher speeds with the cable).
I will take a look at the code to propose a solution for this problem.
No, it's not an xex issue, it is caused by the new handshaking code, it just happened while loading an xex. it also causes some other problems with the this particular xex itself (Nemesis demo). The demo locks up at the end of the load and never starts if one is patient enough to wait till the end
And have you ever written to a real drive?
Am 03.02.2016 um 11:15 schrieb atari8warez:
Marcin, I noticed that you decided to bring the AspeQt handshake
method NONE back into life because it supports Hi-Speed I/O. But I
also noticed your statement which claims: "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)"
This is not true, there are no such restrictions and any SIO device
can co-exist perfectly with AspeQt when the latter is using NONE
handshaking method. You can verify that by copying a file from a real
drive to an AspeQt virtual drive, and then compare the copy with the
original. You will see that the copy will proceed without any problems
and the source and target files will be exactly the same, and that no
byte is lost in the process. I have been using NONE handshake method
for a while and never experienced any problems daisy chaining devices.
And when you think about the SIO protocol in detail, you will see that
it makes perfect sense.—
Reply to this email directly or view it on GitHub
#21 (comment).
Somehow my original message disappeared, so this is what I wrote before:
"Marcin, I noticed that you decided to bring the AspeQt handshake method NONE back into life because it supports Hi-Speed I/O. But I also noticed your statement which claims: "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)". This is not true, there are no such restrictions and any SIO device can co-exist perfectly with AspeQt when the latter is using NONE handshaking method......"
So even though it is theoretically possible for AspeQt to misinterpret data flying in between real drives and the Atari, the chances of AspeQt receiving a random, but perfect command frame, complete with it's correct checksum is next to nill, I would probably get hit by a lightening first before that ever happens. So in practical terms, AspeQt with handshake set to NONE can peacefully co-exist with other real drives in the SIO chain ;-)
You asked if I tried "writing to a real drive", yes I did, and without problems I might add, and here's a video demo of that experience: https://youtu.be/JUaGetGo3Ik
If you watch it to the end you'll see that writing to a 1050 in such a mixed environment works just fine.
Ray, you seem to be very sensitive about the wording. I should probably say that "NONE" hanshake is more straightforward or less sophisticated that the "Software" handshake. And it does not mean worse. It works very nicely with highspeed (that's why it is back in RespeQt and I even extended the Linux version to support this approach).
However the issue with a possible random, but perfect command frame in the data frame sent to a real floppy exists. I do not wish you to get hit by a lightening, but try the following scenario:
- Connect a real floppy (as D1) to your ATARI
- Connect a RespeQt/AspeQt emulation to your ATARI and mount the following ATR as D2:
https://drive.google.com/file/d/0B3-191R-U_S1UEpxdjFHT0ZOQnM/view?usp=sharing - Insert a DOS (2.0 or 2.5) diskette into the real floppy and power on the ATARI
- Try to copy with DOS a file COPYME.BIN from D2 to D1
By the way - this way I discovered a bug in the hardware handshake (the problem happens now even if you select RI/DSR/CTS handshake). But when the bug is fixed, only "NONE" and "SOFTWARE" handshake will stay "vulnerable".
I would not like to continue the discussion here - if you like we can discuss further in a forum.
The reported bug is fixed with re-integration of the "NONE" hanshake.
Marcin, I don't need to run that test, i just looked at the COPYME.BIN file and it contains a format command to D2: (32 21 00 00 53), and indeed if i run that copy it may format D2: (not always, but will format it depending on when the copy is run). But what does that prove?, I've already said that it is possible, the real question is how likely something like this will happen? Luckily math comes to our help, there are 1,099,511,627,776 possible values we can represent with 40 bits (5 hex digits) and the likelihood of this particular combination of bits to occur in a data frame is 1 out of 1,099,...... (can't even read the number... lol)
So, I am not sensitive with words, I am only concerned that such a small odd seems to deserve this much attention. I am not a perfectionist, on the contrary I like to think that I am more practical, and sometimes "simple" is better than "sophisticated". :-)
I tried your test anyway......
Ray, with all respect to your work on the AspeQt project, I do not want to continue this discussion.
I consider the originally reported issue as fixed, since a user has a choice now:
- the "NONE" handshake supports NORMAL and HI-SPEED
- the "SOFTWARE" hanshake supports NORMAL-SPEED only
The simple fact here, Ray, is that it is possible for something to happen which could destroy data as a direct result of the operation of RespeQt. Whether it is likely or not does not matter. All it takes is one guy to say 'Your software made me lose my tax data!' (because maybe there are still people who do their taxes on their 8 bit) and now we've got an angry user on our hands. Best to mention in the manual, that there is this possibility, and that it's possible for data loss to conceivably occur due to this. That way, if someone has an issue, you can point to that part in the manual and say, 'Yeah, we said that could happen.'
It's about protecting against liability, more than anything else, I suppose. Not so much legally speaking (I doubt anyone would try to sue us) but from angry people who are, in fact, sort of justified.
I agree it should be mentioned that there is possibility for data loss/corruption however small it is.
Wow Marcin, you have one evil! COPYME.BIN file, it even breaks the hardware handshaking :-)
But one correction is in order for your latest post at Atariage. You originally said, and I quote directly from your original comment: "The restriction of the "NONE" handshake is, that it should not be used in daisy chain with other SIO devices". You never said "SOFTWARE" and "NONE" ...... ", so please let's be accurate on what we said. Actually you should now say "SOFTWARE, NONE, and Hardware handshakings could all break communications given the right circumstances.
By the way, the "bug" or the problem with formatting D2: by copying the file COPYME.BIN goes all the way back to version v0.6 of AspeQt.