AtariVox/Stella via USB/Serial on MacOS

[+Andrew Davie]

I have had some issues with AtariVox connected to a MacOS serial port.

I have been using generic clone USB-Serial converters, both exhibiting the same behaviour.

Basically, instead of speech from the AtariVox, when I send any data I just get beeps whistles and boops. A bit R2-D2 like.

Anyway, I put a 'scope on the signal and it's pretty clear that the comms is happening at 9600 baud.

When I intervene and externally change the port to 19200 baud, suddenly all is OK, and the AtariVox speaks properly.

 

So this is just a heads-up - at this stage on my machine at least, stella appears to be failing to correclty set the port baud rate to 19200 baud.

 

[+Andrew Davie]

This issue was due to an incompatibility on commmand-line UNIX-style builds of stella on MacOS

When I run the release build of Stella, all is OK.  So, not a bug -- just an incompatibility. Must build Stella with xcode for it to work properly.

 

[+stephena]

It's very odd that this is the case.  Going forward, we would want to have the UNIX and Xcode builds behaving the same, if for no other reason than to prevent 'bug reports' like this.

[RevEng]

From the man pages is looks like the Linux termios library has cfsetspeed, despite it being a BSD specific call. Since Andrew's attempt worked, except for the speed setting, maybe you can just add a cfsetspeed call to the Unix driver, and use the same code for both Unix and Mac OS.

[+stephena]

The problem is, the Mac-specific code works fine as-is.  It seems like the UNIX build is compiling `SerialPortUNIX` instead of `SerialPortMACOS`.  And as such, this is a build issue.  I want to keep the classes separate for now, since eventually we may add code that is system-specific, and I want to avoid using ifdefs everywhere.

[RevEng]

For sure, I hear you on avoiding a nest of OS specific ifdefs. It's a special level of hell.

[+stephena]

I'm pretty sure it's just that the 'configure' script is not properly detecting it's being run on a Mac, and not compiling Mac-specific classes.  We've encountered this before, and I don't think it's a big deal to fix it.  It's just that up to this point, nobody has used the UNIX build in MacOS mode very much, so we're running into some corner cases.