RespeQt 4.3 beta

[+DrVenkman]

Okay, I did manage to compile this branch on my Pi3, though I'd prefer to leave this board dedicated to its current task (providing an OpenHantek front-end to my Hantek 6022BE USB oscilloscope).

 

And I may have figured out what's going on with my Raspberry Pi Zero W. Typically, I compile RespeQt with the same set of commands; after cloning the Git repository and cd'ing into the directory, I'll do qmake, then make -j 4

That has worked fine in previous versions of RespeQt on all my Pi hardware (RPi2, RPi3B, RPi3B Plus, RPiZeroW). However, the "-j 4" command line argument seems to be over-taxing the RPiZero's minimal internal RAM during compilation of larger modules. Although it works fine with earlier versions of RespeQt, this branch adds quite a bit of code to certain modules. Deleting the "-j 4" argument has allowed compilation to proceed (slowly ... ! ) but without error so far through many more modules past its prior choke point. Hopefully it will finish up correctly!

 

Unfortunately, this board is currently headless and nowhere near my Atari machines since I've been in the process of rearranging all my hardware. I'll be able to see if it runs, but not test functionality quite yet.

 

EDIT: Okay, that failed with a bunch of "undefined ..." errors referring to various modules at the end of the process. Hmm. Gonna have to ponder this one for a bit. Or just break down and buy a new Pi3B Plus and repurpose my old Pi3B back to RespeQt duty ...

Edited February 21, 2019 by DrVenkman

[JoSch]

-j n means that make forks n processes for make tasks. That can easily consumes a lot of memory.

Also, this flag ony make sense if you have at least that much cores.

[+DrVenkman]

-j n means that make forks n processes for make tasks. That can easily consumes a lot of memory.

Also, this flag ony make sense if you have at least that much cores.

Yeah I know. But the thing is, it’s always worked for past versions of RespeQt. Worse though is that the single-thread make process failed last night - evidently the script got to a point that it expected some other modules to have completed and they weren’t there when referenced. So the existing makefile seems to expect some degree of threading so things are completed by the time another module needs them. Or so a discussion thread I saw on Stack Exchange last night seems to indicate.

 

I’ll experiment more tonight and see if I can get a successful build out of this PiZeroW and if not, move over the executable build from my Pi3 and see if it works.

[JoSch]

Well, we integrated much more features, which needs more memory while compiling, so probably you came over some threshold.

Concerning your new build problem: Make never assumes threading. It will only thread stuff which is independent of each other.

More likely is that you need to restart the complete build process. The crash you had before, probably left an empty object file, which could mean that make doesn't pick it up again and the linker can't find the stuff it needs.

If you didn't do it already: run "make distclean", then "qmake" and "make".

Edited February 21, 2019 by JoSch

[+DrVenkman]

Well, we integrated much more features, which needs more memory while compiling, so probably you came over some threshold.

Concerning your new build problem: Make never assumes threading. It will only thread stuff which is independent of each other.

More likely is that you need to restart the complete build process. The crash you had before, probably left an empty object file, which could mean that make doesn't pick it up again and the linker can't find the stuff it needs.

If you didn't do it already: run "make distclean", then "qmake" and "make".

I did run “make clean” before I tried again without the -j attribute last night. It was still still running when I went to bed but I did not check this morning. When I get home from work if I find the build process has failed again, I’ll try again.

[+DrVenkman]

Okay, the make process on my RPiZeroW failed last night, probably after I went to bed, my laptop went into sleep mode and my PuTTY session timed out and disconnected. Bah. So I've run make distclean and make again, and now make once more.

 

Fingers crossed for a better result tonight.

 

EDITED TO ADD: EUREKA, it worked! I can confirm that I have finally built the 4.3 branch of RespeQt on my Raspberry Pi Zero W. I still don't know if it actually works for ATX files, but just having built it is a step in the right direction. I'll do some testing with it this weekend once I have time to move more of my stuff upstairs into my newly-repurposed game/retro computer room.

Edited February 22, 2019 by DrVenkman

[+DrVenkman]

Gah, I'm an idiot. Disregard the last post. Sheesh - I managed to build the base r4 code, the very same code I had compiled previously a year or more ago on this board, lol. Yes, I was in the wrong directory tonight when I built the binary again, overwriting the binary that was already in there.

 

So, now I'm in the *correct* directory, confirmed to be holding the 4.3 branch code, and trying again ... (I clearly need more sleep these days).

[+DrVenkman]

Finally for real this time! Don’t know how long it took to compile all night but this morning I hooked the board up to the closest monitor I could find and checked things out. Pardon the photos (it’s a CRT SVGA monitor) but it works! Got some weird misalignment there with the P3: and P4: slots but other than that everything appears to be present.

 

This weekend I’ll do some functional testing and see how it performs. I have the base R4 compiled and ready to compare as well.

 

 

[JoSch]

See, it works

I also saw the misalignment on my RPi build, but have not investigated it yet.

[+DrVenkman]

See, it works

I also saw the misalignment on my RPi build, but have not investigated it yet.

 

Indeed.

 

It launches and runs as expected on my little Pi Zero W, but while the build loads ATR files, it chokes on the ATX files I've tested with (Bruce Lee, The Goonies, Ghostbusters …) All of those load under the Windows build I tried last weekend, and the same files load successfully from my SDrive-MAX. It seems the little Pi just can't keep the timing tight enough.

 

I'm going to check in a bit to see if my RPi3 has enough horsepower to manage it.

Edited February 22, 2019 by DrVenkman

[+DrVenkman]

Wow, what a difference! With the Raspberry Pi 3 (not even the later 3 Plus), The Goonies loaded up just fine the first time, even at 125kbps! Unfortunately, it still choked on both Ghostbusters and Bruce Lee. However, I was able to get at least one of two ATX images I have for M.U.L.E. to load. Unfortunately, both Seven Cities of Gold and Archon freeze when the RespeQt log indicates a phantom sector in the ATX.

 

This was the same sort of error I was having using the prior Windows version (posted back in December), that I was able to correct by UN-checking the Falling Edge option in RespeQt settings. However, that option does not appear in ebiguy's current development branch.

 

So although overall the application is a lot more responsive with the foster RPi3 hardware, performance is still lacking as compared to the December Windows version.

[_The Doctor__]

he removed the edge button? are you sure? without it a number of people won't be able to use respeqt at all! not a good move....

please make sure you have a flow control line selected, if it set to none or bt the check box will be hidden..

Edited February 23, 2019 by _The Doctor__

[+DrVenkman]

he removed the edge button? are you sure? without it a number of people won't be able to use respeqt at all! not a good move....

please make sure you have a flow control line selected, if it set to none or bt the check box will be hidden..

 

This ain't my first rodeo, Doc.

 

I'm using DSR flow control, just as I have been in all prior versions of RespeQt (both my SIO2PC USB devices use DSR). And again, this build works fine with unprotected ATR files, and I've got some limited success with a few ATX files, but the same files that load with my SDrive-MAX and through the December Windows version do NOT load on this Raspbian version. Unfortunately, these are not the same codebase after JoSch's changes and the more recent changes added by ebiguy.

 

If ebiguy compiles a Win64 version of this current r4.3 develop branch, I'll give it a whirl and compare performance with the same files.

Edited February 23, 2019 by DrVenkman

[_The Doctor__]

ebiguy, please make sure the falling edge option is not removed, if you go back and read the thread about how and why the check box was put there you will see it's actually done for a reason.

[ebiguy]

ebiguy, please make sure the falling edge option is not removed, if you go back and read the thread about how and why the check box was put there you will see it's actually done for a reason.

 

Beleive me, I never removed anything. I only worked on ATX emulation, not on SIO communication options.

But I will look at that this afternoon.

BTW, i don't understand why a 64bit binary is so important. The XP compatible version works already on all platforms.

[ebiguy]

This was the same sort of error I was having using the prior Windows version (posted back in December), that I was able to correct by UN-checking the Falling Edge option in RespeQt settings. However, that option does not appear in ebiguy's current development branch.

 

Here is what I found so far about the "missing" option (falling edge).

I am not using Linux so I did not check Linux or RP binaries.

1) I checked the binaries found in this thread: All windows binaries (mine and JoSch) have the falling edge option in the dialog box.

2) I checked out the latest sources and recompiled them on Windows and the falling edge option is still here.

 

So, please, be very clear about which binary version (from which post #), which platform and, if comparing 2 option dialog boxes, make screen shots of both versions.

[+DrVenkman]

 

Here is what I found so far about the "missing" option (falling edge).

I am not using Linux so I did not check Linux or RP binaries.

1) I checked the binaries found in this thread: All windows binaries (mine and JoSch) have the falling edge option in the dialog box.

2) I checked out the latest sources and recompiled them on Windows and the falling edge option is still here.

 

So, please, be very clear about which binary version (from which post #), which platform and, if comparing 2 option dialog boxes, make screen shots of both versions.

 

My Raspberry Pi tests used binaries compiled right from your development branch, obtained via a Raspberry Pi terminal command: git clone -b develop https://github.com/ebiguy/RespeQt.git

 

Then just cd RespeQt into the directory, qmake and make. My Raspbian tests have all been with the above. Sorry for no screenshots - getting screenshots off my RPi boxes and to my Windows machine for posting in the thread is problematic - I'm not using VNC or anything like that on my boards. I'll try to take some pics with my phone and post them later.

 

As for 64-bit binaries, why not? The x86-64 standard was established over 18 years ago now. 64-bit applications tend to be larger but noticeably faster on 64-bit processors, and for timings with ATX files, with an already-sluggish Qt app running on a multi-tasking desktop environment, I'd think you'd want as much performance as possible to deal with the usual Windows system overhead hiccups. I could be completely wrong with this viewpoint (wouldn't be the first time), but I can't see why you wouldn't want to produce a 64-bit binary as well, since 64-bit systems are by far the dominant modern computing platform.

 

I'd build my own Win64 binary myself, but for what it's worth, I can't build your current develop branch under Windows in Qt Creator - I get well over 40 syntax errors when I try to build the code as-is. But that's probably just something wrong on my end; I've never had any luck using the Windows version of Qt Creator even though I used to use it to compile RespeQt binaries on my Mac a few years ago.

[ebiguy]

Then just cd RespeQt into the directory, qmake and make. My Raspbian tests have all been with the above. Sorry for no screenshots - getting screenshots off my RPi boxes and to my Windows machine for posting in the thread is problematic - I'm not using VNC or anything like that on my boards. I'll try to take some pics with my phone and post them later.

 

No problem. It's just that you are taking about missing options on Linux and I don't have a Linux ready to use to test. So, for everyone willing to help you, pictures showing the differences between versions would be useful. And of course the source of the executable (is it your compilation or is it a downloaded version from a post (which #) on AA).

 

As for 64-bit binaries, why not? The x86-64 standard was established over 18 years ago now. 64-bit applications tend to be larger but noticeably faster on 64-bit processors, and for timings with ATX files, with an already-sluggish Qt app running on a multi-tasking desktop environment, I'd think you'd want as much performance as possible to deal with the usual Windows system overhead hiccups. I could be completely wrong with this viewpoint (wouldn't be the first time), but I can't see why you wouldn't want to produce a 64-bit binary as well, since 64-bit systems are by far the dominant modern computing platform.

 

Well, when I started working on RespeQt 4.1, I used the newest Qt Creator version which produces 64bits version of RespeQt. When I posted it, Kyle22 asked for a 32bits version. I did not manage to make a 32bits version with the newest Qt Creator. So I downgraded to an old Qt Creator able to produce 32bits RespeQt. So I don't have the 64bits Qt Creator installed anymore. Of course I can install it again but before doing that, I was wondering if it is really useful. I have a 10 years old PC running Windows 10 (so not the fastest PC you can have nowdays) and ATX protections are working well with the 32bits version of RespeQt. Maybe you're right about the performance issues.. Windows is so complex that I can not be affirmative on the impact of using COM port within a 32bits or a 64bits executable.

 

But I made many tests with ATX emulation on the 32bits version. I am currently testing all ATX found in the preservation initiative with RespeQt 4.3 to get a list of what is running or not. So, about the Windows version, my advice would be to report to me if a title does not work. As you did for Seven Cities of Gold. Then I test it also and tell you if this is a known limitation of my implementation or if there is no issue and it should work also on your side. If it does not work on your side then we can try to investigate together what is the difference and maybe the 64bit version could be a solution. I would be pleased to help you if I can. What is confusing me is that you are talking about problems or differences on 3 different platforms so it's hard to for me to get any conclusion.

 

I'd build my own Win64 binary myself, but for what it's worth, I can't build your current develop branch under Windows in Qt Creator - I get well over 40 syntax errors when I try to build the code as-is. But that's probably just something wrong on my end; I've never had any luck using the Windows version of Qt Creator even though I used to use it to compile RespeQt binaries on my Mac a few years ago.

 

That's really strange because I did not do anything special with the Qt Creator installation. I have installed it, then I impoted the project, then I requested a rebuild all and voila. I got the binary with no error (but many warnings because I left many unused methods in diskimagescp which is not implemented yet).

Again, maybe you could report to us (JoSch or me) which errors you have with which Qt Creator version and which compiler. I use MinGW.

 

[+DrVenkman]

Okay, well I switched the default Qt Creator complilers MinGW and now I get an executable build, but when I try to run it, I get error that the application cannot locate several Qt components. Which is ridiculous, since my PATH includes the full file path to them all. Oddly, if I select RUN from within Qt Creator, the application launches. Even after I run the Deploy process, I don't end up with an app that can run outside of Qt Creator.

 

I feaking *hate* trying to build code in Windows.

 

Anyway, here's what your develop branch produces for Ubuntu (and Raspbian):

 

 

So there must be some kind of conditional compile flags set in the source code for the options window, depending on the target OS.

[ebiguy]

So there must be some kind of conditional compile flags set in the source code for the options window, depending on the target OS.

 

You are probably right. I will try to look for such compile options.

[+DrVenkman]

 

You are probably right. I will try to look for such compile options.

 

I think I found what is causing the difference in interface options between OS versions. Lines 151 - 157 in optionsdialog.cpp seem to make this an Windows-only setting, though I'm not entirely sure why or what the thinking is with the various options.

 

#ifdef Q_OS_WIN

bool no_handshake = (respeqtSettings->serialPortHandshakingMethod()==HANDSHAKE_NO_HANDSHAKE);

m_ui->serialPortFallingEdge->setVisible(!no_handshake && !software_handshake);

m_ui->serialPortDTRControlEnable->setVisible(no_handshake || software_handshake);

#else

m_ui->serialPortFallingEdge->setVisible(false);

#endif

 

Like I said, I don't know why those are there or what is trying to be accomplished.

[ebiguy]

Anyway, here's what your develop branch produces for Ubuntu (and Raspbian):

 

Please, don't see any offense but I want to add more scientific rigor (or scientific accuracy if you prefer) to these investigations. If we want to compare things, then only one modification at a time is allowed. If you are comparing different sources (my develop branch and the official r4) then you must compile and run them with the same tools and on the same platform. For example, you can not compare a version you just compiled with a Linux binary of r4 sources compiled by someone else with, maybe, different flags or different library versions or other differences that I am not aware of.

If this screen shot is from your own compilation of my develop branch, could you please get the r4 release (last official release before any modifications made by me) and compile it within the same environment (same compiler, same platform) and see if the falling edge option is there or not. This way only one thing will be different from both executions: the sources. But the compilation process and the runtime environment will be identical.

 

I have downloaded r4 sources and I don't see anything different from my develop branch about the falling edge option.

In both sources (mine and original r4), I can see that some code exists to handle this option at runtime in file serialport-win32.cpp but this option is completely ignored in file serialport-unix.cpp.

So, whether this option should appear or not in the option dialog box under Linux is not relevant because there is no code to handle it in the Linux version. Or I missed something very tricky !!!

 

EDIT: we replied at the same time. We arrive at the same conclusion: Falling Edge is only for Windows version. Maybe someone can implement it on Linux...

Edited February 23, 2019 by ebiguy

[+DrVenkman]

Well here's another data point: the r4 Win32 binary release from JoeyZ's repository does not have the falling edge option either. So it was added post-r4, which is what I said a week or so ago. I'm guessing TheMontezuma added it as part of his Software handshake for SIO2BT stuff in the last couple years.

 

[_The Doctor__]

Yes themontezuma had really done a fine job working with him and then later working by himself getting a good deal of bugs and other issues solved. The falling edge was for serial the hiding of it's switch only occurs when it is not needed by the selected method in regard to none/bt etc.

 

I thought ebi asked about it earlier and assumed he was building on the best most up to date and bug free respeqt we had so far being r4

 

I'll move this over to the other laptop and see how it gets along with the Atari once more. something must not have installed cleanly on this laptop so I'll install on it's own folder on a the other one and see what's up.

[ebiguy]

Yes themontezuma had really done a fine job working with him and then later working by himself getting a good deal of bugs and other issues solved. The falling edge was for serial the hiding of it's switch only occurs when it is not needed by the selected method in regard to none/bt etc.

 

I thought ebi asked about it earlier and assumed he was building on the best most up to date and bug free respeqt we had so far being r4

 

I'll move this over to the other laptop and see how it gets along with the Atari once more. something must not have installed cleanly on this laptop so I'll install on it's own folder on a the other one and see what's up.

 

My develop branch has all the commits of everybody. It is up to date so the themontezuma's work is fully embedded in my branch.

So, yes, this branch is based on the "best most up to date and bug free RespeQt we had so far being r4".