TIPI Usage and Support

[+OLD CS1]

2 hours ago, dgrissom said:

I've played with JSON strings for a month and still think it refers to JASON from the slasher movies!  😁 

I used to feel similarly about XML and SOAP.

[+jedimatt42]

Update 3.7 - April 15th 2023

 

- I broke something in the JSON stuff... I fixed it now. Just update.

[+jedimatt42]

Update 3.8 - April 15th 2023 - still

 

- Updated WEB UI emulation page to include note about running js99er.net from the 'http:' not 'https:' url for use with the websocket. Added link, and note that some web browsers auto-promote to https: if they can (this was biting me today, most frustrating).

- Updated #? wildcarding in 2 ways:

  - when used for the part of a path that is a directory, then it will only match a directory

  - when used by a LOAD operations ( OLD, or EA5, or Adventure, TOD, TI-Artist, you know, things consuming PROGRAM image files. ), then it only matches files that are PROGRAM images, or follow the rules for TIPI to auto-convert to a BASIC PROGRAM image file. 

 

So, in practice OLD DSK1.#? will load the first PROGRAM image in whatever directory you have mapped DSK1. to even if there are files like !README that are DV80s that are alphabetically first.

 

Note, remember how EA5 loaders work when there are multiple files? Sure you do... the loader ( tms9900 software ) has to increment the last character in the file name, and then attempt to LOAD that. That doesn't work well with using the #? at the end of the name... But if you are using the #? to just be lazy, make that little extra effort to add the last letter of the file you want... if you have PACMAN and PACMAM that need to load, then you can specify #?N and an EA5 loader will be able to increment the N to the M, and then TIPI will be able to match the #?M to that second file 'PACMAM' 

 

 

[+9640News]

@jedimatt42

 

I am looking at the JSON information you have on github.  My first goal is to write some test code in assembly in MDOS.  I see something I question will be an issue/limitation at least for the Geneve from what I am understanding from the XB example.

With something like the following:

 

MAIN:

      URL$="https://api.open-meteo.com/v1/forecast?latitude=32.46&longitude=-86.46&current_weather=true&temperature_unit=fahrenheit&windspeed_unit=mph&precipitation_unit=inch"

READDATA:

      OPEN #1:"PI.?J."&URL$,DISPLAY ,VARIABLE 254

 

I am under the impression something like the above would be passed a full filename, exceeding a 40 character definition with file parameters for DIS/VAR 254 for the Geneve DSR XOP.  DO I have a correct understanding that would be a limitation?  Like I said, if my understanding is correct, it is not a limitation for the TI-99/4A.

 

Or, I am wondering if there is use of the sendmsg that can resolve this construct as a possible solution?  Or, I am thinking I may need to proceed along the lines of using the actual TIPI Eprom code for the handling instead of the Geneve DSR XOP.

 

 

 

 

[+jedimatt42]

4A device/file name strings for an OPEN DSR call can be 255 characters long. URLs can be longer than many 4A programs can support, so I created the URI1, URI2, URI3 mappings. A program that needs to create a long URL for use with PI.HTTP or PI.HTTPS file system access should first write the mapping to PI.CONFIG for URI1, URI2 or URI3. Those mappings were never meant for manual configuration except to test. Programs should set them without regard for manual settings users have misused. The ?J modifier should still work for the URI1, URI2 or URI3 as URI1.?J.some-additional-uri-path-or-http-query-params, for example. This should allow for close to 500 character URL usage.

 

File IO does run through the TIPI messaging system, but that isn't documented outside the TIPI DSR ROM code.

[+9640News]

15 minutes ago, jedimatt42 said:

4A device/file name strings for an OPEN DSR call can be 255 characters long. URLs can be longer than many 4A programs can support, so I created the URI1, URI2, URI3 mappings. A program that needs to create a long URL for use with PI.HTTP or PI.HTTPS file system access should first write the mapping to PI.CONFIG for URI1, URI2 or URI3. Those mappings were never meant for manual configuration except to test. Programs should set them without regard for manual settings users have misused. The ?J modifier should still work for the URI1, URI2 or URI3 as URI1.?J.some-additional-uri-path-or-http-query-params, for example. This should allow for close to 500 character URL usage.

 

File IO does run through the TIPI messaging system, but that isn't documented outside the TIPI DSR ROM code.

Thanks for the feedback.  Going to make sure @InsaneMultitasker sees this comment.

[+jedimatt42]

18 hours ago, 9640News said:

Thanks for the feedback.  Going to make sure @InsaneMultitasker sees this comment.

Here my friend, I have documented the direct messaging workflow of each 4A level 3 device service routine in the TIPI ROM. 

 

https://github.com/jedimatt42/tipi/wiki/PABMessaging

 

With this you should be able to circumvent your OS quirks. There is a note in there, that the way the device-name is messaged allows you to exceed the device-name limits of the PAB system. So you could send a 2 megabyte 64k URL if you want. 

 

I have documented this, so I'll try not to break it in the future.

Edited April 16, 2023 by jedimatt42
correction

[+9640News]

5 minutes ago, jedimatt42 said:

Here my friend, I have documented the direct messaging workflow of each 4A level 3 device service routine in the TIPI ROM. 

 

https://github.com/jedimatt42/tipi/wiki/PABMessaging

 

With this you should be able to circumvent your OS quirks. There is a note in there, that the way the device-name is messaged allows you to exceed the device-name limits of the PAB system. So you could send a 2 megabyte URL if you want. 

 

I have documented this, so I'll try not to break it in the future.

Thanks for the information.  It had been a couple of years since I had last dug into the Eprom code which is where/when @InsaneMultitasker and I started the process of he adding DSR support and I adding the XOP support.  I'll not try to break the 2MB URL length.

 

On a separate project for work, it appears I did encounter a filesize limit for TIF graphic files.  Seems at 700 MB's, I could not find anything to display the graphic.  Seems as though my resolution at 5 cm/pixel for some overhead aerial photography was just too much detail.  I only stiched together just over 360 jpeg's........

[+jedimatt42]

Oh, I was wrong... it's a 64k limit... the length of the message containing the devicename is 16bit.

[+9640News]

19 minutes ago, jedimatt42 said:

Oh, I was wrong... it's a 64k limit... the length of the message containing the devicename is 16bit.

Oh darn, just 64K in length for a filename?  Actually, it is probably more like 16K - 10 bytes if you limit yourself to the amount of TI-99/4A VRAM that is available.  I guess on the Geneve one may be able to push about 56K.

[+InsaneMultitasker]

On 4/15/2023 at 8:55 PM, 9640News said:

Thanks for the feedback.  Going to make sure @InsaneMultitasker sees this comment.

I have used URIx to make life easier and I will try to read topics more diligently 

 

The challenge is often that artificial limitations were implemented based on hardware from that era.  Early programs might ask for a disk number from 1-3 or generously allow 15 character disk device and file, e.g., "DSK5.FILENAME01".  The HFDC DSR imposes a 40-character path.file limitation and I suppose that when 5MB hard drives were all the rage, deep subdirectory levels weren't that important; the same 40-character limitation was replicated in other DSRs and the Geneve OS. Fortunately, the TIPI doesn't adhere to certain past sins artificial limitations imposed by devices and programs/programmers.   TIPI and @jedimatt42's dev approach helped to break me out of the old "must always remain compatible with xyz past device" mentality some time ago and for that I'm grateful. 

[+InsaneMultitasker]

I encountered a problem that I don't know how to resolve.

 

I recently updated my RPI/TIPI to the 3.x branch.  I can read files from the RPI via the TIPI card and via the TIPI share without any issue.  I can copy files from the PC to the TIPI share without any issue.  However, tonight is the first time I have tried writing to the RPI via the TIPI card, and the file IO is extremely slow. 

 

The copy time for 50 files (2300 sectors) is 14 minutes. See the two screenshots for start/end times:

 

When I built 3.x, I used a spare SD card. Since the write speeds via the TIPI share are fast, I figure the SD card is not the culprit? 

 

I restarted the RPI and there was no change to the slow write speed.

 

If I re-insert my 2.40 SD card and copy files to the RPI via the TIPI card, the speed is normal.  If I re-insert the 3.x SD card, the write speed is very slow.

 

I found a CPU utilization command; here is a screenshot taken during the copy. I don't know if this is of any value. (when copying, the TIPIService utilization fluctuates between 15-30%). The TIPI log seemed normal and no errors that I could see. 

 

I'm willing to do some testing to determine the cause (hardware, software, gremlins) but I do not know my way around linux, so be kind. 

[+arcadeshopper]

28 minutes ago, InsaneMultitasker said:

I encountered a problem that I don't know how to resolve.

 

I recently updated my RPI/TIPI to the 3.x branch.  I can read files from the RPI via the TIPI card and via the TIPI share without any issue.  I can copy files from the PC to the TIPI share without any issue.  However, tonight is the first time I have tried writing to the RPI via the TIPI card, and the file IO is extremely slow. 

 

The copy time for 50 files (2300 sectors) is 14 minutes. See the two screenshots for start/end times:

 

When I built 3.x, I used a spare SD card. Since the write speeds via the TIPI share are fast, I figure the SD card is not the culprit? 

 

I restarted the RPI and there was no change to the slow write speed.

 

If I re-insert my 2.40 SD card and copy files to the RPI via the TIPI card, the speed is normal.  If I re-insert the 3.x SD card, the write speed is very slow.

 

I found a CPU utilization command; here is a screenshot taken during the copy. I don't know if this is of any value. (when copying, the TIPIService utilization fluctuates between 15-30%). The TIPI log seemed normal and no errors that I could see. 

 

I'm willing to do some testing to determine the cause (hardware, software, gremlins) but I do not know my way around linux, so be kind. 

can you try another card?

 

[+InsaneMultitasker]

46 minutes ago, arcadeshopper said:

can you try another card?

 

Ok, I copied the image from the "slow" card to another card.  The transfer speed via TIPI seems OK now, I'll test more tomorrow to be sure. Thank you  

 

I pulled out a magnifying glass and here is what I could discern from the markings: 

"slow" card -- Kingston 8G, class (4)

"fast" card -- Sandisk ultra, 16GB, class (10)

 

I thought I used the Kingston with my TIPI a year or so ago but now I am not so sure.  Is there a minimum class / speed requirement?  Or is there something different with how the 3.x file system works?  I'll keep the Kingston SD as-is in case you or @jedimatt42 want me to test something.

[+jedimatt42]

3.x was a full operating system update and a bit of a leap forward on the Linux kernel via the upstream Raspberry PI OS. I can only guess they've changed things such that slow SD cards fall back to SPI or something horrible like that. And it has been 18 months since Raspberry PI OS transitioned form 'buster' to 'bullseye' so there have been more upstream changes than I have time to understand. 

 

SD cards also degrade in write performance over time. 

 

My 4GB card I use to create the master image I share is a class-4. I'll look into how it performs.

[+jedimatt42]

Update 3.9 - April 22nd 2023

 

- add PI.CONFIG option: NATIVE_TEXT_DIRS, which allows setting a list of directories that automatically apply the ?W flag to save files within as native text files instead of TIFILES.

- update PI.CONFIG to allow opening in VARIABLE 256 record length, so you can set longer values for NATIVE_TEXT_DIRS and other things, like the URI1 mappings for instance.

- when reading PI.CONFIG, if the record is longer than your specified record length, then the read record will be truncated.

- 80 character records is still the default if not otherwise specified when the PI.CONFIG file is opened.

 

wiki docs are updated - https://github.com/jedimatt42/tipi/wiki/PI.CONFIG#native-text-directories

[+9640News]

Matt,

I thought I had saved/updated PI.CONFIG with the new NATIVE_TEXT_DIRS option to a specific folder before I rebooted the PI after the update.  If I did save it, then when I rebooted, it changed the setting to:

 

NATIVE_TEXT_DIRS=.

 

I know the line where I placed it was right after the DIR_SORT, and now it's placement is alphabetical.  Not sure if that may have had something to do with it.

 

At the moment, I can not confirm whether I saved the file, or not as I already upgraded.  

 

So, everything on the TIPI drive was being treated as text files with the default option.  This may be an issue for users.  I might suggest changing it to something a user would not expect to have on their drive like NATIVE_TEXT_DIR=ZZZZZZZZZZ and then it would be up to the user to change it to a specific path.  Just a suggestion so it doesn't impact all the file son the TIPI drive.

 

 

[+jedimatt42]

Oops, that is a bug in my adding a trailing '.' without first checking if the setting is empty.

 

Sorry about that. 

 

For now, just delete the line from the /home/tipi/tipi.config file on the Linux side. 

 

----

A side note, updates don't generally benefit or require rebooting the PI. The update process automatically restarts the services.

 

 

[+jedimatt42]

1 hour ago, 9640News said:

Matt,

I thought I had saved/updated PI.CONFIG with the new NATIVE_TEXT_DIRS option to a specific folder before I rebooted the PI after the update.  If I did save it, then when I rebooted, it changed the setting to:

 

NATIVE_TEXT_DIRS=.

 

I know the line where I placed it was right after the DIR_SORT, and now it's placement is alphabetical.  Not sure if that may have had something to do with it.

 

At the moment, I can not confirm whether I saved the file, or not as I already upgraded.  

 

So, everything on the TIPI drive was being treated as text files with the default option.  This may be an issue for users.  I might suggest changing it to something a user would not expect to have on their drive like NATIVE_TEXT_DIR=ZZZZZZZZZZ and then it would be up to the user to change it to a specific path.  Just a suggestion so it doesn't impact all the file son the TIPI drive.

 

 

Ok, so you must have a directory named TIPI on your drive named TIPI ... so it strips the TIPI. off, and then added the '.' back, and ended up referencing the entire drive... 

 

 

[+jedimatt42]

Update 3.10 - April 23rd 2023

 

- fix NATIVE_TEXT_DIRS to not strip the leading 'TIPI.' off the path IF you actually have a directory in your 'TIPI.' drive named 'TIPI'

 

 

[jrhodes]

On 4/22/2023 at 10:33 PM, jedimatt42 said:

Update 3.9 - April 22nd 2023

 

- add PI.CONFIG option: NATIVE_TEXT_DIRS, which allows setting a list of directories that automatically apply the ?W flag to save files within as native text files instead of TIFILES.

- update PI.CONFIG to allow opening in VARIABLE 256 record length, so you can set longer values for NATIVE_TEXT_DIRS and other things, like the URI1 mappings for instance.

- when reading PI.CONFIG, if the record is longer than your specified record length, then the read record will be truncated.

- 80 character records is still the default if not otherwise specified when the PI.CONFIG file is opened.

 

wiki docs are updated - https://github.com/jedimatt42/tipi/wiki/PI.CONFIG#native-text-directories

 

16 hours ago, jedimatt42 said:

Update 3.10 - April 23rd 2023

 

- fix NATIVE_TEXT_DIRS to not strip the leading 'TIPI.' off the path IF you actually have a directory in your 'TIPI.' drive named 'TIPI'

 

 

The new NATIVE_TEXT_DIRS option sounded interesting to me, so i removed my TIPI 2.40 sd card and swapped it out for my 3.9 card. (yes i am running two different TIPI installs, 1 per card. I keep the 3.x card up to date and play with from time to time, but mostly i just stick to the 2.40 card)

I did not see any new update from 3.9 to 3.10, so i tried FCTN+U...

"Upgrade running..." followed by "Upgrade complete", and i'm still on 3.9

I can SSH in from my computer via "ssh -l tipi 192.168.0.7" , but CALL TIPI("TIPI.NET.TELNET") and trying to connect to 192.168.0.7 port 23 , i only get "CONNECTED" and a solid white cursor, it won't take any ti994a keyboard input, and disconnects a few moments later.

TIPI WebUI is working.

"less tipi.config" via SSH session shows that the line "NATIVE_TEXT_DIRS=" is not set to anything.

I can confirm the Pi's internet connection is working, as i successfully logged in via SSH and installed "links" the linux command line www browser, and successfully loaded www.google.com .

So, what do i need to do to update my 3.9 install to 3.10?

Edited April 24, 2023 by jrhodes

[+9640News]

18 hours ago, jedimatt42 said:

Update 3.10 - April 23rd 2023

 

- fix NATIVE_TEXT_DIRS to not strip the leading 'TIPI.' off the path IF you actually have a directory in your 'TIPI.' drive named 'TIPI'

 

 

OK, I did not have a directory at TIPI.TIPI, however I did have a directory at TIPI.MDOS.TIPI and I had NATIVE_TEXT_DIRS pointed to TIPI.MDOS.

 

Beery

[+9640News]

@jedimatt42

 

I too do not see an upgrade option from 3.9 to 3.10

 

 

[+jedimatt42]

My automation to mirror from my internal gitlab to public GitHub seems to have broken. I'll fix it tonight.

 

(turned out to be an IP address error)

Edited April 25, 2023 by jedimatt42
mistakes

[+jedimatt42]

4 hours ago, 9640News said:

@jedimatt42

 

I too do not see an upgrade option from 3.9 to 3.10

 

 

It is available now.  Updates are available based on the data in this file, on this branch of the github repository: https://github.com/jedimatt42/tipi/blob/bullseye_release/version.txt