Jump to content

Photo

RespeQt r1 released

apetime

38 replies to this topic

#1 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • 876 posts
  • Location:Hoffman Estates, IL

Posted Sun Jul 12, 2015 10:03 PM

RespeQt r1 fixed a few minor things, and put ApeTime support back in.

 

More info on the github page for this release: https://github.com/j...releases/tag/r1

 

There is a 32 bit windows build, it can be built from source on linux rather easily, and OSX fixes/support is being worked on by DrVenkman. I hope to have OSX fixes added in r2.

 

The windows build is experimental for the moment. I had a pretty hard time convincing Qt libs to compile on windows, and then had to work out an issue that was stopping me from compiling RespeQt itself. You'll notice some DLL files are included. I am not certain that these are all of the DLL's which are required by RespeQt. If you encounter a DLL error, please submit an issue on github, or reply here (the former is preferred)

 

If you have any other issue, for that matter, please report it on github (preferred) or reply here.

 

Feature requests, reply here.

 

Some things currently on the todo list:

need to deal with AspeCL at some point
new icon?
translations
- need new translation for German manual (which already existed for AspeQt, but is now out of date compared to english)
- translations may be broken
remove any other instances of AspeQt or mention of atari8warez, ray, or atari8warez.com, a8w - ongoing
sioworker.cpp: have devices provide they're own string for debug output? - SioWorker::deviceName
update docs for changes - perpetual :)
Qt4 version?
R: support
SDFS folder imaging
fix include path for windows, seems QZlib is not used, just ordinary zlib

 

If anyone knows a language other than english well enough to do it, I'd appreciate translations of the application and documentiation. There are translations which I have moved over from AspeQt, but I don't really have a guarantee that they work, since I haven't bothered to test them yet, and I also don't know how.


Edited by Joey Z, Sun Jul 12, 2015 10:05 PM.


#2 Kyle22 ONLINE  

Kyle22

    River Patroller

  • 4,031 posts
  • Call my BBS! telnet://broadway1.lorexddns.net
  • Location:McKees Rocks (Pittsburgh), PA

Posted Mon Jul 13, 2015 11:38 AM

The help | about and help | user manual both contain multiple references to Ray and his website.

 

Why don't you use grep or a similar tool to search the entire project for these references?

 

Edit: I also found this near the bottom of the user manual:

 

RespeQt as of v0.8.5 no longer supports ApeTime (Date/Time downloader utility) from the AtariMax APE package. The support code has been removed from the source. Please use AspeCl for Date/Time download and other remote functionality.

I thought ApeTime had been  re-instated.

 

 


Edited by Kyle22, Mon Jul 13, 2015 11:43 AM.


#3 RodLightning OFFLINE  

RodLightning

    Dragonstomper

  • 753 posts
  • Location:USA Southeast

Posted Mon Jul 13, 2015 11:54 AM

Thanks for making the win32 binary!  I was trying to figure out how to compile QT code using CygWin when I saw this posted.

 

I can confirm that RespeQt r1 Windows build works fine on my netbook (XP-SP3) and FT232R setup.  Sparta dos 3.2g with apetime does indeed fetch the correct time and date.  The display line at top of screen says 'Sun' instead of Monday (today) but I expect that is a problem with sparta and not RespeQt.  I mounted a folder image for quick access to apetime.com with no issues.  Right now, I am booting various multi-game disks without a problem.  :thumbsup:



#4 morelenmir OFFLINE  

morelenmir

    Stargunner

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

Posted Mon Jul 13, 2015 12:24 PM

RespeQt r1 fixed a few minor things, and put ApeTime support back in.

 

More info on the github page for this release: https://github.com/j...releases/tag/r1

 

There is a 32 bit windows build, it can be built from source on linux rather easily, and OSX fixes/support is being worked on by DrVenkman. I hope to have OSX fixes added in r2.

 

The windows build is experimental for the moment. I had a pretty hard time convincing Qt libs to compile on windows, and then had to work out an issue that was stopping me from compiling RespeQt itself. You'll notice some DLL files are included. I am not certain that these are all of the DLL's which are required by RespeQt. If you encounter a DLL error, please submit an issue on github, or reply here (the former is preferred)

 

If you have any other issue, for that matter, please report it on github (preferred) or reply here.

 

Feature requests, reply here.

 

Some things currently on the todo list:

need to deal with AspeCL at some point
new icon?
translations
- need new translation for German manual (which already existed for AspeQt, but is now out of date compared to english)
- translations may be broken
remove any other instances of AspeQt or mention of atari8warez, ray, or atari8warez.com, a8w - ongoing
sioworker.cpp: have devices provide they're own string for debug output? - SioWorker::deviceName
update docs for changes - perpetual :)
Qt4 version?
R: support
SDFS folder imaging
fix include path for windows, seems QZlib is not used, just ordinary zlib

 

If anyone knows a language other than english well enough to do it, I'd appreciate translations of the application and documentiation. There are translations which I have moved over from AspeQt, but I don't really have a guarantee that they work, since I haven't bothered to test them yet, and I also don't know how.

 

This is excellent news!!!  Many, many thanks for getting this project up and running again.  I am really looking forward to testing this release out and also seeing what the future holds for R2 and beyond!

 

Update:

 

I find this runs really well indeed.  I do have one suggestion though and it regards the log window.  When you resize the main "RespeQT" dialogue the log window does not resize itself in tandom, it only expands to occupy the new available space when messages are posted to the log.  Obviously not a critical bug, but it can be a little frustrating at first to read any of the status messages that are sent when connecting the device but before it has had chance to update with any logs from data transfer.



#5 Joey Z OFFLINE  

Joey Z

    Dragonstomper

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

Posted Mon Jul 13, 2015 4:16 PM

The help | about and help | user manual both contain multiple references to Ray and his website.

 

Why don't you use grep or a similar tool to search the entire project for these references?

 

Edit: I also found this near the bottom of the user manual:

 

RespeQt as of v0.8.5 no longer supports ApeTime (Date/Time downloader utility) from the AtariMax APE package. The support code has been removed from the source. Please use AspeCl for Date/Time download and other remote functionality.

I thought ApeTime had been  re-instated.

 

 

You know, the funny thing is that I basically did just that. Also, I remember FIXING those already, I wonder if I accidentally changed the wrong file, or didn't save it? I'll take a look when I get a chance.

 

EDIT: no, turns out all I did was change the separate HTML versions of those. I guess I missed that the ui files didn't change.


Edited by Joey Z, Mon Jul 13, 2015 4:28 PM.


#6 Joey Z OFFLINE  

Joey Z

    Dragonstomper

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

Posted Mon Jul 13, 2015 4:19 PM

 

This is excellent news!!!  Many, many thanks for getting this project up and running again.  I am really looking forward to testing this release out and also seeing what the future holds for R2 and beyond!

 

Update:

 

I find this runs really well indeed.  I do have one suggestion though and it regards the log window.  When you resize the main "RespeQT" dialogue the log window does not resize itself in tandom, it only expands to occupy the new available space when messages are posted to the log.  Obviously not a critical bug, but it can be a little frustrating at first to read any of the status messages that are sent when connecting the device but before it has had chance to update with any logs from data transfer.

 

I will look into the log window sizing, I suspect I need to impement some code for a 'window resize event' which changes the log text box to match the new main window size.

 

Thanks for making the win32 binary!  I was trying to figure out how to compile QT code using CygWin when I saw this posted.

 

I can confirm that RespeQt r1 Windows build works fine on my netbook (XP-SP3) and FT232R setup.  Sparta dos 3.2g with apetime does indeed fetch the correct time and date.  The display line at top of screen says 'Sun' instead of Monday (today) but I expect that is a problem with sparta and not RespeQt.  I mounted a folder image for quick access to apetime.com with no issues.  Right now, I am booting various multi-game disks without a problem.  :thumbsup:

 

Good to hear  :)



#7 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Mon Jul 13, 2015 5:58 PM

Okay, I downloaded the new master codebase today, added some conditional compilation blocks so that my Mac-specific changes shouldn't affect Linux users, and then built a working executable. So far so good. :) I don't know if it's my device or RespeQt (need to do more tests) but I can read great and 57,600 bps, but can only write at 38,400 or lower. Trying to write at 57,600 gives me about 50 errors, then an Error -138 on the Atari. But still, 38,400 is WAY better than we had back in the day!

 

Also, I added in HiassofT's suggested changes to lines 80 and 85, as discussed in this post:

 

http://atariage.com/...7r79/?p=3276721

 

I built a new executable and see no ill effects, despite his warning about some devices not liking the change. Mine doesn't seem to be bothered.

 

I do have report that the ApeTime module reports the wrong day of the week - I expect Steve's original code for the Atari APETIME might not be Y2K-compliant, but who knows? :)

 

 

Anyway, now that things are working and seem to be stable/usable for most purposes, I've got some more tests to do:

 

1. Can SIO2OSX write successfully at 3X (57,600 bps) with the same device and on the same Mac?

2. If so, can I fiddle with the timings enough to get 3X writes working in RespeQt?



#8 RodLightning OFFLINE  

RodLightning

    Dragonstomper

  • 753 posts
  • Location:USA Southeast

Posted Mon Jul 13, 2015 7:26 PM

I do have report that the ApeTime module reports the wrong day of the week - I expect Steve's original code for the Atari APETIME might not be Y2K-compliant, but who knows? :)


I noticed that your screen shot shows the same minus one day offset as I got here when I tested. I was blaming the tdline program.

The time and actual numeric calendar values are correct.



#9 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Mon Jul 13, 2015 8:04 PM

Ah, could be. I didn't even realize the day was wrong, just that the APETIME.COM program was accessing the ApeTime server in RespeQt properly and getting the date/time correct. Regardless of little bugs like the day issue, for a kid who grew up with Atari computers and just knew all along they didn't have a real-time clock, it's a petty cool thing to see them displaying the correct time automagically.

#10 Joey Z OFFLINE  

Joey Z

    Dragonstomper

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

Posted Mon Jul 13, 2015 11:25 PM

I do have report that the ApeTime module reports the wrong day of the week - I expect Steve's original code for the Atari APETIME might not be Y2K-compliant, but who knows? :)

 

 

I noticed that your screen shot shows the same minus one day offset as I got here when I tested. I was blaming the tdline program.

The time and actual numeric calendar values are correct.

ApeTime does nothing more than provide the number of the day, the month, and the year, and time of course. Any day of the week errors are caused by the client software miscalculating, probably due to incorrect leap year handling or something. a missed leap day would cause an off by one in the day of week calculations. it could be TDLINE day of week stuff was done before a leap year occurred, and now it's wrong.



#11 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Tue Jul 14, 2015 6:44 AM

That makes sense, Joey. But in any case, it's just an implementation detail. What matters is that you got the ApeTime server code back into RespeQt and working properly. Kudos!

Sent from my iPhone using Tapatalk

Edited by DrVenkman, Tue Jul 14, 2015 6:46 AM.


#12 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Tue Jul 14, 2015 5:36 PM

Okay, so I went back and read what HiassofT wrote in the previous thread. Specifically, this part:


I finally found a little bit of spare time and had a closer look at serialport-unix.cpp - and noticed some odd things:

In StandardSerialPortBackend::writeRawFrame (line no 517) the tcdrain block should be at the end of the method (just before the "return true"). This'll make sure that any written bytes will be handed over to the device before the method returns (the OS/tty layer might do some buffering).
 

 

So, with that in mind, I went back to serialport-unix.cpp and edited the StandardSerialPortBackend::writeRawFrame() module as HiassofT suggested. Combined with his prior two fixes (around lines 80 and 85, also discussed in his post), I no longer need to extend the delays at the end of the write modules from 300 to 500 milliseconds in order to get reliable data transfers!

 

That means the only Mac-specific code that has to be added are those first changes, changing QThread::yieldCurrentThread() to QThread::usleep(500) to prevent runaway CPU usage.



#13 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Tue Jul 14, 2015 7:24 PM

Ugh. Meant microseconds in that last post. Again. I wish the board allowed more time for edits. :)

#14 HiassofT OFFLINE  

HiassofT

    Stargunner

  • 1,140 posts
  • Location:Salzburg, Austria

Posted Wed Jul 15, 2015 9:56 AM

That means the only Mac-specific code that has to be added are those first changes, changing QThread::yieldCurrentThread() to QThread::usleep(500) to prevent runaway CPU usage.

Just did some tests on my Linux box:

The usleep(500) is beneficial on Linux too when using a "real" (16550) serial card - CPU usage is 100% there too.

But when using a FTDI USB-serial adapter it's counter-productive. The ioctl sleeps for about 1ms, it's doing an USB request to the FTDI chip and waits for the response with the current modem status lines. Adding an additional 500µs delay there results in occasionally missed command frames and retries.

I think the best solution would be to add another option to the GUI (maybe only for Linux/Mac) that allows you to select the desired behaviour.

For example a "handshake delay" input field or drop-down box. Then do a yieldCurrentThread() call if it's 0 otherwise do a usleep(delay).

so long,

Hias

#15 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Wed Jul 15, 2015 10:13 AM

Thank you for continuing to look into this, Hias!

Your suggestion of a user-selectable delay is interesting. The commercially-available SIO2OSX program for the Mac has just that - a drop down that lets the user select a delay from 0-9 (no units are specified). My device and system work well with a delay of "1", for instance.


Sent from my iPhone using Tapatalk

#16 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Wed Jul 15, 2015 5:53 PM

So Joey Z, I have no idea how to create a pull request on Github, so here is serial port-unix.cpp with my fixes added, courtesy of Hias's SIO expertise and knowledge. This build works very well under OS X, both floppy reads (at 3X) and writes (only 2X, but still better than back in the day!).  Executables load perfectly at full speed as well. 

 

(change the fie extension to .cpp, obviously - had to change it to .txt to allow uploading)

Attached Files


Edited by DrVenkman, Wed Jul 15, 2015 5:54 PM.


#17 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Wed Jul 15, 2015 6:05 PM

And here is the OS X executable. It's the same exact code in every respect as Joey's r1 code, with the handful of changes to serialport-unix.cpp as discussed above. Any Mac users, feel free to test it out.

 

 

Attached Files



#18 Joey Z OFFLINE  

Joey Z

    Dragonstomper

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

Posted Wed Jul 15, 2015 11:11 PM

So Joey Z, I have no idea how to create a pull request on Github, so here is serial port-unix.cpp with my fixes added, courtesy of Hias's SIO expertise and knowledge. This build works very well under OS X, both floppy reads (at 3X) and writes (only 2X, but still better than back in the day!).  Executables load perfectly at full speed as well. 

 

(change the fie extension to .cpp, obviously - had to change it to .txt to allow uploading)

well, the 'pull request' can only be done on a repository I think, which means you'd have to first push the code to a branch of RespeQt on github, then initiate the pull request. In order to do that, I think I'd have to give you permissions to do so. Do you have a GitHub account? I'll add you. I don't want to add your OSX binary to the r1 release page just yet, since it's technically not pure r1 anymore, but I'll definitely incorporate the changes for r2.

 

EDIT: I suppose you could fork RespeQt, and a pull could happen from that, but that's just messy, so I'll add you as a contributor. You will be in charge of OSX anything, if you're up to it, or you can just provide the binaries, if that's all you want to do.


Edited by Joey Z, Wed Jul 15, 2015 11:19 PM.


#19 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Thu Jul 16, 2015 4:01 PM

Joey, I do have a Github account but as I've said before, I'm just a hack with decent developer tools and a lot of stubbornness. I can implement fixes that experts like you, phaeron and Hias suggest, and I can certainly pull a code branch and build an OS X binary as needed, but I don't know enough to even know what I don't know. :) 



#20 Joey Z OFFLINE  

Joey Z

    Dragonstomper

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

Posted Thu Jul 16, 2015 6:08 PM

Joey, I do have a Github account but as I've said before, I'm just a hack with decent developer tools and a lot of stubbornness. I can implement fixes that experts like you, phaeron and Hias suggest, and I can certainly pull a code branch and build an OS X binary as needed, but I don't know enough to even know what I don't know. :)

well still, I need someone to do OSX binary builds, so adding you as a contributor is the best option I think. There's no reason not to. what is your username?



#21 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Thu Jul 16, 2015 6:16 PM

well still, I need someone to do OSX binary builds, so adding you as a contributor is the best option I think. There's no reason not to. what is your username?

 

I'm 'LameLefty' there. I'm glad to help out.



#22 Joey Z OFFLINE  

Joey Z

    Dragonstomper

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

Posted Thu Jul 16, 2015 6:46 PM

 

I'm 'LameLefty' there. I'm glad to help out.

you are added now. If you want to add your OSX binary to the r1 release, please note in the filename that it's r1.5 or something, just to make it clear it's not quite r1.



#23 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Thu Jul 16, 2015 7:15 PM

you are added now. If you want to add your OSX binary to the r1 release, please note in the filename that it's r1.5 or something, just to make it clear it's not quite r1.

 

Done. 

 

As a Git-newbie, I don't know how to create a formal branch and/or publish my changed serialport-unix.cpp however. 



#24 Joey Z OFFLINE  

Joey Z

    Dragonstomper

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

Posted Thu Jul 16, 2015 7:26 PM

well, I'll handle it, but if you're interested, you should install git and learn how to use it, somewhere like here: https://www.atlassia.../git/tutorials/

that's what I used to get started, and I hadn't used a version control system before now.



#25 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 3,968 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Thu Jul 16, 2015 7:29 PM

well, I'll handle it, but if you're interested, you should install git and learn how to use it, somewhere like here: https://www.atlassia.../git/tutorials/

that's what I used to get started, and I hadn't used a version control system before now.

 

Thanks, Joey. I'll try to spend a little time on it over the weekend. 





Reply to this topic



  


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users