Jump to content

Photo

Programming with the TIPI


21 replies to this topic

#1 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • 578 posts
  • Location:Campbellsburg, KY

Posted Sun Aug 26, 2018 4:33 PM

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 by BeeryMiller, Sun Aug 26, 2018 4:34 PM.


#2 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,202 posts

Posted Sun Aug 26, 2018 5:02 PM

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.



#3 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Sun Aug 26, 2018 6:10 PM

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



#4 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,800 posts
  • Location:Beaverton, OR

Posted Sun Aug 26, 2018 6:54 PM

To use those vectors, there is an assembly example in https://github.com/j...rtist/tipim.a99
 
The TCP protocol that uses those same vectors is documented here: https://github.com/j...i/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. icon_smile.gif 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@

#5 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,800 posts
  • Location:Beaverton, OR

Posted Sun Aug 26, 2018 7:00 PM

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@

#6 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Sun Aug 26, 2018 7:11 PM

Matt,

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

 

Beery



#7 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,800 posts
  • Location:Beaverton, OR

Posted Sun Aug 26, 2018 7:19 PM

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@
  • RXB likes this

#8 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Mon Aug 27, 2018 5:47 AM

OK, thanks for the extra info.

Beery



#9 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Mon Aug 27, 2018 5:08 PM

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



#10 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Tue Aug 28, 2018 2:23 PM

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 by BeeryMiller, Tue Aug 28, 2018 6:09 PM.


#11 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,800 posts
  • Location:Beaverton, OR

Posted Tue Aug 28, 2018 10:25 PM

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@
  • RXB likes this

#12 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,241 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Aug 29, 2018 1:59 AM

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.



#13 Shift838 OFFLINE  

Shift838

    River Patroller

  • 2,412 posts
  • SHIFT838
  • Location:Deer Park, Texas

Posted Sat Sep 1, 2018 5:06 PM

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.



#14 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Mon Sep 17, 2018 4:42 PM

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



#15 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Tue Sep 18, 2018 6:09 AM

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



#16 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Tue Sep 18, 2018 6:50 PM

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

 

Attached Files

  • Attached File  MT.ARK   70.88KB   1 downloads


#17 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,800 posts
  • Location:Beaverton, OR

Posted Tue Sep 18, 2018 8:41 PM

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@



#18 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,202 posts

Posted Tue Sep 18, 2018 9:03 PM

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 by InsaneMultitasker, Tue Sep 18, 2018 9:09 PM.


#19 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Wed Sep 19, 2018 4:58 AM

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



#20 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Wed Sep 19, 2018 6:29 AM

 

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



#21 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 578 posts
  • Location:Campbellsburg, KY

Posted Wed Sep 19, 2018 8:00 PM

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



#22 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,202 posts

Posted Yesterday, 11:49 AM

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. 






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users