Programming with the TIPI

[+9640News]

Matt,

 

I was digging around in the DSR for the TIPI code on GitHub and have a couple of questions regarding the vector at >4010 for "recvmsg". I needed to understand what needed to be passed into the vector, as well as what/where things were returned. I got part of the information, just need some more clarity.

 

Is there a minimum buffer length I should anticipate such that I have no problems?

 

Secondly, is the message for either the recvmsg or sendmsg vectors at >4010 and >4012 prefaced with anything special for Telnet communications? Or, are any characters sent automatically sent/received for processing for the display for a telnet connection?

 

As I am not a C programmer, I am trying to understand the interface and how it compares with the RS232 which is a byte by byte send or receive.

 

Beery

Edited August 26, 2018 by BeeryMiller

[+InsaneMultitasker]

Beery - I saw your question in the TIPI thread re: Fastterm source code. I am replying in your thread versus the TIPI development thread.

 

You'll find that pretty much all terminal programs use the VDP-based circular interrupt buffer (CIB) . Direct polling is even 'worse' than the CIB - it will drop characters much more quickly. The way around this with the RS232 is to use hardware handshaking or the modified interrupt method employed in TIMXT.

 

If I recall correctly, no such handshaking or interrupt method is needed with the TIPI, so a loop method should work fine. Though you might want to use the VDP interrupt to limit how often you call the keyboard scan and/or check for pending characters.

[+9640News]

OK, thanks Tim.

 

Been digging into C source for Telnet. Looks like there is more to the send and receive messages than what I originally though. Going to have to dig into the Mass Transfer source code more to figure out the segments and pieces of the code. Worse part the editing of source is not as easy on the TI than the Geneve.

 

Went digging into the C source code for Telnet and discovered there is a bit more information on the send/receive message required through the vectors. Not that I did not expect it, but the open, close, read, write, etc. through the vector ports.

 

Beery

[+jedimatt42]

To use those vectors, there is an assembly example in https://github.com/jedimatt42/tipi/blob/master/examples/tiartist/tipim.a99

 

The TCP protocol that uses those same vectors is documented here: https://github.com/jedimatt42/tipi/wiki/Extension-TCP

 

---

 

(This is from memory... I'm not an experienced assembly language programmer, so there will be errors)

 

For general extension use:

 

1st: You MUST find the CRUBASE of the TIPI board. There are example routines in the (assembly) TIArtist mouse driver, and the (gcc) Telnet program.

I will assume you stashed the discovered CRUBASE in a memory address referenced by @TIPICRU

 

The DSR ROM has the address of the message routines in these fixed locations... so you lookup address stuff it in a register, and then call it.

SENDMSG	EQU	>4012
RECVMSG	EQU	>4010

A message is sent by stuffing the length of your message in GPLWS R0, and the address of your message's bytes in GPLWS R1

Then transition to the GPLWS, and call the routine:

 

 

MOV @TIPICRU,R12
SETO 0
LWPI GPLWS
MOV @SENDMSG,R4
BL *R4
LWPI MYWORKSPACE
SETZ 0

 

There is no 'result' of the message send... it just worked, or it hung/crashed.. whatever... hobby code. Customarily, there is a message waiting to be received containing your result depending on the extension used.

 

Similiarly to receive a message, you have to load up the GPLWS with some parameters, use that workspace, then call it.

Here I'm assuming you have a chunk of memory who's address is in @RECVBUFF

R0 in GPLWS will end up with the size of the received message, it is important to clear it first. I cannot remember if I fixed the ROM to do this for you or not.

 

MOV @TIPICRU,R12
SETO 0
LWPI GPLWS
CLR R0
MOV @RECVBUFF,R1
MOV @RECVMSG,R4
BL *R4
LWPI MYWORKSPACE
SETZ 0

Now the length of what was received, if anything is @GPLWS. And the received data is in your specified buffer.

 

---

 

Now, to use this messaging to do TCP work...

 

First you need to send a message that requests an open socket. 0x22 is the TCP subsystem. 0x01 is the open command. That message would look like:

 

[ 0x22, 0x00, 0x01 ] + "localhost:23"

 

The wiki page is wrong, but you don't need to worry about the error. It is trying to say you don't have to worry about the length of the hostname:port string.

So, if your hostname and port is as above, your message data would be:

 

2200 016c 6f63 616c 686f 7374 3a32 33

Send that message, then receive a message to see what TIPI thinks of you. If it succeeds you'll get a message of length 1 with the value 255... I often receive these response messages directly into a register as the buffer.

 

Now with this information does the Extension-TCP page make sense?

 

-M@

[+jedimatt42]

Length of the receive buffer is either implied as a requirement of the protocol ( the mouse demands 3 bytes ) or is part of the request data sent (a tcp read command contains the max number of bytes you want to read... your buffer better handle that. )

 

-M@

[+9640News]

Matt,

Thanks for that information. Excellent! Will help me out quite a bit!

 

Beery

[+jedimatt42]

Oh, and those routine don't have to be called in the GPLWS, but they have only been tested there. I do that for accessing them from gcc, so it doesn't play with the gcc workspace, they clobber several registers, so you are best using a different workspace than your main program flow does. The GPLWS is handy cause it's already allocated on a 4A.

 

 

-M@

[+9640News]

OK, thanks for the extra info.

Beery

[+9640News]

Matt,

 

I've got the connection established so it is connecting with another Telnet site. I thought I had the send/receive code worked out, but I am hitting a small snag. Just need time to do some debugging and looking at a few more examples. It is more than likely I am dealing with some remnants of the circular interrupt buffer though I thought I had that all commented out.

 

Fortunately, I figured out an easy way to do the editing in 80 columns. Edit/assemble on the Geneve, copy the files to a floppy and run it on the TI-99/4A / TIPI system.

 

As far as the "Phonebook" features someone mentioned, after looking at the code, it is going to be fairly easy to implement once I have the I/O worked out.

 

Beery

[+9640News]

Matt,

 

Been thinking about the use of Telnet for the Sendmsg and Recmsg routines and have some questions.

 

First, I scan for the TIPI to get the correct CRU. Done.

 

I then do an Open command to establish the connection. Done.

 

 

This message has been edited: Scratch everything else. i have seen some of my logic faults after digging back into the Telnet client again. Then, looking at my code, I saw some issues as well.

Beery

Edited August 29, 2018 by BeeryMiller

[+jedimatt42]

Just to point something out: TELNET is a protocol built on top of TCP.

 

TIPI provides TCP sockets through a messaging extension.

 

The telnet protocol requires negotiations and such... there are plenty of resources on that including the source code for my TELNET client. A uds-10 or Wimodem implements telnet for you. TIPI's TCP extension does not.

 

In addition to telnet, the TCP extension can be used to build ftp, http, and irc (and many more) clients that are written for the 4A.

 

 

-M@

[Tursi]

For what it's worth, back in the day I put a really dumb telnet compatible mode into my muck client. If you've read the RFC, basically I answered every WILL with WON'T and every DO with DON'T until the other side stopped asking. Connected to every server I tried it on (without any features, of course). Definitely not what a real telnet client would want, but if you just want BBS-like functionality, it works.

[Shift838]

I think with the release of the TiPi there are going to be some good programs coming out for all of us TiPi'ers to take advantage of.

[+9640News]

Good news. Finally had time to sit down to dig around more in the Mass Transfer source code. I now have it dialing, connecting to my BBS, and sending/receiving characters as it was supposed too.

 

I have not started digging around the XMODEM code yet.

 

It has taken time identifying the pieces of Mass Transfer I needed to remove to interface the code due to t he way the circular RS232 buffer was being handled.

 

Later,

Beery

[+9640News]

Matt,

 

Trying to resolve an issue with using TIPI with the Mass Transfer source code. What I am seeing is when I do a screen scroll, there are lines about every 3 rows across the screen. As soon as the screen stops scrolling, lines disappear. I also see a hint of screen flicker when entering keys.

 

I am thinking this may be related to interrupts, so I have some questions.

 

Is there a problem with interrupts on or do they need to be off when accessing the TIPI with reads/writes?

 

When a write command is sent to the TIPI, must one read if the content was successfully sent? Trying to understand if this is a requirement with some kind of buffering or stack issue that could complicate things? Thinking here is speed when I start modifying the XMODEM transfer code. Found the area of code needing tweaking, just want to maximize transfer speed.

 

Thanks for any feedback.

 

Beery

[+9640News]

I am uploading a copy of the Mass Transfer source code with compiled image file here for anyone that wants to look at the source code. I will be doing some traveling Thursday through Sunday, and should anyone want to see what could be causing the screen flicker issue, feel free to explore.

 

The code assembles with GenASM under the Geneve and will not assemble with the E/A assembler as I used long file names.

 

As this version of the MT source code was 40 columns, I have a hardcoded BBS telnet connection for Telnetting purposes at Fusionbbs.

When you load the program, skip the Phone directory option that pulls up. At the Main Menu, select R for the connection. If FusionBBS is not busy, it will connect. Then, simply press <ENTER> and you will see the BBS.

 

No support for XMODEM transfer yet. Code in XMODEM1 source file will need to be modified. Have not had time to begin that work.

 

The code for talking with the TIPI is in the TERM_S2 file. It's not pretty, and no error detection is there yet.

 

Anyways, if anyone else wants to look at it, feel free to take a stab and explore/test/etc. Just please share your updates.

 

Right now, I do not know why the screen flicker occurs. I would like to solve that before the XMODEM routine is tackled. As the pieces are in TERM_S2, the changes to XMODEM1 can be pretty much copied and used as the code used direct I/O to the RS232 port rather than the circular interrupt buffer.

 

Myself, I assemble on the Geneve with GenASM, copy the files (UTIL1/UTIL2), and then run on the TI-99/4A.

 

Anyways, hopefully someone will look it over.

 

Beery

 

MT.ARK

[+jedimatt42]

Matt,

 

Trying to resolve an issue with using TIPI with the Mass Transfer source code. What I am seeing is when I do a screen scroll, there are lines about every 3 rows across the screen. As soon as the screen stops scrolling, lines disappear. I also see a hint of screen flicker when entering keys.

 

I am thinking this may be related to interrupts, so I have some questions.

 

Is there a problem with interrupts on or do they need to be off when accessing the TIPI with reads/writes?

 

When a write command is sent to the TIPI, must one read if the content was successfully sent? Trying to understand if this is a requirement with some kind of buffering or stack issue that could complicate things? Thinking here is speed when I start modifying the XMODEM transfer code. Found the area of code needing tweaking, just want to maximize transfer speed.

 

Thanks for any feedback.

 

Beery

 

yes, messaging to TIPI is synchronous. If TIPI is trying to send the 4A a response message, the only thing you can do is read the response message.

 

The response will either be 0x00 or 0xFF. 0x00 indicates a socket write failure. ( sorry, I'm more of a java programmer than a c programmer ) so 0x00 is logically false in C, .. meaning the socket write failed.

 

Interrupts should be off when using the tipi routines if they are using the GPLWS, as depicted in my examples. Otherwise the interrupt routine will trash the WS. There are vrecvmsg and vsendmsg routines in the ROM as well that expect the buffer to be a VDP address, and interrupts would need to be off for those as well for the same reason + consistency of the auto-increment address in the VDP.

 

TIPI does not generate interrupts. So the reasons for interrupts being turned on in the program may require re-evaluation.

 

 

 

-M@

[+InsaneMultitasker]

Beery,

The flicker you described sounded like something I used to do with the vdp color register to mimic the C64 rainbow effect on the background. I took a peek at the code - - Mass Transfer flips the screen color when the internal buffer is reaching its limit (and sets it red) and then flips it back to normal when the buffer is exhausted or a dump occurs. Because you disabled the buffer lower limit test, the routine looks to be dropping into the routine to change the screen colors every time you display a char. Probably just need to finish commenting out that section.

 

(Edit: I don't recall seeing this routine called from the scroll, so you might have to poke around to see if there is anything related to VWTR in the code)

 

DISP

* MOV @MAXLB,R1
* AI R1,-500
* C R13,R1 *WITHIN 500 BYTES OF END OF BUFFER?
* JNE DSP10 *NO
MOV @COLREG,R0 *
CLR R1 *
ANDI R0,>00FF *
SRC R0,4 *SWAP BACKGROUND AND FOREGROUND COLORS
MOVB R0,R1 *
SRC R1,8 *
A R1,R0 *
MOVB @COLREG,R0 *
BLWP @VWTR *CHANGE SCREEN TO RED
DSP10
* C R13,@MAXLB *ARE YOU AT THE END OF THE BUFFER
* JNE DSP20 *NO
* MOV @LOGFLG,@LOGFLG *YES, IS THE LOG OPEN?
* JEQ DSP15 *NO
* BL @DMP5 *YES GO DUMP IT
DSP15
CLR R13 *YES, RESET BUFFER POINTER & OVERWRITE THE BUFFER
MOV @COLREG,R0
BLWP @VWTR
DSP20 INC @BLNKCT
MOV @BLNKCT,R0
CI R0,350
JNE DSP30
BL @BLINK

Edited September 19, 2018 by InsaneMultitasker

[+9640News]

Thanks Tim. If I have time tonight, I will comment out the code. Gotta take the wife out to dinner, pick a mess of okra, do some house chores, and finish packing for an early trip headed to upper Alabama just below Nashville in the morning if the weather holds.

 

Beery

[+9640News]

 

yes, messaging to TIPI is synchronous. If TIPI is trying to send the 4A a response message, the only thing you can do is read the response message.

 

The response will either be 0x00 or 0xFF. 0x00 indicates a socket write failure. ( sorry, I'm more of a java programmer than a c programmer ) so 0x00 is logically false in C, .. meaning the socket write failed.

 

Interrupts should be off when using the tipi routines if they are using the GPLWS, as depicted in my examples. Otherwise the interrupt routine will trash the WS. There are vrecvmsg and vsendmsg routines in the ROM as well that expect the buffer to be a VDP address, and interrupts would need to be off for those as well for the same reason + consistency of the auto-increment address in the VDP.

 

TIPI does not generate interrupts. So the reasons for interrupts being turned on in the program may require re-evaluation.

 

 

 

-M@

 

Thanks Matt. I have not done any coding for the TI-99/4A side of things since the 90's as everything was pretty much on the Geneve side of things.

 

Beery

[+9640News]

Tim,

 

Commenting out that code fixed the issue with the screen issue I had. Thanks for that help!!!

 

I also had a few minutes of spare time and I got the XMODEM code downloading "some". I've got to go through the code and redo some timers, but I did get 7 sectors to transfer this evening. So, I am close.

 

I will be able to tackle more coding next week.

Beery

[+InsaneMultitasker]

Tim,

 

Commenting out that code fixed the issue with the screen issue I had. Thanks for that help!!!

 

I also had a few minutes of spare time and I got the XMODEM code downloading "some". I've got to go through the code and redo some timers, but I did get 7 sectors to transfer this evening. So, I am close.

 

I will be able to tackle more coding next week.

Beery

Glad to hear that! You might need to escape the Telnet IAC character and do some other Telnet-y stuff, depending on the connection that is established.

[+9640News]

Tim,

 

I've been banging my head on trying to figure out what is going on with the XMODEM transfer routine.

 

I start a download, and get about 15 (maybe 16?) x 128 records transferred, then it immediately starts counting up retries and then aborts.

 

I thought it was a timeout issue, but as far as I can tell, that is not the case.

 

Would there be another timer or something that may be going on with interrupts I may not be considering?

 

Beery

[+InsaneMultitasker]

The Mass Transfer interrupt routine is very simple and most likely not the problem. If memory serves, the xfer delay between bytes is one second and record delay is 10 seconds. You can of course adjust the timing using the defined values.

 

Verify that your file transfer receive byte routine is not dropping the null character (0x00). The original terminal receive routine is set to use 0x00 as a flag for no character reception. Thus the terminal and transfer routines are separate.

 

Inspect the file you are transferring. Are there any 0xFF bytes within the first 15-16 records? If not, then you are probably just getting lucky with your choice of file.

 

Create a file with some 0xFF bytes in the first records. The transfer will likely fail at the first record containing the 0xFF bytes.

 

If so, then you probably need to take into account escaping the Telnet IAC (0xFF) and/or enable (and request) 8-bit transfers, i.e., you need to account for the Telnet protocol's nuances yourself.

 

Edit: when I was testing the wimodem/wifimodem devices for compatibility with Heatwave's transfer routines, I used Wireshark and Ethereal to inspect the packets between the PC and Geneve system.

Edited September 24, 2018 by InsaneMultitasker

[+9640News]

Tim,

 

I think you may have hit upon the issue. At about the 16 record (8th sector), there was a >FF character in the file. That was its first occurrence. I copied the same file, and put a >FF in the first 16 bytes, and BAM, it aborted on the first record/sector.

 

I looked at the telnet IAC commands at http://users.cs.cf.ac.uk/Dave.Marshall/Internet/node141.htmland I do not see anything obvious I would need to do.

 

When I looked elsewhere, I saw some issues people were having with Python. So, Matt, what would I need to do if I have a character of >FF coming in on a Telnet connection? Is there some kind of special message I can send when I establish a connection that is active during the entire time the connection is open?

 

Trying to figure out how to capture that byte. I'm also wondering if this could also have some relationship to the PLATO with TIPI communications too.

Beery