Jump to content

Photo

Programming with the TIPI


43 replies to this topic

#26 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,814 posts
  • Location:Beaverton, OR

Posted Mon Sep 24, 2018 2:08 PM

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@

#27 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,814 posts
  • Location:Beaverton, OR

Posted Mon Sep 24, 2018 2:24 PM

When I wrote my telnet for TIPI I spent very little time on this aspect.

But it looks like I did something, the code handling this is here:

https://github.com/j...net/main.c#L177

-M@

#28 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,234 posts

Posted Mon Sep 24, 2018 2:44 PM

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.a...et/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, Mon Sep 24, 2018 2:55 PM.


#29 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

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

Posted Mon Sep 24, 2018 4:50 PM

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



#30 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

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

Posted Mon Sep 24, 2018 5:57 PM

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



#31 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,234 posts

Posted Mon Sep 24, 2018 6:59 PM

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.



#32 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

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

Posted Tue Sep 25, 2018 5:17 AM

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



#33 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

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

Posted Tue Sep 25, 2018 7:48 AM

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

 



#34 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,814 posts
  • Location:Beaverton, OR

Posted Tue Sep 25, 2018 8:47 AM

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@

#35 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

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

Posted Wed Sep 26, 2018 5:25 AM

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

 



#36 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,234 posts

Posted Wed Sep 26, 2018 11:00 AM

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. 



#37 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

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

Posted Fri Sep 28, 2018 5:27 AM

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



#38 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,814 posts
  • Location:Beaverton, OR

Posted Fri Sep 28, 2018 8:46 AM

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@

#39 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

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

Posted Fri Sep 28, 2018 9:50 AM

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



#40 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,234 posts

Posted Fri Sep 28, 2018 4:58 PM

Beery,

 

Spoiler alert! 

 

Spoiler

 

Sounds like you are having some fun :)



#41 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

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

Posted Fri Sep 28, 2018 7:43 PM

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



#42 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,234 posts

Posted Fri Sep 28, 2018 8:31 PM

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, Fri Sep 28, 2018 8:36 PM.


#43 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,814 posts
  • Location:Beaverton, OR

Posted Tue Oct 2, 2018 8:04 AM

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@



#44 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

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

Posted Tue Oct 2, 2018 9:13 AM

 

 

'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






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users