Need help debugging PLATOTerm TIPI routines

tschak909 · September 7, 2018

I have here, an initial first pass for the TIPI version of PLATOTerm.

https://github.com/tschak909/platoterm99/tree/add_initial_tipi

It is connecting, and it starts to display data, but it hangs, because it is not transmitting the echo packets.

Can someone either:

(a) reproduce the same behavior?

(b) help me try to figure out what I'm doing wrong with regards to send_chars? I've tried several approaches.

-Thom

+9640News · September 7, 2018

I have here, an initial first pass for the TIPI version of PLATOTerm.

https://github.com/tschak909/platoterm99/tree/add_initial_tipi

It is connecting, and it starts to display data, but it hangs, because it is not transmitting the echo packets.

Can someone either:

(a) reproduce the same behavior?

(b) help me try to figure out what I'm doing wrong with regards to send_chars? I've tried several approaches.

-Thom

Is there someplace to pull an executable file?

tschak909 · September 7, 2018

Oops, yeah, Sure, I'll attach a DSK here,

PLATOTEST.dsk

-Thom

+9640News · September 10, 2018

OK, got my system back together far enough from some other testing I did this weekend. I was able to download your DSK image, and move the files over to my TI system with TIPI. I ran the program, and it drew the graphics on the screen, connected with the server, and then gave me some information.

I am assuming the Welcome message came from the server. It then said something before the screen went kaput about access and a system administrator.

Assuming the text is coming from the server and is not part of the program, it looks like you have established communications and are further along than my assembly work on a separate project. I am about to get back started, time permitting, on that tomorrow.

Not knowing how you are buffering text, if it is by string, or by single character, one thing that has been on my mind is the processing of command strings. If one is receiving single characters, and there is a string command of multiple characters, how are you handling the rest of the string when it has not been received yet.

Beery

Anyways, just a thought for you to think about

tschak909 · September 10, 2018

@beery, odd that you should see the admin message, it means PNI failed somehow. Can you try reconnecting?

-Thom

tschak909 · September 10, 2018

The whole terminal is a complex state machine.There are two major modes, TTY and PLATO, which are accessed with either ESC STX, or ESC ETX, respectively.

Once in PLATO mode, there are 8 sub-modes which determine what to do, each accessed by a specific escape sequence, each of those 8 sub-modes can take control codes to either specify parameters, or to execute commands.

You can see the meat of the protocol decoder here:

https://github.com/tschak909/platoterm99/blob/master/protocol.c

It can either process a single character, or a string of characters, and in any case, it breaks each character up and handles separately depending on the state of the protocol state machine.

-Thom

+9640News · September 10, 2018

I tried reconnecting. It connected, then through up some text on the second screen that displayed for a couple of seconds, but was too quick before the screen blanked for me to read.

Beery

tschak909 · September 10, 2018

So you are seeing the irata online logo screen (IRATA.ONLINE - a computing service for retro-computing enthusiasts" and it asks you for your user name?)

-Thom

tschak909 · September 10, 2018

I know this has been said over and over, but because there is no TIPI emulation, my turn-around to fix the terminal to work is very slow.

If I could have access, to a TI 99/4A with a TIPI, for...a week..maybe two... I could sew up the TI 99/4A implementation and release it.

-Thom (somebody who _REALLY_ wants to get something done for this community)

+9640News · September 10, 2018

So you are seeing the irata online logo screen (IRATA.ONLINE - a computing service for retro-computing enthusiasts" and it asks you for your user name?)

-Thom

I do not know what text is being displayed as it disappears rather quickly.

RickyDean · September 11, 2018

I do not know what text is being displayed as it disappears rather quickly.

Could you take a video as the text flashes, then slo-mo to that to see what it says, if anything useful?

+9640News · September 11, 2018

I will see what I can do tonight.

Beery

+9640News · September 12, 2018

The text is not all that clear on the second page, but hopefully this will guide you to what I saw this evening. It paushed for a bit longer this time, so I am not sure if it is the same thing yesterday.

SyiL 20.41.14 TE22

CYBIS SYSTEM - CYBDEV. 1. NOS 2.8.7 871/871 USE

S ACCESS NOT POSSIBLE - CONTACT NETWORK ADMIN.

On the first page after getting the Connected I have

WELCOME TO THE NOS SOFTWARE SYSTEM

COPYRIGHT CONTROL DATA SYSTEMS INC 1994.

Then, it goes to the second page as noted above.

Beery

tschak909 · September 12, 2018

somehow you've managed to trip the PNI error, which is very odd that you've statistically managed to do that twice... That's an error on the host side..

unfortunately, unless I can actually #@(%#@(@# get access to ACTUAL #%(@# HARDWARE, trying to debug in this manner will prove quite awkward.

shit.

-Thom

+jedimatt42 · September 12, 2018

I played with this a bit tonight. I don't see anything wrong with your integration with TIPI.

You are reading a chunk of 40 bytes after getting connected. Then in a loop reading, but the socket returns zero bytes.

I think when I mash keys, I see it sending a byte or two.

I turned on debug logging for TIPI, and captured all the bytes messaged back and forth. Nothing appears to be sent to the server, a few polls yield 0 bytes available on the socket, then we get 40 bytes, and nothing again for subsequent polls.

logs.zip

The data sent back to the TI-99/4A starts here in the log: 2018-09-11 23:12:07,117

"sent byte" in TipiMessage means it is going from the PI to the TI. The 1st 2 bytes are the size.

2018-09-11 23:12:07,112 TiSocket    : DEBUG    read 40 bytes from 0
2018-09-11 23:12:07,113 tipi.TipiMessage: DEBUG    waiting to send message...
2018-09-11 23:12:07,114 tipi.TipiMessage: DEBUG    waiting for handshake...
2018-09-11 23:12:07,114 tipi.TipiMessage: DEBUG    reset protocol complete.
2018-09-11 23:12:07,115 tipi.TipiMessage: DEBUG    Sent byte: 0
2018-09-11 23:12:07,116 tipi.TipiMessage: DEBUG    Sent byte: 40
2018-09-11 23:12:07,117 tipi.TipiMessage: DEBUG    Sent byte: 13
2018-09-11 23:12:07,118 tipi.TipiMessage: DEBUG    Sent byte: 10
2018-09-11 23:12:07,119 tipi.TipiMessage: DEBUG    Sent byte: 67
2018-09-11 23:12:07,121 tipi.TipiMessage: DEBUG    Sent byte: 111
2018-09-11 23:12:07,122 tipi.TipiMessage: DEBUG    Sent byte: 110
2018-09-11 23:12:07,123 tipi.TipiMessage: DEBUG    Sent byte: 110
2018-09-11 23:12:07,124 tipi.TipiMessage: DEBUG    Sent byte: 101
2018-09-11 23:12:07,125 tipi.TipiMessage: DEBUG    Sent byte: 99
2018-09-11 23:12:07,126 tipi.TipiMessage: DEBUG    Sent byte: 116
2018-09-11 23:12:07,127 tipi.TipiMessage: DEBUG    Sent byte: 105
2018-09-11 23:12:07,128 tipi.TipiMessage: DEBUG    Sent byte: 110
2018-09-11 23:12:07,129 tipi.TipiMessage: DEBUG    Sent byte: 103
2018-09-11 23:12:07,130 tipi.TipiMessage: DEBUG    Sent byte: 32
2018-09-11 23:12:07,131 tipi.TipiMessage: DEBUG    Sent byte: 116
2018-09-11 23:12:07,132 tipi.TipiMessage: DEBUG    Sent byte: 111
2018-09-11 23:12:07,133 tipi.TipiMessage: DEBUG    Sent byte: 32
2018-09-11 23:12:07,134 tipi.TipiMessage: DEBUG    Sent byte: 104
2018-09-11 23:12:07,135 tipi.TipiMessage: DEBUG    Sent byte: 111
2018-09-11 23:12:07,136 tipi.TipiMessage: DEBUG    Sent byte: 115
2018-09-11 23:12:07,137 tipi.TipiMessage: DEBUG    Sent byte: 116
2018-09-11 23:12:07,138 tipi.TipiMessage: DEBUG    Sent byte: 32
2018-09-11 23:12:07,139 tipi.TipiMessage: DEBUG    Sent byte: 45
2018-09-11 23:12:07,140 tipi.TipiMessage: DEBUG    Sent byte: 32
2018-09-11 23:12:07,141 tipi.TipiMessage: DEBUG    Sent byte: 112
2018-09-11 23:12:07,142 tipi.TipiMessage: DEBUG    Sent byte: 108
2018-09-11 23:12:07,143 tipi.TipiMessage: DEBUG    Sent byte: 101
2018-09-11 23:12:07,144 tipi.TipiMessage: DEBUG    Sent byte: 97
2018-09-11 23:12:07,145 tipi.TipiMessage: DEBUG    Sent byte: 115
2018-09-11 23:12:07,146 tipi.TipiMessage: DEBUG    Sent byte: 101
2018-09-11 23:12:07,146 tipi.TipiMessage: DEBUG    Sent byte: 32
2018-09-11 23:12:07,147 tipi.TipiMessage: DEBUG    Sent byte: 119
2018-09-11 23:12:07,147 tipi.TipiMessage: DEBUG    Sent byte: 97
2018-09-11 23:12:07,148 tipi.TipiMessage: DEBUG    Sent byte: 105
2018-09-11 23:12:07,148 tipi.TipiMessage: DEBUG    Sent byte: 116
2018-09-11 23:12:07,149 tipi.TipiMessage: DEBUG    Sent byte: 32
2018-09-11 23:12:07,149 tipi.TipiMessage: DEBUG    Sent byte: 46
2018-09-11 23:12:07,150 tipi.TipiMessage: DEBUG    Sent byte: 46
2018-09-11 23:12:07,150 tipi.TipiMessage: DEBUG    Sent byte: 46
2018-09-11 23:12:07,151 tipi.TipiMessage: DEBUG    Sent byte: 13
2018-09-11 23:12:07,151 tipi.TipiMessage: DEBUG    Sent byte: 10

When I run, I see pretty intro screen before 'connected', then 'connected', a few lines, the screen clears, a few more lines at the top, it clears again, and an 'A' in the lower right corner.

Smells like mishap in the protocol code? Maybe replaying these bytes through ShowPLATO will reproduce it?

That data above just says:


Connecting to host - please wait ...

-M@

tschak909 · September 12, 2018

The protocol code is the exact same code used in multiple implementations happening across multiple platforms. It is known to work.

It's acting like it's not sending the echo packets back to the server (which look something like 0x1B, 0x50...)

#include "io.h"
#include "protocol.h"
#include "vdp.h"
#include "conio.h"
#include "ti_socket.h"

extern unsigned char buffer[512];

void io_init(void)
{
  connect("irata.online","8005");
}

void io_init_funcptrs(void)
{
}

void io_open(void)
{  
}

void io_send_byte(unsigned char b)
{
  unsigned char outb[1]={b};
  send_chars(outb,1);
}

void io_main(void)
{
  VDP_INT_POLL;
  int bufsize = read_socket();
  if (bufsize)
    ShowPLATO((padByte *)buffer,bufsize);
}

void io_recv_serial(void)
{  
}

void io_done()
{
}

-Thom

Edited September 12, 2018 by tschak909

+jedimatt42 · September 14, 2018

Ok, I telnet in, and see a bunch more come from the server, that I did see on the 4A screen... so I need to look at the logs better. I probably need to tune the logging. From what I see on the screen, we must be getting the NOS copy right statement etc... then we go off the deep end somewhere before getting to display the prompt that follows. It looks like the server normally polls the client for something a few times before the prompt comes up.

It looks like I could capture output from a 'telnet' session to irata.online, and then mock that as a return value of io_main, and the theory would be that under an emulation debugger, it should get stuck on an io_send_byte responding to a PLATO command code?

Or will a telnet command handling interfere and alter data?

-M@

tschak909 · September 14, 2018

See what happens.

The PLATO protocol has a facility called "echo packets" which requires that the terminal look at what's sent over, and either return the same value back (typically means, I do not support that query), or change the value to indicate a particular response.

If the initial echo packets are not received, the system will assume it is talking to a dumb terminal, and present a message asking to log on as a dumb terminal.

The other strange thing to note is that PLATO sends everything with even parity. Modern PLATO terminals literally take this and strip off the parity.

-Thom

+Ksarul · September 14, 2018

The fact that PLATO was using parity bits is not strange at all. Phone lines back then were notoriously noisy, as the line filters were optimized for voice traffic, not data. Using parity helped the computers at both ends to filter out the extraneous line noise. . .and ask the sender to retransmit damaged characters.

tschak909 · September 14, 2018

Oh yeah, I know, I meant "strange" as in "unexpected for modern use"

-Thom

+jedimatt42 · September 17, 2018

irata sends:
------------
0d 0a 43 6f 6e 6e 65 63 74 69 6e 67 20 74 6f 20   Connecting to
68 6f 73 74 20 2d 20 70 6c 65 61 73 65 20 77 61 host - please wa
69 74 20 2e 2e 2e 0d 0a                         it ...

0d 0a 43 6f 6e 6e 65 63 74 65 64 0d 0a 0a         Connected

0c 57 45 4c 43 4f 4d 45 20 54 4f 20 54 48 45 20  WELCOME TO THE
4e 4f 53 20 53 4f 46 54 57 41 52 45 20 53 59 53 NOS SOFTWARE SYS
54 45 4d 2e 0d 00 0a 43 4f 50 59 52 49 47 48 54 TEM.   COPYRIGHT
20 43 4f 4e 54 52 4f 4c 20 44 41 54 41 20 53 59  CONTROL DATA SY
53 54 45 4d 53 20 49 4e 43 2e 20 31 39 39 34 2e STEMS INC. 1994.
0d 00 0a 39 30 2f 30 39 2f 31 36 2e 20 31 38 2e    90/09/16. 18.
34 37 2e 32 39 2e 20 54 45 32 32 20 20 20 0d 00 47.29. TE22
0a 20 4e 4f 53 20 43 59 42 49 53 20 53 59 53 54   NOS CYBIS SYST
45 4d 20 2d 20 43 59 42 44 45 56 2e 20 31 2e 20 EM - CYBDEV. 1.
20 20 20 20 20 20 20 20 20 4e 4f 53 20 32 2e 38          NOS 2.8
2e 37 20 38 37 31 2f 38 37 31 2e 20 20          .7 871/871.

90 82 00 00 00 00 00 00 1b 82 00 00 00 1e 41 1b               A
93 11 1b 59 50 41 c0 8d 0a 90 03 00 00 00 00 00    YPA

The first 3 blips are just terminal text, and they display fine.

I doubt I've interpreted the code correctly... I'm assuming it is starting this sequence with the escape flag == false. xx -> xx is me computing & 0x7f in my head.

(commands translated)
90 -> 10 (newline?)
82 -> 02 (InitPLATOx)
00 x 6
1b -> 1b (escape)
82 -> 02 (??? I cannot find meaning of 2 w/escape-flag)
00 x 3
1e -> 1e (data)
41 -> 41 ('A')
1b -> 1b (escape)
93 -> 13 (cr)
11 -> 11 (data)
1b -> 1b (escape)
59 -> 59 (load echo)
50 -> 50 (query/command? don't see this in the code)
41 -> 41 (data)
c0 -> 40 (data)
8d -> 0d (data)
0a -> 0a (data)
90 -> 10 (data)
03 -> 03 (data)
00 x 5

Some newlines, and whitespace, an InitPLATOx command, some confusion on my part, then the 'A' that we see on the otherwise blank screen.

An escape, that doesn't make sense... as it is followed by 0x13 (or 0x93) that doesn't seem to be interpreted.

Then we get to the loadEcho that causes the 4A to reply as follows:

4a replies:
-----------
1b  -> (response to load echo: 50)
50
60

To the best of my ability to read the code, that is what is expected... Reading the spec ins't helping (me) either.

Then nothing...

What should the 4A be doing in response to that command sequence?

-M@

tschak909 · September 17, 2018

I'm sifting through this, but I'll paste this,anyway. This is a successful connect, all the way up to the welcome screen (which is where I snipped, just before the screen clear for the welcome screen)

https://paste.ubuntu.com/p/sg7jm4BWZ4/

-Thom

+9640News · September 25, 2018

Thom,

As your terminal software was written for serial based devices, and you are now using a Telnet connection with a TIPI, I discovered if your data stream has 0xFF in the stream, it has a special meaning. You would need to look at the IAC command Telnet codes. Not sure if you saw those messages on the other thread in this forum.

I had a data stream with 0xFF contained and had to program around it. If the 0xFF has a specific command following it, you will have to deal with it, etc.

Beery

+jedimatt42 · September 25, 2018

The Plato server assumes you are connecting with a PlatoTerm. TELNET isn't in the mix. TIPI is not inserting TELNET into your stack. It provides a low level TCP socket. From what I read the server is not interacting with the TELNET protocol unless the PlatoTerm negotiation fails.

-M@

+jedimatt42 · September 25, 2018

Additionally, the data captures above are from the socket, and they show no evidence of telnet IAC bytes.

-M@

Need help debugging PLATOTerm TIPI routines

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members