Jump to content
jedimatt42

TIPI Usage and Support

Recommended Posts

Maybe this is a dumb question, but is there any reason not to power the TIPI and Raspberry Pi from the same 5V power source? Especially using a Pi ZeroW, which pulls very minimal current, seems like the 32K sidecar, TIPI and PI could all easily run on a common 5V rail.  Maybe if you need to power cycle the PI while leaving the TI running, but not sure when you'd need to do that.  Thoughts?

Share this post


Link to post
Share on other sites
16 minutes ago, J-Data said:

Maybe this is a dumb question, but is there any reason not to power the TIPI and Raspberry Pi from the same 5V power source? Especially using a Pi ZeroW, which pulls very minimal current, seems like the 32K sidecar, TIPI and PI could all easily run on a common 5V rail.  Maybe if you need to power cycle the PI while leaving the TI running, but not sure when you'd need to do that.  Thoughts?

as long as you are providing at least 500ma to the tipi/32k and whatever your pi requires it seems reasonable.   Though you would probably have to make your own cable. Not everyone is up to that.

Share this post


Link to post
Share on other sites
2 hours ago, arcadeshopper said:

as long as you are providing at least 500ma to the tipi/32k and whatever your pi requires it seems reasonable.   Though you would probably have to make your own cable. Not everyone is up to that.

PeteE runs this way with the ZeroW if I recall. You do end up binding the lifecycle together. I personally leave my PI on all the time, but turn off the other things, either to clear up after a crash or doubts about memory state... But that might be a developer centric issue.

 

I would not recommend doing this to a PI 3 or PI 4, as I would assume powering on the TIPI and 32k while the PI is running might brown-out the PI. I tried that for a bit, and it was trouble. Smarter people might have a better experience.

 

[email protected]

Share this post


Link to post
Share on other sites

Update 1.49 - 2020-02-09

----------------------------------

Fixed reading data files via PI.HTTP ( URI1,2,3 aliases ) 

Now as documented on the PI.HTTP page on the wiki, data streams from the web that are not TIFILES files, will be opened in the format specified ( DIS/VAR 80, DIS/FIXED 128, etc...) and the specified record length will be honored. The data will be broken up to fit within the record length limits.  

 

 The default record length (if 0 is specified, or nothing is specified in BASIC) for VARIABLE is 80, and the default for FIXED is 128.

 

CALL TIPI("PI.HTTP://ftp.whtech.com/TIPI/WEATHER")  once agains works when retrieving the weather data.

 

[email protected]

  • Like 3

Share this post


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

Update 1.49 - 2020-02-09

----------------------------------

Fixed reading data files via PI.HTTP ( URI1,2,3 aliases ) 

Now as documented on the PI.HTTP page on the wiki, data streams from the web that are not TIFILES files, will be opened in the format specified ( DIS/VAR 80, DIS/FIXED 128, etc...) and the specified record length will be honored. The data will be broken up to fit within the record length limits.  

 

 The default record length (if 0 is specified, or nothing is specified in BASIC) for VARIABLE is 80, and the default for FIXED is 128.

 

CALL TIPI("PI.HTTP://ftp.whtech.com/TIPI/WEATHER")  once agains works when retrieving the weather data.

 

[email protected]

 

Thanks for the update!

 

  • Like 2

Share this post


Link to post
Share on other sites

In an update about a month ago, I added internal support for changing the timezone of the PI via the 4A.  I didn't document this. 

In doing so, I added a default value for the TZ in the tipi configuration ( visible as the file PI.CONFIG ). This default was set for Los Angeles.

 

So if you have already manually changed your timezone through some linux or raspi-config technique, writing anything to PI.CONFIG, such as mapping a DSK drive in the TIPICFG tool, will detect a change to the persistent settings, and reset your timezone to Los Angeles. 

 

You should set your timezone via the 4A. This is now possible and documented here:  https://github.com/jedimatt42/tipi/wiki/PI.CONFIG#timezone-setting  ( and as a bonus, you get a tiny reason to use BASIC )

 

Thanks, @BeeryMiller for reporting the issue.

 

[email protected]

  • Like 5

Share this post


Link to post
Share on other sites

Matt,

 

I've got a TIPI at PI-Version 1.49 on my Geneve.  

 

I typed the following program in from Extended Basic and ran it.  Program executed, and got my prompt.

 

10 OPEN #1:"PI.CONFIG",DISPLAY,VARIABLE 80,OUTPUT
20 TZ$="AMERICA/LOUISVILLE"
30 PRINT #1:"TZ="&TZ$
40 CLOSE #1

 

I then went into TIPICFG and went to upgrade.  The spinner keeps spinning and never stops.

 

Thinking something was an issue with the time, I went into telnet localhost/23 and typed the following:

 

sudo timedatectl set-timezone America/New_York

 

Command executed.  A program I wrote is still reading time properly.  Went back into TIPICFG to try and Upgrade.  Spinner keeps spinning and unable to upgrade to 1.50.

 

Scratching my head, I realized I probably should have mixed case in my TZ$ string above as "America/Louisville".  I made the change, and reran the program.  In this case. the program hangs and does not return to the prompt.

 

Repeated the attempt to Upgrade from TIPICFG, and not able to upgrade.  The spinner keeps spinning.  I ge the Starting to Upgrade, and then the Upgrade Running, and things never stop spinning and the Version does not change.  The TIPI is still useable, just not updating.

 

I know my program differed from your example as you had an Input statement.  Could the lack of the use of the <ENTER> key be the issue if the above program created a problem?  Or is there something else potentially amiss?

 

Beery

Edited by BeeryMiller

Share this post


Link to post
Share on other sites

Well, I was able to upgrade finally.  I forgot to mention in the above post that I had told the TIPICFG program to Reboot which also ended up with the spinner spinning.  I logged into the localhost and told it to do a "sudo reboot now" and gave the login credentials.  I exited the Telnet program giving it enough time to reboot.  I then went back into TIPICFG and then told it to Upgrade and it worked.

 

Right now, not sure what happened.  Just reporting so you know.


Beery

 

Share this post


Link to post
Share on other sites

1st TI BASIC isn't a terminal protocol, so you do not end up with any sort of end of line characters in the variable assigned through the INPUT statement. 

 

2nd, yes as noted twice on the wiki regarding timezones, case matters. The 4A filesystem is case sensitive. Call link names are case sensitive, DSR device and subroutine names are case sensitive. Just about the only thing on a 4A that isn't case sensitive are BASIC keywords.

 

3rd, thanks. I saw a hang after setting the timezone once, but couldn't reproduce it. So I had dismissed it. The tipisuper.service is single threaded and responsible for any requiring elevated permission on the PI. So if setting the timezone is hung, it won't notice the request for upgrade, until the tipisuper.service is restarted. 

 

I will explore making that more robust. Maybe the script crashes when it doesn't have a valid timezone. The first time I did it, I think I misspelled New_York. 

 

[email protected]

Share this post


Link to post
Share on other sites

 

On 2/11/2020 at 10:49 PM, jedimatt42 said:

Update: 1.50 - 2020-02-11

-----------------------------------

I broke Catalog of the TIPI. device a few updates back... so now it is fixed again...

 

 

 

Hi Matt.  I updated to 1.50 today.  The file catalog opens as expected using  "TIPI." and I can drill into the folders without any issue.  I have DSK3. temporarily mapped to "." and that is working so far though I ran into an IO error mid-catalog (just once) that I can not reproduce. I'll come back to it if/when needed.

 

Anyway, here is what I noticed while doing some XB programming this afternoon:

 

  • The volume name reported by the catalog function is "TIPI" whether I open the root or a folder.  In the dev thread you brought up parsing the folder name so I wasn't sure if this was intended or not.  (Edit: When I catalog a mapped drive e.g., DSK3, the volume name is blank, so I'm thinking the volume parsing wasn't part of the 1.50 update/catalog fix.)
  •  
  • When I open the catalog using DSK0. I can catalog the root but not any folders, .e.g., "DSK0.FOLDER." generates an IO Error 02 in XB.  I thought DSK0. worked for folder access before I upgraded but I couldn't find anything definitive on the tipi wiki.
  •  
  • Lastly, I am encountering two non-displayable characters in certain files, most recently with files in the TERM80 ZIP file Greg uploaded to a recent TERM80 topic.  Inspecting the name I find characters 194 and 175; with the high bit masked this would be "B/".   (I didn't check every file in the ZIP). I thought this might be related to long filenames but the files in the ZIP (and native filenames as shown in the web UI) don't exceed 10 characters.  I'm a little lost in how to access or deal with these files on the TI side.

Share this post


Link to post
Share on other sites
On 2/16/2020 at 3:39 PM, InsaneMultitasker said:

 

Hi Matt.  I updated to 1.50 today.  The file catalog opens as expected using  "TIPI." and I can drill into the folders without any issue.  I have DSK3. temporarily mapped to "." and that is working so far though I ran into an IO error mid-catalog (just once) that I can not reproduce. I'll come back to it if/when needed.

 

Anyway, here is what I noticed while doing some XB programming this afternoon:

 

  • The volume name reported by the catalog function is "TIPI" whether I open the root or a folder.  In the dev thread you brought up parsing the folder name so I wasn't sure if this was intended or not.  (Edit: When I catalog a mapped drive e.g., DSK3, the volume name is blank, so I'm thinking the volume parsing wasn't part of the 1.50 update/catalog fix.)
  •  
  • When I open the catalog using DSK0. I can catalog the root but not any folders, .e.g., "DSK0.FOLDER." generates an IO Error 02 in XB.  I thought DSK0. worked for folder access before I upgraded but I couldn't find anything definitive on the tipi wiki.
  •  
  • Lastly, I am encountering two non-displayable characters in certain files, most recently with files in the TERM80 ZIP file Greg uploaded to a recent TERM80 topic.  Inspecting the name I find characters 194 and 175; with the high bit masked this would be "B/".   (I didn't check every file in the ZIP). I thought this might be related to long filenames but the files in the ZIP (and native filenames as shown in the web UI) don't exceed 10 characters.  I'm a little lost in how to access or deal with these files on the TI side.

 

There seem to be bugs... 

 

The goals:

* if you access the `TIPI.` device, the volume name is "TIPI" regardless of what folder you are in. (sounds like it works)

* if you access a mapped `DSK_.`, the volume name is the name of the folder you are mapping to. (bugged)

* All the disks support folder access, even `DSK0.` which is logically equivalent to `TIPI.` . (bugged)

 

Naming:

The name of the file on the linux system is the name presented to the 4A. Not the name inside the header. This is to improve reasoning about what you can see without tools. There are archives that are 4 million years old that have odd names. TI'ers could use control characters on a 4A to enter names, or would sector edit disks to give them odd names, and then expect that data file via code. Unicode naming on linux screws that up sometimes. You simply have to rename the files after they were copied to the TIPI. If they must have grumpy characters in their name, you should probably rename from the 4A, you might have to first rename to something you can type in via the windows share, or linux log in to the PI. I saw ArcadeShopper telling someone how to rename things for TERM80 recently.  

 

If a set of rules existed that were deterministic for what is intended, I would attempt to implement it, to auto-repair names. 

 

[email protected]

 

  • Thanks 1

Share this post


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

 

The name of the file on the linux system is the name presented to the 4A. Not the name inside the header. This is to improve reasoning about what you can see without tools. There are archives that are 4 million years old that have odd names. TI'ers could use control characters on a 4A to enter names, or would sector edit disks to give them odd names, and then expect that data file via code. Unicode naming on linux screws that up sometimes. You simply have to rename the files after they were copied to the TIPI. 

 

This is a good point that I had forgotten / overlooked.  I made the poor assumption this was solely related to TIPI; it is quite possible the original names could be at fault. I'll look more closely at this.  On the plus side, when I selected one of the 'weird' text files in the menu program I was able to open and view it, even if I couldn't type the name myself ;)    Thanks for the explanation and review.

 

  • Like 2

Share this post


Link to post
Share on other sites

i needed to setup my tipi after the move on my Geneve as my ISP changed. 

 

I boot into MDOS 6.5 and go into GPL, select ROMPAGE and if the TIPI is powered up all I get is a blank CYAN screen, never goes into the menu so I cannot run  the TIPI.TIPICFG

 

any clues ?

Share this post


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

i needed to setup my tipi after the move on my Geneve as my ISP changed. 

 

I boot into MDOS 6.5 and go into GPL, select ROMPAGE and if the TIPI is powered up all I get is a blank CYAN screen, never goes into the menu so I cannot run  the TIPI.TIPICFG

 

any clues ?

"If the TIPI is powered up" needs clarification. 

 

The TIPI is the board you put in the peb. It has a power up ROM routine that only interacts with the PI in a non-dependent way. If the PI is not on the power up routine should still complete.

 

If the CPLD on the TIPI is fried it might be holding the bus-tranceiver open, particularly if the cable to the PI is still connected to the +5V pins on the PI. 

 

Hope that isn't the case.

 

[email protected]

Share this post


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

Do you have a CRU conflict?

 

Run my MDOS TIPI program and see what CRU address it identifies.  

 

 

I have verified the TIPI is are to CRU 1800 and no conflicts.  

Share this post


Link to post
Share on other sites

Chris,

 

Matt had suggestions above.  Not sure if you have tried those yet.  Sounds like Matt's ideas should confirm whether you have a hardware issue.

 

My ideas below are more software related trying to chase down the source of the problem if it goes that route.

 

I assume from what you wrote earlier, your TIPI  was previously working with the Geneve?  Are you trying to update the WIFI credentials?

 

Not knowing your GPL environment or potential corruption, you might try "EXEC TIPI.TIPICFG /r"  to see if you can get into it that way.  I am not 100% sure if I have tried that route from the MDOS prompt to confirm it is a working route.

 

The other thing is to see if the TIPI version of MyTerm which I believe you have, works within the MDOS environment. If you are worried about the WIFI password, you should be able to plug a network cable into your PI to your router to bypass the WIFI setup to test that out if your router is nearby.  I would think if you can get there from the MDOS side of things, then it is likely something software on the GPL side that should be easy to fix/replace.

 

The other thing you may do is to plug a monitor/keyboard into your PI and confirm it is booting and not having some kind of issue.

 

Back about 4 weeks ago, I had something odd happen to a PI 4 on a TI sidecar TIPI system where things were fine when I went to bed, then the PI went south the next day.  Not sure what the cause was.  Tried chasing things down, but found it simpler to download a new image to the SD card as things were backed up elsewhere.  

 

Beery

 

 

 

 

 

Share this post


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

Not knowing your GPL environment or potential corruption, you might try "EXEC TIPI.TIPICFG /r"  to see if you can get into it that way.  I am not 100% sure if I have tried that route from the MDOS prompt to confirm it is a working route.

 

I can verify that the 'EXEC TIPI.TIPICFG /r' does not work.  After yanking all the cards and starting over going one by one card added again.  I replaced the GPL version i had that still has the TIBASIC enabled and I was able to get into GPL Rompage mode and perfrom the CALL TIPI to get into the configuration program.

 

I have run the update as I was on a 1.40 i believe.  I stated 'Running....' for about 10 minutes and the 'Running....' has now disappeared and has not refreshed to the latest version.  Not sure if it's just hung.  I have not tried to reboot it yet.

 

When accessing the TIPI:9900 I see:

 

sqlite3.OperationalError

OperationalError: no such table: fileheader

 

 

Edited by Shift838

Share this post


Link to post
Share on other sites

i pulled the SD card and put a new one with the latest image on it.  Re-ran the update and now i'm at 1.50

 

I only had Beery's Telnet client on the SD card so easy recovery

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Good day everyone.  I am trying to use PHD 5020 "Music Maker Demonstration" with the PHM 3020 "Music Maker".  I have tried extracting the .dsk file using Ti99Dir 6.4a (then converting to TIFILES format) and also tried uploading the .dsk using the TIPI (v1.50) web browser (which automatically creates a MUSICDEMO folder and extracts the files) but either way, cannot get the program to read in the song data.  I receive a load error "I/O ERROR 25".  I notice that when I double click on a song file (CHILDREN, CHRISTMAS, CLASSIC#1, CLASSIC#2 or ROUNDS) TiDir acts like it is a directory with a file that has a Ti Name of OK.  How do I convert this (encapsulated?) file to TIFILES format?  What am I doing wrong?

 

image.thumb.png.330c8cf85ccfdf4a8d94bd4da71d3afb.png

 

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