Joey Z Posted April 19, 2017 Share Posted April 19, 2017 release 4 (beta) * replaced AspeCl with FJCs RCL (#54) * added enable/disable checkbox for URL submit (#52) (TheMontezuma) * simplified serial port selection (#51) (TheMontezuma) * code cleanup, UI code reorganization, misc bugs (#48) (blind) * code cleanup (#47) (josch1710) * Fix crash from double call to closeEvent (#46) (josch1710) * CPU load reduction for software handshake (#45) (TheMontezuma) * added URL submit functionality (#43) (TheMontezuma) * further PCLINK work (#37, #38, #41, #42, #44) (TheMontezuma and josch1710) * add PCLINK swap + PCLINK eject + code refactoring (#31) (TheMontezuma) * printer emulation status now persists (#30) (TheMontezuma) * added PCLINK support (#29) (TheMontezuma) * trigger options menu on speedlabel click (#28) (TheMontezuma) * added timing adjustment to close #2 * diskeditdialog now closes on program exit * upgraded SpartaDOS boot files to 3.2G https://github.com/jzatarski/RespeQt/releases/tag/r4-beta1 If you'd like to do beta testing, for the moment you will have to build from source, at least until I get a chance to build a win32 version. If I don't have that by tonight (say in 10 hours or so) remind me to do it. If you have any issues with the beta that didn't exist before, or spot an issue in a new feature, list them here or open an issue on github. On the other hand, if you feel you've given the beta a decent test, but have nothing to complain about, then post that here too. If you don't post at all, I don't know whether someone downloaded and didn't have issues, or that nobody bothered to try it out. 1 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted April 19, 2017 Share Posted April 19, 2017 (edited) release 4 (beta) * replaced AspeCl with FJCs RCL (#54) * added enable/disable checkbox for URL submit (#52) (TheMontezuma) * simplified serial port selection (#51) (TheMontezuma) * code cleanup, UI code reorganization, misc bugs (#48) (blind) * code cleanup (#47) (josch1710) * Fix crash from double call to closeEvent (#46) (josch1710) * CPU load reduction for software handshake (#45) (TheMontezuma) * added URL submit functionality (#43) (TheMontezuma) * further PCLINK work (#37, #38, #41, #42, #44) (TheMontezuma and josch1710) * add PCLINK swap + PCLINK eject + code refactoring (#31) (TheMontezuma) * printer emulation status now persists (#30) (TheMontezuma) * added PCLINK support (#29) (TheMontezuma) * trigger options menu on speedlabel click (#28) (TheMontezuma) * added timing adjustment to close #2 * diskeditdialog now closes on program exit * upgraded SpartaDOS boot files to 3.2G https://github.com/jzatarski/RespeQt/releases/tag/r4-beta1 If you'd like to do beta testing, for the moment you will have to build from source, at least until I get a chance to build a win32 version. If I don't have that by tonight (say in 10 hours or so) remind me to do it. If you have any issues with the beta that didn't exist before, or spot an issue in a new feature, list them here or open an issue on github. On the other hand, if you feel you've given the beta a decent test, but have nothing to complain about, then post that here too. If you don't post at all, I don't know whether someone downloaded and didn't have issues, or that nobody bothered to try it out. Many thanks Joey Z - this really gives me a hankering to get the old hardware out again!!! I've built a linux version on my SFTP server machine directly from the source code you link above. I've never really done any source-control work though and always programme for windows from the visual C++ IDE. Is it difficult to get the project in to a shape that it would compile and link from one of the Windows command-line versions of make/qmake? I'm guessing the problem comes from the fact there is no default universal C++ compiler/linker for windows in the same way there is built in to almost every linux distribution? Edited April 19, 2017 by morelenmir Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted April 19, 2017 Share Posted April 19, 2017 You can't open a log Window anymore. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 19, 2017 Author Share Posted April 19, 2017 You can't open a log Window anymore. It works on linux. What OS are you using? Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted April 19, 2017 Share Posted April 19, 2017 I just downloaded the r4-beta1 source and tried to compile on my RPi Zero W - the process errored out with a slew of issues after about 20 minutes (the Zero W is ... underpowered ). Trying again now in case I had a bad download or something. If not, I'll post the errors here. EDITED TO ADD: Okay, tried again. I did an experiment. In the past, I have compiled on my RPi devices per Matthias' instructions over a year ago - basically just cd into the director, qmake and then make, but the way he posted it, it was 'make -j 4'. The second time I tried (and I did NOT re-download the source!) was to omit the parameter and just go with a plain 'make.' This time the process worked, and the resulting binary seems fully functional, including being able to open the log window. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted April 20, 2017 Share Posted April 20, 2017 I can confirm this compiles and links happily enough on Debian 8. You need the build-essential, qt5default, qtdeclarative5-dev, libqtserialport5-dev and zlib1d-dev packages installing. I am not sure if I had the GTK+ packagaes already installed, so cannot say if they are mandatory also. The SHA-256 digest of the finished executable in my case is: D4D9B5F1BDAEFB2E692A0455E70518BAFE62B3BB6F1816F887924DED0ACE751E I run through a remote SSH console and not KDE or one of the other GUI's so cannot speak on the log window issue. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted April 20, 2017 Share Posted April 20, 2017 Windows 10 64bit. RespeQt crashes when you try to open the log window. There were some GUI changes/optimisations introduced if I remember well. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 20, 2017 Author Share Posted April 20, 2017 Seems the issue was an uninitialized pointer, I think, logWindow_. I initialized it in the constructor of MainWindow, and I have pushed the change to the r4 branch. Can you give it a try TheMontezuma? Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted April 20, 2017 Share Posted April 20, 2017 It helped. Thank you Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 20, 2017 Author Share Posted April 20, 2017 It helped. Thank you Valgrind for the win. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 20, 2017 Author Share Posted April 20, 2017 (edited) OK, Release 4 Beta 2 release 4 (beta)* fixed uninitialized pointer to log window instance causing a crash https://github.com/jzatarski/RespeQt/releases/tag/r4-beta2 Also, win32 binaries are available now. Edited April 20, 2017 by Joey Z 1 Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 20, 2017 Author Share Posted April 20, 2017 Many thanks Joey Z - this really gives me a hankering to get the old hardware out again!!! I've built a linux version on my SFTP server machine directly from the source code you link above. I've never really done any source-control work though and always programme for windows from the visual C++ IDE. Is it difficult to get the project in to a shape that it would compile and link from one of the Windows command-line versions of make/qmake? I'm guessing the problem comes from the fact there is no default universal C++ compiler/linker for windows in the same way there is built in to almost every linux distribution? The project mostly does just build on windows, but setting up a compiler is *your* problem if you want to build it yourself. That's the only difference. On linux, the compiler is usually set up for you and that makes it easy, but on windows, you're pretty much on your own unfortunately. That's why I do the win32 builds and release them, because most windows users can't be expected to compile it on their own since the process is a bit convoluted. On linux, you have little to no excuse for not compiling yourself, because you pretty much just have to install the dev libraries, run qmake, then make and you're done (well, it might take a while on a slow machine. I remember building on a K6-2 and it taking 30-40 minutes). Quote Link to comment Share on other sites More sharing options...
w1k Posted April 20, 2017 Share Posted April 20, 2017 i have new save issue with beta 2 https://www.youtube.com/watch?v=ejK4yZLsJ-4 standard serial port, 57600(3x) but when i check USE NON-STANDARD SPEEDs (6), saving works perfect.. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted April 20, 2017 Share Posted April 20, 2017 What I see is a NACK-ed command $92. This is actually $52 (read sector) with the set 7-bit, so you use a (not supported) TURBO. Quote Link to comment Share on other sites More sharing options...
w1k Posted April 20, 2017 Share Posted April 20, 2017 what turbo? i used normal speed.. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted April 20, 2017 Share Posted April 20, 2017 omg Quote Link to comment Share on other sites More sharing options...
w1k Posted April 20, 2017 Share Posted April 20, 2017 can you reply to ma question? what turbo? when i open respeqt first time, that speed is default in settings.... Quote Link to comment Share on other sites More sharing options...
lemiel Posted April 20, 2017 Share Posted April 20, 2017 (edited) What software are you using on Atari side? It looks like something with 1050 Turbo enabled. TheMontezuma, Joey Z - do you plan to support Synchromesh/Super Synchromesh and 1050 Turbo modes? Edited April 20, 2017 by lemiel Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 20, 2017 Author Share Posted April 20, 2017 What software are you using on Atari side? It looks like something with 1050 Turbo enabled. TheMontezuma, Joey Z - do you plan to support Synchromesh/Super Synchromesh and 1050 Turbo modes? I think there was a thread about various drive-specific turbo speed modes. We came to some conclusion that it's more difficult than it sounds IIRC. It might be buried somewhere in the general discussion thread however, so it might take me a minute to find it.... Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 20, 2017 Author Share Posted April 20, 2017 This is the post where the issues become apparent: http://atariage.com/forums/topic/241055-respeqt-r2-released/?p=3431721 Basically the atari expects the 'drive' (RespeQt in these cases) to switch from 19200 to 38400 about 300uS after the ACK is sent from RespeQt. The problem is that a USB serial chip doesn't have anywhere near the timing accuracy to pull that off. Switch speeds early, and we switch in the middle of ACK. Switch speeds late, and we missed data already. To make matters worse, tcdrain, the one call that could probably solve this, doesn't really have determinate timing between machines and SIO2PC. So the synchromesh style of high speed is just not doable. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 20, 2017 Author Share Posted April 20, 2017 can you reply to ma question? what turbo? when i open respeqt first time, that speed is default in settings.... You have high speed software on the atari that isn't supported, as evidenced by it sending commands with bit 7 set. Don't use that software on the atari with RespeQt and you won't have the issue. As far as I can tell, it otherwise works, it's just slow because the high speed atari software continually attempts switching to synchromesh which isn't supported by RespeQt, and can't easily be supported (see above post). Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 21, 2017 Author Share Posted April 21, 2017 (edited) This is the post where the issues become apparent: http://atariage.com/forums/topic/241055-respeqt-r2-released/?p=3431721 Basically the atari expects the 'drive' (RespeQt in these cases) to switch from 19200 to 38400 about 300uS after the ACK is sent from RespeQt. The problem is that a USB serial chip doesn't have anywhere near the timing accuracy to pull that off. Switch speeds early, and we switch in the middle of ACK. Switch speeds late, and we missed data already. To make matters worse, tcdrain, the one call that could probably solve this, doesn't really have determinate timing between machines and SIO2PC. So the synchromesh style of high speed is just not doable. Hmm. Thinking about this more, do the FTDI chips allow asymmetric RX and TX speed? at least on linux, you can independently set ispeed and ospeed, if the hardware supports it. You could switch the ispeed to 38400 right away, but keep the ospeed at 19200 and send the ACK byte, and that would seemingly resolve this issue, but it's dependent on support for asymmetric speeds. I don't know if that's even possible in windows, for example. EDIT: quick test says this is not possible with the FTDI. too bad.... Edited April 21, 2017 by Joey Z Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted April 21, 2017 Share Posted April 21, 2017 (edited) This is the post where the issues become apparent: http://atariage.com/forums/topic/241055-respeqt-r2-released/?p=3431721 Basically the atari expects the 'drive' (RespeQt in these cases) to switch from 19200 to 38400 about 300uS after the ACK is sent from RespeQt. The problem is that a USB serial chip doesn't have anywhere near the timing accuracy to pull that off. Switch speeds early, and we switch in the middle of ACK. Switch speeds late, and we missed data already. To make matters worse, tcdrain, the one call that could probably solve this, doesn't really have determinate timing between machines and SIO2PC. So the synchromesh style of high speed is just not doable. manual calibration of the timing window, maybe? include a slider to speed up or slow down the response time since it can vary based on usb chipset in the cable and pc. generic usb driver might need to replaced for use with respeqt with something a little more responsive? couldn't hurt.....the larger issue of automatically handling other speeders might be handled by not doing it automatically at all for the time being... make it a checkbox to force such a mode. Probably already considered... Edited April 21, 2017 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 24, 2017 Author Share Posted April 24, 2017 (edited) manual calibration of the timing window, maybe? include a slider to speed up or slow down the response time since it can vary based on usb chipset in the cable and pc. generic usb driver might need to replaced for use with respeqt with something a little more responsive? couldn't hurt.....the larger issue of automatically handling other speeders might be handled by not doing it automatically at all for the time being... make it a checkbox to force such a mode. Probably already considered... The other half of the issue is that a given FTDI isn't even consistent byte to byte. I've looked with a scope and there's just jitter in general. I don't know if it's enough to break this, but it exists. Besides that, I still am having trouble seeing the point of emulating it really, there are other high speed options more suited to SIO2PC-USB which clearly don't have this problem. That's not to say I won't ever look into it, but it's not as high priority as the other things (like R: support) which I'd like to see in RespeQt. Edited April 24, 2017 by Joey Z Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted April 24, 2017 Share Posted April 24, 2017 Going to give it a go with some of the DOS XE based atr's again.... last time it of course took forever and kept choking. 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.