Jump to content
SpiceWare

Flow control in Stella?

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

 

1705191548_ScreenShot2020-07-30at4_04_40PM.thumb.png.16d8562887bbae81d936d1b1f36d4ed9.png

 

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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};

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

SW_AV.xml

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Richard H.

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...