Jump to content

Photo

RespeQt r4-beta1 released


24 replies to this topic

#1 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • 819 posts
  • Location:Hoffman Estates, IL

Posted Wed Apr 19, 2017 12:42 PM

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/j...es/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.



#2 morelenmir OFFLINE  

morelenmir

    Stargunner

  • 1,451 posts
  • Location:West Yorkshire, Great Britain

Posted Wed Apr 19, 2017 1:35 PM

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/j...es/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, Wed Apr 19, 2017 1:39 PM.


#3 TheMontezuma OFFLINE  

TheMontezuma

    Moonsweeper

  • 495 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Wed Apr 19, 2017 1:51 PM

You can't open a log Window anymore.



#4 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Wed Apr 19, 2017 4:25 PM

You can't open a log Window anymore.

It works on linux. What OS are you using?



#5 DrVenkman OFFLINE  

DrVenkman

    Stargunner

  • 1,495 posts
  • Starmaster Leader
  • Location:KMBT

Posted Wed Apr 19, 2017 5:59 PM

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.



#6 morelenmir OFFLINE  

morelenmir

    Stargunner

  • 1,451 posts
  • Location:West Yorkshire, Great Britain

Posted Wed Apr 19, 2017 6:19 PM

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.



#7 TheMontezuma OFFLINE  

TheMontezuma

    Moonsweeper

  • 495 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Wed Apr 19, 2017 11:09 PM

Windows 10 64bit.
RespeQt crashes when you try to open the log window.
There were some GUI changes/optimisations introduced if I remember well.

#8 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Thu Apr 20, 2017 12:48 AM

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?



#9 TheMontezuma OFFLINE  

TheMontezuma

    Moonsweeper

  • 495 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Thu Apr 20, 2017 1:07 AM

It helped. Thank you :)



#10 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Thu Apr 20, 2017 9:55 AM

It helped. Thank you :)

Valgrind for the win.



#11 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Thu Apr 20, 2017 10:14 AM

OK, Release 4 Beta 2 :)

 

release 4 (beta)
* fixed uninitialized pointer to log window instance causing a crash

 

https://github.com/j...es/tag/r4-beta2

 

Also, win32 binaries are available now.


Edited by Joey Z, Thu Apr 20, 2017 11:10 AM.


#12 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Thu Apr 20, 2017 11:17 AM

 

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



#13 w1k OFFLINE  

w1k

    Stargunner

  • 1,627 posts
  • Location:martin, slovakia

Posted Thu Apr 20, 2017 11:48 AM

i have new save issue with beta 2

 

 

standard serial port, 57600(3x)

 

but when i check USE NON-STANDARD SPEEDs (6), saving works perfect..:)



#14 TheMontezuma OFFLINE  

TheMontezuma

    Moonsweeper

  • 495 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Thu Apr 20, 2017 12:16 PM

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.



#15 w1k OFFLINE  

w1k

    Stargunner

  • 1,627 posts
  • Location:martin, slovakia

Posted Thu Apr 20, 2017 12:51 PM

what turbo? i used normal speed..



#16 TheMontezuma OFFLINE  

TheMontezuma

    Moonsweeper

  • 495 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Thu Apr 20, 2017 1:09 PM

omg



#17 w1k OFFLINE  

w1k

    Stargunner

  • 1,627 posts
  • Location:martin, slovakia

Posted Thu Apr 20, 2017 2:20 PM

can you reply to ma question? what turbo? when i open respeqt first time, that speed is default in settings....



#18 lemiel OFFLINE  

lemiel

    Chopper Commander

  • 213 posts
  • Location:Tychy, Poland

Posted Thu Apr 20, 2017 3:01 PM

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 by lemiel, Thu Apr 20, 2017 3:02 PM.


#19 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Thu Apr 20, 2017 4:11 PM

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



#20 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Thu Apr 20, 2017 4:33 PM

This is the post where the issues become apparent:

 

http://atariage.com/...ased/?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.



#21 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Thu Apr 20, 2017 4:35 PM

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



#22 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Thu Apr 20, 2017 7:29 PM

This is the post where the issues become apparent:

 

http://atariage.com/...ased/?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, Thu Apr 20, 2017 7:37 PM.


#23 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,032 posts
  • Location:10-0-11-00:02

Posted Fri Apr 21, 2017 10:22 AM

This is the post where the issues become apparent:

 

http://atariage.com/...ased/?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__, Fri Apr 21, 2017 10:32 AM.


#24 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 819 posts
  • Location:Hoffman Estates, IL

Posted Mon Apr 24, 2017 10:02 AM

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, Mon Apr 24, 2017 10:02 AM.


#25 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,032 posts
  • Location:10-0-11-00:02

Posted Mon Apr 24, 2017 5:48 PM

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.





Reply to this topic



  


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users