Using TIPI socket interface in assembler (was: copying E/A 3 problem)

[Stuart]

I'm trying to get a small E/A 3 object file to Omega to test. I'm assembling it using Asm994a and I can load and run it fine using Classic99.

 

I tried sending a copy of this file to Omega to test; Omega copies the file from his PC to the TIPI with the TIPI's browser based transfer routine, like he does with other files. He tries to load it using E/A but gets I/O error 2.

 

Omega sends me an E/A 3 file which works for him for me to look at. It looks like it has a TI files(?) header on it. So I take my object file and use the Ti99Dir program "Convert PC File to TI File" command to convert the file, using the options file type "DIS/FIX", record length 80, "Remove CR and/or LF (EDITOR/ASM)". Omega isn't able to load this file either. I've attached a copy of this file.

 

What do I need to do to get the E/A 3 file to work?

TIPI.zip

Edited September 26, 2018 by Stuart

[HOME AUTOMATION]

When I use E/A option 3 in Classic99 "DSK2.TIPI" I hit enter... I get bumped to the EDITOR MENU!!!

When I use MININMEM option 1 in Classic99 "DSK2.TIPI" I hit enter... I get error 5. So I tried a second time (sometimes a bug in MINIMEM causes the first time to fail) and I got DUPLICATE DEFINITION... so I tried to run "START" it seems to run!

 

"OPENING DEVICE: TIPI.TCP=WWW.CWFK.NET:80

... FAILED"

 

I'm not sure what any error codes are anymore... I try to avoid them. HA-HA...

[HOME AUTOMATION]

Repeated the Above on real iron with TIPI online... same exact results...

[Tursi]

Remember that Classic99 can translate /Windows text files/ into the TI display/variable format transparently - I don't think TIPI does this. And that's what Asm994a outputs - a Windows text file.

So if you want to use it through TIPI, I believe it needs to be converted to TIFILES format or copied to a TI disk image. You also need to make sure the file type is set correctly - compressed files are Display/Variable 80, and uncompressed files (which this is) are Display/Fixed 80.

The ZIP contains a V9T9 file, Display/Fixed 80, but I don't see the end record that an object file needs...? The last line of the file should start with a full colon ( : ), it appears that got lost somewhere in translation.

Since you are testing in Classic99 anyway, you could always just convert it there... load the file up in the Editor then save it back out with a new filename, and Classic99 will write the TIFILES version for you

Edited September 25, 2018 by Tursi

[PeteE]

Remember that Classic99 can translate /Windows text files/ into the TI display/variable format transparently - I don't think TIPI does this. And that's what Asm994a outputs - a Windows text file.

 

So if you want to use it through TIPI, I believe it needs to be converted to TIFILES format or copied to a TI disk image. You also need to make sure the file type is set correctly - compressed files are Display/Variable 80, and uncompressed files (which this is) are Display/Fixed 80.

TIPI will translate some files based on the file extension, see here. But none of those extensions will enable reading as DF/80.

 

I tested the file on my TIPI through the web interface, it shows a TI icon with red ?, so I check the box next to in the "Select Action" menu choose "Convert v9t9 to TIFILES" and click Submit. That makes the red ? go away, so tried loading it with E/A option 3 with file name TIPI.TIPI seems okay, but on the next screen doing 1 TO LOAD results in I/O ERROR CODE 0.

Edited September 25, 2018 by PeteE

[+arcadeshopper]

ok the file is v9t9 format and on the tipi it needs to be tifiles..so converting that to tifiles is first step..

ea option 3 it returns to the editor menu then if i hit back and select run then START for the start point it runs.. "opening device: TIPI.TCP=WWW.CWFT.NET:80 .. FAILED"

 

should't this be PI.TCP? https://github.com/jedimatt42/tipi/wiki/Devices

 

Greg

[Stuart]

Thanks all. Tursi's suggestion of loading the file in the E/A Editor in Classic99 then saving it again under a different filename did the trick!

[Stuart]

 

should't this be PI.TCP? https://github.com/jedimatt42/tipi/wiki/Devices

 

 

Well yes, that's a question, and what I was hoping to find clear documentation for!

 

What I'm trying to do is reproduce what's in the video here (TIPI Does TCP - https://www.youtube.com/watch?v=VpYcPHIbxU4) in assembler. That video shows (in BASIC) opening the device TIPI.TCP. So that's what I've tried doing (opening the device TIPI.TCP=WWW.CWFK.NET:80) using the standard PAB and DSRLNK call, and checking the equal bit in the status error to check if the DSRLNK completed successfully or not. So am I on the right track (although it seems to be failing) or do I need a different approach?

Edited September 26, 2018 by Stuart

[+jedimatt42]

Oops, yes the non-file stuff was moved from the TIPI. device to the PI. device.

 

The DSR approach is really just meant for BASIC integration.

 

For assembly or other languages take a look here: http://atariage.com/forums/topic/282309-programming-with-the-tipi/page-1?do=findComment&comment=4099723

 

-M@

[+9640News]

I have uploaded in another area on Atariage some Mass Transfer source code that got the basics for communications in assembly. I have also uploaded some more recent source files to 9640news.ddns.net:9640 in the Telnet area (MT201809??.ark) source files and images of the more recent code. It is still not the latest code, but has most of the pieces.

 

It is probably not the cleanest piece of code, but I had to "mold" it to work with how Mass Transfer was written without destroying any other registers, etc in other workspaces.

 

I did learn that when you open a socket connection, you can set a longer URL:port length than the actual length is, AS LONG AS, it is spaces. That made the phone directory much easier to implement so I did not have to determine length of URL string. I just tell it to copy something like 50 characters, and tell the Open Command the length of the Open string is like 3 bytes + 50 bytes and all is well.

 

Beery

Edited September 27, 2018 by BeeryMiller

[Stuart]

Thanks all. I'll start again!

[Stuart]

For assembly or other languages take a look here: http://atariage.com/forums/topic/282309-programming-with-the-tipi/page-1?do=findComment&comment=4099723

 

-M@

 

Matt, a couple of questions as I haven't got a TIPI to test against.

 

(1) The open socket command.

 

-- Can I assume that if the specified host does not exist, the open socket command returns a value 0 'failed to connect'?

 

-- The command accepts text and dotted-decimal host addresses (www.bbc.co.uk and 12.456.789.1)?

 

-- I do a MOV @SENDMSG,R4 and BL *R4 to send the message (after setting up R0 and R1). How quickly after that does the Pi have the return value available? Can I immediately prepare R0 and R1 and call the RECVMSG routine? Does the receive routine block until the send command has completed? Or do I need to faff around changing the workspace and resetting/setting the CRU bit to give time for the send command to complete?

 

-- If I don't 'receive' the return value (for any open/close/write command), does that cause any problem with the next command?

 

(2) The write command. An HTTP GET request comprises multiple lines, each terminated with a >0D >0A. Can these be sent as separate, multiple write commands, followed by a read command for the response? Or does the GET request have to be a single write command?

 

(3) The read command. After writing an HTTP GET request, do I need to send a read command and check the length returned in GPLWS R0, and loop (need to repeatedly send the read command, or just call RECVMSG?) until this is greater than zero?

 

Thanks!

Edited September 30, 2018 by Stuart

[+9640News]

Stuart, The open connection is immediately ready for the RECVMSG to know if you got a connection.

 

Beery

[Stuart]

Stuart, The open connection is immediately ready for the RECVMSG to know if you got a connection.

 

Beery

 

Thanks Beery. How did you go about checking if there was data ready to be read?

[+9640News]

 

Thanks Beery. How did you go about checking if there was data ready to be read?

 

It is not so much as checking to see if data is ready to be read, but rather, checking to see if something is present. That is where it is a bit different from serial communications. With serial, you would know something is there before you read it. With the TIPI, you read it and see if you got anything back. Downside with the TIPI in this respect is the character receive throughput can be slower than the RS232. The upside is, you do not have to worry about ever dropping a character because you were running a longer subroutine doing other processing elsewhere.

 

I check for a single byte and process it if one is there. If I am in an XMODEM routine, I check the length returned. It is either >00 or >01. If it is >00, I continue requesting a read and wait until it is a >01. If I am at a menu, I read the TIPI and I read the keyboard waiting for someone to make the next move.

 

The nice thing about the TIPI and the PI, is it buffers the string. So, if you were to say ask for a 1 MB text file with no pausing, you are going to get the full file scrolled to you that you have to process from the TIPI/PI buffer. There may be a way to interrupt that with some Telnet IAC codes, but I am not sure.

 

Beery

[+jedimatt42]

All communication with the TiSocket service is sendmsg, recvmsg, pairs, and recvmsg will block until the PI sends a msg. So, yes you can jump right into the response handling.

 

The backing service code is super simple: https://github.com/jedimatt42/tipi/blob/master/services/TiSocket.py

 

Requesting a read data, as will send whatever data is queued up via the lower level socket buffer. So as Beery said, poll for data, and it is ok if the response is an empty buffer.

 

Speaking of buffers, yes, there is considerable overhead to be using this API for single byte read. Use a fetch buffer on the 4A side to grab many bytes in one call... then if your fetch buffer isn't empty, loop over and process your single bytes from that fetch buffer.

 

-M@

[Stuart]

 

Requesting a read data, as will send whatever data is queued up via the lower level socket buffer. So as Beery said, poll for data, and it is ok if the response is an empty buffer.

 

 

Thanks Matt. Polling for read data - do I need to:

 

send read command

do receive message and check length

send read command

do receive message and check length

send read command

do receive message and check length

etc.

 

or

 

send read command

do receive message and check length

do receive message and check length

do receive message and check length

do receive message and check length

etc.

 

When receiving a web page that could be several kilobytes, is there any guarantee that I'll receive it all through the one read? Or once I've got data, do I need to do multiple reads (adding any further data to my buffer) until a read returns a length of zero?

[+arcadeshopper]

 

Thanks Matt. Polling for read data - do I need to:

 

send read command

do receive message and check length

send read command

do receive message and check length

send read command

do receive message and check length

etc.

 

or

 

send read command

do receive message and check length

do receive message and check length

do receive message and check length

do receive message and check length

etc.

 

When receiving a web page that could be several kilobytes, is there any guarantee that I'll receive it all through the one read? Or once I've got data, do I need to do multiple reads (adding any further data to my buffer) until a read returns a length of zero?

 

pretty sure its until it returns a length of zero

 

I wrote this program in basic

 

1 !T80XB high memory version by Harry Wilhelm

2 CALL INIT :: CALL LOAD(8192,255,178):: CALL LINK("T80ON"):: RUN 3

3 !@P+

4 INPUT "WEBPAGE HTTP://":F$

5 CALL LINK("T80")

6 DIM A$(255)

9 O$="PI.http://"&F$

10 OPEN #1:O$,INPUT ,VARIABLE 128

20 ON ERROR 50

21 D=D+1

30 INPUT #1:A$(D)

40 GOTO 20

50 FOR A=1 TO D

60 CALL LINK("PRINT",A,1,A$(A))

70 NEXT A

1000 INPUT "done":B$

 

its got the 80column xb thing from Harry which is where the call link came from to display.. anyway you can see I'm just pulling data until it errors

[Stuart]

I've now got a working example of using the TIPI socket interface to download a web page (and big thanks to Omega for testing many iterations of the code on his TIPI setup). I have a query though over opening a socket to an invalid host ...

 

I've (temporarily) set up the TIPI calls so the 'open socket' command is to an invalid host, and the 'write socket' command is an HTTP GET request to a valid host and a valid web page. I was expecting the open socket command to fail, but it succeeds, and the response to the GET request is a valid page with a 'refresh' link to a page at http://webhelper/centurylink.com. So I'm wondering if:

 

(1) Whether the open socket command always reports as succeeding (that is, the command itself was processed successfully even though the specified host was invalid).

or

(2) Omega's ISP is intercepting the open socket request, reporting it as OK, and redirecting further requests to this webhelper page.

 

Any ideas?

[+jedimatt42]

That would be a redirect by the ISP DNS server in support of advertising by the ISP... shame on them!

 

-M@

[Stuart]

Thanks Matt.

 

My code is here (http://www.stuartconner.me.uk/ti/ti.htm#tipi_network_socket_interface), should anyone find it useful in the future. Now to incorporate it into my TI Browser ...

[+9640News]

Thanks Matt.

 

My code is here (http://www.stuartconner.me.uk/ti/ti.htm#tipi_network_socket_interface), should anyone find it useful in the future. Now to incorporate it into my TI Browser ...

 

Stuart,

 

I started to look at some FTP specs, and started to wonder if your Browser could TI browser may be able to browse ftp.whtech.com and possibly do a "file save" so uses could transfer files?

 

That would be a heck of an accomplishment if your code could pull that off. The Mass Transfer Telnet client I uploaded a week or so ago has the source code for the XMODEM routine in it. I'm not saying use the XMODEM protocol, however, it does have code for calling the specific DSR routines for file saving.

 

Just a thought.

 

Beery

[Stuart]

I did think about including some sort of file download functionality, but the problem is that each new feature reduces the size of web page that can be downloaded and displayed. So the only practical way to do it would be some sort of code overlay facility, where the browser loads some overlay code to handle file downloads, and that then reloads the browser code when the file download is complete. And that gets very time consuming to do when trying to support disk- and cartridge-based version of the browser. One day maybe ...

[+9640News]

Stuart,

 

I have no idea what is involved with your code management. Mentally, I was just picturing the most basic of "browser" functions that would display a page/directory, and then a point/click/etc to mark a file for transfer. I would have thought the DSR code for file saving would have been 2 to 4 K. I can see where buffering filename/sizes, especially quite a few if there were many on a ftp web page could be extensive consuming a lot of memory. Perhaps one could buffer the page on a TIPI.TEMP. directory for the scrolling up and down.

Anyways, just thinking out loud not knowing what all is involved.

 

Web browsing is definitely a PLUS!

Beery

[Omega-TI]

Just peeking in to see if anything new has been developing...