Jump to content
jedimatt42

TIPI - TI-99/4A to Raspberry PI interface development

Recommended Posts

5 hours ago, InsaneMultitasker said:

I had planned to do some more DSR testing tonight but ran into a head-scratcher.  I was copying files from my ramdisk to TIPI via Fred's DM2K, something that has been working just fine however, as soon as DM2K hit a certain file, the system locked with the TIPI PEB card illuminated.  I finally realized that there was a subdirectory on the TIPI that was the same name as the "bad" file I was trying to copy.  The condition cleared as soon as I powered off/on the TI ( the TIPI PEB light stayed on when I turned off the console; the card reset when the TI was turned back on).   I renamed the ramdisk file and was able to successfully copy it.   I tried to save an XB program using the same name, resulting in an IO error 66.

 

I'm sure the python is not checking for that directory name collision, and crashing... I will fix it to return a file name error gracefully.  Good to hear SAVE handles it more gracefullly than level 2 DIRECT-BLOCK-WRITE... 

 

---

 

The reset functionality is what you'll come to expect. During the card's powerup 9900 code the 4A signals the a watchdog service on the PI that kills the main TIPI python service. The OS on the PI then restarts that service, and it is ready for action again!

 

[email protected] 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 2/1/2020 at 8:47 AM, jedimatt42 said:

 

I'm sure the python is not checking for that directory name collision, and crashing... I will fix it to return a file name error gracefully.  Good to hear SAVE handles it more gracefullly than level 2 DIRECT-BLOCK-WRITE... 

 

Thank you Matt. 

 

I have been experimenting with cataloging the TIPI using level 3 routines via both Extended BASIC and assembly. 

 

I can catalog "DSK0." and as expected, the root and sublevels work fine.   However, many programs don't accept device 0 so I tried to map one of the other DSKx devices.  The tipi wiki isn't clear (to me) as to what is expected to properly map a device so I had a bit of trial and error.   Here are the results of my attempts. I used CALL TIPI to map and write the configuration each time.

 

1. "TIPI.folder." -- trailing period:  failed, io error

2. "TIPI.folder" - no trailing period:  failed, io error

3. "folder." - folder with period:   no error but no files. 

4. "folder" - folder without trailing period: successful, files and directories displayed as expected

 

I also tried to map DSKx. to the TIPI root but could not figure out how to do so. 

5. "TIPI." - failed, IO error

6. "TIPI" - failed, IO error

 

 

  • Like 1

Share this post


Link to post
Share on other sites
Thank you Matt. 

 

I have been experimenting with cataloging the TIPI using level 3 routines via both Extended BASIC and assembly. 

 

I can catalog "DSK0." and as expected, the root and sublevels work fine.   However, many programs don't accept device 0 so I tried to map one of the other DSKx devices.  The tipi wiki isn't clear (to me) as to what is expected to properly map a device so I had a bit of trial and error.   Here are the results of my attempts. I used CALL TIPI to map and write the configuration each time.

 

1. "TIPI.folder." -- trailing period:  failed, io error

2. "TIPI.folder" - no trailing period:  failed, io error

3. "folder." - folder with period:   no error but no files. 

4. "folder" - folder without trailing period: successful, files and directories displayed as expected

 

I also tried to map DSKx. to the TIPI root but could not figure out how to do so. 

5. "TIPI." - failed, IO error

6. "TIPI" - failed, IO error

 

 

TIPI. is implied

 

So the map of directory called games you would just type in games if you wanted games.something you would type in games.something.. this is case sensitive

 

This is documented in the wiki here

 

https://github.com/jedimatt42/tipi/wiki/PI.CONFIG

 

Sent from my LM-G820 using Tapatalk

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
19 minutes ago, arcadeshopper said:

TIPI. is implied

 

So the map of directory called games you would just type in games if you wanted games.something you would type in games.something.. this is case sensitive

 

This is documented in the wiki here

 

https://github.com/jedimatt42/tipi/wiki/PI.CONFIG

 

Thanks Greg. I was looking at the "devices" section https://github.com/jedimatt42/tipi/wiki/Devices  and the TIPICFG section.    I would never have thought to look in PI.CONFIG for the mappings. 

 

I mapped DSK3 to a single period as described in the PI.CONFIG wiki you linked and that that just returns an empty directory instead of the base TIPI directory.   Mapping to folders works just fine.

 

(EDIT: I just now realized that I posted this problem in the development area not the support area -- I can repost there if desired, or the answer can be posted there. Long day.)

 

image.thumb.png.2c439ab9751875869189aa952eca3447.png

Share this post


Link to post
Share on other sites
Thanks Greg. I was looking at the "devices" section https://github.com/jedimatt42/tipi/wiki/Devices  and the TIPICFG section.    I would never have thought to look in PI.CONFIG for the mappings. 

 

I mapped DSK3 to a single period as described in the PI.CONFIG wiki you linked and that that just returns an empty directory instead of the base TIPI directory.   Mapping to folders works just fine.

 

(EDIT: I just now realized that I posted this problem in the development area not the support area -- I can repost there if desired, or the answer can be posted there. Long day.)

 

image.thumb.png.2c439ab9751875869189aa952eca3447.png

That should get you the TIPI. So likely a bug post it to the support forum please. Though I just tried it here with the latest update and it works as described I mapped DSK4 to . And I get the directory of TIPI.

 

Sent from my LM-G820 using Tapatalk

 

 

 

Share this post


Link to post
Share on other sites

TIPICFG is just a front end for PI.CONFIG, PI.STATUS, PI.SHUTDOWN, and another undocumented one, PI.UPDATE

 

In the beginning, I had to configure my TIPI with BASIC programs, or just open PI.CONFIG in Editor/Assembler's editor...  This provided an easy interface that is available in most 4A programming languages. 

 

There is also documentation in 'Devices' page that states:   "Manage DSK1-4 mappings in PI.CONFIG or with TIPICFG program."

 

I'll try and 'devlop' the documentation more with some cross links... so when you are reading TIPICFG, you are told the rules for mapping are in PI.CONFIG

 

[email protected]

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, InsaneMultitasker said:

Thank you Matt. 

 

I have been experimenting with cataloging the TIPI using level 3 routines via both Extended BASIC and assembly. 

 

I can catalog "DSK0." and as expected, the root and sublevels work fine.   However, many programs don't accept device 0 so I tried to map one of the other DSKx devices.  The tipi wiki isn't clear (to me) as to what is expected to properly map a device so I had a bit of trial and error.   Here are the results of my attempts. I used CALL TIPI to map and write the configuration each time.

 

1. "TIPI.folder." -- trailing period:  failed, io error

2. "TIPI.folder" - no trailing period:  failed, io error

3. "folder." - folder with period:   no error but no files. 

4. "folder" - folder without trailing period: successful, files and directories displayed as expected

 

I also tried to map DSKx. to the TIPI root but could not figure out how to do so. 

5. "TIPI." - failed, IO error

6. "TIPI" - failed, IO error

 

 

 

When you write the catalog program in BASIC per Texas Instruments example, with a floppy controller, if you include a trailing '.' it fails.  I'll take that as a bug that I don't fail outwrite... probably a 4A to Linux path conversion issue. 

 

I should put more code in the mapping to self-correct for common mistakes. In Force Command's TIPIMAP command, I allow preceding 'TIPI.' on the target paths, and clean up trailing dots. But in the context of that tool the user and the tool are meant to be aware of full paths.  

 

Mapping to the equivalent of 'TIPI.' was added to compensate for when I removed the special nature of DSK4.  So pretty recent.

 

When I was originally building the mapping, I decided against allowing 'TIPI.' in the base of the mapping to emphasize the requirement that it be some folder within that part of the host filesystem. You can't map DSK1 to DSK2, or anything like that, which I felt users would assume if they saw the device name in the target value. 

 

[email protected] 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
22 hours ago, jedimatt42 said:

 

When you write the catalog program in BASIC per Texas Instruments example, with a floppy controller, if you include a trailing '.' it fails.  I'll take that as a bug that I don't fail outwrite... probably a 4A to Linux path conversion issue. 

 

hmm, I'm not following as a single trailing period is a requirement to catalog a floppy controller device e.g., "DSK1."  and failure to include the period will generate an error.  The same is true of folder access, e.g., "WDS1.FOLDER1." on hard drive controller devices.  The DSRLNK routine never sees the alias ("TIPI.FOLDER.GAMES") behind the scenes so when it encounters DSKx. with a trailing period, it works and the translation is fine.  And on that note... 

 

I discovered that TIPICFG is not showing a pending update yet my TIPI version is older than 1.47, so if the single period alias for "TIPI." is a very recent add, that explains why it doesn't work for me.  Greg  graciously directed me to the steps to force an update which I will attempt later this week. 

 

Edit: Had time to update to version 1.47. 

  • Mapping DSK3="." for the TIPI base/root allows me to run programs from the root as DSK3. Cool. No more DSK4. conflict! ;)
  • The mapped/aliased cataloged volume name reports as NULL; both DSK0 and TIPI report "TIPI".
  • The catalog seems to work just fine via both the mapped DSK3. and the DSK0. / TIPI. device names. Nice.
  • I confirmed that the floppy controller devices require a trailing period to open the catalog.
  • Like 2

Share this post


Link to post
Share on other sites

I think I got confused by some version of the BASIC catalog code that put the "." on for me, and thus required that I not do so... crafting my own version of reading the catalog from BASIC, I see that yes, the device name needs to end in "." for real DSK1., and TIPI based drives.

 

I stand corrected. I really should never post from my phone, since I can't verify before posting. And my rationale for device specification is flawed... and has become a legacy bug.

--- 

 

The missing volume name is an interesting over site... I pull the name from the last part of the mapping path, instead of from the last part of the resolved path... LOL... I'll fix that with next release.. 

 

[email protected]

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

I've noticed on at least two upgrades, the time on the TIPI is being changed to another timezone.  It is not keeping my Eastern Timezone for New_York that I set with the timedatectl.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
I've noticed on at least two upgrades, the time on the TIPI is being changed to another timezone.  It is not keeping my Eastern Timezone for New_York that I set with the timedatectl.
 
 
Strange those should be unrelated

Sent from my LM-G820 using Tapatalk

Share this post


Link to post
Share on other sites
14 minutes ago, arcadeshopper said:

Strange those should be unrelated

Sent from my LM-G820 using Tapatalk
 

At this point I know two of the TIPI's I have updated, the time zone changed on them.  The third is sitting in a PEBox and needs to be upgraded, but haven't done it yet.

 

It's possible some other event could have caused it, but if there was another trigger, the only thing those two TIPI's have seen is a Re(B)oot from the TIPICFG menu.

 

I assume the timedatectl should be "permanent" across reboots...……….

 

Beery

  • Like 1

Share this post


Link to post
Share on other sites
At this point I know two of the TIPI's I have updated, the time zone changed on them.  The third is sitting in a PEBox and needs to be upgraded, but haven't done it yet.
 
It's possible some other event could have caused it, but if there was another trigger, the only thing those two TIPI's have seen is a Re(B)oot from the TIPICFG menu.
 
I assume the timedatectl should be "permanent" across reboots...……….
 
Beery
I think that's the issue.. that it isn't. Test by changing it and doing a reboot

Sent from my LM-G820 using Tapatalk

Share this post


Link to post
Share on other sites

We need to have a feature to properly set the time zone for this variant of Linux that is incorported into the PI.CONFIG management tooling. 

 

In building part of that (you can print TZ=yourtimezone to PI.CONFIG and it will apply the change), I noticed that raspi-config does more than just timedatectl for setting the timezones. 

 

I'll add proper documentation tonight, sometime after commuting and dinner.

 

[email protected]

  • Like 4

Share this post


Link to post
Share on other sites

Matt,

 

I'm trying to understand a difference between the Telnet client you wrote for the TI-99/4A and the terminal application I wrote for the Geneve under MDOS for the TIPI.

 

Within the GPL interpreter on the Geneve, I can login to localhost:23 using your client.  I can also connect to my BBS, Heatwave, etc. with no issues.  Within MDOS mode on the Geneve, I can login to my Telnet BBS, Heatwave, etc.  Again, no issue.


What I can not do, is when I try to login from MDOS mode with my application, get a proper display from localhost:23.  I get a scramble of characters.  

 

I reviewed your source code to your Telnet client and I can not see anything immediately obvious thinking there could be some kind of unique character handling.  Is there a unique ANSI sequence or some other special escape sequence when communicating with localhost:23 ? 

 

If I can solve this issue, then I have a way of displaying things in 80 columns with localhost:23 instead of the 40/64 columns I am limited too under GPL mode since the Geneve lacks the F18A.

 

Beery

 

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, BeeryMiller said:

Matt,

 

I'm trying to understand a difference between the Telnet client you wrote for the TI-99/4A and the terminal application I wrote for the Geneve under MDOS for the TIPI.

 

Within the GPL interpreter on the Geneve, I can login to localhost:23 using your client.  I can also connect to my BBS, Heatwave, etc. with no issues.  Within MDOS mode on the Geneve, I can login to my Telnet BBS, Heatwave, etc.  Again, no issue.


What I can not do, is when I try to login from MDOS mode with my application, get a proper display from localhost:23.  I get a scramble of characters.  

 

I reviewed your source code to your Telnet client and I can not see anything immediately obvious thinking there could be some kind of unique character handling.  Is there a unique ANSI sequence or some other special escape sequence when communicating with localhost:23 ? 

 

If I can solve this issue, then I have a way of displaying things in 80 columns with localhost:23 instead of the 40/64 columns I am limited too under GPL mode since the Geneve lacks the F18A.

 

Beery

 

 

Well, 1st, if you have to log into the PI so often that this is worth this kind of effort, I've done something grossly wrong. 

 

If you get scrambled noise just when logging into the Linux telnet service on the PI, it is probably either the TELNET negation, or the Csi code 'c' that should respond with the term-type.  Probably the TELNET negotiation. The BBS's typically don't actually use the telnet protocol, but just a raw TCP socket which telnet clients can attach to. 

 

The telnet negotiation:  https://github.com/jedimatt42/tipi/blob/ef1396b8319ef8730571fd9820f6496842866819/examples/telnet/main.c#L177

 

You'll notice the telnet protocol has precedence over the terminal protocol.

 

The termtype request handler: https://github.com/jedimatt42/tipi/blob/ef1396b8319ef8730571fd9820f6496842866819/examples/telnet/terminal.c#L375

 

[email protected]

  • Like 1

Share this post


Link to post
Share on other sites

Matt,

 

I've captured the telnet negotiation protocol and I have been reviewing your Telnet source code.  I'm not a C programmer, but can mostly follow what is written.

 

Logging into localhost:23, I get the following hex sequence:

 

>FF,>FD,>18

>FF,>FD,>20

>FF,>FD,>23

>FF,>FD,>27

 

I know the >FF is the CMD code, and the >FD is a "DO".  The >18 is "Terminal Type" and the >20 is a "Terminal Speed".  Not exactly sure what the >23 and >27 commands are.

 

I though I should send the following sequences back trying to interpret your C source, but that isn't working. 

 

>FF,>FC,>18

>FF,>FC,>20

>FF,>FC,>23

>FF,>FC,>27

 

I am trying to read this piece of your code, but not following it completely.

 

switch (command) {
  case DO:
  send_cmd(WONT, current);
  break;
  case DONT:
  send_cmd(WONT, current);
  break;
  case WILL:
  break;
  case WONT:
  break;
  default:
  break;

 

Anyways, any feedback is appreciated.  Once I figure out this IAC issue, then I should be able to add the extra interpretation routines.

 

Again, thanks for any feedback if you have the time.


Beery

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, BeeryMiller said:

Matt,

 

I've captured the telnet negotiation protocol and I have been reviewing your Telnet source code.  I'm not a C programmer, but can mostly follow what is written.

 

Logging into localhost:23, I get the following hex sequence:

 

>FF,>FD,>18

>FF,>FD,>20

>FF,>FD,>23

>FF,>FD,>27

 

I know the >FF is the CMD code, and the >FD is a "DO".  The >18 is "Terminal Type" and the >20 is a "Terminal Speed".  Not exactly sure what the >23 and >27 commands are.

 

I though I should send the following sequences back trying to interpret your C source, but that isn't working. 

 

>FF,>FC,>18

>FF,>FC,>20

>FF,>FC,>23

>FF,>FC,>27

 

I am trying to read this piece of your code, but not following it completely.

 

switch (command) {
  case DO:
  send_cmd(WONT, current);
  break;
  case DONT:
  send_cmd(WONT, current);
  break;
  case WILL:
  break;
  case WONT:
  break;
  default:
  break;

 

Anyways, any feedback is appreciated.  Once I figure out this IAC issue, then I should be able to add the extra interpretation routines.

 

Again, thanks for any feedback if you have the time.


Beery

I believe you are interpreting my code correctly. If the terminal server says DO x, I reply WONT x. 

 

My code is a little state machine so I can parse that and respond byte by byte. 

 

Maybe something else is wrong? Can you mockup a server that accepts a socket, sends those DO commands, and prints the bytes it gets back? 

 

[email protected]

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, jedimatt42 said:

I believe you are interpreting my code correctly. If the terminal server says DO x, I reply WONT x. 

 

My code is a little state machine so I can parse that and respond byte by byte. 

 

Maybe something else is wrong? Can you mockup a server that accepts a socket, sends those DO commands, and prints the bytes it gets back? 

 

[email protected]

That is an excellent idea.  I should be able to do that.  Time permitting, I will try that tonight.


Beery

 

  • Like 1

Share this post


Link to post
Share on other sites
On 2/19/2020 at 7:06 AM, BeeryMiller said:

That is an excellent idea.  I should be able to do that.  Time permitting, I will try that tonight.


Beery

 

 

I am rechecking some code as I am not getting any information back from the string that I am sending.  

Share this post


Link to post
Share on other sites

Matt,

 

I've got a request if you will entertain the idea.  Is it possible to add a client or server command, let's call it VERIFY, that tests whether a socket is still connected? Perhaps non zero if socket is active, and 0 if not connected.  It's got two applications.  One, for a client application such as a telnet client, it will allow immediate determination the connection is still active if one is waiting for characters.  Same thing for the server side of things if one is waiting for an input from the client.

 

The Write command will return if there is a failure to write.  Just not something to alert the app if one is waiting for to receive something.

 

Beery

 

Share this post


Link to post
Share on other sites
3 hours ago, BeeryMiller said:

Matt,

 

I've got a request if you will entertain the idea.  Is it possible to add a client or server command, let's call it VERIFY, that tests whether a socket is still connected? Perhaps non zero if socket is active, and 0 if not connected.  It's got two applications.  One, for a client application such as a telnet client, it will allow immediate determination the connection is still active if one is waiting for characters.  Same thing for the server side of things if one is waiting for an input from the client.

 

The Write command will return if there is a failure to write.  Just not something to alert the app if one is waiting for to receive something.

 

Beery

 

Are you trying to get me to solve the carrier detect doesn't exist problem? 

 

If a BBS over TCP/IP wants to solicit an error from the socket your best bet it to have the BBS send some data periodically. Like if the user is sitting at the prompt and seems idle, just resend the prompt. 

 

If it is disconnected, you should then get an error writing to the socket. 

 

There is a lot of buffering and retry in the lower layer, and in my experience it is extremely difficult to ask if a socket is still open, in the same sense as how modem communication could check for carrier detect.

 

If you are just trying to be lazy in your own software so you don't have to keep track yourself, well I don't get it. Writing the 9900 code is supposed to be the fun part.

 

[email protected]

  • Haha 1

Share this post


Link to post
Share on other sites

Yup..I spent an easy week full of fun then I found out I was doing a INC instead of

A INCT as I was moving a word.

Oh that's fun I'll try to never duplicate again. Lol haha

Share this post


Link to post
Share on other sites
12 hours ago, jedimatt42 said:

Are you trying to get me to solve the carrier detect doesn't exist problem? 

 

If a BBS over TCP/IP wants to solicit an error from the socket your best bet it to have the BBS send some data periodically. Like if the user is sitting at the prompt and seems idle, just resend the prompt. 

 

If it is disconnected, you should then get an error writing to the socket. 

 

There is a lot of buffering and retry in the lower layer, and in my experience it is extremely difficult to ask if a socket is still open, in the same sense as how modem communication could check for carrier detect.

 

If you are just trying to be lazy in your own software so you don't have to keep track yourself, well I don't get it. Writing the 9900 code is supposed to be the fun part.

 

[email protected]

 

It would be nice if there was the ability to test the socket connection (i.e., with BBS software a Carrier Detect) situation.

 

The source code I am trying to modify has in parts what must be 4 to 5 layers deep in BLWP calls interacting with previous RS232 code, the simultaneous keyboard scanning, clock timer, and more.  And some of those routines are modifying data in the registers of other workspaces.  It is a tangled mess.

 

With a Sysop locally logging in, I have had no issues with the timer expiring and logging off the call.  Somewhere buried who knows where at the moment, when accessing the socket, something is not getting picked up.  I know it is not your problem, but I thought if it was easy as checking the status of a variable and passing that information back, it would have multiple uses.  I do not know how the Windows Telnet client does it, but it seems to know when the connection is immediately dropped.

 

As far as writing a character out, I have been a bit hesitant to do that as there are multiple terminal emulators out there and I do not know how they would all respond to an extraneous character even with something as simple as sending out hex >00 as a byte.

 

Another thought, what happens if one uses the Write command but zero length.  Will that alert if the socket connection is dropped?

 

Please note, I realize this is not your issue with the software I am trying to modify.  I do think it has future implications and realize it is totally your call.  If something as simple as a zero write length can accomplish the same thing if that is simpler to implement, maybe that is another way to skin the cat.

 

Beery

 

  • Like 1

Share this post


Link to post
Share on other sites

I don't expect a zero length write would work. I would write something terminals can handle like valid and I or plain text the user should actually see. 

 

I also wouldn't modify old code. Catering to it's architecture that is about keeping up with RS232, is a losing game in a TCP world.

 

Just my opinion.

 

I don't know how to implement the solution you ask for.

 

[email protected]

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