TIPI Usage and Support

[broettger]

Just now, jedimatt42 said:

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.

My tipi.log always shows a file not found error.  If I create a file, it is removed on reboot and not recreated.

I have attached the daemon.log, but I don't really see any clues in it.

 

Any suggestions would be welcome.

tipi.daemon.log

[+jedimatt42]

the web-ui failure is due to the tipi.service never actually starting, so no /var/log/tipi/tipi.log file is created. Creates a bunch of noise... 

 

downloading on a bigger screen to see what else I see... 

[+jedimatt42]

Apr  3 17:25:54 tipi systemd-fsck[183]: fsck.fat 4.1 (2017-01-24)
Apr  3 17:25:54 tipi systemd-fsck[183]: 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Apr  3 17:25:54 tipi systemd-fsck[183]:  Automatically removing dirty bit.
Apr  3 17:25:54 tipi systemd-fsck[183]: Performing changes.
Apr  3 17:25:54 tipi systemd-fsck[183]: /dev/mmcblk0p1: 288 files, 98482/516190 clusters

Looks like after the sd card was flashed, it wasn't unmounted from windows or something... but there aren't tipi specifics in the /boot partition... so probably not it...

 

Apr  3 17:26:11 tipi nmbd[440]: mkdir failed on directory /var/log/samba/cores: No such file or directory
Apr  3 17:26:11 tipi nmbd[440]: Failed to create /var/log/samba/cores for user 0 with mode 0700
Apr  3 17:26:11 tipi nmbd[440]: Unable to setup corepath for nmbd: No such file or directory
Apr  3 17:26:11 tipi nmbd[440]: [2022/04/03 17:26:11.111636,  0] ../lib/util/debug.c:1063(reopen_logs_internal)
Apr  3 17:26:11 tipi nmbd[440]:   Unable to open new log file '/var/log/samba/log.': No such file or directory
Apr  3 17:26:11 tipi nmbd[440]: [2022/04/03 17:26:11.152950,  0] ../lib/util/debug.c:1063(reopen_logs_internal)
Apr  3 17:26:11 tipi nmbd[440]:   Unable to open new log file '/var/log/samba/log.nmbd': No such file or directory
Apr  3 17:26:11 tipi systemd[1]: Started Samba NMB Daemon.
Apr  3 17:26:11 tipi systemd[1]: Starting Samba SMB Daemon...
Apr  3 17:26:12 tipi dhcpcd[437]: wlan0: no IPv6 Routers available
Apr  3 17:26:17 tipi smbd[496]: [2022/04/03 17:26:17.049565,  0] ../lib/util/debug.c:1063(reopen_logs_internal)
Apr  3 17:26:17 tipi smbd[496]:   Unable to open new log file '/var/log/samba/log.smbd': No such file or directory
Apr  3 17:26:17 tipi smbd[496]: [2022/04/03 17:26:17.098057,  0] ../lib/util/debug.c:1063(reopen_logs_internal)
Apr  3 17:26:17 tipi smbd[496]:   Unable to open new log file '/var/log/samba/log.smbd': No such file or directory
Apr  3 17:26:17 tipi smbd[496]: [2022/04/03 17:26:17.109665,  0] ../lib/util/debug.c:1063(reopen_logs_internal)
Apr  3 17:26:17 tipi smbd[496]:   Unable to open new log file '/var/log/samba/log.smbd': No such file or directory

This smells bad, but it happens for all of us... so not really a sign of sd corruption... 

 

Apr  3 17:30:08 tipi systemd[1]: Stopping TI-99/4A DSR Service...
Apr  3 17:30:08 tipi systemd[1]: tipi.service: Main process exited, code=killed, status=15/TERM
Apr  3 17:30:08 tipi systemd[1]: tipi.service: Succeeded.
Apr  3 17:30:08 tipi systemd[1]: Stopped TI-99/4A DSR Service.
Apr  3 17:30:08 tipi systemd[1]: Started TI-99/4A DSR Service.
Apr  3 17:30:09 tipi tipi.sh[527]: checking for operation mode...

This happens over and over again with no further info from tipi.sh so the service isn't starting at all. Like the python setup is totally trash.  At first I suspected the reset wire being bad, but IDK there is a >30 second gap between some, and only about 4 seconds between others. 

 

Best I could recommend is a fresh SD Card flashing. https://jedimatt42.com/downloads/tipi-sdimage-buster-2.28.zip

 

 

[broettger]

2 hours ago, jedimatt42 said:

Best I could recommend is a fresh SD Card flashing. https://jedimatt42.com/downloads/tipi-sdimage-buster-2.28.zip

I have tried downloading the zip file again.  I also copied to 2 different SD cards.  The first using BalenaEtcher and the second using the Raspberry Pi Imager.

Same results as before with both SD cards.

I then ran the update.sh script and it updated to 2.36.  I then ran the post-upgrade.sh (entering the password for what seemed like 100 times.) and rebooted the Pi.

Same results - locks up when I CALL TIPI from TI Basic.  I have attached the new daemon.log from my latest attempt.

tipi-daemon.log

Edited April 4, 2022 by broettger

[+jedimatt42]

8 hours ago, broettger said:

I have tried downloading the zip file again.  I also copied to 2 different SD cards.  The first using BalenaEtcher and the second using the Raspberry Pi Imager.

Same results as before with both SD cards.

I then ran the update.sh script and it updated to 2.36.  I then ran the post-upgrade.sh (entering the password for what seemed like 100 times.) and rebooted the Pi.

Same results - locks up when I CALL TIPI from TI Basic.  I have attached the new daemon.log from my latest attempt.

tipi-daemon.log 21.55 kB · 0 downloads

It should work without running upgrade scripts. Upgrade runs post-upgrade as the correct user. If you had to enter passwords during post-upgrade I have no idea if file ownership will be correct.

 

Start over, do not manually run scripts to solve this problem. 

 

Your new log shows: 

Apr  3 22:09:23 tipi systemd[1]: Stopping TI-99/4A DSR Service...
Apr  3 22:09:23 tipi systemd[1]: tipi.service: Main process exited, code=killed, status=15/TERM
Apr  3 22:09:23 tipi systemd[1]: tipi.service: Succeeded.
Apr  3 22:09:23 tipi systemd[1]: Stopped TI-99/4A DSR Service.
Apr  3 22:09:23 tipi systemd[1]: Started TI-99/4A DSR Service.
Apr  3 22:09:23 tipi tipi.sh[591]: checking for operation mode...
Apr  3 22:09:23 tipi tipi.sh[591]: TIPI_SIG_DELAY=0

This sequence shows up a couple times. That last line is one more output than happened before. There might be an actual tipi.log now

 

I would reflash. Ssh into the PI as user 'tipi', and then :

 

sudo systemctl stop tipi.watchdog.service

sudo systemctl stop tipi.service

 

Then manually run the TIPI service:

 

/home/tipi/tipi/services/tipi.sh

 

Output for the service startup will then go to the shell display. If it gets far enough output will begin going to /var/log/tipi/tipi.log

 

If the software is working correctly, it will not return to a prompt. So you'll need to use the webui or a second ssh session to look at the tipi.log

 

 

[+jedimatt42]

tipiwatchdog.service is responsible for killing tipi.service when the 4A run the power on reset code. tipi.service should never exist itself.

 

I don't see logs from the watchdog like here https://github.com/jedimatt42/tipi/blob/1d727e92e0f4fbbd2edcdd711f9cdce184733eba/services/TipiWatchDogService.py#L33

 

But it did look like systemd is killing it. I don't know why that would be. My previous instructions seem like the best course to learn more. 

 

I am curious where the TIPI board came from? It looks like a 2017 models... Is it second hand or just old? Or just independently made? No wrong answers... Edit: reading more carefully, just old. 

 

Has the +5v side of the raspberry pi ever been in contact with the cabling to the TIPI? 

 

Edit: I see you have power to the memory board, is the power selection on the board correct? Trying to imagine why it would stop after installing an F18A...

[broettger]

2 hours ago, jedimatt42 said:

tipiwatchdog.service is responsible for killing tipi.service when the 4A run the power on reset code. tipi.service should never exist itself.

 

I don't see logs from the watchdog like here https://github.com/jedimatt42/tipi/blob/1d727e92e0f4fbbd2edcdd711f9cdce184733eba/services/TipiWatchDogService.py#L33

 

But it did look like systemd is killing it. I don't know why that would be. My previous instructions seem like the best course to learn more. 

 

I am curious where the TIPI board came from? It looks like a 2017 models... Is it second hand or just old? Or just independently made? No wrong answers... Edit: reading more carefully, just old. 

 

Has the +5v side of the raspberry pi ever been in contact with the cabling to the TIPI? 

 

Edit: I see you have power to the memory board, is the power selection on the board correct? Trying to imagine why it would stop after installing an F18A...

Edit - I don't think the wiring was ever hooked up wrong so that the +5v would go to the TIPI.  That is on the other end of the GPIO pins. 

Not a chance it could happen with my Pi zero, it only has the pin headers for pins 31-40 soldered in.

If it was accidentally done when testing with the Pi 3, is there any way to verify and/or fix the situation?

 

Another fresh flash of the SD card.   I followed the steps you mentioned.  

Photo shows the results.  No watchdog loaded.

I also attached the new daemon.log

 

 

tipi-daemon.log

Edited April 4, 2022 by broettger
add log file and question about +5v.

[HOME AUTOMATION]

1 hour ago, broettger said:

I don't think the wiring was ever hooked up wrong so that the +5v would go to the TIPI.

I dunno...

[broettger]

13 minutes ago, HOME AUTOMATION said:

I dunno...

point well taken.   but that solder blob is on a ground pin.  

Let's assume that my poor soldering job somehow managed to send the +5v to the cpld on the TIPI. 

Is there any way to diagnose and/or repair the TIPI?

Edited April 4, 2022 by broettger

[twoodland]

Don't know if this helps but I have a F18 (Newer one built by Hans Huebner), RPi3B+, Speech Synth, SAMS Sidecar, and TIPI Sidecar.  This configuration works for me.  Have you tested the RAM?  I had similar issues which turned out to be defective soldering of the SAMS RAM Chip.

 

 

 

 

[broettger]

1 minute ago, twoodland said:

Don't know if this helps but I have a F18 (Newer one built by Hans Huebner), RPi3B+, Speech Synth, SAMS Sidecar, and TIPI Sidecar.  This configuration works for me.  Have you tested the RAM?  I had similar issues which turned out to be defective soldering of the SAMS RAM Chip.

Thanks for the suggestion.  I have tried it both with my 32K sidecar and SAMS sidecar.  Both of them do pass their respective memory tests when I ran them.

[+arcadeshopper]

point well taken. [emoji4]  but that solder blob is on a ground pin.  
Let's assume that my poor soldering job somehow managed to send the +5v to the cpld on the TIPI. 
Is there any way to diagnose and/or repair the TIPI?

Troubleshooting steps are in the wiki. You can get a mini memory cartridge and do some testing to see if there's problems on one side or the other. Usually the CPLD just doesn't work if it got five volts. Repair is to replace the CPLD which is interesting because they are unobtainable at this point due to parts shortage

Sent from my Pixel 6 Pro using Tapatalk

[broettger]

22 minutes ago, arcadeshopper said:

Troubleshooting steps are in the wiki. You can get a mini memory cartridge and do some testing to see if there's problems on one side or the other. Usually the CPLD just doesn't work if it got five volts. Repair is to replace the CPLD which is interesting because they are unobtainable at this point due to parts shortage

Sent from my Pixel 6 Pro using Tapatalk
 

I went through the those steps (using easy bug) already and everything appeared to be working.  I could toggle the led with the c1100 command.   
 

I was a bit confused with regards to to m4000 command and what I should be seeing. 

When I enter M4000 and hit enter, it comes back with 00 for as long as I keep hitting enter.

When I enter a value after M5FFF (such as 55 or AA) it is always zero when I check it again.

 

Edited April 4, 2022 by broettger
easy bug details

[+dhe]

22 hours ago, jedimatt42 said:

This is a cool feature of how traditional DSRLNK works

Two other kewl DSR features,

  1) When I was using TI-Writer heavily for word-processing, I was able to insert the date with a LF command from I think it was a triple tech.

  2) The McGovern's documented it, but it was also very cool that TI shipped their RS232's with a ROM based DSR, and where able, based upon the CRU address able to map, the first card to rs232(1/2) and the second card would answer rs232(3/4).

 

 

[+jedimatt42]

42 minutes ago, broettger said:

I went through the those steps (using easy bug) already and everything appeared to be working.  I could toggle the led with the c1100 command.   
 

I was a bit confused with regards to to m4000 command and what I should be seeing. 

When I enter M4000 and hit enter, it comes back with 00 for as long as I keep hitting enter.

When I enter a value after M5FFF (such as 55 or AA) it is always zero when I check it again.

 

 

m4000 gets to the ROM address on the TIPI board, and m5FFF is one of the registers that is writable by the 4A... they are only in the memory map if crubit 1100 is set, c1100 is 1

[+jedimatt42]

3 hours ago, broettger said:

point well taken.   but that solder blob is on a ground pin.  

Let's assume that my poor soldering job somehow managed to send the +5v to the cpld on the TIPI. 

Is there any way to diagnose and/or repair the TIPI?

+5v is only on one of those first 6 pins on the Raspberry PI... so I doubt that is your problem... diagnosing a fried CPLD is only certain by removing the CPLD and putting a fresh one on. But I doubt that is your problem.

[broettger]

2 minutes ago, jedimatt42 said:

 

m4000 gets to the ROM address on the TIPI board, and m5FFF is one of the registers that is writable by the 4A... they are only in the memory map if crubit 1100 is set, c1100 is 1

Hmmm.  That makes sense.   I am new to using easy bug.   Here are the results.  

[+jedimatt42]

so that says all the ROM bus vs register selection, and the registers in the CPLD are working... 

[+jedimatt42]

There is some stuff that can be done from the PI + EasyBug to test reading that 5fff address you set in easy bug from the PI.. I don't recall if I've ever written up any instructions on that... I'll try and put a python script together this evening to add to our diagnostic abilities.

[+dhe]

I was looking at this section of the wiki:

   https://github.com/jedimatt42/tipi/wiki/File-name-rules

 

The complexity of what can be in a filename ;:- seems somewhat daunting given the file might show up on a ti, the pi-os or a samba/cifs share.

 

Last night I unpacked a funnelweb 4.4 disk and used the web file upload. That worked, but later I found some of the files where corrupt and tried to delete them, the web interface was able to delete all but one. For that I had to go in to tipi_disk and rid myself of the file manually.

 

Can you add some rules of thumb to the above wiki section on filenames? Characters that seem ok, and those that should be avoided?

 

 

[+jedimatt42]

1 hour ago, dhe said:

I was looking at this section of the wiki:

   https://github.com/jedimatt42/tipi/wiki/File-name-rules

 

The complexity of what can be in a filename ;:- seems somewhat daunting given the file might show up on a ti, the pi-os or a samba/cifs share.

 

Last night I unpacked a funnelweb 4.4 disk and used the web file upload. That worked, but later I found some of the files where corrupt and tried to delete them, the web interface was able to delete all but one. For that I had to go in to tipi_disk and rid myself of the file manually.

 

Can you add some rules of thumb to the above wiki section on filenames? Characters that seem ok, and those that should be avoided?

 

 

 

The short answer to your question is "I won't"

 

Texas Instruments provided some really good guidance a long time ago... I think it was in an addendum for the extended basic manual... to paraphrase, if you want to share files, you and your friends should both be able to type their names. The extension to this, is use names that work well on all the systems you might transfer that TIFILES file to, where you on windows are a friend of you on a TI.

 

We already know that the 4A just can't have '.' or ' ' in a file name. Any of those control characters some vendor might have put in the TI file to obfuscate or break a copy program can be handled by the linux filesystem. (Maybe you get into a tricky state if the ascii code for escape is embedded in a TI file name) -- Samba might rename the thing, but I have to lean on the community to tell me what doesn't work, specifically, because theoretically they'll all work. If you use the windows side to put spaces in the name then you have an alternative name provided by TIPI. It should treat it like a long name and give you a BLAH`23F kind of name format... 

 

My preferred approach to this is have you all share with me the DSK file that has the TI file names that cause trouble, and I fix the TIPI software to not have trouble with them.  I'd rather do that than suggest that some rails should be used that we know various legacy programs will not comply with. There is some replication of code between the tipi.service and the tipiweb.service and then the tipiweb.service has to deal with shipping names to your browser and back. Plenty of room for me to have a mistake that I can fix.

[+jedimatt42]

9 hours ago, jedimatt42 said:

There is some stuff that can be done from the PI + EasyBug to test reading that 5fff address you set in easy bug from the PI.. I don't recall if I've ever written up any instructions on that... I'll try and put a python script together this evening to add to our diagnostic abilities.

@broettger I have added a TipiDebug.py tool to github with details on my tipi.wiki for how to fetch and run it. It will instruct you to stop some of the services, and run this script while in Minimemory EasyBug, and you can then observe values the PI has written into the TIPI registers, and values you have the 4A write into the other TIPI registers...

 

See: https://github.com/jedimatt42/tipi/wiki/LOW_LEVEL_TESTING

 

If that simply shows that the PI <-> TIPI communication doesn't work, then we can talk about repair service over a private message. 

[+jedimatt42]

14 hours ago, jedimatt42 said:

@broettger I have added a TipiDebug.py tool to github with details on my tipi.wiki for how to fetch and run it. It will instruct you to stop some of the services, and run this script while in Minimemory EasyBug, and you can then observe values the PI has written into the TIPI registers, and values you have the 4A write into the other TIPI registers...

 

See: https://github.com/jedimatt42/tipi/wiki/LOW_LEVEL_TESTING

 

If that simply shows that the PI <-> TIPI communication doesn't work, then we can talk about repair service over a private message. 

 

Oops, that doc needed an update... the TipiDebug.py uses a slow python sleep of 10 milliseconds, and I meant to delete the comment (at the very end) about TIPI_SIG_DELAY as it does not apply to this test. 

[broettger]

20 hours ago, jedimatt42 said:

@broettger I have added a TipiDebug.py tool to github with details on my tipi.wiki for how to fetch and run it. It will instruct you to stop some of the services, and run this script while in Minimemory EasyBug, and you can then observe values the PI has written into the TIPI registers, and values you have the 4A write into the other TIPI registers...

 

See: https://github.com/jedimatt42/tipi/wiki/LOW_LEVEL_TESTING

 

If that simply shows that the PI <-> TIPI communication doesn't work, then we can talk about repair service over a private message. 

It looks like the communication is not working. 

The values for M5FF9 and M5FFB in Easy Bug did not match the TIPI was writing.

The reads on the TIPI side were always 00, even after setting the values in Easy Bug.

 

I tried this with both my Pi Zero and Pi 3B.

[XLERB]

A little off of recent topics, but I have to say that one thoughtful little feature of the TIPI software that I really appreciate is the automatic extraction of .dsk files into a directory on the TIPI as soon as the file is dropped there. The first time I watched that automagically happening, I was blown away. Amazing. Well done.