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

[Stuart]

I've got as far as copying and cleaning up a copy of the browser code ready to add in the TIPI stuff, but unfortunately 'life' is getting in the way of any further progress as the moment.

[+9640News]

With all the different internet protocols out there, is there any particular protocol that uses more than two sockets for a connection?

 

Telnet uses one, and if I recall, FTP can establish two connections if you start getting files. Is there anything else the TI/Geneve is likely to use that would use any additional sockets for communications?

 

When I started thinking about this, it dawned on me that that it is technically feasible a program could establish two telnet sessions so that one could be connected to two BBS's simultaneously. I would hate to try and program ANSI for two, but ASCII mode for both would be easier. Again, I see no reason to be connected to two BBS's at the same time so I am not inclined to do a proof of concept, but just wanted to mention it in passing. Actually, the core pieces of GEME are already there so something like this could be done with "windowed" terminals in ASCII mode.

 

Anyways, my purpose for asking is to understand what may be needed to build a XOP library for the TIPI.

Beery

[+mizapf]

All FTP servers should support the PASV command, which routes data over the command connection, that is, it only requires a single connection.

[Stuart]

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

 

OK, so back to this question again. I've got an E/A object file (uncompressed) on my PC from Asm994a and I need to convert it to TIFILES format so it can be loaded through a TIPI, and it's now too big to load in the E/A editor in Classic99 and save back out. How else can I convert it? I expect Ti99Dir will do it but can someone confirm exactly which menu option and dialog options I need please?

 

Thanks all!

[Tursi]

TI99Dir drops the last line for me (v6.3a). There are other disk managers out there... xdt99's command line tools work well if you like Python.

 

Since it's a normal file, you could do it in Classic99 too, using XB:

 

 

10 INPUT "INPUT FILENAME: ":A$
20 INPUT "OUTPUT FILENAME: ":B$
30 OPEN #1:A$,INPUT,DISPLAY,FIXED 80
40 OPEN #2:B$,OUTPUT,DISPLAY,FIXED 80
50 IF EOF(1) THEN 100
60 LINPUT #1:X$
70 PRINT #2:X$
80 GOTO 50
100 CLOSE #1
110 CLOSE #2

 

Of course, that's the slowest way.

[+mizapf]

And if you tried TIImageTool? Do you have your object file on a disk image? Drag and drop it into a folder on your PC.

[+arcadeshopper]

TI99Dir drops the last line for me (v6.3a). There are other disk managers out there... xdt99's command line tools work well if you like Python.

 

Since it's a normal file, you could do it in Classic99 too, using XB:

10 INPUT "INPUT FILENAME: ":A$
20 INPUT "OUTPUT FILENAME: ":B$
30 OPEN #1:A$,INPUT,DISPLAY,FIXED 80
40 OPEN #2:B$,OUTPUT,DISPLAY,FIXED 80
50 IF EOF(1) THEN 100
60 LINPUT #1:X$
70 PRINT #2:X$
80 GOTO 50
100 CLOSE #1
110 CLOSE #2

Of course, that's the slowest way.

 

could always compile this with xb256

 

Greg

[Stuart]

And if you tried TIImageTool? Do you have your object file on a disk image? Drag and drop it into a folder on your PC.

 

Hi Michael,

 

I downloaded the TIImageTool this evening and had a play. Lovely user interface!

 

So I created a new disk, then Edit > Import Files and imported the Asm994a object file as type Dis/Fix 80. Viewed the file in the tool and it all looks OK. Right-clicked the file and selected Save As TIFILES, and saved the file. But if I try to load the file in Classic99 E/A option 3 I get an illegal tag error (just testing the file in Classic99 as if it works on there it seems to work on Omega's TIPI). Any idea of the problem? I've attached a zip file containing the disk image and exported TIFILES file.

TIFILES.zip

[HOME AUTOMATION]

When you posted yesterday I tried using a hex editor to transplant an asm994a .obj files' content into a working TIPI object file in between the header and trailer. I got an illegal tag error as well... by then Tursi had posted, so I gave up. I have run into this before, I'm not sure how it ended... but your files' bigger.

[+arcadeshopper]

i was goofing around and compiled it..ea5 load file CONVERT in the zip file with tifiles header

CONVERT.zip

[Tursi]

 

Hi Michael,

 

I downloaded the TIImageTool this evening and had a play. Lovely user interface!

 

So I created a new disk, then Edit > Import Files and imported the Asm994a object file as type Dis/Fix 80. Viewed the file in the tool and it all looks OK. Right-clicked the file and selected Save As TIFILES, and saved the file. But if I try to load the file in Classic99 E/A option 3 I get an illegal tag error (just testing the file in Classic99 as if it works on there it seems to work on Omega's TIPI). Any idea of the problem? I've attached a zip file containing the disk image and exported TIFILES file.

 

Just for troubleshooting's sake, the file on the DSK image is not properly formatted for 80 byte records. The first line is right, but then there are two additional bytes that should not be there - they look like the Windows line ending characters (0x0D, 0x0A). So whatever copied the file to the disk image didn't strip those.

 

The TIFILES file looks okay (didn't check the header) until the very last line of the file. While this line is correct, it's followed by 80 0x00 bytes, which is probably the invalid tag it's reading. Not sure if Classic99 /should/ be stripping that part out (since it technically should be past the end of file, it depends on whether the header correctly marks the end of the last sector), but it shouldn't be there in a TIFILES file. It's not simple padding, since it doesn't bring the filesize to a multiple of 128 bytes (256 bytes + 128 bytes for the TIFILES header).

[+mizapf]

Interestingly, and most likely related to that, TIMT fails to disassemble the file, complaining about a missing end tag. I'll have to check the log output to find out more.

[+mizapf]

OK, this works: Export the file as binary, change DOS/Win line endings to Unix line endings (dos2unix), then import the binary file again as DIS/FIX 80. I attached the new image here. Seems as if I have to fix the import component of TIMT.

 

(Edit: "Works" in the sense of: TIMT stops complaining about missing end tags and disassembles the object code, so it seems to be properly formatted again.)

tipi.dsk

Edited November 20, 2018 by mizapf

[+mizapf]

Stuart,

 

did you have some progress from here on? More information needed?

[Stuart]

Stuart,

 

did you have some progress from here on? More information needed?

 

I was rather hoping you were going to fix the import bug in TIMT as I'll have a succession of file images to import. Is that a possibility? (No great rush, looks like there might be a PC-->TIPI transfer bug that needs sorting out as well.)

[+arcadeshopper]

 

I was rather hoping you were going to fix the import bug in TIMT as I'll have a succession of file images to import. Is that a possibility? (No great rush, looks like there might be a PC-->TIPI transfer bug that needs sorting out as well.)

Please elaborate the PC to TIPI is it a file copy to share or the web interface?

 

Sent from my LG-H872 using Tapatalk

[Stuart]

Please elaborate the PC to TIPI is it a file copy to share or the web interface?

 

Sent from my LG-H872 using Tapatalk

 

It's a problem copying a particular TIFILES format EA3 file from PC to TIPI - there's some sort of corruption going on. Omega will raise it direct with Matt.

[+mizapf]

Ah, OK, I did not know that there is more. I cannot do it right now, but maybe during the next two weeks.

 

I just had a quick look. How did you create the ZTIFILES.OBJ file? It already contains the invalid 0d0a bytes, which cause the problem when importing.

Edited November 22, 2018 by mizapf

[Stuart]

Hi Michael,

 

I've attached a (slightly later version of) the object file I tried importing onto the disk. This was generated by Asm994a running under Windows, and it has >0D >0A bytes at the end of every 80-byte record.

zTIPI.obj

[Tursi]

Ah, OK, I did not know that there is more. I cannot do it right now, but maybe during the next two weeks.

 

I just had a quick look. How did you create the ZTIFILES.OBJ file? It already contains the invalid 0d0a bytes, which cause the problem when importing.

 

Asm994A outputs Windows-style text files for object files. 0D0A is the line ending for Windows. If you're importing text files (Windows OR Linux) you probably want to consider line ending translation - the LF on Linux would also be incorrect. The only PC-side tool I've seen that outputs native files without line endings is the XAS99 assembler.

 

In Classic99 I check the native file for line endings by reading the equivalent of a few records, and looking to see if there are any line ending characters present. But since your tool is user-driven, you can probably just explicitly ask.

Edited November 23, 2018 by Tursi

[+mizapf]

It's not a problem that there are line endings (whether crlf or lf), but rather that they get into the TIFILES file. I guess that Asm994A outputs plain text files. I know a similar situation when I import text files as DIS/VAR 80.

[+Lee Stewart]

Hi Michael,

 

I've attached a (slightly later version of) the object file I tried importing onto the disk. This was generated by Asm994a running under Windows, and it has >0D >0A bytes at the end of every 80-byte record.

 

 

Asm994A outputs Windows-style text files for object files. 0D0A is the line ending for Windows. If you're importing text files (Windows OR Linux) you probably want to consider line ending translation - the LF on Linux would also be incorrect. The only PC-side tool I've seen that outputs native files without line endings is the XAS99 assembler.

 

In Classic99 I check the native file for line endings by reading the equivalent of a few records, and looking to see if there are any line ending characters present. But since your tool is user-driven, you can probably just explicitly ask.

 

Asm994A can directly output TI Files format files just fine, but you must check the box labeled “Copy HEX Object File To TI Disk”. The target DSK or TIDISK image file must exist prior to that operation, however. If you need a free-standing file, you can export it from the image with TI Image Tool or TI99Dir.

 

...lee

[+mizapf]

Stuart, the "import fixed from text" feature is seriously broken in TIMT, I am afraid. I never needed it until now, so that is the reason why I never noticed it. As it seems, I'll have to fetch a sheet of paper.

[Stuart]

Stuart, the "import fixed from text" feature is seriously broken in TIMT, I am afraid. I never needed it until now, so that is the reason why I never noticed it. As it seems, I'll have to fetch a sheet of paper.

 

Hi Michael. No worries ... I've just tried out the suggestion from Lee above (thanks Lee!) of using Asm994a to write directly to a disk image, then I've used TIMT to extract the TIFILES file image from the disk, and that works fine. So I'm all good to go again!

[+9640News]

I've got a question regarding Telnet's use of the IAC control bytes.

 

Is there specific bytes I can send to the other server that would instruct it to not send IAC bytes in the data stream?

 

This is not a problem for general Telnet BBS access displays. Where the problem becomes is in file transfers where I have to filter. The 9640 News BBS (9640news.ddns.net:9640) is Windows software that has IAC bytes in the data stream I have to manage. FusionBBS and likely Heatwave, do not have the IAC bytes in the data stream that need to be managed.

 

Beery