Flow control in Stella?

[+stephena]

The fact that it turns red right away when you remove the '!' implies that the current code is correct.  This is what happens with my faulty USB adaptor too.

 

But the fact that the garbled speech is still happening is puzzling.  It works for me in all 3 OS's.

[+SpiceWare]

Found my USB Serial adapter, a Keyspan USA-19Qi.  However I don't have the driver for it.  Keyspan was apparently bought by Tripp Lite, but the only legacy driver they offer doesn't work with the 19Qi - and I tried even though it wasn't listed.

 

 

Going to see if I can't build the latest Stella on my Linux laptop and try out the AtariVox Interface on it, as well as the Keyspan.

[+SpiceWare]

1 hour ago, stephena said:

The fact that it turns red right away when you remove the '!' implies that the current code is correct.  This is what happens with my faulty USB adaptor too.

 

But the fact that the garbled speech is still happening is puzzling.  It works for me in all 3 OS's.

 

Since it works on the 2600, the problem is most likely with my AtariVox USB interface - maybe the connection for CTS is faulty, such as a broken solder joint. If I can get the Keyspan working on my Mac or Linux laptop then I can try the AtariVox Serial Interface.

[+stephena]

A faulty connection might explain your USB adaptor.  For me, it's almost as if a NOT gate is missing, since the signal is exactly the inverse of what it should be.  I opened both adaptors, and they look the same at first glance.  Guess I'd have to power it on and check the voltages to be sure.

 

My concern is if others have a similar faulty device.  If I knew it was just me I wouldn't care.  But if they're out there in the wild, we need Stella to detect and work around it.

[+SpiceWare]

no luck building Stella on my Linux machine:

 

In file included from src/gui/ComboDialog.cxx:19:0:
src/emucore/Control.hxx:384:71: error: array must be initialized with a brace-enclosed initializer
     std::array<bool, 5> myDigitalPinState{true, true, true, true, true};
                                                                       ^
src/emucore/Control.hxx:384:71: error: too many initializers for ‘std::array<bool, 5ul>’
src/emucore/Control.hxx:387:73: error: array must be initialized with a brace-enclosed initializer
     std::array<Int32, 2> myAnalogPinValue{MAX_RESISTANCE, MAX_RESISTANCE};
                                                                         ^
src/emucore/Control.hxx:387:73: error: too many initializers for ‘std::array<int, 2ul>’
In file included from src/gui/ComboDialog.cxx:27:0:
src/gui/ComboDialog.hxx:47:49: error: array must be initialized with a brace-enclosed initializer
     std::array<PopUpWidget*, 8> myEvents{nullptr};

 

[+stephena]

You need to be using at least gcc6, but preferably gcc7.  Or perhaps a somewhat recent version of clang.

[+SpiceWare]

Thanks, that would be it:

 

$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609

 

The laptop's running Ubuntu 16.04.3 LTS, I see the the current version is 20.04 LTS so it's behind by quite a bit.  My SSD only has a couple GB free, so I think my best plan of action will be to get a larger SSD then do a clean install.

[+stephena]

49 minutes ago, SpiceWare said:

Thanks, that would be it:

 

$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609

 

The laptop's running Ubuntu 16.04.3 LTS, I see the the current version is 20.04 LTS so it's behind by quite a bit.  My SSD only has a couple GB free, so I think my best plan of action will be to get a larger SSD then do a clean install.

You can add a PPA to 16.04 to get newer versions of gcc.  That would be the quickest way to do it.  Of course going forward, it's probably better to have 20.04.  But it's up to you.

 

https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test?field.series_filter=xenial

[+SpiceWare]

Thanks!  I've already ordered the new mSATA SSD, should arrive on the 6th, so will go the 20.04 route.  Had planned to pick one up locally from MicroCenter, but they longer longer carry them.

[+stephena]

@Richard H., could I get a definitive answer on how the SpeakJet READY and CTS signals interact through the AVox-USB interface?  All signs point to SpeakJet READY means high on pin 2 of the controller port, which makes CTS low.  And then when we read CTS from Stella, we invert it again to get high, which is passed on to the ROM code indicating the SpeakJet is ready.  So confusingly, CTS being low means that the SpeakJet is ready and can accept more data.  Is this correct??

 

The problem is that I have two AVox-USB converters here, and they work exactly the opposite.  One works when CTS low means SpeakJet READY, and the other works when CTS high means SpeakJet READY.  So very confusing to say the least.

[Richard H.]

Check if the USB interface has the attached settings.

 

You'll need this utility - https://www.ftdichip.com/Support/Utilities/FT_Prog_v3.8.128.448 Installer.exe

Avox_USB.xml

[+SpiceWare]

only difference I see with mine is the product_description is set to AtariVox instead of AtariVox+

SW_AV.xml

[+stephena]

OK, I ran the program above with each of my adaptors.  First one is exactly like @SpiceWare; the XML file from @Richard H. contains "AtariVox+", while my adaptor contains "AtariVox".  Let's call that adaptor A.  The second one contains 10 fields that are different.  In particular, the CTS signal is not inverted.  Let's call that adaptor B.

 

Adaptor A looks very much like the one that was released BITD by @Richard H..  And adaptor B is probably the one released later in a second run, by golden.axe I believe.  Problem is, Stella is currently coded to work with adaptor B, and not A!!!  So to get it working with adaptor A, we read the CTS signal from the adaptor and pass it to SWCHA in D1 as-is.  This makes more sense to me.  CTS means clear to send, and the AtariVox routines in a game ROM check for D1=1 to tell whether it should keep sending data.  So it's now one-to-one.  The current code in Stella does an invert, so that CTS = 0 means D1=1.  That to me seems backwards.

 

So I ask the question again.  Should CTS=1 mean that D1 of SWCHA = 1?  As in Richard's original XML file, and what I get from adaptor A?  If so, how does the 'invert' of CTS come into effect?  Or is that an implementation detail of the hardware that I shouldn't even care about in Stella??

 

In the end, I can probably code it all in such a way that both adaptors work.  I just want to know which is correct, so we can have it formally documented, and that future adaptors can do it the right way.

[Richard H.]

7 hours ago, stephena said:

Or is that an implementation detail of the hardware that I shouldn't even care about in Stella??

 

Correct

 

If you flash the interface with CTS not inverted, it will not work in Phrasalator (with hardware flow enable). I used this as a 'normal serial' test.

Edited August 2, 2020 by Richard H.

[+stephena]

OK, so I finally have it worked out then.  The code I'm about to commit works with both normal, inverted and non-working CTS signal (although in the latter case, the will be audio corruption on long phrases).  Basically I check after opening the serial port what isCTS() returns.  I assume it should be true, since it's ready to accept data right away.  If it's false, then either CTS was flashed incorrectly, or not available at all.  Stella then remembers this, and when setting SWCHA D1 it corrects the issue there.

[+stephena]

I've committed the changes to Stella github.  If you're able, please check out the latest release and compile/test.  If there are issues, you can report them at https://github.com/stella-emu/stella/issues/687.  Thanks everyone for helping to get this sorted out.

[+stephena]

OK, final update on this.  I just committed code earlier today that works with normal CTS, inverted CTS and also using software flow control (XON/XOFF).  The latter is needed for the 2600-daptor II flashed to be an AVox-USB converter.  This updated firmware hasn't been released yet, but will be ready for whenever we do the Stella 6.3 release.

 

If you have the ability, please download and test this.  I think I have it working in all cases though, but extra testing never hurts.

[+stephena]

Forgot to mention that @dualcam has provided the updated firmware for the 2600-daptor II to be flashed as an AVox-USB adaptor.  See http://www.2600-daptor.com/AtariVox-daptor.htm for more info.  Of course you'll have to compile Stella from GitHub to test it.  Full support will come in Stella 6.3.