tschak909 Posted September 7, 2018 Share Posted 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 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted September 7, 2018 Share Posted 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? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 7, 2018 Author Share Posted September 7, 2018 Oops, yeah, Sure, I'll attach a DSK here, PLATOTEST.dsk -Thom Quote Link to comment Share on other sites More sharing options...
+9640News Posted September 10, 2018 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 10, 2018 Author Share Posted September 10, 2018 @beery, odd that you should see the admin message, it means PNI failed somehow. Can you try reconnecting? -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 10, 2018 Author Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+9640News Posted September 10, 2018 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 10, 2018 Author Share Posted 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 10, 2018 Author Share Posted 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) Quote Link to comment Share on other sites More sharing options...
+9640News Posted September 10, 2018 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
RickyDean Posted September 11, 2018 Share Posted 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? Quote Link to comment Share on other sites More sharing options...
+9640News Posted September 11, 2018 Share Posted September 11, 2018 I will see what I can do tonight. Beery Quote Link to comment Share on other sites More sharing options...
+9640News Posted September 12, 2018 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 12, 2018 Author Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted September 12, 2018 Share Posted 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@ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 12, 2018 Author Share Posted September 12, 2018 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted September 14, 2018 Share Posted 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@ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 14, 2018 Author Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted September 14, 2018 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 14, 2018 Author Share Posted September 14, 2018 Oh yeah, I know, I meant "strange" as in "unexpected for modern use" -Thom Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted September 17, 2018 Share Posted 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@ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 17, 2018 Author Share Posted 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 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted September 25, 2018 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted September 25, 2018 Share Posted 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@ Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted September 25, 2018 Share Posted September 25, 2018 Additionally, the data captures above are from the socket, and they show no evidence of telnet IAC bytes. -M@ Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.