Jump to content
Joey Z

RespeQt r3 released

Recommended Posts

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

 

 

It should work with anything that can connect to a standard Windows COM: port, but it's been a long damn time since I've had anything connected to a machine through an old school RS-232 serial connection.

  • Like 1

Share this post


Link to post
Share on other sites

yeah I guess one of those SIO to SD items would keep the desktop smaller, and hell a $10 8g sd card will hold more than I could ever put on it.

 

This might be in the future .. if I keep going with my atari's again.. I am more a hardware hack than a software guy.. one of the reasons I loved 8bits.. and I love the fact there were parts of the world that just keep on chugging with these computers. Disposable NA.. grrrr

Share this post


Link to post
Share on other sites

I use two "solutions," myself. First, an SIO2USB device based on the FTDI serial chip and RespeQt. Works great and infinitely flexible. In fact, with RespeQt now running on my Raspberry Pi, I plan to mount the Pi inside an old Atari peripheral with a touchscreen interface and keep it connected pretty much full-time.

 

Second, I installed an Ultimate 1MB board inside my "daily driver" 800XL and use it along with a SIDE2 cart for fast virtual CF-based hard disk storage and .XEX/.ATR loading.

Share this post


Link to post
Share on other sites

I use two "solutions," myself. First, an SIO2USB device based on the FTDI serial chip and RespeQt. Works great and infinitely flexible. In fact, with RespeQt now running on my Raspberry Pi, I plan to mount the Pi inside an old Atari peripheral with a touchscreen interface and keep it connected pretty much full-time.

 

Second, I installed an Ultimate 1MB board inside my "daily driver" 800XL and use it along with a SIDE2 cart for fast virtual CF-based hard disk storage and .XEX/.ATR loading.

 

Yes I will be doing pretty much everything you said here.. this looks like the best way for me to do the 8-bit thing. Get everything from Lotharek's Lair, sio2usb, side2, U1mb.

 

James

Share this post


Link to post
Share on other sites

it seems like my Linux port does have a lot of timing issues while on Windows everything works fine.

 

Can you tell me, how to build RespeQt on Linux properly? May be I have to add some compiler flags to make RespeQt run better? At the moment I'm not adding any flag to any of the commands I type into the bash.

Share this post


Link to post
Share on other sites

it seems like my Linux port does have a lot of timing issues while on Windows everything works fine. Can you tell me, how to build RespeQt on Linux properly? May be I have to add some compiler flags to make RespeQt run better? At the moment I'm not adding any flag to any of the commands I type into the bash.

What is the reason to make you think that way?

 

Your Debian builds are in use here running very properly under Linux Mint 17-3 Cinnamon 64-bit up to High Speed Modus Pokey Divisor 0.

post-18804-0-72602900-1462119352_thumb.png

Edited by GoodByteXL

Share this post


Link to post
Share on other sites

We were trying to run RespeQt on several Ataris during the AIB Meeting yesterday, and nearly all configurations (changed cables, PCs, Ataris) were experiencing trouble on Linux using my build. May be or may not, it can be caused by the QT5static build - or by the RespeQt build ... I don't know.

 

I will check out several of my configs I have at home (serial, USB, debian wheezy 32 bit, and so on ...).

 

What flags might have been given to the Win32 build?

Share this post


Link to post
Share on other sites

I have a totally bizarre problem here...

 

Turn off the A8, plug in the SIO2PC to both Atari and PC and then start up Respeqt. I attach a DOS2.5 disk as D1: and then start the A8. DOS2.5 loads properly. I then go in to DOS and try option A for a disk directory of the D1: and... after a handshaking buzz get error 138!!! But... The thing can see the disk as it happily reads in DOS on first start up....

 

This is at all standard transfer rates.

 

Weirder still this was working perfectly yesterday!

 

I am at a loss.

Share this post


Link to post
Share on other sites

Update:

 

This has got something to do with the 'Device Manager->Ports->USB Serial Port->Properties->Port Settings->Advanced...->Selective Suspend Idle Timeout(secs)' settings. At the default value of 5 seconds I cannot get the Atari to work with the emulated disks even after booting from one. Set at the maximum 3600 seconds it works properly. I would guess what is happening is the port is being sent to sleep after 5 seconds of no data throughput. Perhaps RespeQT needs to send some kind of keep alive signal to the port every second or so to stop 'Selective Suspend' kicking in. I guess if I leave the machines connected, switched on but idle for 3600 seconds it will again go to sleep and stop receiving commands from the A8.

 

Sadly I need to have 'Selective Suspend' enabled in these settings and the 'Power management' control panel applet in order to prevent the weird, maybe related, maybe not disconnection failure I described here some months ago.

 

For the record. I am using a home-made SIO2PC based on the Sparkfun FT232RL breakout board which otherwise works properly, even at POKEY divisor 0. I have installed (and removed and reinstalled many times over!) the newest official FTDI drivers.

 

I also cannot get Montezuma's fork with PCLink built in to work, despite the PCLink driver under SDX properly recognizing that a PCLink server is available. But that is another story for another thread!

Share this post


Link to post
Share on other sites

As I see it the problem is that in the Atari world the drives never speak unless spoken-to, so RespeQT cannot really keep pinging the USB port to keep it awake, not unless it does so every 600ms or something, which sounds like a resource hog. I guess you could synchronize a 'keep alive' timer setting in RespeQT to whatever value you give 'Selective Suspend Idle Timeout'. Another approach might be to alter the wiring inside the SIO2PC so that you cross-patch the handshaking signal to whichever pin on the FT232RL wakes it up from suspend. If there is one - maybe 'SLEEP''?

Edited by morelenmir

Share this post


Link to post
Share on other sites

So - you got this fixed by fiddling with the driver settings?

 

I told you I was doing myself in by crowing about my success earlier Jon!!!

 

The answer is yes and no... I have just posted another update with further details.

 

Its these FTDI drivers and chip, they seem hell bent to power down the port at all costs. I think some of the clone ICs benefit from not being as 'well' made and respectful of the environment!

Edited by morelenmir

Share this post


Link to post
Share on other sites

 

Its these FTDI drivers and chip, they seem hell bent to power down the port at all costs.

Hm, this sounds strange. As I learned by doing it's more or less the combo hw/sw on the pc side. Most problems to me in using AspeQt/RespeQt occurred on systems with AMD processors and weak USB designs. And of course a original FTDI breakout board should be used. I never had to fiddle with any driver to get it working on my current hardware/software. It's just plug & paly on Linux and Win.

 

Recorded a few minutes ago the start of RespeQt 3 on Linux Mint 17.3 Cinnamon 64 bit and the boot of SpartaDOS 3.2G (50Hz version). It works perfect also under Windows 7 Pro 64 bit on the same hardware.

 

See the attached video.

R3_LM17_3.mp4

Edited by GoodByteXL

Share this post


Link to post
Share on other sites

Reading through the FT232R datasheet it seems that when the device is in USB suspend mode it can be woken by taking the RI line low. Therefore as the Atari SIO transmits control signals as active on low you could cross-patch the SIO command-line to RI - that is the handshking line - and it should ensure the SIO2PC is 'awake' when data is being sent to it.

Share this post


Link to post
Share on other sites

Surely it should wake up anyway if RI is used for the SIO command line (with handshaking set to "RI" in RespeQt")?

 

True enough! I had momentarily forgotten that RI was used that way, or could be - ironic as I went out of my way to make the handshaking flexible on my box!!!

 

Supposedly the 'wake up' behaviour is set in the FT232 EEPROM and enabled by default. Yet i find the device it still suspends unless I have set the timeout to a long delay in Device Manager and doesn't wake up on RI... I wonder if the EEPROM setting is not as claimed. I will have a look at that next.

 

Update:

 

Nope, 'USB Remote Wakeup' is properly enabled.

Edited by morelenmir

Share this post


Link to post
Share on other sites

I am continuing to investigate, but this is a summary of my current findings after many hours of false leads and dead ends.

 

The problem:

  • If I disable 'Selective Suspend' either globally for Windows or specifically for the FT232 virtual COM port then the SIO2PC/RespeQT pair will only function properly for a brief period. It will cease to work after an indeterminate but short time - ~10 min - and only resume when the SIO2PC is physically unplugged from the USB socket and then replugged - a hardware reset. The 'software reset' through RespeQT as described below does not work, nor does disabling then enabling its VCP entry in Device Manager. In fact if the latter is attempted the device will cease to function entirely and Device Manager will report a 'Code 10' error which is only lifted by rebooting the whole PC.

Investigative findings:

  • Broadly speaking the SIO2PC and RespeQT pair does work properly when I ensure 'Selective Suspend' is enabled both globally and locally.
  • A further wrinkle is once 'Selective Suspend' activates - after an idle interval that can be specified in the VCP advanced settings from 5 secs to 3600 secs - the device again ceases to function. Moreover, even though - according to the FT232 datasheet - pulling the RI line low should wake it from suspend in practice this does not happen.
  • It is possible to wake it by clicking on RespeQT's status bar connection icon to disconnect and then clicking again to reconnect - a software reset.

Possible solutions:

  • A kludge for this would be to add a setting within RespeQT to automatically disconnect/reconnect itself after a set period of time. This period could be synchronized with the 'Selective Suspend' idle interval so it occurs within that period. A far from ideal solution.

At the end of the day, this is most likely some problem with my Windows 7 installation. I don't think it is hardware related as there are no similar symptoms with other USB devices. It is definitely not a problem with the physical FT232 as I have experienced identical behaviour with two different chips. It must therefore be an incompatibility or conflict with the FTDI drivers. So long as I enable 'Selective Suspend' as described above then it is manageable via the software reset in RespeQT. Obviously this should not be necessary and for all other SIO2PC users it is not. However right now I am out of ideas!

Share this post


Link to post
Share on other sites

Couple of thing I've noticed in R3 (with Windows 10 64-bit):

 

1) Drive slot disk IDs appear to rely on monospacing of numerals for alignment. This works fine until we get to drive "J:" and beyond, at which point the horizontal alignment of the ensuing controls is all messed up.

2) Log windows open multiple instances and seem to take a bit of getting rid of. I had three open windows, closed them down, and three appeared to suddenly pop up again subsequently.

 

EDIT: specifically, all previously closed log windows may spontaneously reappear after closing the Options dialog.

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

I noticed the source for ASPECL is missing so while I was messing around with other device related stuff I wrote a replacement (RCL: RespeQt Client):

 

rcl.zip

 

Not sure if it's of any use or if anyone uses it, but at least the source is there and it can be changed if needed. It attempts to be 100 per cent compatible with ASPECL and it appears to do the job.

 

This is the first time I messed with the client and I noticed a few oddities and shortcomings while creating an implementation based on the MISCDEVICES source:

  • The 'All drives' ID ('*') is converted to $FA since it has $30 subtracted from it, just like an ASCII digit. Wondered at first why the server was looking for -6. :o Maybe $00 would be a good choice for "all drives"... or even the asterisk character itself?
  • The server expects IDs (J-O) for drives 10-15 to be encoded as $1A-1F instead of a perhaps more logical $0A-$0F. This is a result of the alpha character having $30 subtracted from it in the original client, I guess.
  • There's currently no way to obtain a list of files on the server or specify a path for ATRs, etc. Nor is there any way to specify a preferred slot for a disk mount.

With a slightly fuller set of commands, we could have something like the SIO2SD client, but really it depends if anyone's going to use it.

 

 

 

  • Like 2

Share this post


Link to post
Share on other sites

I noticed the source for ASPECL is missing so while I was messing around with other device related stuff I wrote a replacement (RCL: RespeQt Client):

 

attachicon.gifrcl.zip

 

Not sure if it's of any use or if anyone uses it, but at least the source is there and it can be changed if needed. It attempts to be 100 per cent compatible with ASPECL and it appears to do the job.

 

This is the first time I messed with the client and I noticed a few oddities and shortcomings while creating an implementation based on the MISCDEVICES source:

  • The 'All drives' ID ('*') is converted to $FA since it has $30 subtracted from it, just like an ASCII digit. Wondered at first why the server was looking for -6. :o Maybe $00 would be a good choice for "all drives"... or even the asterisk character itself?
  • The server expects IDs (J-O) for drives 10-15 to be encoded as $1A-1F instead of a perhaps more logical $0A-$0F. This is a result of the alpha character having $30 subtracted from it in the original client, I guess.
  • There's currently no way to obtain a list of files on the server or specify a path for ATRs, etc. Nor is there any way to specify a preferred slot for a disk mount.

With a slightly fuller set of commands, we could have something like the SIO2SD client, but really it depends if anyone's going to use it.

 

 

 

actually this has been on the todo list for a while now. AspeCl was included in RespeQt but it was a known issue since it didn't have source, and licensing was unknown. At some point, when you feel this is complete enough/tested enough, I'd like to add it to RespeQt as a replacement for AspeCl.

Share this post


Link to post
Share on other sites

actually this has been on the todo list for a while now. AspeCl was included in RespeQt but it was a known issue since it didn't have source, and licensing was unknown. At some point, when you feel this is complete enough/tested enough, I'd like to add it to RespeQt as a replacement for AspeCl.

 

Yeah: I remember you talking about those issues a few months back, and I'm getting so much use out of RespeQt these days (especially PCLink) that I thought it would be nice to contribute something that was missing. Obviously it's pretty fresh and could probably use a few more pairs of hands doing some basic tests, but I'm happy for it to be included in its current form once we're sure there are no serious bugs.

  • Like 2

Share this post


Link to post
Share on other sites

We were trying to run RespeQt on several Ataris during the AIB Meeting yesterday, and nearly all configurations (changed cables, PCs, Ataris) were experiencing trouble on Linux using my build. May be or may not, it can be caused by the QT5static build - or by the RespeQt build ... I don't know.

 

I will check out several of my configs I have at home (serial, USB, debian wheezy 32 bit, and so on ...).

 

What flags might have been given to the Win32 build?

 

During the Fujiama 2016 the issue was solved, and it is not related to your builds.

Share this post


Link to post
Share on other sites

On my own hardware, some of the problems where caused by different firmwares, so does the KMK firmware a higher highspeed (POKEY divisor zero) than the SpeederPlus OS (3×) ... and the few issues I had with RespeQT, I also had using AspeQt. So in general, yeah, the problems where solved for me too.

Edited by atarixle

Share this post


Link to post
Share on other sites

there is an issue with the Log-window: whenever you open and close a log window, it will open again when you go to the preferences-tools-window. if you open the log window once more, and close it, it will open two log-windows when you enter the preferences-tools.

 

may be, the log-window is just hidden instead of detroyed? idk much about GUI programming but I remembered some sort of that ...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...