TheMontezuma Posted June 8, 2016 Share Posted June 8, 2016 Well... the H: device uses $ while PCL: uses !. Don't remember offhand why the two schemes are different, and I should probably change one of them. Please let me know, which one you choose to stay with The host device code can do long name mangling, though, while the PCLink code cannot. Neither the original sio2bsd code nor RespeQt can do it. Quote Link to comment Share on other sites More sharing options...
GoodByteXL Posted June 15, 2016 Share Posted June 15, 2016 Sound. Altirra's audio engine has a DC filter, so if the emulated computer isn't playing sound, the audio signal will eventually go to zero, which can then be detected by the kernel mixer. Whether or not this actually prevents the screen saver or sleep, however, is not guaranteed and likely OS version and driver specific. The OS is particularly aggressive about activating the screen saver if a password is set. Altirra only directly nudges the system when detecting controller input; otherwise, the system staying awake is up to OS heuristics. RespeQt should call SetThreadExecutionState() or PowerCreateRequest() to keep the system running. I am not sure what this should tell me. Just upgraded to Altirra 2.71-64 and it works as always. Had it booted to Altirra's BASIC prompt READY and leave it there. It surpresses the energy settings of Win7Pro and that's it. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 18, 2016 Share Posted June 18, 2016 (edited) Does the folder image entry that will be used for PCLink have to be set as D1:? If I set a normal *.ATR image as D1: and then select an arbitrary folder as D2: for PCLink I get the following error from SDX: 138 Device does not respond However if I drag the PCLink folder entry up to D1: it works properly. I also have a potential feature request. Would it be possible for the PCLink process to do on the fly conversion of line-endings between the Atari and Windows standard when accessing data? Perhaps this would not be hardcoded always-on but maybe an option? Altirra currently does this through the D6:->D9: 'Host device' entries and it is very useful when typing listings in as text on the PC. Obviously not essential but very user friendly in some situations. There are also situations where you might not want that to happen. Edited June 18, 2016 by morelenmir Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 18, 2016 Share Posted June 18, 2016 You are referring to the PClink volume on drive 2 as PCL2:, I take it? Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 18, 2016 Share Posted June 18, 2016 You are referring to the PClink volume on drive 2 as PCL2:, I take it? Ahhhhh.... No. I was not. The wording in the SDX user guide is a little unclear, but it makes all the difference. Many thanks Jon! Moreover, under BASIC and ASM editor at least - therefore under all CIO I guess - a PCLink drive set up as entry two is addressed as 'DPCL2:'. Excellent! WIll this fork be kept updated when fixes and new features are added to the primary release or will they both at some point be folded in together do you think? Quote Link to comment Share on other sites More sharing options...
Joey Z Posted June 18, 2016 Share Posted June 18, 2016 Ahhhhh.... No. I was not. The wording in the SDX user guide is a little unclear, but it makes all the difference. Many thanks Jon! Moreover, under BASIC and ASM editor at least - therefore under all CIO I guess - a PCLink drive set up as entry two is addressed as 'DPCL2:'. Excellent! WIll this fork be kept updated when fixes and new features are added to the primary release or will they both at some point be folded in together do you think? This is all being put into the main branch, and when it's mature enough, I'll do another release on github. Now that there's more developers working on this than just me, we should probably start using the branch feature of git to work on things independently of the main branch. As it is, if I added a feature today, I'd have to do a release with a mostly-baked PCLINK implementation. You can see how this would get more and more complicated if there was more parallel/simultaneous work going on. 1 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 18, 2016 Share Posted June 18, 2016 This is all being put into the main branch, and when it's mature enough, I'll do another release on github. Now that there's more developers working on this than just me, we should probably start using the branch feature of git to work on things independently of the main branch. As it is, if I added a feature today, I'd have to do a release with a mostly-baked PCLINK implementation. You can see how this would get more and more complicated if there was more parallel/simultaneous work going on. Yep - makes sense Joey Z! Many thanks for all the work you have already done! Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted June 19, 2016 Share Posted June 19, 2016 we should probably start using the branch feature of git to work on things independently of the main branch Good idea. Locally I always use branches. You may want to use the main remote branch to merge changes from the "feature" branches just before releasing the software. Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted June 19, 2016 Share Posted June 19, 2016 Moreover, under BASIC and ASM editor at least - therefore under all CIO I guess - a PCLink drive set up as entry two is addressed as 'DPCL2:'. Excellent! If you are using Respeqt and the Pclink branch you can have a PCL folder on all the drives that don't have an ATR attached and does not interfere with partitions. Personally I like making my PCL access on PCL3: PCL4: PCL5: and PCL6:... But with the emulator you are stuck with only one even though you can change it any time you want.. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 20, 2016 Share Posted June 20, 2016 One idea for a feature that struck me last night is purely a GUI suggestion. In the past I asked if it would be possible for RespeQT to detect if other SIO devices were attached to the channel and automatically disable the corresponding numbered entry on its device list. One of the chaps explained how individual SIO devices are totally unaware of each other, therefore RepeQT would have no way to interrogate other machines on the daisy chain - makes sense. However, working with the same general idea I wonder if it would be possible to add either a checkbox or just a popup context-menu item to each entry in RespeQT's device list that would manually disable it? For example it would be possible to plug the SIO2PC as the last item in a daisy chain containing an 1050 and an XF551, designated D1: and D2: respectively. Within RespeQT one would then manually disable entry #1 & #2 so it is impossible to set up a conflict with the physical drives. I know the ultimate answer is 'be more careful', but I find myself quite frequently assigning a D1: in RespeQT when I have my physical 1050 switched on and already set as that number. Quote Link to comment Share on other sites More sharing options...
GoodByteXL Posted June 22, 2016 Share Posted June 22, 2016 ... but I find myself quite frequently assigning a D1: in RespeQT when I have my physical 1050 switched on and already set as that number.Since the old ages of home computing manual drive switches are the simplest but not most sophisticated solution. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 22, 2016 Share Posted June 22, 2016 I did the exact same thing yesterday (discovered an ATR mounted on D1: on my SIO2SD NAKed, only to find that there was a RespeQt volume mounted on the same unit number). I clicked eject, used the SIO2SD, and blamed the bugs/features between the desk and the chair. Having said that: being able to grey out the corresponding drive slot (so that it becomes inactive and invisible but remembers any current folder/ATR assignment, which becomes effective again once the slot is reactivated) would appeal to human laziness. Then - when I am finished testing SIO2SD - I could un-hide the slot and everything would be exactly as it was before. 1 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted June 22, 2016 Share Posted June 22, 2016 Hi lazy users what about drag and drop? You may "dock" your D1 assignment by exchanging D1 with an unused drive (for the time working with a real drive / SIO2SD). 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 22, 2016 Share Posted June 22, 2016 You may "dock" your D1 assignment by exchanging D1 with an unused drive (for the time working with a real drive / SIO2SD). Good idea. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted July 21, 2016 Share Posted July 21, 2016 (edited) Due to great support from community, there are higher baud rates possible with Bluetooth. That's why I uploaded Windows binaries with updated "SOFTWARE (SIO2BT)" handshake: - baud rate settings: x1/x2/x3 are now supported - the serial port is opened with selected baudrate - there is no automatic fallback to normal speed in error cases RespeQt.zip This software contains the same PCLINK support as the previously uploaded version (issue with illegal file/dir names under Windows is not yet solved). Edited July 21, 2016 by TheMontezuma Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted July 21, 2016 Share Posted July 21, 2016 (edited) Today HIAS asked me about virtual serial port drivers (for SPP Bluetooth connections) in regard to baudrate settings. I have tried different settings and realized that it completely does not matter what baudrate is set. The communication always works. So even if the above version still works, the changes I introduced were superfluous (and perhaps even confusing, so I have already created a git pull request to revert them). Thank you Hias for a very good tip! Edited July 21, 2016 by TheMontezuma 1 Quote Link to comment Share on other sites More sharing options...
576XE Posted July 25, 2016 Share Posted July 25, 2016 If I could understand, the SDX PCLINK is some kind of workaround like the same drivers to access H*: devices in emulators. From the Atari side it's SDX driver to provide r/w/x access between Atari and PC. All works going on PC side in server. Thus if you provided server (Special versions of RespeQT FE) with drive D3: (C:) thus your PCL can be accessed only as PCL3: Not as PCL: or PCL1: You can not to change drive to PCL2: because it's really occupied by D2: (B:) device. thus you are going to D2: The programs that accept long device names (like most of SDX programs) works with PCL's comfortably, but others alas can't do anything. They reads first P letter and begins thinking about printer. Now I've loaded and run Marbled from PCL2: with IDEPlus exeloader Quote Link to comment Share on other sites More sharing options...
greblus Posted July 25, 2016 Share Posted July 25, 2016 (edited) I'd not call it a "workaround", rather an ingenious feature . No configuration needed. It simply works. And you still can access mounted folders read-only as before (D1:, D2:, etc), or rw through PCLINK protocol (PCL1:, PCL2:, etc). W. Edited July 25, 2016 by greblus Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted July 25, 2016 Share Posted July 25, 2016 (edited) PCLINK is conceptually independent of the mounted folders. But for simplicity (user interface re-use) I have combined PC LINKs with RespeQt mounted folders, so the same PC folder can be accessed in two ways: - (read only) disk, for example D3 - R/W PCLINK, for example PCL3 So, if you mounted an ATR image (instead of a folder) as D2, then you can't use PCL2 device. Edited July 25, 2016 by TheMontezuma 1 Quote Link to comment Share on other sites More sharing options...
lemiel Posted July 25, 2016 Share Posted July 25, 2016 Lx: device additionally in hatabs? Quote Link to comment Share on other sites More sharing options...
drac030 Posted July 25, 2016 Share Posted July 25, 2016 What for? The device is available in CIO as "DPCL:". Try DIR "DPCL:*.*" in Turbo BASIC XL. Quote Link to comment Share on other sites More sharing options...
576XE Posted July 26, 2016 Share Posted July 26, 2016 Is there a program which shows us all modern devices in hatabs? Quote Link to comment Share on other sites More sharing options...
JoSch Posted July 26, 2016 Share Posted July 26, 2016 I compiled the recent source code on OS X and tinkered with the source code. What I observe is, that the directory image via D1: works fine and as soon as I use PCL1: everything breaks down. The serial code called from pclink.cpp never receives anything and so times out. As I can't get the break point to work in the Qt IDE, and I have no outline of the code yet, I don't know how proceed from here. Any pointers or hints, where to look at? Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted July 26, 2016 Share Posted July 26, 2016 I compiled the recent source code on OS X and tinkered with the source code. What I observe is, that the directory image via D1: works fine and as soon as I use PCL1: everything breaks down. The serial code called from pclink.cpp never receives anything and so times out. As I can't get the break point to work in the Qt IDE, and I have no outline of the code yet, I don't know how proceed from here. Any pointers or hints, where to look at? > as soon as I use PCL1: everything breaks down. The serial code called from pclink.cpp never receives anything and so times out. Could you please search in the PCLINK.cpp for "static bool D = false; // extended debug" and change the value to true ? Then execute your test and copy the content of the log window and paste it here? I think you are the first person testing PCLINK on OS X. PCLINK works well under Linux (sio2bsd was originally written for Unix/Linux) and since OS X is based on Linux, I would expect it to work under OS X, too. Thr first thing, which comes to my mind are security permissions of a mounted folder. Could you, please, set all possible permissions to this folder and check it again? Quote Link to comment Share on other sites More sharing options...
JoSch Posted July 26, 2016 Share Posted July 26, 2016 > as soon as I use PCL1: everything breaks down. The serial code called from pclink.cpp never receives anything and so times out. Could you please search in the PCLINK.cpp for "static bool D = false; // extended debug" and change the value to true ? Then execute your test and copy the content of the log window and paste it here? I think you are the first person testing PCLINK on OS X. PCLINK works well under Linux (sio2bsd was originally written for Unix/Linux) and since OS X is based on Linux, I would expect it to work under OS X, too. Thr first thing, which comes to my mind are security permissions of a mounted folder. Could you, please, set all possible permissions to this folder and check it again? 1.) When I'm home, I will try to compile D with true. 2.) Yes, I know, but since there a lot #ifdef Q_OS_LINUX, but, as far as I see, no Q_OS_OSX. I had to change two occurences to get RespeQt to compile. I want to add Q_OS_OSX to the occurrences of #ifdef Q_OS_LINUX. 3.) Yes, I see what you're driving at. But as I see it, the code never comes to sending the directory structure or accessing files, because it can't read the commands from the client (i.e. the computer). 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.