RespeQt r3 released

[Joey Z]

RespeQt release 3

* removed settings migration feature due to foreseeable

incompatibilities between AspeQt settings and RespeQt settings

* code cleanup by TheMontezuma to reorganize various SIO constants into

a pair of enumerations

* updated contact info in readme.txt (thanks to Kyle22 IIRC)

* fix for hardware handshaking issue in Windows which could cause data

which are not commands to be interpreted as commands. (issue #21)

* fix for performance issue with Software Handshaking using wired

SIO2PC (issue #21)

* Software handshaking for bluetooth (TheMontezuma)

* fix for serial port name in log windows (TheMontezuma)

* format command timeout value fixed (TheMontezuma)

* bug fix for COM ports higher than COM9 in windows (TheMontezuma)

* Spanish language update, thanks to ascrnet

* reorganization of messy HTML in about.html, thanks to ascrnet

* Spanish version is included in the about.html, thanks to ascrnet

* fixed broken language option in about dialog (#14)

* reorganization of messy HTML in RespeQt User Manual-English.html,

thanks to ascrnet

 

NOTE: software and 'none' handshaking have small risks of data loss when used alongside real atari devices. The risk arises from the slight possibility that some consecutive 5 bytes will form a valid format command and cause a drive in RespeQt to format. The risk is miniscule, but existent, so it's worth mentioning. Hardware handshaking does not carry this risk.

 

https://github.com/jzatarski/RespeQt/releases

 

There is source, as well as a win32 build, and I suspect DrVenkman will upload an OSX build when he gets a chance.

 

I am officially declaring the win32 build as stable now, since nobody has reported any issues with the win32 releases that have not been fixed.

 

the current ever-growing todo list:

put NONE and software handshake data loss warnings in documentation (there's always something I forget to do when a release comes around)

need to deal with AspeCL at some point

translations

sioworker.cpp: have devices provide their own string for debug output? - SioWorker::deviceName

Qt4 version?

R: support

folder imaging write support

SDFS folder imaging

better printer support - MX-80 and 1020, possibly others. direct to file, full 8 bit support, etc.

VAPI/ATX

conditional compilation for nativeMenuBar stuff in OSX

PCLINK.SYS support?

XF551 compatibility issue: http://atariage.com/forums/topic/241055-respeqt-r2-released/?p=3427201

[+DrVenkman]

Updating Xcode now. A new OS X build should be up tonight.

 

EDITED: Okay, Github has an OS X build available now, and I'll attach it directly here as well.

 

RespeQt-OSX.zip

Edited March 16, 2016 by DrVenkman

[TheEditor]

Has git been updated so I can compile a new Pi version?

 

Sent from my LG-V496 using Tapatalk

[Joey Z]

Has git been updated so I can compile a new Pi version?

 

Sent from my LG-V496 using Tapatalk

Yes, git stays up to date. Still, I recommend you download source from the releases page. The 'master' source may have unstable changes. Currently, it doesn't, but at any given time it could.

[GoodByteXL]

RespeQt release 3

...

Great, thanks for your ongoing efforts, will try it later today.

 

@AtariXLE:

RespeQt version 1 & 2 for linux (debian 64) work fine (except some hassles with SIO highspeed).

will you catch up soon?

[TheMontezuma]

I hope we can count on Hias regarding SIO highspeed improvements for linux

[GoodByteXL]

I hope we can count on Hias regarding SIO highspeed improvements for linux

I guess Hias is the only A8 user with appropriate insights :-).

 

RespeQt R3 so far works fine on Win 7-64 & 32. Not tested yet on Win 10.

 

While reading the user manual I spotted an editing failure: the first mentioning of SD 3.2f is an incomplete paragraph.

The second mentioning is the same para but complete, as it seems. Nevertheless it needs correction:

 

At first it should read SD 3.2G as version F is a buggy version superseeded by G as declared by FTE when it was released as shareware back in 1994.

 

Then

You can not load drivers or run an autorun.bat file during the boot process

was fixed already with version AspeQt 0.6 iirc,

 

Once booted from, a Folder Image won't be bootable again until ...

same as above. Enter RUN E477 on the command line and watch it reboot and load e.g. a rtc driver.

 

SpartaDOS and SpartaDOS X work pretty good with AspeQt/RespeQt on Win (Speed PD 0) and Linux (Speed PD 4), cannot say for MacOX.

 

The speed issue under Linux seems to be related to a failure in timing adjustments between the A8 and the pc side as they do not exist under Win. One can help this by using a FIFO on the A8 side, which accelerates up to PD 0 (e.g. SD 3.2G) depending on the capabilities of the software.

 

What puzzles me most is that the UltraSpeed driver of the IDE+ 2.0 (Rev C here) speeds up every software always under Win to PD 0 whereas the same under Linux leads to instant timing errors and stops transfering.

 

The pc hardware for both Win 7-64 and Linux 64 is the same, just two different hard drives.

[Joey Z]

RespeQt R3 so far works fine on Win 7-64 & 32. Not tested yet on Win 10.

good to hear.

 

While reading the user manual I spotted an editing failure: the first mentioning of SD 3.2f is an incomplete paragraph.

The second mentioning is the same para but complete, as it seems. Nevertheless it needs correction:

 

At first it should read SD 3.2G as version F is a buggy version superseeded by G as declared by FTE when it was released as shareware back in 1994.

That's not incorrect. RespeQt comes with a copy of 3.2F, that's why the docs are that way. I haven't changed the boot files since I forked it. Would someone get mad if I stripped the boot sectors and files off a 3.2G disk?

 

Then

was fixed already with version AspeQt 0.6 iirc,

 

same as above. Enter RUN E477 on the command line and watch it reboot and load e.g. a rtc driver.

 

SpartaDOS and SpartaDOS X work pretty good with AspeQt/RespeQt on Win (Speed PD 0) and Linux (Speed PD 4), cannot say for MacOX.

Have you tested these recently? I'd like to be sure before I update the manual.

 

The speed issue under Linux seems to be related to a failure in timing adjustments between the A8 and the pc side as they do not exist under Win. One can help this by using a FIFO on the A8 side, which accelerates up to PD 0 (e.g. SD 3.2G) depending on the capabilities of the software.

 

What puzzles me most is that the UltraSpeed driver of the IDE+ 2.0 (Rev C here) speeds up every software always under Win to PD 0 whereas the same under Linux leads to instant timing errors and stops transfering.

 

The pc hardware for both Win 7-64 and Linux 64 is the same, just two different hard drives.

The speed issue is a result of all USB serial adapters being horrible in general. You have one timing setting, and you get issues at 19200. Another timing value, you've got issues at divisor 0. USB-serial adapters just don't have accurate enough timing to work for everything. As I said before somewhere else, it's a real crapshoot.

 

EDIT: source for the windows and linux serial backends are separate, which explains the difference between windows and linux performance, BTW.

Edited March 17, 2016 by Joey Z

[+DrVenkman]

SpartaDOS and SpartaDOS X work pretty good with AspeQt/RespeQt on Win (Speed PD 0) and Linux (Speed PD 4), cannot say for MacOX.

 

 

 

I don't bother messing around with manually setting a POKEY divisor but I can tell you that through r2, RespeQt works great at 38,400 on OS X and through 57,600 on my RPi2. I haven't actually done any speed tests with r3 yet, nor compiled it on the RPi2.

[TheMontezuma]

I attached the R3 Binaries for Raspberry Pi:

RespeQt-r3.tar.gz

 

@Joe

Could you please upload it to Github?

 

How to get a desktop icon:

1) Extract "RespeQt-r3" to your HOME folder (/home/pi/)

2) Open a terminal and type in:

cd Desktop
ln -s ../RespeQt-r3/RespeQt.desktop .

Now you can just doubleclick the icon on the desktop.

 

The tool is started via respeqt.sh script.

You may edit the script and uncomment the line for automatic binding of the Bluetooth device (just remove the '#' character at the beginning of the line and edit the BT address).

 

BTW:

I tested the Windows binaries on the WIN10 (64bit) and on WIN7 (64bit).

Edited March 18, 2016 by TheMontezuma

[Joey Z]

@Joe

Could you please upload it to Github?

done

[GoodByteXL]

 

GoodByteXL, on 17 Mar 2016 - 9:12 PM, said:

Nevertheless it needs correction:

At first it should read SD 3.2G as version F is a buggy version superseeded by G as

declared by FTE when it was released as shareware back in 1994.

That's not incorrect. RespeQt comes with a copy of 3.2F, that's why the docs are

that way. I haven't changed the boot files since I forked it. Would someone get mad

if I stripped the boot sectors and files off a 3.2G disk?

 

Though having no programming capabilities I would go for the most accurate version.

 

Does it have any outcome which SD version is used?

 

 

GoodByteXL, on 17 Mar 2016 - 9:12 PM, said:

SpartaDOS and SpartaDOS X work pretty good with AspeQt/RespeQt on Win (Speed PD 0)

 

and Linux (Speed PD 4), cannot say for MacOX.

Have you tested these recently? I'd like to be sure before I update the manual.

 

 

This is daily business as I use it that way. Currently testing SDX 4.48 for the

updates to the user guide and frequently using SD 3.2G and also Steven's RealDOS, I

haven't seen it fail in more than a decade.

 

 

GoodByteXL, on 17 Mar 2016 - 9:12 PM, said:

The speed issue under Linux seems to be related to a failure in timing adjustments

between the A8 and the pc side as they do not exist under Win. One can help this by

using a FIFO on the A8 side, which accelerates up to PD 0 (e.g. SD 3.2G) depending

on the capabilities of the software.

What puzzles me most is that the UltraSpeed driver of the IDE+ 2.0 (Rev C here)

speeds up every software always under Win to PD 0 whereas the same under Linux

leads to instant timing errors and stops transfering.

 

The pc hardware for both Win 7-64 and Linux 64 is the same, just two different hard

drives.

The speed issue is a result of all USB serial adapters being horrible in general.

You have one timing setting, and you get issues at 19200. Another timing value,

you've got issues at divisor 0. USB-serial adapters just don't have accurate enough

timing to work for everything. As I said before somewhere else, it's a real

crapshoot.

 

I wouldn't sign that as my experiences are different. It seems to depend very much on the hard-/software combo on the pc side and how it manages the USB ports. Even when using the first USBtoSerial breakout boards from prolific were working well as soon as the right conditions for the pc combo was found.

 

Same applies to the story about the 4 capacitators in XL/XE which are recommended to be de-soldered. I never experienced any influence of these concerning SIO2PC with RS232 or USB2Serial. Nevertheless, following the proposal of the makers of the IDE+ I desoldered last week those caps in a 600XL to see if this causes the speed problems under Linux when using the Ultra Speed driver of the IDE+. No difference.

 

EDIT: source for the windows and linux serial backends are separate, which

 

explains the difference between windows and linux performance, BTW.

I guess that's the real reason why the performance is so different. With Win7 I even had "waving" transfer rates with a Asus M3N mainboard and a AMD processor up to PD 0. It sounded like a record player that cannot keep its rpm. To "fix" this I started a tool to get the processor to 100%. With Linux on the same system the max. was 3xSIO.

 

 

I don't bother messing around with manually setting a POKEY divisor...

 

Hey, that's what it's all about, having a real fast SIO connection to the pc/mac. My preset PD is always 0 until something else proofs a need to change it.

 

P.S.: Sorry for the bad quoting, but the forum software under FF on Win7 and Linux doesn't allow any proper writing here. I have to do copy & paste from/to a text editor.

[Joey Z]

This is daily business as I use it that way. Currently testing SDX 4.48 for the

updates to the user guide and frequently using SD 3.2G and also Steven's RealDOS, I

haven't seen it fail in more than a decade.

OK, just to be clear, you tested these issues specifically when booting sparta from a bootable folder, right? That's when the issues listed in the docs occur.

 

I wouldn't sign that as my experiences are different. It seems to depend very much on the hard-/software combo on the pc side and how it manages the USB ports. Even when using the first USBtoSerial breakout boards from prolific were working well as soon as the right conditions for the pc combo was found.

Well yeah, that's what I'm saying. There's no way to be sure you're going to get good results. USB to serial converters just aren't going to be consistent from machine to machine, and aren't even all that consistent byte to byte. For that matter, real serial ports might not be either, although that's been less of an issue in my experience. But if you look at serial data transfer with an oscilloscope, you can easily see the timing jitter on the USB-serial converters.

[GoodByteXL]

OK, just to be clear, you tested these issues specifically when booting sparta from a bootable folder, right?

Ups, you're true, I was riding the wrong horse, sorry. The "bootable folder" A:/D1: isn't really usable with SpartaDOS. The folder option gets just used here to copy files to hard disk images.

 

Nevertheless, if SD 3.2G could be made available, it would omit the errors built into SD 3.2F (hopefully).

[atarixle]

Get my Linux builds of R3 here:

 

http://www.abbuc.de/~atarixle/download/#respeqt

[atarixle]

Thanks to the power of the VirtualBox, you get five builds of RespeQt R3 here: http://www.abbuc.de/~atarixle/download/#respeqt

 

it is built for

debian 8.2 x86

debian 8.2 x86_64

debian 7.9 x86_64 QT5static

Ubuntu 12.04 LTS x86_64 QT5static

Ubuntu 14.04 LTS x86_64 QT5static

Edited March 20, 2016 by atarixle

[Joey Z]

Ups, you're true, I was riding the wrong horse, sorry. The "bootable folder" A:/D1: isn't really usable with SpartaDOS. The folder option gets just used here to copy files to hard disk images.

 

Nevertheless, if SD 3.2G could be made available, it would omit the errors built into SD 3.2F (hopefully).

It seems extracting the boot files out of a spartados ATR is a nontrivial process. I took a quick look at it just now, but I don't think I'll be able to make very much progress right now without taking a more in depth look. Given what time it is, I think I'll just go to bed instead, and catch up on lost sleep in the last semester of school.

[GoodByteXL]

Thanks to the power of the VirtualBox, you get five builds of RespeQt R3 here: http://www.abbuc.de/~atarixle/download/#respeqt

 

it is built for

debian 8.2 x86

debian 8.2 x86_64

debian 7.9 x86_64 QT5static

Ubuntu 12.04 LTS x86_64 QT5static

Ubuntu 14.04 LTS x86_64 QT5static

debian 8.2 x86_64 works just fine under Linux Mint Cinnamon 17-2 64bit :-)

 

It seems extracting the boot files out of a spartados ATR is a nontrivial process. I took a quick look at it just now, but I don't think I'll be able to make very much progress right now without taking a more in depth look. Given what time it is, I think I'll just go to bed instead, and catch up on lost sleep in the last semester of school.

Don't know anything about this process, but if I can help please let me know.

[morelenmir]

RespeQt release 3

* removed settings migration feature due to foreseeable

incompatibilities between AspeQt settings and RespeQt settings

* code cleanup by TheMontezuma to reorganize various SIO constants into

a pair of enumerations

* updated contact info in readme.txt (thanks to Kyle22 IIRC)

* fix for hardware handshaking issue in Windows which could cause data

which are not commands to be interpreted as commands. (issue #21)

* fix for performance issue with Software Handshaking using wired

SIO2PC (issue #21)

* Software handshaking for bluetooth (TheMontezuma)

* fix for serial port name in log windows (TheMontezuma)

* format command timeout value fixed (TheMontezuma)

* bug fix for COM ports higher than COM9 in windows (TheMontezuma)

* Spanish language update, thanks to ascrnet

* reorganization of messy HTML in about.html, thanks to ascrnet

* Spanish version is included in the about.html, thanks to ascrnet

* fixed broken language option in about dialog (#14)

* reorganization of messy HTML in RespeQt User Manual-English.html,

thanks to ascrnet

 

NOTE: software and 'none' handshaking have small risks of data loss when used alongside real atari devices. The risk arises from the slight possibility that some consecutive 5 bytes will form a valid format command and cause a drive in RespeQt to format. The risk is miniscule, but existent, so it's worth mentioning. Hardware handshaking does not carry this risk.

 

https://github.com/jzatarski/RespeQt/releases

 

There is source, as well as a win32 build, and I suspect DrVenkman will upload an OSX build when he gets a chance.

 

I am officially declaring the win32 build as stable now, since nobody has reported any issues with the win32 releases that have not been fixed.

 

the current ever-growing todo list:

put NONE and software handshake data loss warnings in documentation (there's always something I forget to do when a release comes around)

need to deal with AspeCL at some point

translations

sioworker.cpp: have devices provide their own string for debug output? - SioWorker::deviceName

Qt4 version?

R: support

folder imaging write support

SDFS folder imaging

better printer support - MX-80 and 1020, possibly others. direct to file, full 8 bit support, etc.

VAPI/ATX

conditional compilation for nativeMenuBar stuff in OSX

PCLINK.SYS support?

XF551 compatibility issue: http://atariage.com/forums/topic/241055-respeqt-r2-released/?p=3427201

 

Many thanks Joey Z!!! I am looking forward to testing this out.

 

If its a question of votes then please count me as a 'Yay' for removing that question mark from the PCLINK.SYS entry!!!

[TheMontezuma]

I can report some progress regarding PCLINK. The sio2bsd code (integrated locally to RespeQt) compiles, however does not work yet. I'm working on that, but it will take a few more days.

[morelenmir]

A few weeks ago I mentioned I was experiencing a total connectivity failure with RespeQT seeming to lose or 'forget' its virtual COM port via my SIO2PC, despite being plugged in all the time. The consensus seemed to be this was a local driver issue, which did indeed seem logical. I may be jumping the gun a little, but I think I have solved the problem. After some investigation I discovered there were at least three separate copies of the FTDI drivers on my machine; two had been installed from the official releases and one from Microsoft via Windows Update. I guess it could have been these pieces of software were conflicting with one another and causing the issue. Accordingly I used the 'FTClean' tool which used to be available directly from tthe FTDI 'Tools' website and supposedly removes every trace of their drivers. This it seemed to do - with the qualification that while the official FTDI releases were indeed deleted, the Windows Update/Microsoft drivers were not. Whatever the case, after rebooting several times - principally due to the totally unrelated and ongoing nVidia 'black screen' issues - and leaving the machine overnight I returned this morning to power-up both PC and A8 to find... RespeQT was immediately recognized as an SIO device by the A8 and its emulated drives worked fully.

 

So; a fix? It seems so for now, although I have been hopeful in the past and then found that problems lingered. It is also possible that the new code introduced with r3 also aided the problem. I guess time will tell.

 

For those interested I have included a copy of the 'FTClean' utility here as it seems to be no longer available direct:

 

FTDI Cleaner.rar

 

So far as I know it is free of viruses/malware and I have used the app several times myself without seeming harm. However, it goes without saying that all files downloaded from the internet should be treated with a degree of suspicion until you are personally satisfied with their safety.

[GoodByteXL]

For those interested I have included a copy of the 'FTClean' utility here as it seems to be no longer available direct:

Should be here for Windows:

http://www.ftdichip.com/Support/Utilities/CDM_Uninst_GUI_Readme.html

[Joey Z]

Ups, you're true, I was riding the wrong horse, sorry. The "bootable folder" A:/D1: isn't really usable with SpartaDOS. The folder option gets just used here to copy files to hard disk images.

 

Nevertheless, if SD 3.2G could be made available, it would omit the errors built into SD 3.2F (hopefully).

I think I have managed to extract the boot files out of the 3.2G ATR I found, can you please see if you can test this in place of the $bootspa/$boot.bin file for folder boot of sparta?

 

EDIT: old file was wrong, fixed now.

 

EDIT: file was wrong again, working on fixing now. fixed now hopefully

$boot.bin

Edited March 23, 2016 by Joey Z

[Joey Z]

I think I have managed to extract the boot files out of the 3.2G ATR I found, can you please see if you can test this in place of the $bootspa/$boot.bin file for folder boot of sparta?

 

EDIT: old file was wrong, fixed now.

 

EDIT: file was wrong again, working on fixing now. fixed now hopefully

This file has been reported as working, and has been pushed to git. It will be included in the next release.

[Bikerbob]

This fork of the software works with the original Nick Kennedy serial SIO2PC does it not? I just pulled mine out and want to start using it with a windows based interface.

 

thanks

 

James