Jump to content
IGNORED

RespeQt r4-beta1 released


Joey Z

Recommended Posts

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.

  • Like 1
Link to comment
Share on other sites

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

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

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

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 by Joey Z
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...