Jump to content
Stuart

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

Recommended Posts

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 by Stuart

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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 by Tursi

Share this post


Link to post
Share on other sites

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 by PeteE
  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

 

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 by Stuart

Share this post


Link to post
Share on other sites

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 by BeeryMiller
  • Like 2

Share this post


Link to post
Share on other sites

 

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 by Stuart

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

 

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

  • Like 1

Share this post


Link to post
Share on other sites

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@

Share this post


Link to post
Share on other sites

 

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?

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 ...

Share this post


Link to post
Share on other sites

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

  • Like 1

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.

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...