TIPI Usage and Support

[+jedimatt42]

@PeteE provided a patch for the websocket code used when connecting TIPI to emulators. 

 

Update 2.36 - 2022-04-02 

 

Update for emulators works the same as for everyone else: CALL TIPI -> press 'U' when upgrade is offered. It will rebuild the library and update dependencies as necessary.

 

 

[+jmazzy]

My current TIPI software version is fairly old (V2.5, Release Date: 2020-07-12), and I'd like to update it.

 

I'm guessing a fresh rebuild of the SD card by flashing the latest version is the way to go?  If so, what the easiest way I can back up the data currently stored on my TIPI?  

 

I know the newer TIPI versions include a backup tool, but looks like v2.5 came before that functionality was added.

[+9640News]

@jmazzy

 

If you can map a shared drive on a Windows PC, that is probably the easiest.

 

If you go into Windows Explorer, and at the taskbar for the file path you type in   "\\tipi" (do not use quotes), I think you will get a prompt for username/pwd  (tipi/tipi).

 

Then you can navigate to the tipi_disk path and at the upper window menu prompts, you should be able to "Map Network Drive".  Just specify an unused drive letter and click to remember at logon so it will always re-establish.

 

Then, it is just a matter of highlight the files/directories, and copy them to another path.

 

Beery

 

[+mizapf]

6 hours ago, jedimatt42 said:

Update for emulators works the same as for everyone else: CALL TIPI -> press 'U' when upgrade is offered. It will rebuild the library and update dependencies as necessary.

Does this also work for the QEmu Raspberry?

 

Note that the QEmu version does not use Wifi but uses the host interface via NAT. I had a look in the Python code, and it seems to me at first sight that the Wifi connection is set up in TipiSuper.py.

[+arcadeshopper]

1 minute ago, mizapf said:

Does this also work for the QEmu Raspberry?

 

Note that the QEmu version does not use Wifi but uses the host interface via NAT. I had a look in the Python code, and it seems to me at first sight that the Wifi connection is set up in TipiSuper.py.

yes

[+jedimatt42]

For the curious...

 

The python code you are seeing is non-essential. It is a convenience to setup the PI's Wifi via the 4A via PI.CONFIG usually through CALL TIPI, as the TIPI's PI when used with a 4A is meant to never require you to access the Linux shell. 

 

If Ethernet or virtual Ethernet is available the OS will use that instead of the unconfigured WiFi.

 

Use with a 4A emulator requires networking to be setup first or of course or the emulator will not be able to find the PI. 

 

In TIPICFG (the program that gets loaded and run from CALL TIPI) it updates via PI.CONFIG. Saving PI.CONFIG only triggers the actions necessary for the change the user makes. So if you don't modify the WiFi data, the wpa_supplicant.conf will not be modified.

 

 

[+jmazzy]

5 hours ago, 9640News said:

@jmazzy

Then you can navigate to the tipi_disk path and at the upper window menu prompts, you should be able to "Map Network Drive".  Just specify an unused drive letter and click to remember at logon so it will always re-establish.

 

Then, it is just a matter of highlight the files/directories, and copy them to another path.

 

 

I thought I remembered reading in an earlier thread that a simple file/directory copy would do the trick but wasn't entirely sure what needed to be copied.  Thank you for the clarification, Beery.

 

Reflashed the SD card to v2.28 then ran upgrade to v2.36 in TIPICFG.  No problems.

 

I'm using a Mac so I opted to just SFTP into the Pi (with FileZilla) to do the file copying.

 

@jedimatt42 The new updates look great.  I especially liked how quickly and easily v.28 updated to v.36.  Thank you for all of your hard work.

 

[+dhe]

Is anyone running funnelweb from tipi and how did you configure it?

[+arcadeshopper]

Is anyone running funnelweb from tipi and how did you configure it?

Yes auto on and loaded the executable

Sent from my Pixel 6 Pro using Tapatalk

[+dhe]

@arcadeshopper

 

I have Funnelweb saved to tipi.fwb.*

 

The usual path to configure funnelweb is to load CF > Modify Syscon and save it to FW.

 

I first tried changing boot tracking to on, and that didn't work.

  Defining didn't work - Funnelweb menu loads, but, attempting to load the edit fails.

 

To get SCSI working, I used Charlie Goods Article:

     95:06:02. How to install Funnelweb on a hard drive
     by Charles Good, Lima 99/4A User Group

 

It consists of sector editing a number of files to change the hard drive path to: scs1 or hds1 from the hard coded path wds1.

 

  Before I hit the old sector editor, I have a feeling that is not what you are talking about?

 

 

[+arcadeshopper]

Should work fine with DSK1

Sent from my Pixel 6 Pro using Tapatalk

[broettger]

Hi all,

I just installed my recently acquired F18A in my TI 99-4/A.  After that was successfully done, I tried to reconnect my sidecar TIPI and play some Realms of Antiquity.

I encountered some issues and odd behavior that I haven't been able to solve.  I have tried it both with my 32k and SAMS sidecar with the same results.  I am using a Pi Zero W that was hooked up when everything was working last year.   Everything seems to be working correctly on the  PI side of things.

 

When I issue CALL TIPI from TI Basic, the TI  just hangs and the red LED on the TIPI comes on solid.

I also noticed if I try to launch TI Extended Basic that it just hangs on a bluish screen when the TIPI is connected.  If I disconnect just the TIPI, it works as expected.

If I  use DU2K to list devices with the TIPI attached, it lists all of the expected devices (TIPI, DSK0-4, URI1-3, etc.) at the >1100 CRU address.

 

Any suggestions on what the problem could be or any troubleshooting steps to help figure it out?

 

Thanks

 

 

 

 

 

 

[+arcadeshopper]

Double check you plugged the pi in correctly. No photos so we have no suggestions unless you give us a lot more details like how it's hooked up etc. Also you might verify that the pi is booting up correctly with the SD card.

A good way to shotgun is to program another SD card with the image and try that

Sent from my Pixel 6 Pro using Tapatalk

[broettger]

The PI side of things appear to be working fine.  I can see it on my network, etc.

The P Zero W is plugged directly into the TIPI using a female header that was soldered on to the Pi GPIO. 

 

The issue with extended basic hanging on launch happens if the pi is connected to the TIPI or not.

ugly job adding a header to the pi zero.  it worked previously.

Hangs on blank screen when launching TI Extended Basic.

Hangs when CALL TIPI is entered.

DU2k showing devices.

Edited April 3, 2022 by broettger
Added photos

[+jedimatt42]

20 minutes ago, broettger said:

The PI side of things appear to be working fine.  I can see it on my network, etc.

The P Zero W is plugged directly into the TIPI using a female header that was soldered on to the Pi GPIO. 

 

The issue with extended basic hanging on launch happens if the pi is connected to the TIPI or not.

ugly job adding a header to the pi zero.  it worked previously.

Hangs on blank screen when launching TI Extended Basic.

Hangs when CALL TIPI is entered.

DU2k showing devices.

 

If you are off by a row with the pin connections between the TIPI and PI ( which is 100% doable inside the jacket on the TIPI board with those type of connectors ) then it'll just hang...

 

Is the TIPI software actually running on the PI? http://tipi.local:9900 <- does that respond in your web browser?  Hard to test if WiFi isn't setup yet... 

 

XB tries to load DSK1.LOAD, which will cause a TIPI board to try and talk to the tipi.service on the PI. The 4A will block until the PI responds. So you'd get the same behavior if misaligned, not connected or not running the sd image provided on the PI.

 

 

[+arcadeshopper]

Yeah it's hanging because it's not communicating with the pi correctly.. the DSR will sit there and wait until it gets good communications

If you look in the wiki there is troubleshooting steps that you can try, but I would very much take a look at your connector

Sent from my Pixel 6 Pro using Tapatalk

[+9640News]

Very unlikely to be the case, but make sure you have separate power for the 32K/Sams and the TIPI.

 

I thought I had a bad 4A unit as everytime I plugged the sidecar in, I could not get the Title Screen.  The power cable had pulled loose and slid down behind a table and was "out of sight, out of mind".  Took quite a bit of time to figure out that issue.

Beery

 

[+dhe]

3 hours ago, arcadeshopper said:

Should work fine with DSK1

 

Spent some time playing with various options in cf and with call tipi.

 

Does dsk1 and auto only work if the tipi cru is at >1000? I have mine at >1800 -

 FWB will of course load from tipi.fwb.fw , but then fwb itself can't actually load editor or disk review (dr).

[+arcadeshopper]

 
Spent some time playing with various options in cf and with call tipi.
 
Does dsk1 and auto only work if the tipi cru is at >1000? I have mine at >1800 -
 FWB will of course load from tipi.fwb.fw , but then fwb itself can't actually load editor or disk review (dr).

It only works if it is the first controller in the cru

Sent from my Pixel 6 Pro using Tapatalk

[+jedimatt42]

Traditional DSRLNK routines in most assembly programs start by searching expansion card ROMs by enabling the ROM with crubit 0 at crubase >1000, then crubase >1100 (the typical floppy controller), then crubase >1200 and so on until they get past >1F00. 

 

From my documentation: 

 

For maximum TIPI functionality, TIPI works best at >1000 if along side an existing floppy controller or >1100 if alone. This allows the DSK1-3, and DSK. <volumename> feature to work.

At higher CRUBASES >1200 - >1F00, "TIPI." and "PI." devices are available, as well as all other low level functionality such as networking features.

 

Actual DSRs in those ROMs have the opportunity to say they don't want to handle the request.  If TIPI is asked for a device and it is not mapped, or the file isn't found, it rejects the request allowing for the DSRLNK to resume searching the next crubase and therefore some other cards ROMs.  (The ROM itself is not a DSR. A small piece of the ROM in a DSR entry list is the DSR. DSRs are part of Level 3 IO, like the things you can do from BASIC. Level 2 routines are not DSRs, they are basic subprograms in the ROM with a hidden-ish single character name so you aren't likely to hit it from a CALL command, and they do not support rejecting a request, only handling it or failure.)

 

TI and all other floppy controllers that I know of, do not pass the buck, if for instance, there is no disk in the drive or even no drive connected.... they fail the request instead of rejecting it. 

 

Therefore for TIPI to act as DSKx, it must be found before some other DSKx device when a traditional DSRLNK searches in crubase order.  DSRLNK routines are typically embedded in the software, so you can't just replace it to for a legacy program to respect some other order.

 

Force Command's DSRLNK is different, and anything written for it allows specifying the crubase to use instead of searching. DM2K as of a couple years ago also supports specifying the crubase. 

 

-

This is a cool feature of how traditional DSRLNK works, how forward thinking Texas Instruments engineers were, and a first principle of the TIPI design. A big part of why TIPI was designed for Level 3 IO first. 

 

 

[+dhe]

  In my case, I'm going to see if I can't do some type of sed on all the files in tipi_disk/fwb and search for scs1.fwb and change to tipi.fwb - if it works, it will be easier then sector editing again.

 

  If might be worth greying out the options of dsk1-3 if call tipi see's that the cru is not >1000.

 

[broettger]

Ok.  I have resoldered pins on my pi zero and even tried hooking up a Pi 3B with the same results.  Here a a few photos showing that the web and samba interfaces are showing up on my network and the updated wiring.   
 

I have also tried multiple SD cards with the same results.  
 

 

[+arcadeshopper]

https://github.com/jedimatt42/tipi/wiki/TIPI-to-PI-Wiring

Ensure you have it wired correctly... It's easy to flip especially when dealing with the back side of the zero

Sent from my Pixel 6 Pro using Tapatalk

[broettger]

6 minutes ago, arcadeshopper said:

https://github.com/jedimatt42/tipi/wiki/TIPI-to-PI-Wiring

Ensure you have it wired correctly... It's easy to flip especially when dealing with the back side of the zero

Sent from my Pixel 6 Pro using Tapatalk
 

I have checked and rechecked my wiring about a dozen times today.   On both the pi zero and 3B.  
 

here is a photo of the 3B.  

[+jedimatt42]

Looks correct..

 

from http://tipi.local:9900/ the MyTipi menu has a view tipi.log and view daemon.log that might show something... 

 

typically the tipi.log will show:

 

2022-04-03 17:47:17,622 TipiService : INFO     physical mode enabled
2022-04-03 17:47:17,634 TipiService : INFO     TIPI Ready

when it is happily waiting for requests from the 4A.