RespeQt: Fork of AspeQt 1.0.0-preview7/r79

[+DrVenkman]

I understood it to be a massive ball-ache to compile 32-bit Qt stuff for OS X these days, possibly involving a complete re-build of Qt itself. I'll be pleased as punch if this is not the case.

 

Anyway: thanks in advance. Keen to do some testing.

 

Alright, I did that extra reading. Apparently it's more involved than I'd hoped, though not impossible by any stretch. I'd have to download Qt sources and build a separate set of 32-bit libraries, then compile the app using a 32-bit compiler. It's not something I'm likely to be able to accomplish before the weekend at any rate. Sorry FJC, nothing tonight.

[Joey Z]

I don't think 32-bit mode is the problem. I seem to recall reading about that when I first tried building OS X versions of AspeQt last summer. There's an option somewhere in Qt Creator that takes that into account and builds the binary differently. I think. I'm not at my Mac right now but I'll look into it tonight after work and see what I can figure out.

 

 

Sent from my iPhone using Tapatalk

 

you'd be looking to build 'statically'

 

What I missed with all emulations over the decades until today is a graphics print output. Text print is available only. It would be nice to have the chance to see the print results of programs like print shop, newsroom, mini office, etc. on screen, and having the option to save them as e.g bmp or jpg.

 

Yes, I've thought of that a few times. I was thinking Epson Esc/P support, and 1020 plotter support. Perhaps more in depth emulation of other Atari printers as well (stuff like the backwards/upside down/whatever text).

It has been added to the ever-growing TODO list

[flashjazzcat]

 

Alright, I did that extra reading. Apparently it's more involved than I'd hoped, though not impossible by any stretch. I'd have to download Qt sources and build a separate set of 32-bit libraries, then compile the app using a 32-bit compiler. It's not something I'm likely to be able to accomplish before the weekend at any rate. Sorry FJC, nothing tonight.

No problem. Thanks for looking into it anyway. I realize it's a bit of a niche request, and rather time consuming.

[Kyle22]

Question: Is there a way to have straight through P: with no ATASCII / ASCII translation of any kind? I have programs that supply their own printer control codes. I have had trouble with APE in this regard. I need full 8 bit throughput.

[Joey Z]

Question: Is there a way to have straight through P: with no ATASCII / ASCII translation of any kind? I have programs that supply their own printer control codes. I have had trouble with APE in this regard. I need full 8 bit throughput.

it can be added, if it doesn't already exist in some way.

[Joey Z]

My guess would be that it's the TIOCMGET ioctls in readCommandFrame().

 

A similar thing happens on Linux when using a real serial port (onboard or PCI/PCIe 16550 card).

 

The code polls for changes of the command line in a loop and that needs, well, all the available CPU time.

 

For some reason this doesn't happen with USB-serial converters on Linux, IIRC the ioctl only returns every 1ms maybe sleeping until the next status-change packet arrives from the USB-serial chip.

 

The Windows code OTOH doesn't use busy-waiting but uses WaitCommEvent() which sleeps until the state of the command line changes.

 

In Linux there's the TIOCMIWAIT which does a similar thing to the Windows implementation - but I'm not sure if this ioctl is also available on OSX or if there's some equivalent ioctl.

 

Well, I started noticing the same issues as DrVenkman (as far as SIO retries) today on linux, now that I finally have an SIO2PC to try RespeQt out with. Looking with my scope, I would guess that the issue is RespeQt taking too long to send the response after a command is received. I'm going to look further into it, but I'd also like to check if that TIOCMIWAIT call works while I'm messing with the serial code anyway.

[Joey Z]

 

Well, I started noticing the same issues as DrVenkman (as far as SIO retries) today on linux, now that I finally have an SIO2PC to try RespeQt out with. Looking with my scope, I would guess that the issue is RespeQt taking too long to send the response after a command is received. I'm going to look further into it, but I'd also like to check if that TIOCMIWAIT call works while I'm messing with the serial code anyway.

according to the SIO spec, the peripheral has up to 16 milliseconds to respond ACK to a command frame, so I don't think that's the issue. On the other hand, the peripheral is supposed to have a delay of at least 250 microseconds after the last bit of ACK is sent, and the first bit of complete is to be sent. RespeQt is NOT doing this, and I'm wondering it it's causing issues.

 

Also, this problem is very intermittent here. It was happening every time I booted, multiple times before, and now it didn't happen once.

[Joey Z]

OK, so the problem after all of this, is an issue with tcdrain() in the FTDI driver. It only waits until the system buffer is clear, not the actual buffer on the FTDI device. because of this, the 300 microsecond delay which occurs before sending Complete after a command ACK happens while the ACK is still in the TX buffer of the FTDI chip, meaning the actual delay on the far end (the atari) is *0*. This is the root cause of all the issues I think, and it's a bug in the FTDI for linux and (and I assume OSX stuff as well). That's why increasing the delay helped. I can calculate the time, for now, of 1 byte being sent at 19200 baud (about .0005 seconds I think) and add on the 250 microseconds to that, to come up with the grand total of 750 microseconds. This would slow down performance on devices where tcdrain() works properly, but would increase reliability on devices where it doesn't. At some point, I should be able to add a menu entry for all this timing stuff.

 

Anyway, I'm not sure how tcdrain is supposed to act when the device has a hardware buffer. Is this proper behavior? or should the FTDI driver be changed so that it waits until the hardware device buffer is clear? apparently the FTDI chip *does* report when it's internal buffer is empty, so it should be possible to detect. A google search reveals I am not the first one to discover this issue.

[Joey Z]

 

Well, I started noticing the same issues as DrVenkman (as far as SIO retries) today on linux, now that I finally have an SIO2PC to try RespeQt out with. Looking with my scope, I would guess that the issue is RespeQt taking too long to send the response after a command is received. I'm going to look further into it, but I'd also like to check if that TIOCMIWAIT call works while I'm messing with the serial code anyway.

so the issue with TIOCMIWAIT is that it blocks, and even thought the SIOWorker/serialport stuff is in it's own thread, apparently whatever way it's setup it blocks the UI too. so if you use TIOCMIWAIT, the UI won't register anything unless SIO emulation is off, or the command line switches states. Obviously this is not usable behavior. Of course, there should be a way to fix this, I would think, but it requires more digging. So for now, I'll stick with polling.

[+DrVenkman]

I can calculate the time, for now, of 1 byte being sent at 19200 baud (about .0005 seconds I think) and add on the 250 microseconds to that, to come up with the grand total of 750 microseconds. This would slow down performance on devices where tcdrain() works properly, but would increase reliability on devices where it doesn't. At some point, I should be able to add a menu entry for all this timing stuff.

 

That's the way the commercial program SIO2OSX handles the variable performance of different interface chips on their drivers - a menu-selectable delay. There are no units given in the menu, but you get the idea: larger = "longer delay in the transmission process". With this software, my personal FTDI device works best with a delay of 1, for instance.

 

 

so the issue with TIOCMIWAIT is that it blocks, and even thought the SIOWorker/serialport stuff is in it's own thread, apparently whatever way it's setup it blocks the UI too. so if you use TIOCMIWAIT, the UI won't register anything unless SIO emulation is off, or the command line switches states. Obviously this is not usable behavior. Of course, there should be a way to fix this, I would think, but it requires more digging. So for now, I'll stick with polling.

 

The delays I inserted in serialport-unix.cpp for OS X give me reasonable, if not optimal, performance: I can read .atr files and boot .xex files reliably at 57,600, though I cannot write reliably that fast.

 

And that brings up another oddity with how RespeQt currently handles SIO in general: when there's an issue with write speed, it does not seem to handle it very gracefully; it throws up a bunch of errors as it tries, fails, reduces speed, and tries again at the higher speed. Further, you have to tell the UI to stop emulation, manually reduce speed to 38,400 (if the Atari software accepts even that fast) or 19,200, then restart emulation in order for writes to work reliably. The software doesn't seem to know when to throw in the towel and simply accept that it has to drop back to a slower rate. It keeps trying to respect what the user has selected through the UI, regardless of whether it's working.

 

Conversely, if I simply start emulation in 38,400, using a high-speed Atari driver I can do reads and writes reliably at that rate. So long as there are no speed-related errors thrown up during writes, RespeQt is fine.

Edited July 26, 2015 by DrVenkman

[HiassofT]

Anyway, I'm not sure how tcdrain is supposed to act when the device has a hardware buffer. Is this proper behavior? or should the FTDI driver be changed so that it waits until the hardware device buffer is clear? apparently the FTDI chip *does* report when it's internal buffer is empty, so it should be possible to detect. A google search reveals I am not the first one to discover this issue.

tcdrain should consider the state of hardware buffers (FIFO, transmit holding register etc), but not all devices support this (IIRC PL2303 is such a device). It also depends on the linux kernel version you are using - some ancient kernels might lack that functionality.

 

I did a quick test here (Debian Jessie running kernel 4.1) with a 16550 serial port, a PL2303 USB-serial adapter and an FTDI FT232BM - and it looked like tcdrain is working fine.

 

I transmitted 2 bytes at 19200 bit/sec, with a tcdrain() call after each byte and recorded the timestamps and checked the serial line with my scope.

 

With the FT232BM the second byte started 2ms after the beginning of the first byte (so there was a pause of ~1.5ms between those bytes). With the PL2303 the second byte started 1ms after the beginning, so ther was a delay of approx. 0.5ms. With the 16550 I got varying delays of around 0.5ms to 1.5ms between the bytes.

 

Which kernel version are you running ("uname -a"), and are you running Linux in a VM or on a "real" computer?

 

If in doubt just add a delay of some 0.5ms, that shouldn't hurt.

 

so the issue with TIOCMIWAIT is that it blocks, and even thought the SIOWorker/serialport stuff is in it's own thread, apparently whatever way it's setup it blocks the UI too. so if you use TIOCMIWAIT, the UI won't register anything unless SIO emulation is off, or the command line switches states. Obviously this is not usable behavior. Of course, there should be a way to fix this, I would think, but it requires more digging. So for now, I'll stick with polling.

Sounds strange, but I haven't checked that yet myself.

 

Anyways, it's better to use polling and stay away from TIOCMIWAIT, that won't work with a 16550 card and command connected to RI - the 16550 only reports low-to-high changes on RI but to detect the beginning of a command frame you need high-to-low change detection.

 

Welcome to the fun of serial programming :-)

 

so long,

 

Hias

[Joey Z]

tcdrain should consider the state of hardware buffers (FIFO, transmit holding register etc), but not all devices support this (IIRC PL2303 is such a device). It also depends on the linux kernel version you are using - some ancient kernels might lack that functionality.

 

I did a quick test here (Debian Jessie running kernel 4.1) with a 16550 serial port, a PL2303 USB-serial adapter and an FTDI FT232BM - and it looked like tcdrain is working fine.

 

I transmitted 2 bytes at 19200 bit/sec, with a tcdrain() call after each byte and recorded the timestamps and checked the serial line with my scope.

 

With the FT232BM the second byte started 2ms after the beginning of the first byte (so there was a pause of ~1.5ms between those bytes). With the PL2303 the second byte started 1ms after the beginning, so ther was a delay of approx. 0.5ms. With the 16550 I got varying delays of around 0.5ms to 1.5ms between the bytes.

 

Which kernel version are you running ("uname -a"), and are you running Linux in a VM or on a "real" computer?

 

If in doubt just add a delay of some 0.5ms, that shouldn't hurt.

 

Sounds strange, but I haven't checked that yet myself.

 

Anyways, it's better to use polling and stay away from TIOCMIWAIT, that won't work with a 16550 card and command connected to RI - the 16550 only reports low-to-high changes on RI but to detect the beginning of a command frame you need high-to-low change detection.

 

Welcome to the fun of serial programming :-)

 

so long,

 

Hias

 

Linux JOE-LAPTOP-LINUX 3.13.0-58-generic #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

 

I am running an older (LTS release, IIRC) of ubuntu, so I could try upgrading.

 

[Joey Z]

I found reference to a patch someone was working on, but looking in the linux source it doesn't appear to have ever been implemented.

http://www.spinics.net/lists/linux-usb/msg71689.html

 

In usb-serial.c, there is a function serial_chars_in_buffer which makes a call to serial->type->chars_in_buffer(tty) which I believe should point to a function in ftdi_sio.c, the driver for the FTDI USB serial driver. The driver does not appear to have this function at all.

 

EDIT: the implementation was changed at a later date, looking into it...

Edited July 26, 2015 by Joey Z

[HiassofT]

Linux JOE-LAPTOP-LINUX 3.13.0-58-generic #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

 

I am running an older (LTS release, IIRC) of ubuntu, so I could try upgrading.

Hmmm, I'm not quite sure what's going on, could also be some kernel-config thing on my side. I did another test on an older PC running Debian Wheezy (with a 32-bit kernel 3.2) and also saw significantly lower delays.

 

I've attached the test program if you want to give it a try. Just compile it with gcc and start it with the serial port device as argument #1.

 

On my main PC it looks like this:

$ uname -a
Linux camel2 4.1.0 #1 SMP Tue Jun 23 22:04:48 CEST 2015 x86_64 GNU/Linux
$ ./drain-timing /dev/ttyUSB0
return values write1: 1 drain1: 0 write2: 1 drain2: 0
delay write1:          5
delay drain1:       2000
delay write2:       2003
delay drain2:       3999
delay close :       8005

But on my older PC I get these results:

$ uname -a
Linux hp 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u2 i686 GNU/Linux
$ ./drain-timing /dev/ttyUSB0
return values write1: 1 drain1: 0 write2: 1 drain2: 0
delay write1:         26
delay drain1:        194
delay write2:        202
delay drain2:        308
delay close :        820

The values are the relative delays in µs after opening the serial port. Clearly 100-200µs is too short to transmit a byte at 19200 bit/sec. Haven't checked with my scope yet, though.

 

Anyway, I think we need to be prepared for both situations and your PC seems to be quite suited for testing with the delays. The additional 1-2ms delay on some other PCs shouldn't be a problem at all.

 

so long,

 

Hias

drain-timing.zip

[HiassofT]

I found reference to a patch someone was working on, but looking in the linux source it doesn't appear to have ever been implemented.

http://www.spinics.net/lists/linux-usb/msg71689.html

 

In usb-serial.c, there is a function serial_chars_in_buffer which makes a call to serial->type->chars_in_buffer(tty) which I believe should point to a function in ftdi_sio.c, the driver for the FTDI USB serial driver. The driver does not appear to have this function at all.

 

EDIT: the implementation was changed at a later date, looking into it...

I also noticed this message, but the code should long be in the kernels. There was another issue a few months ago, affecting only 64-bit kernels, but it looks like these commits are included in your kernel as well.

 

In the meanwhile I discovered an interesting thing: I get the low delays when I connect the FTDI adapter to a USB hub, but larger delays when I plug it directly into the USB port.

 

Here are the results from my main PC when using a hub (I connected it directly before):

$ uname -a
Linux camel2 4.1.0 #1 SMP Tue Jun 23 22:04:48 CEST 2015 x86_64 GNU/Linux
$ ./drain-timing /dev/ttyUSB0
return values write1: 1 drain1: 0 write2: 1 drain2: 0
delay write1:          5
delay drain1:        243
delay write2:        245
delay drain2:        492
delay close :       1138

And here are the results of my older PC when plugging it directly into the PCI USB-card (I had a hub in between before):

$ uname -a
Linux hp 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u2 i686 GNU/Linux
$ ./drain-timing /dev/ttyUSB0
return values write1: 1 drain1: 0 write2: 1 drain2: 0
delay write1:         21
delay drain1:        952
delay write2:        960
delay drain2:       2938
delay close :       9959

I repeated the test on yet another PC running Debian Jessie with the stock 3.16 debian kernel.

Without a hub:

$ uname -a
Linux tv 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
$ ./drain-timing /dev/ttyUSB0
return values write1: 1 drain1: 0 write2: 1 drain2: 0
delay write1:          8
delay drain1:       1986
delay write2:       1989
delay drain2:       3983
delay close :       8987

And with a hub:

$ uname -a
Linux tv 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
$ ./drain-timing /dev/ttyUSB0
return values write1: 1 drain1: 0 write2: 1 drain2: 0
delay write1:          7
delay drain1:        240
delay write2:        244
delay drain2:        489
delay close :       1374

I have no idea whats causing this, but the pattern is consitent accross all 3 PCs. Low delays when using a hub, larger delays without a hub...

 

so long,

 

Hias

[Joey Z]

After more screwing around, I think I may have determined the issue. tcdrain returns when the last byte is in the process of being sent maybe. That is, it's 'not in the buffer' but it hasn't finished sending yet. If this is the case and if you need <1 byte accuracy with the timing of tcdrain, then you're screwed basically, and you just have to compensate. If I time the amount of time it takes to send a data frame in RespeQt, the number of milliseconds comes out properly, about .5ms per byte at 19200. The function I am using to test this only has millisecond precision though, so 1 byte transfers show as 0ms. Anyway, I think this could explain the issue. I wish I had a way to trigger my scope just after tcdrain returns, to be able to see where it happens on the scope, but the FTDI board I have just has DSR connected, so I can't turn on a handshaking line on the FTDI to do it.

 

I'll run your program, see what it shows, and I'll try with writing larger amounts of data as well, before the tcdrain. I suspect it will be closer to 500us/byte, than writing one byte.

[Joey Z]

here are the results of 1 byte, 2 bytes, and then 4 bytes several times

return values write1: 1 drain1: 0 write2: 1 drain2: 0
delay write1: 11
delay drain1: 132
delay write2: 137
delay drain2: 284
delay close : 542
return values write1: 2 drain1: 0 write2: 2 drain2: 0
delay write1: 9
delay drain1: 162
delay write2: 166
delay drain2: 8171
delay close : 8715
return values write1: 4 drain1: 0 write2: 4 drain2: 0
delay write1: 11
delay drain1: 3706
delay write2: 3719
delay drain2: 7681
delay close : 8081
return values write1: 4 drain1: 0 write2: 4 drain2: 0
delay write1: 15
delay drain1: 2509
delay write2: 2528
delay drain2: 6529
delay close : 6852
return values write1: 4 drain1: 0 write2: 4 drain2: 0
delay write1: 12
delay drain1: 1051
delay write2: 1056
delay drain2: 9125
delay close : 9908
return values write1: 4 drain1: 0 write2: 4 drain2: 0
delay write1: 12
delay drain1: 3495
delay write2: 3505
delay drain2: 7584
delay close : 7946

You can see than 1 and 2 bytes are significantly shorter than they should take, and then 4 bytes are significantly longer in some cases, significantly shorter in others, and overall don't seem to follow a pattern. The tcdrain call does not seem very accurate at all. I am starting to wonder, would it be better to just have RespeQt manually keep track of the time? send some data, store the time just after the data is sent, tcdrain, compare stored time to current time, sleep some more if needed, then finally return from writerawframe.

[HiassofT]

The 2nd transfer in the 2-byte case (delay 8171 on drain2) is somewhat strange, but this could be due to scheduling, i.e. some other program running in the background. Same for the 3rd 4-byte test.

 

BTW: which FTDI adapter are you using and are you using an USB hub as well?

 

I fired up wireshark and sniffed the USB traffic. 1-byte transfers when using a hub are really strange. The computer transfers the byte to the USB device, gets an ACK 44us later, 14us after that queries the modem status and 237us later gets the reply "transmitter empty" (0x60 in second status byte).

 

That's a total of 295us after the PC initiated the transmit-byte transfer and the byte can't have been transferred in that time. On multi-byte transfers I saw "transmitter+holding register" full status messages during tcdrain (2nd byte 00) so that could be some quirk in the FT232(BM).

 

Not sure if it's related (and I'm no USB expert either), but when connected directly to the USB port I saw the repeated status messages (sent by the FTDI chip every 1ms or so) plus the host ACK between the "transmit byte" message and the "transmit byte" ACK from the device. Very strange...

 

I think getting rid of tcdrain() completely isn't a good idea. At least it ensures that the bytes queued in the kernel are being sent out. I think it's best to do a tcdrain() followed by a 500-1000us delay and hope that's working.

 

Getting more precise timing than +/- a few ms with USB-serial adapters might be impossible after all.

 

so long,

 

Hias

[Joey Z]

The 2nd transfer in the 2-byte case (delay 8171 on drain2) is somewhat strange, but this could be due to scheduling, i.e. some other program running in the background. Same for the 3rd 4-byte test.

 

BTW: which FTDI adapter are you using and are you using an USB hub as well?

 

I fired up wireshark and sniffed the USB traffic. 1-byte transfers when using a hub are really strange. The computer transfers the byte to the USB device, gets an ACK 44us later, 14us after that queries the modem status and 237us later gets the reply "transmitter empty" (0x60 in second status byte).

 

That's a total of 295us after the PC initiated the transmit-byte transfer and the byte can't have been transferred in that time. On multi-byte transfers I saw "transmitter+holding register" full status messages during tcdrain (2nd byte 00) so that could be some quirk in the FT232(BM).

 

Not sure if it's related (and I'm no USB expert either), but when connected directly to the USB port I saw the repeated status messages (sent by the FTDI chip every 1ms or so) plus the host ACK between the "transmit byte" message and the "transmit byte" ACK from the device. Very strange...

 

I think getting rid of tcdrain() completely isn't a good idea. At least it ensures that the bytes queued in the kernel are being sent out. I think it's best to do a tcdrain() followed by a 500-1000us delay and hope that's working.

 

Getting more precise timing than +/- a few ms with USB-serial adapters might be impossible after all.

 

so long,

 

Hias

I did not mean to get rid of tcdrain() entirely. I meant that I would send the data, store the time, call tcdrain(), and then check if the amount of time which has elapsed is at least a certain amount, depending on data and baudrate. If the time elapsed is short by some amount, I would usleep for the rest of the time.

 

Anyway, I'm not messing with it now. For now, the temporary fix is another ~400-500 micro seconds of delay on Operation Complete and Operation Error responses. I'll do that some time later today (it's 12:21AM on a monday here). Long term, I will make the delay accessible in the config menu and add some description of what they do, and why you might want to mess with it in the documentation.

 

EDIT: forgot to mention, I'm using an FT232RL, plugged directly into the USB port on my laptop no hubs.

Edited July 27, 2015 by Joey Z

[_The Doctor__]

bottom line can I download RespeQT for windows and simply click install and have it work?

[+DrVenkman]

bottom line can I download RespeQT for windows and simply click install and have it work?

Wow, two month necro post. There is an update thread, by the way, for RespeQt r2. I don't know if there is a Windows build yet - you'd have to follow the link to the Github repository and check the file downloads to see. I have built OS X binaries for download but have no experience building Windows binaries.

 

 

Sent from my iPhone using Tapatalk

[RodLightning]

Yes, RespeQt r2 for Windows works fine. There is no installer package, just extract the files to a directory and run.

You will need to select proper COM port, handshake method and baud rate in tools->options, to match your hardware setup.

 

Check out the r2 thread here:

 

http://atariage.com/forums/topic/241055-respeqt-r2-released/

[atarixle]

without reading the whole thread, here I introduce my build of RespeQt (built from the Sept 13 2015 snapshot of the RespeQt-master zip from this location: https://github.com/jzatarski/RespeQt) ... built on Debian Jessie 64 bit

 

download location and additional hints at http://www.abbuc.de/~atarixle/download/#respeqt

(as I didn't read the this thread, I don't know if this is these were the most current sources)

Edited September 14, 2015 by atarixle

[+DrVenkman]

without reading the whole thread, here I introduce my build of RespeQt (built from the Sept 13 2015 snapshot of the RespeQt-master zip from this location: https://github.com/jzatarski/RespeQt) ... built on Debian Jessie 64 bit

 

download location and additional hints at http://www.abbuc.de/~atarixle/download/#respeqt

(as I didn't read the this thread, I don't know if this is these were the most current sources)

Thanks for that but you really should read all three of the thread titles before deciding where to post. You posted in the thread announcing the fork and creation of the project. There have been two releases since then: r1 and r2. Considering the date of the sources you built from, your build is closer to r2 than the first fork. If anything, it's "r3-minus" or something.

 

 

Sent from my iPhone using Tapatalk

[Joey Z]

without reading the whole thread, here I introduce my build of RespeQt (built from the Sept 13 2015 snapshot of the RespeQt-master zip from this location: https://github.com/jzatarski/RespeQt) ... built on Debian Jessie 64 bit

 

download location and additional hints at http://www.abbuc.de/~atarixle/download/#respeqt

(as I didn't read the this thread, I don't know if this is these were the most current sources)

yes, these are the most current sources. I haven't made any changes since r2. I can add your build to the releases section on github, if you'd like.