TIPI Usage and Support

[dgrissom]

40 minutes ago, Keneg said:

The mouse now just goes to the right and stays there unusable.  I think this happened when I updated to version 2.8.  It used to work.  I have tried it with two USB mice.  Has anyone else reported this issue?

Which software?  Let me know and I'll try to test it.

 

I tested mine with Stuart's browser and TI Artist and it seems to work fine.

 

My setup is a TIPI/32k with Pi Zero W.  My mouse is a cheap older Best Buy wireless.  (and TIPI version 2.8).

 

DG

Edited October 16, 2020 by dgrissom
forgot to confirm TIPI version.

[Keneg]

Stuart’s browser.  I am at Version 2.8 Also.  I thought it might have been due to the failing RPI0W, so I tested again today after swapping in a RPI3B.  Still does the same.  Is there a way to reload the mouse driver?

[dgrissom]

I don't know.  Matt or Greg may have the answer's.

 

You may want to get a load new 2.5 image on a test SD.  Load Stuart's browser and test? 

 

[+arcadeshopper]

2 hours ago, Keneg said:

The mouse now just goes to the right and stays there unusable.  I think this happened when I updated to version 2.8.  It used to work.  I have tried it with two USB mice.  Has anyone else reported this issue?

I'm running 2.8 works fine.. with the mouse 

[+arcadeshopper]

1 hour ago, Keneg said:

Stuart’s browser.  I am at Version 2.8 Also.  I thought it might have been due to the failing RPI0W, so I tested again today after swapping in a RPI3B.  Still does the same.  Is there a way to reload the mouse driver?

you might have a corrupt card might try a reimage..   have you tried another mouse? 

[GDMike]

30 minutes ago, arcadeshopper said:

I'm running 2.8 works fine.. with the mouse 

Mee too

[Keneg]

Tried another mouse.  Will back up added files and re-image.

[Keneg]

Ok, took a while, but I am back up and running.  This mouse now works fine.  Maybe whatever went wrong with the RPI0W corrupted a file.

[dgrissom]

1 hour ago, Keneg said:

Ok, took a while, but I am back up and running.  This mouse now works fine.  Maybe whatever went wrong with the RPI0W corrupted a file.

That's great... I think we have all been there for one reason or another.  ?

 

 

[Keneg]

On the positive side, it had been too long since I did a backup.

[pcoderdude14]

Hey there, All!  ?

 

Which version of "Buster(Raspian)" was TIPI version 2.5 written on?

  I'm still having problems getting my TIPI version 2.5 to "view" on my Raspberry PI".  Tested same "PI" with different sdcard with "TIPI Ver. 1.43" and no problem.

Just  having problems with 2.5.  I also  redownloaded sdimage from Matt's TIPI Downloads site.  Flashed and tried it...same problem.

Any thoughts?

 

Jt

[GDMike]

I didn't have issues. Rpi B+ and some ole SD card once I figured out I wasn't formatting correctly

Edited November 2, 2020 by GDMike

[+arcadeshopper]

Hey there, All!  [emoji846]
 
Which version of "Buster(Raspian)" was TIPI version 2.5 written on?
  I'm still having problems getting my TIPI version 2.5 to "view" on my Raspberry PI".  Tested same "PI" with different sdcard with "TIPI Ver. 1.43" and no problem.
Just  having problems with 2.5.  I also  redownloaded sdimage from Matt's TIPI Downloads site.  Flashed and tried it...same problem.
Any thoughts?
 
Jt

What do you mean view

Sent from my LM-V600 using Tapatalk

[pcoderdude14]

16 hours ago, arcadeshopper said:

What do you mean view

Sent from my LM-V600 using Tapatalk
 

I mean the display for the RasPI just "blanks".  I see that the "disk" LED (green) on the RasPI is still moving,  when this  happens. And,  I am able to use the TI99 console to "CALL TIPI".  But, when I try "H"(Halt)  on console,  the Raspi doesn't do anything.  Also , I cannot "pull" a IP address off the Raspi,  from TI99 console, either.

 

Jt

[pcoderdude14]

Hey Greg...do  you know what version of "Buster " that Matt used ,  for TIPI ver. 2.5?  I  want to try and put a "GUI" on my Raspi, with TIPI software on it,  too

 

[+arcadeshopper]

I mean the display for the RasPI just "blanks".  I see that the "disk" LED (green) on the RasPI is still moving,  when this  happens. And,  I am able to use the TI99 console to "CALL TIPI".  But, when I try "H"(Halt)  on console,  the Raspi doesn't do anything.  Also , I cannot "pull" a IP address off the Raspi,  from TI99 console, either.
 
Jt

Hdmi interface or ?

Sent from my LM-V600 using Tapatalk

[pcoderdude14]

16 hours ago, arcadeshopper said:

Hdmi interface or ?

Sent from my LM-V600 using Tapatalk
 

Yep...HDMI.  Also,...I am using "analog" sound, not thru HDMI

 

Jt

[+jedimatt42]

14 hours ago, pcoderdude14 said:

I mean the display for the RasPI just "blanks".  I see that the "disk" LED (green) on the RasPI is still moving,  when this  happens. And,  I am able to use the TI99 console to "CALL TIPI".  But, when I try "H"(Halt)  on console,  the Raspi doesn't do anything.  Also , I cannot "pull" a IP address off the Raspi,  from TI99 console, either.

 

Jt

Does the exact same hardware do the same thing with an unmodified "Raspberry Pi OS (32-bit) Lite" sd image?

[pcoderdude14]

22 hours ago, jedimatt42 said:

Does the exact same hardware do the same thing with an unmodified "Raspberry Pi OS (32-bit) Lite" sd image?

I  don't  know about "Raspberry Pi OS (32-bit) Lite" but I have been able  to  run TIPI ver. 1.43 on this machine(3B+) well as (3b,  and,  4b-4G-ram).

I also  have tried the 2.5 sdimage on the other RasPI's with the same thing happening.

The sdimage starts to "boot" then at a certain point ,  the screen  just "blanks" (on the  RasPI side) and when I  try at this  point to

use CALL TIPI, I cannot get an IP address and I cannot  "H"alt the RasPI or reboot.  I  have to do that manually on  the RasPI.

Is "Raspberry PI OS (32-bit) Lite" the version you used to  make the TIPI  ver. 1.43 image?  I'm trying to "install" a "GUI" on my

3B and would am  trying to gather as much info  about the TIPI as I can in  case  I run into trouble.  So far, though...no problems with

TIPI ver 1.43 ?

 

[+jedimatt42]

5 hours ago, pcoderdude14 said:

I  don't  know about "Raspberry Pi OS (32-bit) Lite" but I have been able  to  run TIPI ver. 1.43 on this machine(3B+) well as (3b,  and,  4b-4G-ram).

I also  have tried the 2.5 sdimage on the other RasPI's with the same thing happening.

The sdimage starts to "boot" then at a certain point ,  the screen  just "blanks" (on the  RasPI side) and when I  try at this  point to

use CALL TIPI, I cannot get an IP address and I cannot  "H"alt the RasPI or reboot.  I  have to do that manually on  the RasPI.

Is "Raspberry PI OS (32-bit) Lite" the version you used to  make the TIPI  ver. 1.43 image?  I'm trying to "install" a "GUI" on my

3B and would am  trying to gather as much info  about the TIPI as I can in  case  I run into trouble.  So far, though...no problems with

TIPI ver 1.43 ?

 

The version I used is Raspbian 10 (buster)

 

So to be clear, I'm asking you to find out if "Raspberry Pi OS (32-bit) Lite", latest available from https://www.raspberrypi.org/downloads/raspberry-pi-os/ works (does not have the blanking issue) on your hardware? This separates if the issue is your hardware, or something specific to the additional TIPI centric software. If the problem persists without the TIPI software, there are still things you can research to recover the PI. The SoC's have eeprom on them, that can get corrupt... The power supply could just be crap. The display might not detect well. 

 

There are controls in a Raspbian "config" file related to disabling and or forced detection of the HDMI port. I don't recall exactly... 

 

To help troubleshoot, I recommend having an ethernet cable attached the PI, and having a strategy to find the IP address through nmap or your router, so you can SSH in. If it is live at all. Keep it simple... don't connect anything you don't need ( audio, mouse, keyboard ) just Ethernet, HDMI, then POWER. You can hot plug the keyboard if the screen stabilizes. Take the TIPI out of the equation.

 

I've heard stories of using the audio jack confusing the HDMI selection. Keep it as simple as possible. The PI attached to your TI is a disk drive and network adapter for your TI. It is designed to be remotely monitored. You can SSH in... You can mount the TIPI share on any other desktop/laptop OS and manage the files from there. 

 

Installing the 'desktop' packages is not recommended by the guy who has to answer these questions. That creates a substantial number of other processes increasing disk/sd-card activity, logging, memory usage... I've carved off 200megabytes for ramdisk so that logging and other temporary things don't wear down the sd card. It isn't tuned for the desktop applications running. 

 

Remember when flashing the SD card image, there isn't a ton of room on the SD card until you grow the filesystem. It's hobby grade code. Updates and patching processes aren't designed for out-of-space errors. 

 

If as you said earlier in another channel, you want to monitor the PI while it is busy being a TIPI, then try something like `atop` from the console ( if you can solve your hdmi issue )

[+jedimatt42]

WARNING: There is a bug in the handling of VARIABLE record files in TIPI. When they write, I increment the last sector data offset as I write the 0xFF end of sector marker, before I stuff the file header. So things doing LVL2 direct read while trying to determine the last sector length are getting an off by one error.  TIPI doesn't use this value when reading the file back with RECORD level IO. 

 

Copying such files off of TIPI to a floppy, or other controller, or copying the FIAD off to an emulator will likely cause trouble with the use of some devices.

 

TIPI also pads VARIABLE length files empty sector space with 0x00's... so I should be able to write code into the migration/upgrade process that finds your variable record files and fixes them. The last sector will be all zeros after the end of sector marker 0xFF. 

 

I'm tired tonight, so I'm not going to rush the fix out. It's just deleting one line of code, but then there is the update machinery.. The repair migration will come as a subsequent update. 

[+InsaneMultitasker]

18 hours ago, jedimatt42 said:

So things doing LVL2 direct read while trying to determine the last sector length are getting an off by one error.  TIPI doesn't use this value when reading the file back with RECORD level IO. 

I've made a note to look at the Horizon ROS to validate how EOF is reported as it might be more stringent (too stringent?) than some other spinning disk controllers. I saw an error on the ramdisk that doesn't occur in a floppy controller and I wonder if it is related. 

 

I know what you mean about being tired - that's today for me   Question that came to mind:  Level 2 reads/writes happen on a 'block' basis so I'm not so sure there would be any impact felt there.   Your second sentence mentions TIPI doesn't use the EOF value when reading back the file. Is that a manifestation of how the rpi back end deals with the file or am I just reading to much into that. 

 

<deleted image as I did not intend to copy it into this response>

 

[+9640News]

Not that it matters too much, but when I developed that Excel program with the VBA Form for the AfterHours BBS program, I had to be very careful with everything in the header as well as the file termination.  I was having to pull in the written file and comparing it to a MyWord file to get everything "just right".  As AfterHours was for the TIPI, I matched the file outputs to be the same for the TIPI.  I know something seemed off initially as I may have viewed a file contents on the HFDC first before TIDIR was updated and I could view it that way never realizing the discrepancy may have been in the device saving the file when I started trying to debug why the file would not load properly in MyWord.

 

Beery

[pcoderdude14]

On 11/2/2020 at 11:38 PM, jedimatt42 said:

The version I used is Raspbian 10 (buster)

 

So to be clear, I'm asking you to find out if "Raspberry Pi OS (32-bit) Lite", latest available from https://www.raspberrypi.org/downloads/raspberry-pi-os/ works (does not have the blanking issue) on your hardware? This separates if the issue is your hardware, or something specific to the additional TIPI centric software. If the problem persists without the TIPI software, there are still things you can research to recover the PI. The SoC's have eeprom on them, that can get corrupt... The power supply could just be crap. The display might not detect well. 

 

There are controls in a Raspbian "config" file related to disabling and or forced detection of the HDMI port. I don't recall exactly... 

 

To help troubleshoot, I recommend having an ethernet cable attached the PI, and having a strategy to find the IP address through nmap or your router, so you can SSH in. If it is live at all. Keep it simple... don't connect anything you don't need ( audio, mouse, keyboard ) just Ethernet, HDMI, then POWER. You can hot plug the keyboard if the screen stabilizes. Take the TIPI out of the equation.

 

I've heard stories of using the audio jack confusing the HDMI selection. Keep it as simple as possible. The PI attached to your TI is a disk drive and network adapter for your TI. It is designed to be remotely monitored. You can SSH in... You can mount the TIPI share on any other desktop/laptop OS and manage the files from there. 

 

Installing the 'desktop' packages is not recommended by the guy who has to answer these questions. That creates a substantial number of other processes increasing disk/sd-card activity, logging, memory usage... I've carved off 200megabytes for ramdisk so that logging and other temporary things don't wear down the sd card. It isn't tuned for the desktop applications running. 

 

Remember when flashing the SD card image, there isn't a ton of room on the SD card until you grow the filesystem. It's hobby grade code. Updates and patching processes aren't designed for out-of-space errors. 

 

If as you said earlier in another channel, you want to monitor the PI while it is busy being a TIPI, then try something like `atop` from the console ( if you can solve your hdmi issue )

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

[+jedimatt42]

4 hours ago, InsaneMultitasker said:

I've made a note to look at the Horizon ROS to validate how EOF is reported as it might be more stringent (too stringent?) than some other spinning disk controllers. I saw an error on the ramdisk that doesn't occur in a floppy controller and I wonder if it is related. 

 

I know what you mean about being tired - that's today for me   Question that came to mind:  Level 2 reads/writes happen on a 'block' basis so I'm not so sure there would be any impact felt there.   Your second sentence mentions TIPI doesn't use the EOF value when reading back the file. Is that a manifestation of how the rpi back end deals with the file or am I just reading to much into that. 

 

<deleted image as I did not intend to copy it into this response>

 

 

I don't need the EOF offset marker because I have the end of sector marker in the data for Variable record files... When TIPI reads a Variable record file, it 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... and so on... all the records get loaded into an array of bytearrays. cause 100s of megabytes of ram are available. 

 

If everything is consistent, it should never matter.

 

Level 2 read writes are cool, except for the meta-block, block 0. That is your FDR or whatever... and I transform my 0x06 into the slot that should have your 0x05, and give it to a different disk controller that later gets confused. The actual file data in blocks is fine... 

 

I think as Fred said in another thread, what's in the FDR is the internal business of a storage device. Except where he and I devices like HDX that then expose those bits in what are supposed to be standardized FIAD formats.