plato 1.0 atari

[mr-atari]

I was not able to get online with my ESP for testing, so I did most debugging with altirra. On the real atari, debugging done without be able to get online, but with my build-in feedback to see if keys work and data comes or goes.

Beside my report below, it looks great, pity it does not go all the way for me (for now). I will try another method later this week, to get first online, then start plato.

Report: TTY-mode, return sends CR LF LF (expected CR only) BOTH-modes, SELECT-return sends CR LF LF (not CR LF) TTY-mode, control-M sends CR LF (great, that works for me). PLATO-mode, control-M does nothing (sends value $7B).

Filename-handling is not conform atari-standard, giving issues with other DOSsen. Please pad the name with SPACE ($20) to 11 characters long or use EOL ($9B) if the name is short. Use "CONFIG " or "CONFIG",$9B not "CONFIG", please.

The new "fill-in" screen takes long to draw, at 1200 baud the serial-buffer overflows. Beside that, slowing down users from doing actual work can be rather annoying... On faster systems, this looks nice, but on the atari the wait it looooooong. Can the fill-in be disabled from the user/config?

Xon/Xoff, the plato-server does not respond to these codes. I know I have raised this issue before, the server does it wrong, not the R:device/handler. Now with the fill-in active..... Results in buffer overflows all the time. Sending Xoff goes through the modem to the server and should pause the server. Sending Xon goes through the modem to the server and it can start sending data again. Can Xon/Xoff be disabled from the user/config? Options now are 2 threshold values.

[tschak909]

I will make the changes for the filename. :) And I will add a feature to turn on/off fill (paint).

As I have mentioned before, XON/XOFF is due to the extreme asymmetry of the connection between the server and the host, there is nothing I can do about this, and XON/XOFF must be handled locally at the device.

Chris Groessler is working on an improved serial driver which moves the XON/XOFF handler into the CC65 part of the stack, and we'll add the ability to toggle once this is in.

TTY mode and PLATO mode descrepancies are noted, and I will work through them. The state machinery for handling keypresses is slightly complex, due to the fact that PLATO and TTY modes are completely different in how keypresses are handled, so we'll slowly work those issues out, some patience is asked. :)

Chris is also working with me to try and make things better for devices which have hardware flow control on the Atari (ICD MIO and Black Box), so performance will get better soon.

-Thom

[tschak909]

I am bifurcating these tickets, so they'll be easier to track. :)

Issue #15 - Filename handling Issue #18 - Fill toggle Issue #19 - Work through TTY/PLATO mode keyboard mappings

I will make an issue for XON/XOFF, once I have defined the problem better. This is on me.

-Thom

[mr-atari]

Xon/Xoff-handling is fully described in paragraph 3.1.4

The modem can not stop receiving data on the Xoff-command, simply because you loose data. There is a misunderstanding at this point I guess. Xoff goes through the modem to the server, then the server pauses (sequence 4 below). The server should stop sending on receiving the Xoff, or several Xoff's in a row, see below.

From the manual: 3.1.4 Flow control

   At higher communications rates (greater than 1200 bps) it
   may not be possible for terminals to keep up with the output
   of the PLATO host.  To prevent the terminal from losing data
   a method of flow control has been instituted.  This uses the
   XON/XOFF protocol.

   When the terminal has determined that it is in danger of
   losing data, it sends an XOFF to the host.  The host will
   then wait until the terminal sends an XON to indicate that
   it has caught up and is again ready to receive data from the
   host.

   Unfortunately, the characters used for XON and XOFF were
   also used for PLATO keypresses (the XON character is
   control-Q [DC1] and the XOFF character is control-S [DC3].
   These correspond to shift-STOP and SUPER in the original
   PLATO ASCII protocol).

   Thus, to allow flow control to work, the keyboard mapping
   must be changed.  However, since the PLATO host must commu-
   nicate with terminals that have not been changed to work
   with flow control, the old keyboard mapping must also be
   retained.

   To activate flow control the host must send a special query
   to the terminal to find out whether the terminal supports
   flow control.  This query is implemented in the form of an
   echo code that will, when received, turn flow control on in
   the terminal and cause it to use the flow control
   keymapping, freeing the XON and XOFF characters for their
   proper use.  A resident that supports flow control responds
   to that code with a special echo reply, rather than echoing
   the code back verbatim.

   When the host receives that reply, it knows that the
   terminal is capable of using flow control, so it changes the
   way it interprets the terminal's keys, and activates flow
   control handling in the terminal interface software.  If the
   host receives a verbatim echo, it knows that the terminal
   cannot use flow control and will treat the terminal in the
   old fashion (using the non-flow control keymapping).

   Occasionally the host will continue to send data after an
   XOFF has been sent.  It may be the case that an XOFF was
   lost or that the host takes several character times to
   respond to the terminal's XOFF.  The terminal may have to
   send a few XOFFs (four or five) before the host stops
   transmitting.  However, it should avoid sending a constant
   stream of XOFFs to the host.

   A terminal that supports flow control has the following
   responsibilities:

        1) It must start out with flow control off and the
        original keyboard mapping.

        2) It must respond to the flow control echo code with
        the appropriate reply, and switch to the flow control
        keymapping.

        3) It must send all keys the user presses with the
        flow control keymapping (including keys sent from
        Micro PLATO through the R.XMIT entry point) when flow
        control has been turned on in the terminal.

        4) It must send the XOFF character (DC3, 13 hex) to
        turn off host output when the buffer is in danger
        of overrun.

        5) It must send the XON character (DC1, 11 hex) to
        turn on host output again when the buffer is out of
        the danger zone.

        6) If the user presses a key while flow control has
        been invoked (i.e., an XOFF was sent, but not an XON)
        an XON should be sent before the user's key.  This is
        to keep the bookkeeping straight because some host
        terminal interface programs assume that any key from
        the terminal is equivalent to an XON, and will turn
        host output on again.

        7) It must turn off flow control and revert to the
        original keymapping when it is placed back in TTY
        mode.

[tschak909]

No, you misunderstand. Seriously dude, you need to listen, as I know precisely what i'm talking about.

Because this is a TCP abstraction, the MODEM CAN handle XON/XOFF locally, the same as if RTS/CTS were done, because the result is a setting of the TCP transmit window to 0, which causes the other side to STOP immediately, and anything that may have made it across is subsequently re-sent. This is a TCP abstraction.

With the modem properly implementing this in their firmware, it can handle the issue.

I'm tired of arguing these points.

-Thom

On Wed, Oct 24, 2018 at 1:01 AM Sijmen Schouten notifications@github.com wrote:

Xon/Xoff-handling is fully described in paragraph 3.1.4

The modem can not stop receiving data on the Xoff-command, simply because you loose data. There is a misunderstanding at this point I guess. Xoff goes through the modem to the server, then the server pauses. The server should stop sending on receiving the Xoff, or several Xoff's in a row, see below.

From the manual: 3.1.4 Flow control

At higher communications rates (greater than 1200 bps) it may not be possible for terminals to keep up with the output of the PLATO host. To prevent the terminal from losing data a method of flow control has been instituted. This uses the XON/XOFF protocol.

When the terminal has determined that it is in danger of losing data, it sends an XOFF to the host. The host will then wait until the terminal sends an XON to indicate that it has caught up and is again ready to receive data from the host.

Unfortunately, the characters used for XON and XOFF were also used for PLATO keypresses (the XON character is control-Q [DC1] and the XOFF character is control-S [DC3]. These correspond to shift-STOP and SUPER in the original PLATO ASCII protocol).

Thus, to allow flow control to work, the keyboard mapping must be changed. However, since the PLATO host must commu- nicate with terminals that have not been changed to work with flow control, the old keyboard mapping must also be retained.

To activate flow control the host must send a special query to the terminal to find out whether the terminal supports flow control. This query is implemented in the form of an echo code that will, when received, turn flow control on in the terminal and cause it to use the flow control keymapping, freeing the XON and XOFF characters for their proper use. A resident that supports flow control responds to that code with a special echo reply, rather than echoing the code back verbatim.

When the host receives that reply, it knows that the terminal is capable of using flow control, so it changes the way it interprets the terminal's keys, and activates flow control handling in the terminal interface software. If the host receives a verbatim echo, it knows that the terminal cannot use flow control and will treat the terminal in the old fashion (using the non-flow control keymapping).

Occasionally the host will continue to send data after an XOFF has been sent. It may be the case that an XOFF was lost or that the host takes several character times to respond to the terminal's XOFF. The terminal may have to send a few XOFFs (four or five) before the host stops transmitting. However, it should avoid sending a constant stream of XOFFs to the host.

A terminal that supports flow control has the following responsibilities:

    1) It must start out with flow control off and the
    original keyboard mapping.

    2) It must respond to the flow control echo code with
    the appropriate reply, and switch to the flow control
    keymapping.

    3) It must send all keys the user presses with the
    flow control keymapping (including keys sent from
    Micro PLATO through the R.XMIT entry point) when flow
    control has been turned on in the terminal.

    4) It must send the XOFF character (DC3, 13 hex) to
    turn off host output when the buffer is in danger
    of overrun.

    5) It must send the XON character (DC1, 11 hex) to
    turn on host output again when the buffer is out of
    the danger zone.

    6) If the user presses a key while flow control has
    been invoked (i.e., an XOFF was sent, but not an XON)
    an XON should be sent before the user's key.  This is
    to keep the bookkeeping straight because some host
    terminal interface programs assume that any key from
    the terminal is equivalent to an XON, and will turn
    host output on again.

    7) It must turn off flow control and revert to the
    original keymapping when it is placed back in TTY
    mode.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/17#issuecomment-432523622, or mute the thread https://github.com/notifications/unsubscribe-auth/ACocZmzRLCLzfHTpNGQNbUhRww9oK88Bks5uoAIcgaJpZM4X1TTc .

[tschak909]

And yes, you excerpted s0ascers. I am very familiar with this document..have basically memorized it at this point.

It is important to understand, that:

(1) This is not a re-implementation of PLATO. THIS IS PLATO. So what you see above IS what's implemented.

(2) XON/XOFF does indeed work when the connection speeds are closer in symmetry. The Windows/Mac/Linux clients implement the XON/XOFF flow control, and work correctly.

Again, the reason you're seeing this, is because of the extreme asymmetry of the underlying physical connections, and the way that TCP is being abstracted away from the serial portion of your connection.

I studied this problem in depth, with the input of several individuals who are experts on this subject, and got a very thorough chalk-talk of the problem.

-Thom

[tschak909]

Ok, so, looks like adding EOL to the end of the filename fixed the problem. This will be in 1.1.

[tschak909]

Keyboard mapping is now fixed as much as I can fix it.

Trying to do CTRL-M in PLATO mode is meaningless. Please do not treat PLATO mode like an ASCII TTY terminal mode, the code mappings are different, and in PLATO mode, CTRL-M becomes the MICRO key. plato-fix-filenames-and-key-mappings.zip

[mr-atari]

As long as the plato-server does not respond to Xon/Xoff it will never work. So, one more time: "Does the server stop sending data when it gets Xoff"? Answer: No. Please investigate this and get this solved. I done deep digging too, when it does not stop, it does not stop. Sending Xoff does nothing, nada, zip. It is not the modem, nor the atari, not the driver, it is the server. It simply will not stop talking.....

[tschak909]

It does respond to XON/XOFF,as the code in pterm for windows/linux/mac relies on this. Difference is, their connection speeds are close enough together that in-band signalling works.

without the xon/xoff flow control implemented in these versions of pterm, the diagnostics lesson fails because the test patterns send too much data. I discovered this when implementing the original Android terminal that I based on pterm code.

-Thom

[mr-atari]

I will check/investigate this again. Until now, the plato-server did not stop sending after Xoff in any of my test-runs. It never dead-stopped either after sending a battery of Xoff's. And yes, after Xoff, I do NOT send Xon to see if it will stop eventually.

Just to be sure we talk the same language: Xon = $11 or Control-Q Xoff = $13 or Control-S The Plato-manual says it does, so I still assume these are the 2 correct ASCII-codes to send.

Xon/Xoff can not be handled locally. Simply because you will loose data, atari-modems do not have internal buffer. Stopping the modem will loose all data that comes in from the server.

[tschak909]

Yes, XON = 0x11 XOFF = 0x13

and yes, those are the correct codes to send.

It does indeed work, because: https://github.com/tschak909/pta/blob/master/app/src/main/java/org/cyber1/platoterm/PLATONetworkService.java#L162

The Android terminal implements this, because if it didn't, diagnostics fails during test patterns.

PTerm also implements this, (they do not have their code on repo, or I would link to it.)

It is also in the code running on IRATA and CYBER1 (COMPASS assembler).

-Thom

On Fri, Oct 26, 2018 at 12:53 AM Sijmen Schouten notifications@github.com wrote:

I will check/investigate this again. Until now, the plato-server did not stop sending after Xoff in any of my test-runs. It never dead-stopped either after sending a battery of Xoff's. And yes, after Xoff, I do NOT send Xon to see if it will stop eventually.

Just to be sure we talk the same language: Xon = $11 or Control-Q Xoff = $13 or Control-S The Plato-manual says it does, so I still assume these are the 2 correct ASCII-codes to send.

Xon/Xoff can not be handled locally. Simply because you will loose data, atari-modems do not have internal buffer. Stopping the modem will loose all data that comes in from the server.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/17#issuecomment-433294675, or mute the thread https://github.com/notifications/unsubscribe-auth/ACocZn2ms5z7qhxOqbXOsPiKfO9we6Rbks5uoqNNgaJpZM4X1TTc .

[tschak909]

I am also digging deep into the system card deck to cross reference the relevant XON/XOFF code (this is not trivial, as I have to look through a whole stack of "cards" to find the relevant cross reference)

Will post when I have it...

-Thom

[mr-atari]

No use sending me "Russian" code. Can't read it anyway..... I will check/investigate and see what data is passed through.

The current Rverter Rhandler/driver (for testing) sends out Xoff (but never Xon) on certain treshhold. And nothing happens, the server does/did never stop.

More news later.

Something else you should know. XIO 40 on device R: with "external"-mapped buffer is not supported by all modems. They keep using their "internal"-mapped memory.

[mr-atari]

OK, I did some testing....

First I made sure codes $11 and $13 are passed through, and they do. Then I rigged up a new driver, sending Xoff if the receive-buffer >50% filled. (resulting in a battery of Xoff when still over 50%) Never sending Xon and blocking Xon from being send by users.

Now call me insane, but the result is that the plato-server does NOT stop sending data. Resulting in buffer-overflow and erratic behavior of the plato-terminal..... It does not matter how many Xoff I send, it won't shut up.

Tested at 2400/4800 baud, by playing the game checkers, overflow happens during loading.

Sorry, that is what I see, that is what I report.

[edit] I used this latest build. plato-fix-filenames-and-key-mappings.atr

[beretta42]

Mr atari: re Atari modem: you have my curiosity: what exactly is on the other side of this modem? POTS?

[mr-atari]

Mr atari: re Atari modem: you have my curiosity: what exactly is on the other side of this modem? POTS?

???

[mr-atari]

Just wanted to let you know guys, that the Xon/Xoff issue still exists.

Reminder my test-case: In my R:Handler Xon is blocked from being send to the server and Xon/Xoff must be handled by the server, since the Atari/Modem-setup share system-RAM, thus stopping the modem makes no sense at all. You will loose all bytes that come in when the modem is stopped. Test-case result: Xoff is being send out (I see it's being send several times), but the server does NOT stop sending data. Where is should start sending again once it gets Xon, but that is blocked from being send, hmmm.

I am using "plato-fix-filenames-and-key-mappings.atr"

Beside this, I tried to get online and show Plato (this build) but was not able. That was at the Atari E-Jagfest 2018 in Germany, last weekend. Once I got online, the login-screen was stuck in a continues loop. After the user prompt, it reloaded over and over again. I tried several times, no luck, such a pity they could not have a look how plato works.

You have a video I shot when this happened at my place in an earlier release..

I was wondering if something was fixed in the meantime.

[tschak909]

Sijmen. Thank you for testing, and trying to show PLATOTerm.

I can't "Fix" the XON/XOFF problem on the server, because there is nothing to fix, it is there, and is implemented. It is not working for you because of the extreme connection asymmetry between the Atari and my host.

You need proper handshaking, full stop. We need a proper hardware handshaking solution for the Atari. Full stop. I do not know how many times I can say this, before I finally collapse from sheer frustration and exhaustion.

The other 8-bit systems targeted here, Apple2, Commodore 64, Commodore 128, all support hardware handshaking, and can handle transmission rates all the way up to 19200 without issue.

Now, I'm going to ask something, and please do not get mad.

I want to make support for your device better. Can you or somebody build the cable you're using, so I can attempt to fix the issues you're having?

(It is worth noting, I have roughly 7 people who have actively tested the Atari version on various configurations, and have not been reporting the issues you have)

-Thom

[mr-atari]

Don't get me wrong: 1/ But an Atari modem has NO ram. So when you stop the modem with "Xoff", data is lost, that is surely not an option. 2/ Tell me why the server does not stop on receiving Xoff. You tell me it's there, I believe you, but it does not work, why? And It's not only on my device, its on all my test systems (APE, Altirra, USB/ttl) 3/ Atari is not just any other 8bit system. I can do 19k2k too, even go as high as 38k4/57k6, that is not the issue here.

You are welcome to build the Rverter-setup to connect an ESP8266. http://www.abbuc.de/community/forum/viewtopic.php?f=15&t=9713#p80178 Get the ESP out of the box from 115k2 to 1200 http://www.abbuc.de/community/forum/viewtopic.php?f=15&t=9713#p80318

You are welcome to try my driver with Xon blocked, so you can see yourself. That works also on any Rverter-modem.

I am a low-level programmer, so I can see all bytes coming and going.

[tschak909]

I'd love to, but I have cerebral palsy.

-Thom

On Wed, Nov 7, 2018 at 12:53 AM Sijmen Schouten notifications@github.com wrote:

Don't get me wrong: 1/ But an Atari modem has NO ram. So when you stop the modem with "Xoff", data is lost, that is surely not an option. 2/ Tell me why the server does not stop on receiving Xoff. You tell me it's there, I believe you, but it does not work, why? And It's not only on my device, its on all my test systems (APE, Altirra, USB/ttl) 3/ Atari is not just any other 8bit system. I can do 19k2k too, even go as high as 38k4/57k6, that is not the issue here.

You are welcome to build the Rverter-setup to connect an ESP8266. http://www.abbuc.de/community/forum/viewtopic.php?f=15&t=9713#p80178 Get the ESP out of the box from 115k2 to 1200 http://www.abbuc.de/community/forum/viewtopic.php?f=15&t=9713#p80318

You are welcome to try my driver with Xon blocked, so you can see yourself. That works also on any Rverter-modem.

I am a low-level programmer, so I can see all bytes coming and going.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/17#issuecomment-436522897, or mute the thread https://github.com/notifications/unsubscribe-auth/ACocZiYUptQYVUMLibT8RThNL8Dv8ImJks5usoNwgaJpZM4X1TTc .

[tschak909]

And I have explained why this happens, repeatedly.

and yes, the 8266 not only HAS A buffer, but since you're dealing with TCP, it can ask for packets to be retransmitted.

-Thom

On Wed, Nov 7, 2018 at 12:56 AM Thom Cherryhomes thom.cherryhomes@gmail.com wrote:

I'd love to, but I have cerebral palsy.

-Thom

On Wed, Nov 7, 2018 at 12:53 AM Sijmen Schouten notifications@github.com wrote:

Don't get me wrong: 1/ But an Atari modem has NO ram. So when you stop the modem with "Xoff", data is lost, that is surely not an option. 2/ Tell me why the server does not stop on receiving Xoff. You tell me it's there, I believe you, but it does not work, why? And It's not only on my device, its on all my test systems (APE, Altirra, USB/ttl) 3/ Atari is not just any other 8bit system. I can do 19k2k too, even go as high as 38k4/57k6, that is not the issue here.

You are welcome to build the Rverter-setup to connect an ESP8266. http://www.abbuc.de/community/forum/viewtopic.php?f=15&t=9713#p80178 Get the ESP out of the box from 115k2 to 1200 http://www.abbuc.de/community/forum/viewtopic.php?f=15&t=9713#p80318

You are welcome to try my driver with Xon blocked, so you can see yourself. That works also on any Rverter-modem.

I am a low-level programmer, so I can see all bytes coming and going.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/17#issuecomment-436522897, or mute the thread https://github.com/notifications/unsubscribe-auth/ACocZiYUptQYVUMLibT8RThNL8Dv8ImJks5usoNwgaJpZM4X1TTc .

[mr-atari]

You have the schematics how to connect the ESP8266. And the tool to get it working on 1200 baud. Once set to 1200 baud, you can use any Rverter driver. And you get on to it.

Ik heb geen idee wat je bedoeld met "cerebral palsy"

I live across the ocean, so me building/sending is not preferred. The link to the forum also shows the article to buy on Aliexpress. 2 dollars for the ESP including 5 volt breakout board. The rest of the stuff you can buy at your local Tandy for a few dollars.

I have a hard time testing for you and not been recognized the Xon/Xoff-issues with the server. I mean, I am not daft, the server just not stop, never, does not matter how many Xoff you send... Does not matter on what system either, non ESP8266 do the same.

Anyhow, you have the tools to get cracking with an ESP8266. If you need more to get going, drop me a line and I get it sorted.

[tschak909]

Cerebral palsy, scar tissue on my brain, which, in my case affected my motor functions. I was in physical and occupational therapy from the time I was 6 months old, until I was almost 15.

It affects the right side of my body, and It takes a conscious effort for me to do anything physical that most people take for granted, and I had to develop my own method of typing using my left hand and two right fingers.

I shy away from doing hardware work unless I absolutely have to, because of the sheer amount of conscious effort required to move my hands in small increments.

-Thom

On Wed, Nov 7, 2018 at 1:10 AM Sijmen Schouten notifications@github.com wrote:

You have the schematics how to connect the ESP8266. And the tool to get it working on 1200 baud. Once set to 1200 baud, you can use the any Rverter driver. And you get on to it.

Ik heb geen idee wat je bedoeld met "cerebral palsy"

I live across the ocean, so me building/sending is not preferred. The link to the forum also shows the article to buy on Aliexpress. 2 dollars for the ESP including 5 volt breakout board. The rest of the stuff you can buy at your local Tandy for a few dollars.

I have a hard time testing for you and not been recognized the Xon/Xoff-issues with the server. I mean, I am not daft, the server just not stop, never, does not matter how many Xoff you send... Does not matter on what system either, non ESP8266 do the same.

Anyhow, you have the tools to get cracking with an ESP8266. If you need more to get going, drop me a line and I get it sorted.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/17#issuecomment-436526074, or mute the thread https://github.com/notifications/unsubscribe-auth/ACocZtjfvVWug8wOfcy5rS1ualpLurGxks5usodNgaJpZM4X1TTc .

[mr-atari]

Ok, sorry to hear about that.

I have thought of another easy way to check this out. Can you do something for me? Just a small request. This will give results, without the fuzzy noise of unknown devices/software.

Your last build "plato-fix-filenames-and-key-mappings.atr" Can you change Xon to Xoff to be send out? That way you create the same test-condition as I have. So plato sends out Xoff when it needs to, but never sends Xon. Instead of sending out Xon it does Xoff again. So somewhere in time, the server should dead-stop.

That would be great, thanks.

[tschak909]

Ok. I will make a build tomorrow. -Thom

On Thu, Nov 8, 2018 at 1:04 AM Sijmen Schouten notifications@github.com wrote:

Ok, sorry to hear about that.

I have thought of another easy way to check this out. Can you do something for me? Just a small request. This will give results, without the fuzzy noise of unknown devices/software.

Your last build "plato-fix-filenames-and-key-mappings.atr" Can you change Xon to Xoff to be send out? That way you create the same test-condition as I have. So plato sends out Xoff when it needs to, but never sends Xon. Instead of sending out Xon it does Xoff again. So somewhere in time, the server should dead-stop.

That would be great, thanks.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/17#issuecomment-436893938, or mute the thread https://github.com/notifications/unsubscribe-auth/ACocZrT8PND7ycTAYl9cR5Z8ZdavE3eLks5us9eYgaJpZM4X1TTc .

[greg-king5]

Instead of sending out Xon, it does Xoff again.

No, don't do that! Send XOFF only once. Then, remain dead silent, indefinitely. Doing it that way will avoid the possibility that a server will interpret any character after XOFF as a signal to resume sending data.

(Some servers assume that a client doesn't repeat itself. Therefore, any character that's heard after that is either XON or user input. Users expect to see a quick echo of the stuff that they type; so -- either way -- the server starts sending again.)

[mr-atari]

Interesting..... I have noted your remark.

The manual says this: Occasionally the host will continue to send data after an XOFF has been sent. It may be the case that an XOFF was lost or that the host takes several character times to respond to the terminal's XOFF. The terminal may have to send a few XOFFs (four or five) before the host stops transmitting. However, it should avoid sending a constant stream of XOFFs to the host.

Thom: go ahead and make the requested build, I want to test instead of talking.

[tschak909]

Change made: https://github.com/tschak909/platoterm64/compare/xonxoff_test

plato-xoff-xoff-test.zip

[mr-atari]

Thanks for the test-build. I assume you tried this version too?

I see Xoff's being send out and I see Xon never been send. So that is OK.

But the server does not stop. I can works with plato as normal. There is no dead-stopping the server....

In other words, my finding that the server does not stop is still valid.

So that leaves us with the remark of greg-king5. You administrate the server, so you are the only one who knows the answer. Does the server resume on the second Xoff?

[tschak909]

I am the one who administrates the server. I tried to show you the code that processes xon and xoff.

Greg is a major contributor to cc65, and has nothing to do with my project.

On Fri, Nov 9, 2018, 03:01 Sijmen Schouten notifications@github.com wrote:

Thanks for the test-build. I assume you tried this version too?

I see Xoff's being send out and I see Xon never been send. So that is OK.

But the server does not stop. I can works with plato as normal. There is no dead-stopping the server....

In other words, my finding that the server does not stop is still valid.

So that leaves us with the remark of greg-king5. You administrate the server, so you are the only one who knows the answer. Does the server resume on the second Xoff?

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/17#issuecomment-437294390, or mute the thread https://github.com/notifications/unsubscribe-auth/ACocZv5AOZzLD_fpmKmAxiyN4hjO9_Haks5utURSgaJpZM4X1TTc .

[mr-atari]

Then there must be a bug somewhere. Your build shows it, I have no doubts. (I can show you my code, but what it the purpose?)

Sending Xoff to the server does nothing.

You did not answer to this: Does the server resume on the second Xoff?

[mr-atari]

How do I disable Xon/Xoff in plato? There is no option for this, I notice, some specific values to enter?

[tschak909]

there isn't. 0 and 0 would probably work for values though. -Thom

On Sat, Nov 10, 2018 at 1:49 AM Sijmen Schouten notifications@github.com wrote:

How do I disable Xon/Xoff in plato? There is no option for this, I notice, some specific values to enter?

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/17#issuecomment-437565816, or mute the thread https://github.com/notifications/unsubscribe-auth/ACocZgkxBHPWDPKW8uVJpCH1TwLK0Oikks5utoT3gaJpZM4X1TTc .

[mr-atari]

You did not answer to this: -Does the server resume on the second Xoff? -I assume you tried this version too?

Recap what I did/see: I see Xoff's being send out and I see Xon never been send. So that is OK.

But the server does not stop. I can works with plato as normal. There is no dead-stopping the server.... It never shuts up (!).....

[tschak909]

no, it does not resume.

-Thom

On Sat, Nov 10, 2018 at 3:24 AM Sijmen Schouten notifications@github.com wrote:

You did not answer to this:

-Does the server resume on the second Xoff? -I assume you tried this version too?

Recap what I did/see:

I see Xoff's being send out and I see Xon never been send. So that is OK.

But the server does not stop. I can works with plato as normal. There is no dead-stopping the server....

It never shuts up (!).....

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/tschak909/platoterm64/issues/17#issuecomment-437570653, or mute the thread https://github.com/notifications/unsubscribe-auth/ACocZqGTUAZfpLcYL8urH5d8LEzRJQZtks5utptZgaJpZM4X1TTc .

[mr-atari]

It does not stop either.....