handling RTS/CTS handshaking on R: devices

[tschak909]

I might as well ask this question, BEFORE I run into it. I am about to start a serious sprint to get the Atari PLATOTerm brought up in earnest, but in order to get a reliable connection at any appreciable baud rate, I will need to implement RTS/CTS hardware handshaking, and I need the ear of someone who knows the subtle differences between implementing hardware handshaking for an Atari 850, versus say a MIO or a Blackbox, or even an RVerter interface, and I need to know if the CIO calls to assert the RTS line are essentially the same, or if there are quirks I need to be aware of? (I already know that I will need to disengage concurrent mode, before asserting the line change, anything else?)

 

-Thom

[phaeron]

The R-Verter is basically just a serial port glued onto the SIO bus. I'm not sure if there's much consistency in whether clones support handshaking, but RTS seems to often be connected to motor control.

 

The MIO and BlackBox use directly addressable ACIAs, and therefore can sense and flip control lines during communications.

 

The 850 is the problematic one. SIO commands can only be sent outside of concurrent mode, including the sense/control commands and checking control lines on entry to concurrent mode. However, exiting concurrent mode disconnects POKEY from the serial transmission, so you can't do this without dropping some bits. I don't have experience using an actual 850 in a real situation but I'm guessing that hardware handshaking is not possible to do reliably unless maybe at a very low baud rate.

[_The Doctor__]

???? now that is very strange, there is some way it must work.... after all the 850 reliably controlled communication with flow controlled serial devices on factory floor using 9600 and 4800 baud.... perhaps a guard time of some sort to prevent lost data? has to be an odd way to tell... I would suggest reading a little bit about 850 control from the Express BBS as to switching between the modes...there used to be some decent info about the 850, it's different roms... might be a little to learn from some of the high speed drivers that were tossed around out there..... there has to be some way the heads up occurs. or are we considering 4800 a very low baud rate...

there were a few modes, vaguely in my mind.... block mode... small block mode.... concurrent mode... depending on duplex and careful timing you snag status pulls and control lines....

 

there were some creative rbin floating around as well...

 

 

in the meantime, does software flow control perturb plato? is it possible plato has some form of software flow control already built in to it?

Edited July 14, 2018 by _The Doctor__

[phaeron]

Perhaps those devices used XON/XOFF instead of RTS/CTS? XON/XOFF is in-band signaling in the data stream, so it works fine while staying in concurrent mode.

[tschak909]

PLATO does support XON/XOFF. I deliberately set that mode in my echo packets that communicate back with the system.

 

HOWEVER,

 

the problem with XON/XOFF is that with the modern PLATO systems, the mode of control is ridiculously asymmetrical in terms of data rates, by the time XOFF has been asserted, the host computer very well may have sent another few hundred bytes down the pipe.

 

I developed a 'slowdown' server in Erlang to anticipate this problem, initially for the C= 64 users, before I had managed to get hardware flow control working there...but....

 

sigh.

 

every...single...system architecture thus far has had its own unique headaches in the serial communications department.

 

What makes it worse, the IP65 side of things isn't much better... The send/receive window for TCP packets is fixed, and therefore there is NO flow control...not to mention the stack is large enough that simply including it balloons my code by 12K which is enough to push it off the standard Atari memory map...

 

I need a drink.

-Thom

[phaeron]

What kind of connection are you using between the Atari serial port and the PLATO system? If it's an IP bridge by modem emulator, a possible option is XON/XOFF at the modem instead of XON/XOFF to the remote system. Altirra doesn't currently support this (AT&I5), but that could be fixed....

 

For the IP65 case I'm pretty confused as TCP inherently has flow control by sliding window. You're saying that IP65 doesn't shrink the receive window when data is received and expand it when the program reads data? That'd be pretty broken, I'd be surprised if anything worked reliably in that case given how slow the IP65 stack would be relative to a modern network.

[tschak909]

What kind of connection are you using between the Atari serial port and the PLATO system? If it's an IP bridge by modem emulator, a possible option is XON/XOFF at the modem instead of XON/XOFF to the remote system. Altirra doesn't currently support this (AT&I5), but that could be fixed....

 

For the IP65 case I'm pretty confused as TCP inherently has flow control by sliding window. You're saying that IP65 doesn't shrink the receive window when data is received and expand it when the program reads data? That'd be pretty broken, I'd be surprised if anything worked reliably in that case given how slow the IP65 stack would be relative to a modern network.

That is EXACTLY what I am saying. Yes. Broken, by the author's own admission. With no time table to fix.

 

-Thom

 

Sent from my SM-G920F using Tapatalk

[_The Doctor__]

as you peruse the Plato terminal, are you sure there isn't an expedited software flow control... that sort of thing existed in modems and terminal back in the day... it jumped ahead in line to stop things sometimes there were 'destructive' forms of this as well....

Edited July 15, 2018 by _The Doctor__

[tschak909]

out of band signaling of XON/XOFF just isn't possible here, and the effective data rates in this case are SO asymmetrical, that software flow control is utterly useless.

 

Another possibility is of course, as phaeron mentioned, local XON/XOFF, which, he could possibly add.

 

-Thom

Edited July 16, 2018 by tschak909

[_The Doctor__]

local x on xoff could get a modem to buffer the data to a small degree and a remote modem could follow suit... on a lantronix device there are setting for local only, local and remote or just remote...pass thru... it adds a layer of complexity for the average user to overcome.... it is also possible if the lantronix gets misses x on and the system sending it doesn't detect inactivity it will just sit there stupidly....

 

I wonder if there is a way to fix up 850 code or otherwise to deal with it, replace the rom and the rhandler sort of thing... still think there a pseudo method to make it work on the 850 the more I think on it.... I really don't think the machinery handled anything soft....

 

there were a few 850 rom revisions out there each with their own plus and minus..... like so many things probably lost to time, maybe such things will be rediscovered... it might be worth mentioning there were custom roms for the 850 as well....

 

there is always talk about fixing up rverter devices with proper flow control or some hybrid use a joystick port for missing signal talk....

 

I can only toss out fleeting bits of remembrance there were many months that the issues were looked at and dissected back when modems ruled... and it was written up.... maybe someone still has the papers with what each revision did correctly and incorrectly... the fixes... and the frankenrom.. maybe the image is still out there somewhere along with some rbins/handlers

 

I can hope someone will read this and say hey wait I remember that... and go find a box with what is needed.... can an assumed timing be calculated as to when the terminal would get overun and just force the flow control to engage for a predetermined time....?

 

ei, if receive continues for certain time period, then drop line for period of time we know it can and will catch up then raise line, rinse repeat.... it would use the control line more as a regulator at that point.... not a true flow control, but might keep the rate up..

Edited July 16, 2018 by _The Doctor__

[tschak909]

This is why the existing solutions need to be ditched, and an all in one device needs to be made with SIO connector at one end, and an 8266 at the other. Just cut to the #@(%@# chase, and be done with it. There is a thread doing this, elsewhere.

 

I don't mean to be short, but..honestly, any other approach is wasted time, especially given the relatively inexpensive price of 8266 based devices (bill of materials less than $15), and the ease of which they can be interfaced to the atari's serial bus.

 

-Thom

[phaeron]

I would argue that the Parallel Bus Interface has some advantages over SIO for much faster control signal handling and not conflicting with disk drives. It also has precedent with the BlackBox and MIO. The SIO bus has problems for out of band signaling from peripherals to the computer because it only has the proceed/interrupt lines and both of them are edge triggered only, the PIA can't report the current polarity. The SX212 driver has to do some gymnastics to work around this.

[tschak909]

I would understand that, but it would immediately nix compatibility with the 400/800 systems, unless it was done as a cartridge.

 

-Thom

[Kyle22]

Why not design a simple, cheap R:Verter interface that uses a joystick port to provide the additional flow control signals? Such a device would be very cheap to produce.

 

R:Verters have no speed limit, they can go as fast as PoKey. A small addition to the handler for a small RAM buffer, and code to toggle the joy port for RTS/CTS.

 

Edit: I mentioned this before, why hasn't anyone responded to tell me why this won't work? That makes me think even more that it WILL work...

http://atariage.com/forums/topic/278330-rverter-handler-source-code/?do=findComment&comment=4021890

Edited July 18, 2018 by Kyle22

[sanny]

PLATO does support XON/XOFF. I deliberately set that mode in my echo packets that communicate back with the system.

 

HOWEVER,

 

the problem with XON/XOFF is that with the modern PLATO systems, the mode of control is ridiculously asymmetrical in terms of data rates, by the time XOFF has been asserted, the host computer very well may have sent another few hundred bytes down the pipe.

 

I guess you are talking about the problem you are having in PLATO with an 850<---RS232--->tcpser<---TCP--->PLATOServer connection.

 

The XON/XOFF handling should be done in the tcpser program. Maybe in addition the the PLATOServer host, but care has to be taken that no deadlocks will occur.

 

Since the direct peer of the Atari/850 is the tcpser program, it should cease sending input bytes to the Atari when it receives an XOFF. The Atari of course doesn't expect to receive any more data after sending XOFF. If yes, it will appear to it, that the peer doesn't do handshaking correctly.

 

regards,

chris