Jump to content
9640News

TIPI - Geneve 9640 to Raspberry PI interface development

Recommended Posts

16 minutes ago, jedimatt42 said:

When you send the open message, it shouldn't have trailing bytes...  the sendmsg routine should be specifying the actual length of the message which in this case is 20 bytes.. 

 

This message is received by the python code and split on the ':' the second part should just be the digits in the port. But if you are sending a padded buffer, the python int(string) function is having to deal with the extra data. 

 

So your open request should only be this part:  2201 0131 3932 2E31 3638 2E31 2E37 323A 3936 3430

 

OK, I see my error.  I had hard coded a length in the sendmsg routine for the OPEN URL call, and everything in the past had been padded with >20's that were not an issue.  Got to clean up some code.


Beery

 

  • Like 1

Share this post


Link to post
Share on other sites

This is TIPI related Matt...........  First two paragraphs are giving some background information.

 

I have seen a behavior with the Geneve I remember existing back in the 90's, and is still present today when using MyWord.  On occasion, I have run a MDOS program and I will subsequently run MyWord from EXEC and the time/date information on the bottom of the screen does not display.  I believe this is tied to an interrupt handler or some bit(s) being set on the bus, but not certain.

 

On a fresh boot of MDOS, or on a warm reboot of MDOS with the "&" key, the time/date information reappear back in MyWord.

 

On a fresh boot or warm reboot of MDOS, I have an issue detecting ANSI from the MDOS CLI embedded Telnet client.  However, when I run MyTerm for the TIPI and then return to MDOS to use the Telnet client, I have no issue with the embedded telnet client detecting ANSI from the connected system.

 

Both the embedded Telnet client and MyTerm for the TIPI are using the same ANSI driver (new installable driver/XOP for MDOS) and the same XOP code for TIPI TCP access.

 

If I remember correctly Matt, I think you indicated some unreliable ANSI detection issue with your telnet client and is why I brought it up here.

 

 

Share this post


Link to post
Share on other sites
9 hours ago, 9640News said:

This is TIPI related Matt...........  First two paragraphs are giving some background information.

 

I have seen a behavior with the Geneve I remember existing back in the 90's, and is still present today when using MyWord.  On occasion, I have run a MDOS program and I will subsequently run MyWord from EXEC and the time/date information on the bottom of the screen does not display.  I believe this is tied to an interrupt handler or some bit(s) being set on the bus, but not certain.

 

On a fresh boot of MDOS, or on a warm reboot of MDOS with the "&" key, the time/date information reappear back in MyWord.

 

On a fresh boot or warm reboot of MDOS, I have an issue detecting ANSI from the MDOS CLI embedded Telnet client.  However, when I run MyTerm for the TIPI and then return to MDOS to use the Telnet client, I have no issue with the embedded telnet client detecting ANSI from the connected system.

 

Both the embedded Telnet client and MyTerm for the TIPI are using the same ANSI driver (new installable driver/XOP for MDOS) and the same XOP code for TIPI TCP access.

 

If I remember correctly Matt, I think you indicated some unreliable ANSI detection issue with your telnet client and is why I brought it up here.

 

 

I don't know how to interpret this. All I can say is TIPI only provides 'socket' level interface. Anything protocol related like TELNET, TERMinal negotiation, and processing of the bytes received is the realm of the code we write on the TMS9900 or TMS9995 to execute. Maybe one of the programs is not closing the socket? The socket object on the python side is stateful for the life of the tipi.service (which on a 4A is reset for every visit to the TI title screen) , paired with the socket id number the client chooses.  Maybe change the socket ID that MyTerm uses, and see if that stops 'clearing' the issue with the MDOS embedded TELNET. My guess is there is cleanup code in MyTerm that is missing from TELNET. And for reliability sake, it needs to be on the entry

 

What is the 'detecting ANSI' dataflow? The TELNET layer can describe the terminal upon request, a little. But does it know that the XOP based ANSI driver is loaded? Or is the server sending codes, that get blindly forwarded through the TELNET layer to the ANSI layer? And does the ANSI layer then have a means of actually responding (to the socket) ? ( I have had very poor luck finding documentation on what BBS servers attempt to do to decide if a terminal client supports ANSI or not... ) 

 

 

Share this post


Link to post
Share on other sites
33 minutes ago, jedimatt42 said:

I don't know how to interpret this. All I can say is TIPI only provides 'socket' level interface. Anything protocol related like TELNET, TERMinal negotiation, and processing of the bytes received is the realm of the code we write on the TMS9900 or TMS9995 to execute. Maybe one of the programs is not closing the socket? The socket object on the python side is stateful for the life of the tipi.service (which on a 4A is reset for every visit to the TI title screen) , paired with the socket id number the client chooses.  Maybe change the socket ID that MyTerm uses, and see if that stops 'clearing' the issue with the MDOS embedded TELNET. My guess is there is cleanup code in MyTerm that is missing from TELNET. And for reliability sake, it needs to be on the entry

 

What is the 'detecting ANSI' dataflow? The TELNET layer can describe the terminal upon request, a little. But does it know that the XOP based ANSI driver is loaded? Or is the server sending codes, that get blindly forwarded through the TELNET layer to the ANSI layer? And does the ANSI layer then have a means of actually responding (to the socket) ? ( I have had very poor luck finding documentation on what BBS servers attempt to do to decide if a terminal client supports ANSI or not... ) 

 

Matt,

 

I have posted a portion of the communication between a MyTerm connection to the Mystic BBS.  This is where an ESC[6n (>1B,>5B,>36,>6E) command is received, and then the response is sent back.

 

Receive byte(s): 1B
Receive byte(s): 5B
Receive byte(s): 36
Receive byte(s): 6E
Send byte:       1B
Send byte:       5B
Send byte:       32
Send byte:       35
Send byte:       3B
Send byte:       30
Send byte:       38
Send byte:       30
Send byte:       52

 

The Sent bytes are defined as:

 

BYTE   >1B,>5B

DATA   0       (line number, 2 digits in ASCI)

BYTE   ';','0'  (zero, not null)

DATA   0   (column number, 2 digits in ASCI)

BYTE   'R'
 

Now, on my BBS, there is text with an initial clear screen that is sent with expectation of 80x24 screen at which time the 4 receive bytes noted above come in the sequence.  It "knows" where the cursor should be at the end of the text sequence, and I believe the response with the line number and column number should match its expected location.  At least that is my take.

 

Still working through the issue as something isn't adding up.

 

 

 

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
18 hours ago, 9640News said:

BYTE   >1B,>5B

DATA   0       (line number, 2 digits in ASCI)

BYTE   ';','0'  (zero, not null)

DATA   0   (column number, 2 digits in ASCI)

BYTE   'R'

FYI, (you may already know this) 6n is a request to query cursor position and 'R' reports the position.  This is not the terminal type query or detection, though if a terminal responds you can infer some level of capability. 

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...