JoSch Posted July 30, 2016 Share Posted July 30, 2016 Yes, you get that, because I didn't push the change I made. In serialport-unix.cpp in methdo readRawFrame, line 618 there is the value 12,000. Append an zero, and you should be good. Most of the time anyway. The software handshake for SIO2BT works better for PCLINK. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 30, 2016 Share Posted July 30, 2016 (edited) Ok, I figured the changes weren't pushed yet. I'll try your suggestion. EDIT: Great. That got PCLINK working, albeit only at 1xSIO. Standard disk device access is good at 3x SIO, but encounters issues at higher speeds. Good progress, anyway. EDIT2: PCLink and standard disk access working across SIO2BT as well. Edited July 30, 2016 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
JoSch Posted July 30, 2016 Share Posted July 30, 2016 I suspect that something in PCLINK and OS X work against each other. The parameter you changed was some experiment, so I didn't see fit to push it to Github. But my build has this changed parameter in it. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 30, 2016 Share Posted July 30, 2016 Yes - understood. Unless the OS X FTDI drivers are inherently crippled, I guess there's no reason we shouldn't eventually see reliable divisor 0 operation, as with Windows. I don't claim to have any special expertise in the area under discussion, but since I've spent the past few weeks testing SIO drivers with the Windows build of RespeQt, I'll be glad to try and help in any way. Quote Link to comment Share on other sites More sharing options...
JoSch Posted July 30, 2016 Share Posted July 30, 2016 Me neither. But still it bugs me that it works so good under Windows and under OS X RespeQt is such pain. On the other hand, the software handshake works better than the hardware one. Since Montezuma gets in the fold, my hope he can figure it out. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 30, 2016 Share Posted July 30, 2016 The choice of handshake method (Software, which I only tried with SIO2BT so far under OS X, sticking with CTS on my SIO2PC) might offer some clues in itself, since it assumes no command line whatsoever and just analyses all data on the bus looking for valid command frames. So could this tell us that with CTS/DSR/RI handshake, asserting the command line is somehow being missed at higher speeds? I don't know... Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted July 31, 2016 Share Posted July 31, 2016 (edited) The choice of handshake method (Software, which I only tried with SIO2BT so far under OS X, sticking with CTS on my SIO2PC) might offer some clues in itself, since it assumes no command line whatsoever and just analyses all data on the bus looking for valid command frames. So could this tell us that with CTS/DSR/RI handshake, asserting the command line is somehow being missed at higher speeds? I don't know... The reason is simple. Serial port is opened in non blocking mode (O_NDELAY), so read() / write() calls come back immediately (even if a requested number of bytes was not yet read/written). A loop takes care to continue reading/writing, but it exits afer specifc time. I increased timeout values for Bluetooth (see readRawFrame() and writeRawFrame() in the source code). That's why you observed different behaviour with SIO2BT handshake. Now that I have a Mac at home, I will be able to do some measurements and come up with a new formula for timeout for OS X. Edited July 31, 2016 by TheMontezuma Quote Link to comment Share on other sites More sharing options...
JoSch Posted July 31, 2016 Share Posted July 31, 2016 (edited) The reason is simple. Serial port is opened in non blocking mode (O_NDELAY), so read() / write() calls come back immediately (even if a requested number of bytes was not yet read/written). A loop takes care to continue reading/writing, but it exits afer specifc time. I increased timeout values for Bluetooth (see readRawFrame() and writeRawFrame() in the source code). That's why you observed different behaviour with SIO2BT handshake. Now that I have a Mac at home, I will be able to do some measurements and come up with a new formula for timeout for OS X. But I need to use at least ten times (i.e. 5 times the BT value) the normal read timeout to get a somewhat reliable behaviour with a hardware handshake.BT software handshake is still more reliable than the hardware one with PCLINK. Edited July 31, 2016 by JoSch Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted August 5, 2016 Share Posted August 5, 2016 In the meantime I finally started adaptations to support reserved file names under Windows. I want to do it in the same way as Phaeron implemented it in Altirra (for example: creating a folder COM1 on the PCL1, will physically create a folder !COM1 in the host file system, however it will still be visible as COM1 to ATARI). This will allow to use the same PCLINK directory with Altirra and with a real ATARI Reserved names are Windows specific, but I wondered if it would make sense to apply the same logic for Linux and Mac for consisteny reasons? This way one could exchange file system archives, which would stay compatible between Windows/Linux/Mac users. Even sio2bsd tool could be easily updated to work in the same way. Existing (linux) backups containing files/folders named COM1, etc would still work, only new backups would look different. What do you think? Any opinions? Shall names like "COM1" be replaced with "!COM1" only under Windows or (for consistency) also under Linux/Mac ? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 5, 2016 Share Posted August 5, 2016 Do it the Altirra way if there's no reason not too. I always just avoided those few reserved names so didn't see it as a major problem. 2 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted August 18, 2016 Share Posted August 18, 2016 Shortly before my holidays I finished an update of the PCLINK, which now can handle Windows reserved file names. RespeQt-PCLINK3.zip I would be grateful for any feedback. I haven't created a PULL request in a Github yet, because the changes are not tested very well. If you are interested in the source code, here it is: https://github.com/TheMontezuma/RespeQt 3 Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted August 19, 2016 Share Posted August 19, 2016 Shortly before my holidays I finished an update of the PCLINK, which now can handle Windows reserved file names. RespeQt-PCLINK3.zip I would be grateful for any feedback. Windows reserved name seem to copied to the PCL: folder on the PC without any hesitations at all. I only tested for CON. 1 Quote Link to comment Share on other sites More sharing options...
tuf Posted August 23, 2016 Share Posted August 23, 2016 Anyone had complete success with this for the Mac yet (with PC-LINK)? Quote Link to comment Share on other sites More sharing options...
JoSch Posted August 23, 2016 Share Posted August 23, 2016 If you set handshake mode to SIO2BT (software handshake), it works reliably. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted September 2, 2016 Share Posted September 2, 2016 (edited) Yesterday I finally got time for more testing and implementing of (so far missing) handling for some use cases for reserved file names. It should behave now like in Altirra, so one can work with the Emulator with folders backed-up from a real ATARI. For simplicity and consistence, the same handling is applied under Win/Linux/Mac. RespeQt-PCLINK4.zip Edited September 2, 2016 by TheMontezuma 4 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 2, 2016 Share Posted September 2, 2016 Excellent - thank you. RespeQt's killer feature gets better and better. 2 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted September 2, 2016 Share Posted September 2, 2016 Many, many thanks TheMontezuma for sticking with this! 'PCLink' is a really key feature in my opinion and can completely transform how one uses the real hardware if a WIndows/Linux/Apple machine is sufficiently close by. 2 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted September 3, 2016 Share Posted September 3, 2016 The "reserved file names" feature was more tricky, than just integrating sio2bsd PCLINK code to RespeQt, since I had to understand the code from drac030 and the changes mustn't break any functionality. That's why it took a little bit more time, but now it should be safe to use all names that are allowed by Sparta Dos, independent of Windows restrictions 1 Quote Link to comment Share on other sites More sharing options...
Madi Posted September 15, 2016 Share Posted September 15, 2016 drac030 had already clarified the differences between the PCLink and the traditional Folder approach. As a summery, Atari DOS and compatibles "so far", can access images (R/W) inside PC folders with some success (might be clumsy, but works). On the other side, SpartaDos has difficulties access PC folders in AtariDOS FS way. Even more, accessing only 64/folder limits some of its strengths. As a casual user to SpartaDOS (because it is too complex and advanced for me), I have a feeling that RespeQt is (unintentionally) being gradually drifted towards SpartaDOS. The not so good is that users of Atari DOS/MyDOS and a like might find themselves "forced" to use SpartaDOS in order to enjoy the great PCLINK features or resort to the the traditional AspeQt (or Ray's AspeQt 1.01 which can handle folder R/W using AtariDOS as outlined by drac030). Is is possible to modify PCLINK so that RespeQt is able to work with Atari DOSs ? I am sure people like me who likes Menu driven Doses and simple command will enjoy this nice product. madi Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 15, 2016 Share Posted September 15, 2016 (edited) It's not really a question of drifting towards SpartaDOS. The fact is PCLINK originated on SDX and works well there because the highly modular kernel design allows FMS calls to be mapped to PCLINK functions pretty much 1:1, using a formal protocol in which there is no ambiguity (i.e. no need for the server to make best guesses about the purpose of a sector write originating from the client). As a SpartaDOS X user, I find RespeQt's PCLINK functionality to be superior to AspeQt's promised SDFS virtual drive read/write (or even read-only) support, not least because the PCLINK implementation actually exists. Regarding AspeQt virtual folder writing and ATARIDOS.SYS: I understood this was still impossible owing to the unexpected order of written sectors. Where is it written that this problem has been solved? Despite the fact PCLINK returns information in a format compatible with the SDX kernel drivers, I guess drivers could be written for other Disk Operating Systems, but the question is: who will write them? In any case - I guess you can't please all the people all the time. RespeQt could probably do with writeable DOS 2.x/MYDOS virtual folders at least (it's a reasonable request), but SDFS virtual folders are pretty much redundant since we already have PCLINK. Edited September 15, 2016 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
Madi Posted September 15, 2016 Share Posted September 15, 2016 It's not really a question of drifting towards SpartaDOS. The fact is PCLINK originated on SDX and works well there because the highly modular kernel design allows FMS calls to be mapped to PCLINK functions pretty much 1:1, using a formal protocol in which there is no ambiguity (i.e. no need for the server to make best guesses about the purpose of a sector write originating from the client). As a SpartaDOS X user, I find RespeQt's PCLINK functionality to be superior to AspeQt's promised SDFS virtual drive read/write (or even read-only) support, not least because the PCLINK implementation actually exists. Regarding AspeQt virtual folder writing and ATARIDOS.SYS: I understood this was still impossible owing to the unexpected order of written sectors. Where is it written that this problem has been solved? Thank you flashjazzcat for your prompt input. What you have illustrated is very true. The whole thing emerges as a result of the fact that virtual folder R/W access is only available under SpartaDOS for RespeQt. I do understand that AtariDOSs come short against SparatDOS when it come to features and complexity. As a normal user, I would love to have the PCLink feature migrated to Atari compatible DOSs, Of course I know that we have to Waite for someone with skilled programming knowledge to make it. Regarding AspeQt virtual folder writing and ATARIDOS.SYS: I understood this was still impossible owing to the unexpected order of written sectors. Where is it written that this problem has been solved? This is the reason of why was carious to import the virtual folder R/W access of PCLink to AtariDOS. I will send you shortly PM of more info. Thank you again for you usual kind support. madi 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 15, 2016 Share Posted September 15, 2016 No problem - and thanks. To clarify my previous post, I was aware of read/write folder support in AspeQt, but also that the support is aimed at DOS 2.x, MYDOS and derivatives, and not envisaged to work with the SDX ATARIDOS.SYS driver for reasons of sector write sequence, etc. That's my understanding of the status-quo, but it's certainly a useful feature for non-SDX users (as it is in APE), even if quite unnecessary for SDX users since RespeQt already has PCLINK. I always considered support for DOSes other than SDX important, and the same applies here. 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 20, 2016 Share Posted September 20, 2016 (edited) Noticing a strange thing here using SDX 4.48 on U1MB equipped machines SIO2PC/RespeQt. The PCLINK client (PCLINK.SYS) frequently times out a speeds around 57k ("No server response") when booting SDX, but then works fine the next time the PCL: device is accessed. Upping the speed (to - say - Pokey divisor 4 in RespeQt) fixes the issue. I never noticed the issue using SIO2BT. Edited September 20, 2016 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted September 20, 2016 Share Posted September 20, 2016 It looks like a timing issue (similar to the issue reported by the Mac users). Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted October 31, 2016 Share Posted October 31, 2016 Better late than never...I finally setup my mini MAC (Qt, RespeQt) and was able to see the PCLINK issue (and provide a fix for it).Background:Some of the PCLINK actions require a sequence of SIO commands:P - parameters (setting the action parameters)S - statusR - results (execution of a PCLINK action)S - statuswhere the parameters (for a "P" command) are set not only in AUX1,AUX2 but also in a DATA FRAME following the command.Even if the ATARI only wants to read a file, first it has to open it, which means sending a "P" command with a data frame containing specific parameters.The "serial port read timeout" observed was related to this activity (Atari writing a data frame and RespeQt reading it).Basically RespeQt was not waiting long enough for a data frame.I didn't test it, but I guess that the same problem may occur under OSX when writing data sectors to the emulated disks (*.atr).The funny thing is that the timing on the SIO bus is exactly the same under Windows/Linux and OSX, because the delay in sending a data frame is caused by the ATARI.The solution for the problem was increasing the offset in the formula for calculating the timeout value.I have tested the PCLINK successfully with 19200 and with 57600 (both with a SIO2BT adapter and with a SIO2PC/USB cable).The source code is available in the Github repository. 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.