TIPI Usage and Support

[GDMike]

Upsssss...sheezz...good for 15 mins unless you are actively changing those cheap batteries for known good ones that gives an hour of life..

Overnight, power goes off, computers are at work off site..yawn...wake up, go to work.everythings dead... I guess power went off last night for more than an hour. Oops, no watchman software works to shutdown the computers.. junk

Different at home, a UPS gives me 10 mins IF I'm home. But will probably save those spikes from killing things.

Ahh..it's a surge protector. I got it.

 

Edited February 14, 2021 by GDMike

[Omega-TI]

Actually, it depends how large of a UPS you get and how much crap you hang off of them.  If you simply power an RPi, you'll have quite literally HOURS of backup time.  The small one I use with my portable TI will run the TI, TIPI and monitor for 2 hours, I simply have no clue to how long it'll last with just the TIPI.

 

Now when it comes to my home PC, I have a substantially larger unit on that, and it will also shut down my PC on it's own at certain threshold if I'm not around.  I understand people have had different experiences in life and come to different conclusions because of it, but I've had nothing but positive experiences with all the ones I have.  I'll tell you this much, they've saved me a TON of time over the years on having to redo something because of a power glitch.  I'll NEVER run a PC without one!

 

 

[+InsaneMultitasker]

2 minutes ago, Omega-TI said:

I'll tell you this much, they've saved me a TON of time over the years on having to redo something because of a power glitch.  I'll NEVER run a PC without one

This happens here periodically.  When I am working from the laptop, a momentary glitch if of no concern.  However, if it is a RPi or my Geneve where I do MDOS development, a momentary glitch is unacceptable. UPS has saved me many times over the past year that I reworked my setup.

[+jedimatt42]

1 hour ago, RXB said:

You would think this would be in RAM not on the SD card and use a buffer in case it does lose power?

But that is one bad design if you think about a OS so prone to such a simple problem.

It's not the OS as much as SD card tech. SD cards are prone to the same issue in any other device including desktop PCs. 

 

TIPI configures most of the background OS write activity into ramdisks. 

The Linux OS caches what it has room for from the rest of the filesystem. 

This reduces risk considerably.

Does nothing to protect against brownout.

 

There are background daemons bundled with the Raspberry PI OS that periodically check for security updates. Otherwise an idle PI isn't really that prone. 

 

There has been a lot of progress in read-only filesystem operation support for Raspberry PI... https://www.google.com  

Some of the solutions require more rigorous testing to ensure the suite of systems work, than a hobby project like TIPI merits.

Edited February 14, 2021 by jedimatt42

[Omega-TI]

6 minutes ago, InsaneMultitasker said:

This happens here periodically.  When I am working from the laptop, a momentary glitch if of no concern.  However, if it is a RPi or my Geneve where I do MDOS development, a momentary glitch is unacceptable. UPS has saved me many times over the past year that I reworked my setup.

 

Yup!  Mine saved my ass only yesterday!

 

 

[GDMike]

18 minutes ago, InsaneMultitasker said:

This happens here periodically.  When I am working from the laptop, a momentary glitch if of no concern.  However, if it is a RPi or my Geneve where I do MDOS development, a momentary glitch is unacceptable. UPS has saved me many times over the past year that I reworked my setup.

I'm soooo much in agreement with this

[RXB]

TIPI has a huge error in how it is addressed:

 

See here is the problem:

DSK#. or SCS#. or IDE#. are all a number that means 1 to 9 or even A to Z for RAMDISK.

But TIPI screws the pooch as it uses TIPI. and I is not a DRIVE NUMBER so violates the rule used by TI standards!

 

Every other device made for file access in the TI has always been 3 letters and the 4th letter was DRIVE or DEVICE number.

i.e. SCS1. or WDS2. or IDE4. or DSK9. or DSKC. for RAMDISKs.

 

How it normally works is SCS. or WDS. or IDE. or DSK. was for path names that way it knows this is a path and does not have a device number.

 

I could not figure out why TIPI was crashing every time I tried to catalog it and found this is a huge screw up on standards.

I have been wasting weeks on RXB 2020 thinking I was the issue on these crashes but found that RXB that has used this method for over 20 years

is not compatible with TIPI due to the violation of standards everyone has used for 20 years on making devices.

 

What should be the name for the device is TIP. not TIPI. as that would be like every other DISK like access made.

 

So I either have to totally go in and make an exception for TIPI. ALONE or just take it for granted that TIPI. is a bad idea for a DEVICE that violates a 

38 year rule of the TI99/4A. So great now I have to re-write every Catalog and Device access due to a screw up of naming conventions violated.

 

This would also explain all the other programs that will not work with TIPI as they all take for granted like I did that 3 letters with period is path. 

i.e. DSK. or SCS. or IDE. or WDS. or CRD. or every other device ever made for TI99/4A

 

I bet money if this is changed to TIP. vs TIPI. you will find all kinds of programs now again work as supposed to work.

[+arcadeshopper]

Try DSK0

And maybe rtfm

Sent from my LM-V600 using Tapatalk

 

 

 

 

[GDMike]

Tipi should be thought of as an Internet device, not a local device?

I dunno..I'm just guessing

[RXB]

11 minutes ago, arcadeshopper said:

Try DSK0

And maybe rtfm

Sent from my LM-V600 using Tapatalk

 

 

 

 

RXB 2001 to RXB 2020 all allow for DSK0. and has been not a problem with even CLASSIC99 or MESS or naming a RAMDISK DSK0.

 

And it did work will on RXB 2020, will have to test RXB 2001 and RXB 2012 or RXB 2015

 

OMG this is great news as I was in a panic of having to re-write a patch for all access to DISK or HARD DRIVES.

[+arcadeshopper]

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

Devices

Drive device names:

TIPI. - Primary device name for all file access

DSK0. - Alias for "TIPI."

DSK1. - Mappable alias for any directory under "TIPI."

DSK2. - " "

DSK3. - " "

DSK4. - " "

DSK. - Volume name search device

Manage DSK1-4 mappings in PI.CONFIG or with TIPICFG program.

Web device names:

URI1. - Can be mapped to a URL prefix, as alias for PI.HTTP

URI2. - " "

URI3. - " "

Manage these mappings in PI.CONFIG or with TIPICFG program.

Other Devices:

PI. - Device prefix for special file access

This device supports an extensible set of special file handlers. Currently we have the following:

PI.PIO - print to PDF

PI.CLOCK - fetches a timestamp whenever a record is read

PI.TCP - read/write access to sockets

PI.HTTP / PI.http - read access to web hosted files

PI.CONFIG - read/write access to TIPI's configuration map

PI.STATUS - read access to TIPI status values

PI.VARS - read/write distributed variables hosted by myti99.com

PI.SHUTDOWN - write a record, shutdown your PI

PI.REBOOT - write a record, reboot your PI

PI.UPGRADE - write a record, triggers update of TIPI PI software



Sent from my LM-V600 using Tapatalk

[RXB]

I have tried over and over to map ALIAS for DSK1. or DSK2. with every time crashing.

MAP: TIPI.RXB2020.RXB-SAMS. 

Does not work just uses physical disk 1 or 2 each time.

[+arcadeshopper]

I have tried over and over to map ALIAS for DSK1. or DSK2. with every time crashing.
MAP: TIPI.RXB2020.RXB-SAMS. 
Does not work just uses physical disk 1 or 2 each time.

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



Sent from my LM-V600 using Tapatalk

[RXB]

4 minutes ago, arcadeshopper said:

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



Sent from my LM-V600 using Tapatalk
 

Hmmm set it at: RXB2020.RXB-SAMS.

CALL CAT(1) just returns error 1635 what ever the hell that is...?

 

[+jedimatt42]

The github wiki covers this. This thread covers this. The dev thread covered this.

 

We talked about this in person in 2016.

 

I built TIPI for LVL3 io first, cause that is what I cared about. This is the standard that TI documented for us to program applications against.

 

I added LVL2 io for in system file management, and direct file io. Mostly used by file management tools. 

 

I have no intention of implementing LVL1 io. This is used for custom filesystems on spinning disks, and programs that do not follow the specifications for cataloging a device.

 

If someone thinks I have engaged in bestiality with a canine, I would ask that they sell their device to someone else who would enjoy it.

[RXB]

8 hours ago, jedimatt42 said:

The github wiki covers this. This thread covers this. The dev thread covered this.

 

We talked about this in person in 2016.

 

I built TIPI for LVL3 io first, cause that is what I cared about. This is the standard that TI documented for us to program applications against.

 

I added LVL2 io for in system file management, and direct file io. Mostly used by file management tools. 

 

I have no intention of implementing LVL1 io. This is used for custom filesystems on spinning disks, and programs that do not follow the specifications for cataloging a device.

 

If someone thinks I have engaged in bestiality with a canine, I would ask that they sell their device to someone else who would enjoy it.

Hmmm RXB will catalog and do fine with CALL CAT("DSK0.") and does crash a few times but does work with CALL CAT("TIPI") ! NO PERIOD

 

That does not explain why setting path never works?

Instead TIPI returns on screen in RXB using CALL CAT("DSK1.")       * IO ERROR 1635 *

OLD "DSK1.LOAD" and RUN "DSK1.LOAD" also return  * IO ERROR 1635 * 

Will try re image the SD card next.

[+9640News]

Is RXB, subdirectory aware?

[+arcadeshopper]

Hmmm RXB will catalog and do fine with CALL CAT("DSK0.") and does crash a few times but does work with CALL CAT("TIPI") ! NO PERIOD
 
That does not explain why setting path never works?
Instead TIPI returns on screen in RXB using CALL CAT("DSK1.")       * IO ERROR 1635 *
OLD "DSK1.LOAD" and RUN "DSK1.LOAD" also return  * IO ERROR 1635 * 
Will try re image the SD card next.

Does the DSK1. work in dm2k?

TIPI. does

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

18 hours ago, RXB said:

TIPI has a huge error in how it is addressed:

 

See here is the problem:

DSK#. or SCS#. or IDE#. are all a number that means 1 to 9 or even A to Z for RAMDISK.

But TIPI screws the pooch as it uses TIPI. and I is not a DRIVE NUMBER so violates the rule used by TI standards!

 

Every other device made for file access in the TI has always been 3 letters and the 4th letter was DRIVE or DEVICE number.

i.e. SCS1. or WDS2. or IDE4. or DSK9. or DSKC. for RAMDISKs.

 

How it normally works is SCS. or WDS. or IDE. or DSK. was for path names that way it knows this is a path and does not have a device number.

 

I could not figure out why TIPI was crashing every time I tried to catalog it and found this is a huge screw up on standards.

I have been wasting weeks on RXB 2020 thinking I was the issue on these crashes but found that RXB that has used this method for over 20 years

is not compatible with TIPI due to the violation of standards everyone has used for 20 years on making devices.

 

What should be the name for the device is TIP. not TIPI. as that would be like every other DISK like access made.

 

So I either have to totally go in and make an exception for TIPI. ALONE or just take it for granted that TIPI. is a bad idea for a DEVICE that violates a 

38 year rule of the TI99/4A. So great now I have to re-write every Catalog and Device access due to a screw up of naming conventions violated.

 

This would also explain all the other programs that will not work with TIPI as they all take for granted like I did that 3 letters with period is path. 

i.e. DSK. or SCS. or IDE. or WDS. or CRD. or every other device ever made for TI99/4A

 

I bet money if this is changed to TIP. vs TIPI. you will find all kinds of programs now again work as supposed to work.

 

With a post like this, full of swiss cheese information that doesn't actually back up your premise and just show you clearly haven't read the specifications from Texas Instruments, or the many documentation pages on the TIPI wiki, I am not inspired to assist you.

 

The specifications allow for up to 7 characters in a device name. The 3 + number convention is a community convention allowing programmers to make assumptions of how to determine the unit number for LVL1 and LVL2 IO. LVL 3 IO does not care. The subprogram name mask must be hard coded anyway for LVL2 IO, as most devices use different subprogram names than the TI FDC. 

 

It is a legacy pattern that devices hosting 'DSKn' named devices, use the same LVL2 IO subroutine names as Texas Instruments did.

 

File storage devices on TIPI support sub directories and timestamps in their CATALOG file generation. This is done in the same manner as HDX, and IDE and the Myarc approach on the Geneve. This is an extension that does create some incompatibility with the CATALOG specification original published by Texas Instruments. For very good documentation on how to read a catalog from a TI-99 storage device, I refer everyone to ti99-geek.nl. 

 

----

 

There is a list on the TIPI wiki of incompatible programs. That list is pretty small. I would be happy to add RXB to it, but that needs someone to qualify what exactly doesn't work as it seems RXB users are able to work, and have not reported issues. 

 

[Omega-TI]

[RXB]

4 hours ago, arcadeshopper said:

Does the DSK1. work in dm2k?

TIPI. does

Sent from my LM-V600 using Tapatalk
 

No DM2K also crashes.

[RXB]

2 hours ago, jedimatt42 said:

 

With a post like this, full of swiss cheese information that doesn't actually back up your premise and just show you clearly haven't read the specifications from Texas Instruments, or the many documentation pages on the TIPI wiki, I am not inspired to assist you.

 

The specifications allow for up to 7 characters in a device name. The 3 + number convention is a community convention allowing programmers to make assumptions of how to determine the unit number for LVL1 and LVL2 IO. LVL 3 IO does not care. The subprogram name mask must be hard coded anyway for LVL2 IO, as most devices use different subprogram names than the TI FDC. 

 

It is a legacy pattern that devices hosting 'DSKn' named devices, use the same LVL2 IO subroutine names as Texas Instruments did.

 

File storage devices on TIPI support sub directories and timestamps in their CATALOG file generation. This is done in the same manner as HDX, and IDE and the Myarc approach on the Geneve. This is an extension that does create some incompatibility with the CATALOG specification original published by Texas Instruments. For very good documentation on how to read a catalog from a TI-99 storage device, I refer everyone to ti99-geek.nl. 

 

----

 

There is a list on the TIPI wiki of incompatible programs. That list is pretty small. I would be happy to add RXB to it, but that needs someone to qualify what exactly doesn't work as it seems RXB users are able to work, and have not reported issues. 

 

Hmmm unlike you I do not know TIPI inside out and your god like attitude is not warranted please be patient.

I will re image the SD card as that might be the issue, I do not know maybe the issue is my PBOX is flaky.

As for RXB it has been getting debugged since 1996 so I have a much longer history of fixing bugs then TIPI which is not very old.

No one can keep everyone happy so I do not expect you to, but RXB has had a long history of Cataloging devices using TI Standards.

Since 1996 that is alot of devices over the years.

[+arcadeshopper]

No DM2K also crashes.

Photos of the crash and log cut and paste please

Sent from my LM-V600 using Tapatalk

[+arcadeshopper]

Here is mine working as expected in dm2k tipicfg and rxb2015

 

The issue is entirely on your side. Stop attacking tipi and Matt's work for your issue.

 

Idk what's really going on because you continually post non-information and no logs no screen captures no actual facts about how things are configured on your end.

 

Sent from my LM-V600 using Tapatalk

 

 

 

 

 

[RXB]

1 hour ago, arcadeshopper said:

Here is mine working as expected in dm2k tipicfg and rxb2015

 

The issue is entirely on your side. Stop attacking tipi and Matt's work for your issue.

 

Idk what's really going on because you continually post non-information and no logs no screen captures no actual facts about how things are configured on your end.

 

Sent from my LM-V600 using Tapatalk

 

 

 

 

 

Not attacking TIPI just saying what is happening.

I go to CALL TIPI put in any path into DSK1 or DSK2 or DSK3 or DSK4 and that path only responds to TIPI. or DSK0. and ignores the path.

When I do a CALL TIPI again the path I put in is not the path but just a  . (period)

If I knew squat about doing a LOG I would post it. Pretend I am not a expert on TIPI but as a new user of one.

How come no matter what path I put in it only does DSK0. or TIPI. as the path?