Jump to content
IGNORED

TIPI Usage and Support


jedimatt42

Recommended Posts

7 minutes ago, pcoderdude14 said:

Well...it seems that my PI  is working fine.   I was able to "login" to the Raspberry PI OS "Lite" version (without the HDMI cutting out, like it does in the TIPI 2.5 version) and I was able to (then)  hook up a keyboard and change the "PI" password.  So, I don't know  what  else to try..I did have problems with SSH and "login" to the PI.  I used an  ethernet cable, and, (checking with the program "ifconfig" ) saw  that the PI had  generated a IP-Address.  All of this  I COULD NOT do with the TIPI 2.5 version.  I don't have access to my TIPI and TI99 console right now, but, I  am guessing that the RasPIOS  "Lite" would  make little difference  "hook up" to my Ti99/TIPI!?!  Any other ideas?  I think I've tried just  about everything with TIPI 2.5

Thanks for satisfying that.  This weekend, I'll move my PI close enough to a TV to try the HDMI connection. And I will try a fresh TIPI 2.5 install. 

 

Link to comment
Share on other sites

4 minutes ago, jedimatt42 said:

t traverses the linked list in each sector, and when it gets to an end of sector 0xff marker, it continues to the next sector, and then processes the linked list there

Thanks, that makes sense, and seems to agree with what I was anticipating.   I am still not 100% certain why some DSRs use the EOF byte in the FDR versus just calculating it from the final record.  That's what I want to look into further.  Thanks for looking into this.

  • Like 1
Link to comment
Share on other sites

16 hours ago, pcoderdude14 said:

Well...it seems that my PI  is working fine.   I was able to "login" to the Raspberry PI OS "Lite" version (without the HDMI cutting out, like it does in the TIPI 2.5 version) and I was able to (then)  hook up a keyboard and change the "PI" password.  So, I don't know  what  else to try..I did have problems with SSH and "login" to the PI.  I used an  ethernet cable, and, (checking with the program "ifconfig" ) saw  that the PI had  generated a IP-Address.  All of this  I COULD NOT do with the TIPI 2.5 version.  I don't have access to my TIPI and TI99 console right now, but, I  am guessing that the RasPIOS  "Lite" would  make little difference  "hook up" to my Ti99/TIPI!?!  Any other ideas?  I think I've tried just  about everything with TIPI 2.5

I figured out the  "raspi-config" setting for getting SSH.  Now,  "login" to PI without any problems. 

  • Like 1
Link to comment
Share on other sites

UPDATE 2.9 - 2020-11-03

 

Fix for off by one on end of file marker in tipi generated FIADs for VARIABLE record files. 

Fix for non-ascii characters in os native files. 

 

-- like I said earlier, writing the fix-your-files script will take a bit longer... but this stops propagating the mistake. 

  • Like 4
Link to comment
Share on other sites

Well...something else  has been found!  With  the TIPI 2.5 , ...  I ran the "boot" as  always; and, as always, the screen "blanked".  But,  I wasn't  entirely

sure that the OS wasn't still "working".  So, remembering that old "trick" that  seems to  work with every OS, I pressed "CTRL" "ALT" and "DEL" at the same time

(in other  words, a "software" reboot)...and,  sure enough, the OS rebooted!!!  So,  when I get back  to my TI99console/TIPI , I will try using SSH to "login" to the

OS and see what  I can do,  thru  the "TIPI side".  Thanks goes out to DGrissom for the helpful emails, and, setting up "PI" to work with "wireless"...thanks again

Dave. ?

Link to comment
Share on other sites

UPDATE 2.10 - 2020-11-06

 

- Repairs mixed up Variable record FIADs during TIPI Update.

 

Finds only the Variable record files that are wrong in the way TIPI makes them wrong, and corrects them. 

I'll add manual execution instructions to the tipi wiki, but you shouldn't need that unless you are restoring an old backup of FIADs. 

  • Like 2
Link to comment
Share on other sites

I prefer to keep my ti files on a external usb drive (Formatted NTFS), so i made a change to /etc/rc.local to auto-mount my drive at pi boot (drive gets mounted to /home/tipi/tipi_disk/USB/).

To accomplish this, i connected a monitor and keyboard to my Pi and did the following:

sudo apt-get install ntfs-3g
cd ~
cd tipi_disk
mkdir USB
cd /
cd etc
nano rc.local

Then i edited the file like this (delete or comment out the sample command [which displays ip address] with # at start of each line):

mount -o uid=0.gid=0 /dev/sda1 /home/tipi/tipi_disk/USB
exit 0

I then did:
 

ctrl+o [save]
ctrl+x [exit]
sudo chmod a+x rc.local
sudo poweroff

Now i can store all my TI files and programs on a external USB drive without overworking the TIPI sd card.

I have been running with this setup since TIPI  2.8 .


In regards to the the TIPI 2.10 update, will the update search files on this drive or does it only check the sd card?

  • Thanks 1
Link to comment
Share on other sites

11 hours ago, jedimatt42 said:

UPDATE 2.10 - 2020-11-06

 

- Repairs mixed up Variable record FIADs during TIPI Update.

 

Finds only the Variable record files that are wrong in the way TIPI makes them wrong, and corrects them. 

I'll add manual execution instructions to the tipi wiki, but you shouldn't need that unless you are restoring an old backup of FIADs. 

On my TIPI/32K my Version would not update to 2.10.   If forced an update with instructions from a July post.

This is the first time my unit has not detected an update from CALL TIPI?

Curious?

 

David G 

 

UPDATE:  I found my FinalGROM99 needed reseating.  May have affected the update?

Edited by dgrissom
Found potential problem after the fact....
  • Like 1
Link to comment
Share on other sites

20 minutes ago, dgrissom said:

On my TIPI/32K my Version would not update to 2.10.   If forced an update with instructions from a July post.

This is the first time my unit has not detected an update from CALL TIPI?

Curious?

 

David G 

 

UPDATE:  I found my FinalGROM99 needed reseating.  May have affected the update?

 

Probably a bug in my version string comparison... I'm used to upgrading from an upgraded state, so I didn't think enough of this.

 

in 'CALL TIPI' / TIPICFG, press FCTN-U to trigger an upgrade even if it isn't detected.

 

This just worked for Arcadeshopper.

 

(I'll take some time off from FTP this afternoon, and fix TIPICFG)

  • Like 1
Link to comment
Share on other sites

I was able to update from 2.8 to 2.11 with the FCTN-U keypress.  After rebooting TIPICFG, I am not getting the message the TIPI is up to date.  Just a FYI in case there is something else going on as well that needs to be addressed.
 
Beery
You only get that message after an update is completed otherwise it's just blank

Sent from my LM-V600 using Tapatalk

Link to comment
Share on other sites

After doing the upgrade, I tried running the fix script manually because I was worried I may have rebooted the tipi too quickly afterwards.  It shows this error:

(ENV) tipi@tipi:~/tipi/services $ python -m ti_files.fix_dv_fiads
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/tipi/tipi/services/ti_files/fix_dv_fiads.py", line 39, in <module>
    if is_broken(data):
  File "/home/tipi/tipi/services/ti_files/fix_dv_fiads.py", line 20, in is_broken
    return data[ridx-1] == 0xff and data[ridx] == 0x00
IndexError: bytearray index out of range

 

Link to comment
Share on other sites

36 minutes ago, webdeck said:

After doing the upgrade, I tried running the fix script manually because I was worried I may have rebooted the tipi too quickly afterwards.  It shows this error:


(ENV) tipi@tipi:~/tipi/services $ python -m ti_files.fix_dv_fiads
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/tipi/tipi/services/ti_files/fix_dv_fiads.py", line 39, in <module>
    if is_broken(data):
  File "/home/tipi/tipi/services/ti_files/fix_dv_fiads.py", line 20, in is_broken
    return data[ridx-1] == 0xff and data[ridx] == 0x00
IndexError: bytearray index out of range

 

1st, do you mean rebooting the PI? Why would you do that? The update process restarts all the services. 

 

2nd, looks like you have an edge case on record size I didn't consider or some foreign or empty files. I will have to update the script, and do more testing I guess. It will have done no harm, but won't have fixed everything. Good find.

Link to comment
Share on other sites

9 minutes ago, jedimatt42 said:

1st, do you mean rebooting the PI? Why would you do that? The update process restarts all the services. 

 

2nd, looks like you have an edge case on record size I didn't consider or some foreign or empty files. I will have to update the script, and do more testing I guess. It will have done no harm, but won't have fixed everything. Good find.

Yeah, I wasn't thinking and went and rebooted it for no good reason.  But hey, it found the bug at least.

 

Yes, I have empty files, so that's probably the bug.

Link to comment
Share on other sites

Update 2.12 - 2020-11-08

 

- FIAD fixer take 2 - (still) happens synchronously during update

 

If you are curious, it logs to the /var/log/daemon.log - it will list each file it is fixing.

Most TIers will see nothing fixed cause they have no problems, or were completely fixed yesterday.

 

I do see evidence that bad files have leaked out into community distributions. File copying from TIPI to disks, or DSK images with anything will preserve the error. This is not a problem unless they are intended to be consumed off TIPI by programs that care. File copying back to TIPI also preserves the error.

 

If these leaked malformed files haven't been problematic already, they probably never will be.

Link to comment
Share on other sites

@pcoderdude14 - I hooked my TIPI PI up to a display today, and only see a little trouble, easily fixed in raspi-config

 

The default display mode is 'monitor default' so it detects what the monitor can do, and tries to do that. On my monitor, this partially fails... ( I see this sometimes on my MiSTer as well ) - My symptom is simply the screen image is cut off a bit on 3 of four sides. Going into raspi-config, under the advanced options, and selecting a fixed display mode seems to fix that for me. I've tried 640x480, and 1920x1080 - after that, it doesn't do screen detection, and just uses what it was told, and my issues go away.

 

This isn't exactly your symptom, but it does indicate there can be display specific quirks, that can be cured by using raspi-config -- there is also a screen blanking feature that can be disabled in there.

 

( I've been exploring this on the PI 3B )

Link to comment
Share on other sites

15 minutes ago, acadiel said:

I need to burn a new image today.  I was like .7 versions behind and went to update, and it tried all day.  Thanks for the heads up - I’ll just set it up again. 

Well, 2.12 - 0.7 is 2.5, the latest image that I've produced. 

 

So you'll just be back were you started. 

 

If people have trouble with updates, try an ethernet cable. 

  • Like 2
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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