Jump to content
IGNORED

Version 3 boots fine, 4 does not.


scotty

Recommended Posts

I mount the disk image, turn on the power, it makes the farting noise, and then goes right to basic. Multiple disk images tried. Close down, open version 3 back up, and they boot fine.

 

Hardware is the serial version of SIO2PC, with a USB adapter. As mentioned, 3 works fine, and 4 will not boot. Both use Serial port 2 if that makes a difference.

 

Would also like to get APE to work, as I like the colorful display and all the options, and would really like to get BobTerm going so I can get back on some BBS'es.

Link to comment
Share on other sites

What platform? Windows? What version of Windows? Have you tried running it in compatibility mode?

 

RespeQt r4 works for me under Win10, though I usually use one of my Raspberry Pi units on full-time "Atari duty."

​Can't help you with APE as I don't use it.

 

post-30400-0-19399800-1501622764_thumb.png

 

post-30400-0-19639500-1501622780_thumb.png

 

Link to comment
Share on other sites

The program runs, it will just not boot disk images, whereas 3 is fine. Windows 7.

 

Next questions - did you compile yourself or download the Win32 binaries from GitHub? Have you tried different SIO speeds in the options? Have you tried multiple disk images or XEX files? These details might help narrow down stuff in case Joey Z. or The Montezuma or whomever can find a bug in stuff that changed between r3 and r4.

Link to comment
Share on other sites

Also, which handshaking method? Are there any messages in the log window?

 

Lastly, we changed the method of serial port selection in RespeQt with this latest release. Please try selecting a different serial port in the options menu, save the settings, then again select the correct serial port in the options menu, and save the settings again. I don't remember off the top of my head how the serial port selection works in handling invalid settings in the configuration file, but it's possible there may be two entries in the list which appear to be correct, in which case you should attempt to use the other one.

 

That's really the only change I can think of that would cause this, is that you're not successfully opening the serial port. This is why you need to post the contents of the log window, there may be an error about this there.

Edited by Joey Z
Link to comment
Share on other sites

Tried Com1 and Com2 both just made the farting noise and went in to Basic.

PS, I have the Ultimate Cart and the Ultimate 1MB installed. No matter what OS or whiteout the cart, still does the same thing, yet no problems on version 3.

Link to comment
Share on other sites

OK, well the only other way to go about this is for me to start building from various commits and trying to narrow this down. I'm not doing that now, I have to get some sleep and move my stuff down at school tomorrow, I can't get around to it until next week at the earliest.

Link to comment
Share on other sites

No problem at all. Take your time. 3 works fine, so I have that to use until you can find a solution. I am in no hurry, and appreciate your time and effort.

 

FWIW, I was just in your area the other day (Wednesday). I am a motor coach operator, and drove Cedar Point employees to Navy Peer for the day. Been to the Chicagoland area quite a few times. Always enjoyable.

Edited by scotty
Link to comment
Share on other sites

  • 2 months later...

looks like I am in the same boat... older revisions work fine.... r4 will not communicate.....

XP

played with all the ticks and rates and handshakes real rs232 port

r2 works r3 works r4 nada

 

When active com2 dsr interface light go low like they are suppose to... but no coms....

when wrong com port selected lights all go high as expected

 

same selections on all 3 revs

 

and APE works perfectly

 

Respeqt r4 is hating on the real rs232 port

Edited by _The Doctor__
Link to comment
Share on other sites

do not have that check box

 

Sorry, you are right, I submitted it, but the change didn't manage to the master branch (is still in the develop branch).

 

The Windows implementation of the serial port layer had a bug in the previous versions of the RespeQt/AspeQt.

It is event based and the worker thread was woken up on every change of the command line signal (on rising and on falling edge).

Normally the command line goes high and the worker thread shall be woken up on the rising edge to read a command frame.

If the worker thread is woken up on the falling edge it may lead to misinterpret a data frame as a command frame!

Starting from Release 4, the worker thread does nothing if woken up on the falling edge.

 

However it looks like that with a real (hardware) serial port and SIO2PC cables using DSR signal - windows serial port drivers do not trigger events on a rising edge :(

That's why I added a checkbox to inverse the logic.

 

Please change the handshake to "NONE" or to "SOFTWARE (SIO2BT)" and give it a try.

In those two modes the above logic does not apply.

Edited by TheMontezuma
Link to comment
Share on other sites

do not have that check box

 

Sorry, you are right, I submitted it, but the change didn't manage to the master branch (are still in the develop branch).

 

The Windows implementation of the serial port layer had a bug in the previous versions of the RespeQt/AspeQt.

It is event based and the worker thread was woken up on every change of the command line signal (on rising and on falling edge).

Normally the command line goes high and the worker thread shall be woken up on the rising edge to read a command frame.

If the worker thread is woken up on the falling edge it may lead to misinterpret a data frame as a command frame!

Starting from Release 4, the worker thread does nothing if woken up on the falling edge.

 

However it looks like that with a real (hardware) serial port and SIO2PC cables using DSR signal - windows serial port drivers do not trigger events on a rising edge :(

That's why I added a checkbox to inverse the logic.

 

Please change the handshake to "NONE" or to "SOFTWARE (SIO2BT)" and give it a try.

In those two modes the above logic does not apply.

Link to comment
Share on other sites

port is dead no matter what the choice is...

 

There was one more change introduced in R4 that resulted from problems reported by SIO Cart developers.

It is about DTR and RTS lines. Until R4 they were cleared when the serial port was opened.

 

I changed the logic to set both lines to high (otherwise RespeQt could not receive any data from Atari via SIO Cart):

 

EscapeCommFunction(mHandle, SETDTR)

EscapeCommFunction(mHandle, SETRTS)

 

Perhaps this is the root cause :(

I will locally roll this change back and prepare a new R4 binary for you (if you are so kind and could retest it once again).

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...