Jump to content
IGNORED

Programming with the TIPI


9640News

Recommended Posts

The socket mechanism for TIPI is a socket, NOT a TELNET session. You need to grab a specification for TELNET and implement all of it in the TERM program, since the things you are connecting to expect to be talking to a TELNET client.

 

Process the telnet layer before the terminal emulation layer.

 

I don't know specifically what to do about the 0xFF. Maybe the telnet protocol has a command to enter 8bit safe mode? I don't think so though. I would go read the RFC for TELNET.

 

-M@

Link to comment
Share on other sites

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

 

At minimum two pieces.

 

First, you should request (and respond to) 8-bit mode. Heatwave sends the IAC request/command at login to help with some of the terminal implementations. I believe I also send a "WILL" response to the terminal, though I am not 100% sure it was needed.

 

To deal with the IAC byte in the file transfer stream, when you receive two successive 0xFF bytes, you need to strip one of them. When you send 0xFF, you need to send a second one immediately. These extra bytes do NOT count as part of your CRC calculation, so you'll need to add or remove them before calling the CRC routine.

 

Remember, you need to interpret and manage the telnet protocol yourself. (The UDS-10, for example, does the heavy lifting for you to present a raw stream. If you look at the UDS-10 raw packets, you would see the "double" 0xFF bytes).

 

(One caution: my implementation of both pieces could be 'colored' by the serial devices in the mix. So be sure to review the specs and results yourself)

Edited by InsaneMultitasker
Link to comment
Share on other sites

OK, I believe with that information, I resolved the downloading issue as I just transferred a file without any errors being reported. Unfortunately, I must have commented out something somewhere that did not allow it to save. Need to check the code to see if somewhere in the process of trying to resolve this, I commented something out.

 

Beery

  • Like 2
Link to comment
Share on other sites

I figured out the issue with saving. File saves fine to a HRD at DSK6. Will not save if TIPICFG is set in TI mode, must be in Myarc mode as I have a HFDC in the system.

 

Need to see the code for TIPICFG and will browse Github to see if I can figure out how to toggle (if possible) modes without returning to the title screen.

Beery

Link to comment
Share on other sites

I would recommend you add an option to turn your IAC escaping code on and off as you may encounter systems that use a completely transparent stream. In fact, Heatwave may be set up like that right now. I'd have to check the settings.

 

OK, thanks Tim for the suggestion.

 

Beery

Link to comment
Share on other sites

Matt,

 

I found the TIPICFG code where you change the TI/Myarc mode with a SBO/SBZ 3 at the TIPI CRU.

 

Does this take immediate effect? Or, does one need to go back to the title screen and let the TIPI powerup routine do anything?

 

Next question is this. I have a Myarc HFDC at >1100 and the TIPI at CRU >1800.

 

The Myarc HFDC has floppy drives DSK1 and DSK2, and a HFDC subdirectory DSK1. I am trying to understand why a file is not being saved to Myarc Floppy DSk1 when it is at a lower CRU than the TIPI, but when the Myarc mode on TIPI is enabled, it saves to Myarc Floppy DSK1. Help me understand where my ignorance is.

 

Thanks, much appreciated.

Beery

 

Link to comment
Share on other sites

The answer to the first question, is yes, it takes I'm immediate effect. What that does is bank switch the DSR rom.

 

The second question belongs in the support thread. But.. I think your stated assumptions are correct for level 3 io using a standard DSRLNK routine, and 100% program dependent for level 2 io. I don't know what program you are using, how it was written or what else a HFDC asserts.

 

I don't know how the HFDC works. All my 'myarc' mode does is switch to different device names and different level 2 routine names. Those level 2 routines do not imple ment the CPU RAM buffer feature.

 

-M@

Link to comment
Share on other sites

I am trying to get a handle on something where the information posted on the Platoterm project was not making sense with some experiences I am having.

 

OK, my BBS is a Telnet BBS. At what level the socket level is handled, I do not know. With MyTerm, I can transfer the file that had the >FF byte without doing anything special in the coding. It uses a WiModem232.

 

Now, go to Mass Transfer using TIPI, transfer the same file and now I have to deal with the IAC character. Is the WiModem232 just passing the raw data stream through and not doing anything? However with the TIPI, it is not passing the raw stream through?

 

I am trying to understand why they would be different, or need to be different. Is there a way to send a command to the TIPI to get the same behavior as the WiModem232? I am asking as I was trying to make it simple for the user to not have to worry which BBS's they have to deal with an IAC command, etc.

 

Feedback to help my understanding is appreciated.

 

Beery

 

Link to comment
Share on other sites

Wimodem232 has a command to enable/disable the IAC escaping. I know Jim did a lot of testing in that area. To provide a raw stream that looks like a full 8-bit serial connection, the wimodem, UDS, and other devices have to account for Telnet protocol. The wimodem232 is equivalent to Mass Transfer in this regard - both need to deal with the protocol.

 

Toggle the Telnet command on the Wimodem232 and you'll see or not see the IAC byte.

Link to comment
Share on other sites

Got a question. In some topic area unless I was dreaming, someone indicated the TIPI should be able to save files to the RPI during the Xmodem transfer. That comment surprised me a bit because I thought the TIPI DSR did not support it.

 

So, last night, I attempted a test.

 

With a Myarc HFDC in the system, TI mode on, I have a directory specified in the TIPI Cfg as DSK2, the Xmodem transfer routine appears to be saving the file, however upon the completion of the file transfer, nothing is there.

 

I am trying to understand if the DSR for the file save routine is just not passing an error back or if there is something else going on. Right now, my file saves are to DSK2 during the test and I have the CFG option for DSK1 empty. Editor Assembler loads the program fine from HFDC DSK1.

 

Beery

Link to comment
Share on other sites

The TIPI DSR supports the level 2 direct write file subprogram that an Xmodem, or file copy routine would use.

 

This talk of 'direct to RPi' is confusing and ambiguous. People say a lot of things on this forum that are 'hopeful tense' using present or past-tense Grammer.

 

If I understand your experiment correctly, and we assume the Xmodem code is on the 4A trying to direct write a file to DSK2, then there is probably a bug in my DSR.

 

If the Xmodem code is using sector io instead of direct write, then Xmodem is failing to notice that there is no routine in the basic/level 2 subroutine list for the device.

 

-M@

Link to comment
Share on other sites

I will admit I am very limited in assembly specifics on the TI-99/4A side. Give me a Geneve and MDOS mode, I am good. The specifics for dealing with PABS, GPL workspaces, and all the other nuances is not my forte on the 4A side of things as I never dug into those details. That is why I did very little programming on the 4A.

 

I will do some digging into the Xmodem code and see if I can determine if it is using sector io or direct write as well as how it may be handling any failure codes. It may be the original author never anticipated a device not having the routine and never tested for an error response.

 

Beery

Link to comment
Share on other sites

Beery,

 

Spoiler alert!

 

 

 

What you should uncover is that the xmodem routines use level 2 IO (direct input/output routines >15 and >14) to access the files. However, you will also find level 3 IO for the non-TI files saves as Display/Fixed 128. If I recall correctly, there are two or three subroutines that contain the majority of the IO code, but the error trapping is branched into at various places.

 

 

 

Sounds like you are having some fun :)

Link to comment
Share on other sites

Well, I solved the "fun". Somewhere along the line, I deleted the directory pointers to DSK1, DSK2, and DSK3 in the TIPICFG program setup. So, there was no path configured. I thought for sure I only deleted DSK1, but I guess I wiped out DSK2 and DSK3.

 

However, whether it is a bug or not, I think that did expose an issue. If the DSK1, DSK2, and DSK3 pointers are empty, a file will still look like it is being saved. I checked the TIPI root directory just to double check, and it was not there.

 

So, is it a bug? Matt?

 

After I entered the DSK1, DSK2, and DSK3 paths as DSK1, DSK2, and DSK3, I was able to save files.

 

I do need to explore the multi-file transfer option of MXT. Is that implemented on Heatwave or Fusion?

 

Beery

Link to comment
Share on other sites

I do need to explore the multi-file transfer option of MXT. Is that implemented on Heatwave or Fusion?

Heatwave, yes. Set the (P)rotocol to either Mass Xfer or Mass Xfer Ymodem (coresponds to MXT Xmodem and MXT Ymodem). Select up to 25 files. Edit: I haven't viewed the 40 column protocol menu in a while, it may reference multiple or MXT for the protocol.

Edited by InsaneMultitasker
Link to comment
Share on other sites

Well, I solved the "fun". Somewhere along the line, I deleted the directory pointers to DSK1, DSK2, and DSK3 in the TIPICFG program setup. So, there was no path configured. I thought for sure I only deleted DSK1, but I guess I wiped out DSK2 and DSK3.

 

However, whether it is a bug or not, I think that did expose an issue. If the DSK1, DSK2, and DSK3 pointers are empty, a file will still look like it is being saved. I checked the TIPI root directory just to double check, and it was not there.

 

So, is it a bug? Matt?

 

After I entered the DSK1, DSK2, and DSK3 paths as DSK1, DSK2, and DSK3, I was able to save files.

 

I do need to explore the multi-file transfer option of MXT. Is that implemented on Heatwave or Fusion?

 

Beery

 

 

'It' needs a ton of clarification. I don't know anything about MXT...

 

Level 3 IO routines for mapped drives will try tipi if the crubase is earlier than the floppy controller. If there is no mapping for that device name, then 0 is returned and flow goes back to the 'keep searching part of DSRLNK', meaning bad device name. Great care was taken so that the DSRLNK state was not destroyed, so it can cascade on to the next piece of hardware that implements that device name.

 

Level 2 IO routines, follow the same for tipi mapped drives. I doubt there is any precedence for that. But this was done under the naive hope that if not mapped, it would just fall back to your real floppy.

 

So, I assume MXT does Level 2 IO. How does it handle errors?

 

-M@

Link to comment
Share on other sites

 

 

'It' needs a ton of clarification. I don't know anything about MXT...

 

Level 3 IO routines for mapped drives will try tipi if the crubase is earlier than the floppy controller. If there is no mapping for that device name, then 0 is returned and flow goes back to the 'keep searching part of DSRLNK', meaning bad device name. Great care was taken so that the DSRLNK state was not destroyed, so it can cascade on to the next piece of hardware that implements that device name.

 

Level 2 IO routines, follow the same for tipi mapped drives. I doubt there is any precedence for that. But this was done under the naive hope that if not mapped, it would just fall back to your real floppy.

 

So, I assume MXT does Level 2 IO. How does it handle errors?

 

-M@

 

Matt, at present, I do not know to what extent error checking is done as I do not have the source code to MXT in front of me here at work. Tim wrote this note up in an earlier post:

 

What you should uncover is that the xmodem routines use level 2 IO (direct input/output routines >15 and >14) to access the files. However, you will also find level 3 IO for the non-TI files saves as Display/Fixed 128. If I recall correctly, there are two or three subroutines that contain the majority of the IO code, but the error trapping is branched into at various places.

 

As the file to be transferred was indeed a TI file, it should have been using the level 2 IO routines. I do not know what to expect from those routines if there is no mapping present in the TIPI ????

 

I know you are extremely busy and I posted MXT and the source code up as an archive in the TIPI Programs topic area this past weekend if you want to look at the program sometime when you are free.

 

Myself, I am not going to do anything with the DSRLNK code as I know there is too much I do not know that I could screw things up. I was able to make the necessary changes to switch MXT from serial based to Telnet based, but much more than that is pushing it for me on the 4A side.

 

Beery

Link to comment
Share on other sites

  • 1 year later...

OK, got a question for a couple of different potential projects in mind.

 

If I am using Level 2 code, i.e., code very similar to XMODEM transfer code, can I retrieve records using this manner say for example from ftp.whtech.com using the URL device name?

 

Where I am headed with this, if it is possible, to build a "library" of filenames with full paths, that a user could run a program to search the Whtech site for a particular string and then retrieve the file and save on the TIPI.

 

I should also ask if that if I can access the file with level 2 code, is there a filename length maximum as some of the paths and filenames are very long.

 

Beery

Edited by BeeryMiller
Link to comment
Share on other sites

56 minutes ago, BeeryMiller said:

OK, got a question for a couple of different potential projects in mind.

 

If I am using Level 2 code, i.e., code very similar to XMODEM transfer code, can I retrieve records using this manner say for example from ftp.whtech.com using the URL device name?

 

Where I am headed with this, if it is possible, to build a "library" of filenames with full paths, that a user could run a program to search the Whtech site for a particular string and then retrieve the file and save on the TIPI.

 

I should also ask if that if I can access the file with level 2 code, is there a filename length maximum as some of the paths and filenames are very long.

 

Beery

You should go read all the great documentation on Fred Kaal's website.  That is to say, I don't really understand what you are asking... TIPI level 2 IO adheres to the rules of a TI floppy controller + directory support.

 

The PI.HTTP device is a stream input device like RS232... you can read records from it. The PI uses a command to fetch the resource at the URL provided, and then splits the data up into records and offers them for the 4A to READ from with level 3 IO (open, read, status, close, load). 

 

If you are trying to skip sockets and build a web downloader... I don't understand all the library whatever stuff.. but yes, if you have a URL to a TIFILES formatted file, and you open the PI.HTTP url to it as DIS/FIX 128, you will get the TIFILES/XMODEM header in the first 128 byte record, and then subsequent pairs of records make up the logical sectors of the file. My FTP program doesn't use PI.HTTP, but it does the same necessary second phase work of detecting the TIFILES header, and then using LVL2 IO to write the file. 

 

LVL3 IO on a TI is limited to 256 byte paths. As recently outlined in some other thread, URI1-3 devices exist so that you can extend that limit by setting the URI1 or whichever device alias first, and then accessing the stream with the shortcut. I regret giving URI1-3 a 3 letter prefix, cause people think that means 'disk' 

 

Using LVL3 IO, open, write, close, you can set the alias, and then you can use it to fetch a long path... For example:

 

OPEN "PI.CONFIG", APPEND, DISPLAY, VARIABLE 254

WRITE "PI.CONFIG" "URI1=HTTP://my-file.repository.org/somewhere/deep/down/in/the/tree/4AFILES/category1/A"

CLOSE "PI.CONFIG"

OPEN "URI1.but/wait/there/is/more/some_really_long_named_file.arc" INPUT, DISPLAY, FIXED 128

...

 

Now you have opened the url: HTTP://my-file.repository.org/somewhere/deep/down/in/the/tree/4AFILES/category1/A/but/wait/there/is/more/some_really_long_named_file.arc

 

Of course saving that file with that really long name will require you to come up with a 10 character short name. If it is an XMODEM/TIFILES file, there is a name inside the header. 

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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