Jump to content
jedimatt42

TIPI Usage and Support

Recommended Posts

It seems like you are on the correct track. 

 

Ignore the 'tiname' in ti99dir, TIPI doesn't look at that. If you had renamed outside of ti99dir the name in the header wouldn't have changed. 

 

If I recall, DM2K doesn't have a text view, but a file block view... and DM2K doesn't know how to do LVL2 direct-read operations on the device named "TIPI". 

 

So everything looks good except your ability to map a drive. Once using a mapped drive, DM2K can view files from those mappings.

  • Like 1

Share this post


Link to post
Share on other sites

I have determined today that the weird behavior with MXT and now AFTER HOURS is due to my PI OLED display. Beery's code sends and receives every byte, which then overwhelms the GPIO sending updates to the display for every send and receive slowing things down to a crawl.. removing the display from my PI removes the issue.

 

This also was the reason my disk catalog in the new 80 col BOOT with TIPI support was slow, its zippy now without the display installed. 

 

Greg

  • Thanks 1

Share this post


Link to post
Share on other sites
On 5/9/2020 at 2:19 PM, curtludwig said:

In the best of times I'm just barely smart enough to use the TIPI at all. I got through the commands above and get M5FFD = 0x0 M5FFF = 0x0 over and over.

I dug around and found my Mini Memory cart and did the tests in the troubleshooting guide, C1000 seems to act as described most of the time. Sometimes 01 is already there, in those cases when I shut the TI off the TIPI LED comes on and I need to power cycle it before the TI will boot again.

 

M4000 etc is always 00, up through M4029 anyway.

M5FFF won't take a change.

 

Sounds like this suggests solder issues. I don't see any obvious problems on the board but I don't have any real magnification to examine it under.

 

I suspect we've hit my peak in the Peter Principle. If somebody can help me proceed using very small words I might be able to move forward, otherwise I'm going to need help.

 

Turns out it was just the 32k memory board @curtludwig. The TIPI tested good, the memory board had issues, but the chips were all good. I repaired the memory board brute force style... just wicked up excess solder and re-flowed all the solder points. Then it was all happy. The memory burn in ran for an hour fine... Then I let the tipi stream data over telnet for an hour and it was all good. 

 

Hard to test a TIPI if the memory address decoding is interfering... there was definitely some bridging around A0 or A1, the part of the circuit that consumes them to determine which 8k of the 64k address space is being accessed was having trouble, my guess memory was active on the bus the same time TIPI was active on the bus... 

 

  • Like 1

Share this post


Link to post
Share on other sites

Just a quick comment...  TIPI won't associate to an ESSID that is hidden.  Bug or feature?

 

I would like to figure out the disk mapping issue.  Can someone post a screenshot of their CALL TIPI screen properly set up?  If I knew what was correct, it would be a good place to start.

Share this post


Link to post
Share on other sites

The options for WIFI setup are massive... TIPICFG only supports the most common case.  If you have more complex WIFI, then you can place a wpa_supplicant.conf file on the FAT boot partion of the SD card, and it should apply when you put the SD back in the PI...   Modern WIFI also requires correct country code setup in the wpa_supplicant... TIPICFG will always set it to the US... Access points in other parts of the world have a few more bands they can use.

 

Lots of documentation here: https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md

Share this post


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

...

 

I would like to figure out the disk mapping issue.  Can someone post a screenshot of their CALL TIPI screen properly set up?  If I knew what was correct, it would be a good place to start.

 

I'd like to figure out your disk mapping issue too... 

 

1st, the ability for disk mapping to work, requires that the TIPI be the first device that a DSRLNK will discover the DSKn device name on. Typically this means TIPI is at crubase >1000 with a floppy at >1100, or TIPI is at >1100 and you have no floppy controller.

 

https://github.com/jedimatt42/tipi/wiki/PI.CONFIG <- describes the rules

https://github.com/jedimatt42/tipi/wiki/TIPICFG <- shows a transcribed screen - copied below

 

TIPICFG v9   PI-Version: 1.42
CRUBASE: 1100        IP: 192.168.1.48
DSR Build: 2018-04-19T21:37:02-07:00
----------------------------------------

----------------------------------------
Drive Mappings
  1) DSK1=DISKS.INFOCOM.DEADLINE
  2) DSK2=
  3) DSK3=
  4) DSK4=
  J) URI1=
  K) URI2=
  L) URI3=HTTP://www.cwfk.net/4afiles/
----------------------------------------
WiFi Settings
  S) SSID=sillyname
  P)  PSK=*******
----------------------------------------


----------------------------------------
CFG: Q)uit, R)eload
 PI: H)alt, re(B)oot

 

In the above screen, my mapping of DSK1 is to DISKS.INFOCOM.DEADLINE

 

DISKS.INFOCOM.DEADLINE is the TI directory: TIPI.DISKS.INFOCOM.DEADLINE.

The unix path :  /home/tipi/tipi_disk/DISKS/INFOCOM/DEADLINE/

The windows share path: \\TIPI\TIPI\DISKS\INFOCOM\DEADLINE\

 

In that directory can live the DEADLINE program image, and support data file. 

You can then load DSK1.DEADLINE from an EA5 loader, such as CALL TIPI("DSK1.DEADLINE")

 

If you have the auto-map feature on.. you don't have to have DSK1 pre-mapped... you can CALL TIPI("TIPI.DISKS.INFOCOM.DEADLINE.DEADLINE") 

It will load the program image and temporarily map the DSK1 drive to the folder it was loaded from.. Having the same result. That temporary mapping will be gone when you return to the TI title screen.

 

A few posts back, I pointed InsaneMultitasker at the TIPI special file that can live in a directory, and create more complex auto-mappings on program image load. The goal here is you can setup your art software and auto map your clip art folder or save data folders as needed. 

 

For my own organization, I have a folder TIPI.DISKS. and whenever I upload a .DSK image to the TIPI, I drop it in that folder. I usually only do this for software that relies on volume name or DSKn access. This is just my style, not a requirement.

 

If your program has volume name matching requirements, like multiplan, then it is important that the leaf most folder name matches the volume name your legacy software expects.. such as TIMP for multiplan. Or INSCEBOT for TI Artist.

 

 

 

Share this post


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

 

I'd like to figure out your disk mapping issue too... 

 

1st, the ability for disk mapping to work, requires that the TIPI be the first device that a DSRLNK will discover the DSKn device name on. Typically this means TIPI is at crubase >1000 with a floppy at >1100, or TIPI is at >1100 and you have no floppy controller.

 

https://github.com/jedimatt42/tipi/wiki/PI.CONFIG <- describes the rules

https://github.com/jedimatt42/tipi/wiki/TIPICFG <- shows a transcribed screen - copied below

 

TIPICFG v9   PI-Version: 1.42
CRUBASE: 1100        IP: 192.168.1.48
DSR Build: 2018-04-19T21:37:02-07:00
----------------------------------------

----------------------------------------
Drive Mappings
  1) DSK1=DISKS.INFOCOM.DEADLINE
  2) DSK2=
  3) DSK3=
  4) DSK4=
  J) URI1=
  K) URI2=
  L) URI3=HTTP://www.cwfk.net/4afiles/
----------------------------------------
WiFi Settings
  S) SSID=sillyname
  P)  PSK=*******
----------------------------------------


----------------------------------------
CFG: Q)uit, R)eload
 PI: H)alt, re(B)oot

 

In the above screen, my mapping of DSK1 is to DISKS.INFOCOM.DEADLINE

 

DISKS.INFOCOM.DEADLINE is the TI directory: TIPI.DISKS.INFOCOM.DEADLINE.

The unix path :  /home/tipi/tipi_disk/DISKS/INFOCOM/DEADLINE/

The windows share path: \\TIPI\TIPI\DISKS\INFOCOM\DEADLINE\

 

In that directory can live the DEADLINE program image, and support data file. 

You can then load DSK1.DEADLINE from an EA5 loader, such as CALL TIPI("DSK1.DEADLINE")

 

If you have the auto-map feature on.. you don't have to have DSK1 pre-mapped... you can CALL TIPI("TIPI.DISKS.INFOCOM.DEADLINE.DEADLINE") 

It will load the program image and temporarily map the DSK1 drive to the folder it was loaded from.. Having the same result. That temporary mapping will be gone when you return to the TI title screen.

 

A few posts back, I pointed InsaneMultitasker at the TIPI special file that can live in a directory, and create more complex auto-mappings on program image load. The goal here is you can setup your art software and auto map your clip art folder or save data folders as needed. 

 

For my own organization, I have a folder TIPI.DISKS. and whenever I upload a .DSK image to the TIPI, I drop it in that folder. I usually only do this for software that relies on volume name or DSKn access. This is just my style, not a requirement.

 

If your program has volume name matching requirements, like multiplan, then it is important that the leaf most folder name matches the volume name your legacy software expects.. such as TIMP for multiplan. Or INSCEBOT for TI Artist.

 

 

 

Fixed.  Ran DU2K to get a complete dump of DSR and devices - and discovered the card was set to 1800 - which I should have noticed earlier.  Reset to 1000 and all is working!  :)

  • Like 2

Share this post


Link to post
Share on other sites

Is there any place I can hack a different value into the volume size reported back to the TI?  It's currently fixed at 1440 - but needs to be larger for programs that create bigger than diskette sized files.  The ability for a disk mapping to be 2880 or even 5760 would likely resolve some large file issues I am running into. 

 

Seems that so long as I run DB sizes that are smaller than 1440 all is OK - but when I merge files that push above that number weird things happen.

 

Thank you, Arthur...

 

 

  • Like 1

Share this post


Link to post
Share on other sites

@aftyde this release is for you! :)

 

release 1.61 - 2020-05-19

 

Allow setting reported sector count by writing a config value to ti file "PI.CONFIG"

Values may be from 2 to 9999 ( garbage values will be sanitized, possibly leaving you with the default of 1440 )

 

In TI BASIC

10 OPEN #1:"PI.CONFIG"
20 PRINT #1:"SECTOR_COUNT=9999"
30 CLOSE #1

 

I viewed my results in DM2K...

 

I believe ForceCommand hasn't had attention spent on the disk size reported by the DIR command, so ignore that for this purpose.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

It has come to light that the OLED display code is detrimental to the applications made available for the TIPI by @BeeryMiller.  It causes performance problems that are otherwise not experienced. Thanks to @arcadeshopper for identifying this finally. 

 

I don't know how many of you use the OLED attachment.. I haven't since the thing went live.  It started as a debugging tool, it isn't useful anymore, and now it is known to be detrimental. I can't test fixes for it, cause I refuse to spend $0.02 toward it. 

 

So, I'd like to remove it from upcoming release of the PI software.  

 

  • Like 2

Share this post


Link to post
Share on other sites

It also slowed down the 80col boot disk directory function quite a bit.. Nuke it

Sent from my LM-G820 using Tapatalk

  • Like 3

Share this post


Link to post
Share on other sites

@jedimatt42 - works like a champ.  No problem sorting large files!   Agreed - I don't think the software does the math beyond looking at space available.  :)

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I had a little bit of bad luck this evening, I started to update my TIPI in tipiconfig, pressed U and the update started.

Suddenly all the electricity in the house was cut, and when it came back on my tipi won´t work.

When I write CALL TIPI in basic, the led lights up and the computer locks. I restarted the RPI but no luck.

What is there to do?, get a new eprom?

 

/Niklas

Share this post


Link to post
Share on other sites
9 minutes ago, Nick99 said:

I had a little bit of bad luck this evening, I started to update my TIPI in tipiconfig, pressed U and the update started.

Suddenly all the electricity in the house was cut, and when it came back on my tipi won´t work.

When I write CALL TIPI in basic, the led lights up and the computer locks. I restarted the RPI but no luck.

What is there to do?, get a new eprom?

 

/Niklas

I had the same trouble last year with my tipi and I could solve the problem with making a new SD-card for the pi.

 

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, wolhess said:

I had the same trouble last year with my tipi and I could solve the problem with making a new SD-card for the pi.

 

Thanks! I´ll try that.

 

It worked with making a new SD-image.

 

Edited by Nick99
update of information.
  • Like 3

Share this post


Link to post
Share on other sites

Yes, SD Cards in a Raspberry PI are fragile... always safe shutdown.

 

Find an imaging tool on your atariage browsing machine, and back up your configured sd card image... or backup your files in TIPI windows share at least. 

  • Like 2

Share this post


Link to post
Share on other sites

Hi Team, Python seems to be consuming 30% of the CPU - the TI is switched off - as is the PEB.  Logged into to the PI to map some drives and it's really sluggish - hard to even edit a file.  Feels like this is new as I don't recall previous ssh sessions on the PI being like this.  Has there been a change, or perhaps a process I can kill?

Share this post


Link to post
Share on other sites

Turn the TI on... it should reset the tipi service... 

 

If things are still slow, it would be good to know which process is being a beast.   Look at the /var/log/daemon.log and see if there is activity... there are some auto-update mechanisms for the linux system... 

 

there are 2 other python processes, the web service and the file metadata cache, but I've not seen them take up much in resources, unless you just copied a massive amount of files to the system. 

 

The PI can be restarted, within TIPICFG, using the 'B' option.. or 'sudo reboot now' if you are shelled in.

Share this post


Link to post
Share on other sites

Seems like network is the issue.  The pi is seeing ping times of 1.5 ms to 4000ms and it seems bursty.  It'll go fast (2 pings), then several pings at 3 to 4K MS, then another 2 pings at less than 10ms.  Never seen anything like this.  Seems to be this way no matter which wireless net I connect it to.  Presently connected to localhost on the TI console via. telnet to get around the choppy connection speed.

 

Anyone else seen this?  Should I apt-get update, and then upgrade?  See if I can trade some old bugs for new?  Is there a service I can stop and start for tipi?

Share this post


Link to post
Share on other sites

Tried ethernet to the LAN; .3 MS.  Consistent.  So something might be up with wifi connectivity - since no matter which wifi AP I hit, the variable performance issue mentioned above is a problem.  So, question is...  can I disable wifi and just use this from ethernet with no ill effect?

  • Like 1

Share this post


Link to post
Share on other sites

I have seen the WiFi connection to the PI be 'pause' prone.  In the middle of debugging something, and then it just stares at me, and comes back later... Yes never a problem with my Ethernet, just WIFI... If it gets to be a real nuisance, I plug an Ethernet cable in... You can run with Ethernet instead of Wifi to your heart's content... 

 

When I said 'turn the TI on' 'it will reset the tipi service' - the reset process is that the service is killed, and the operating system restarts it. This is so you don't have to ever worry about restarting the TIPI service.  If the TI crashes, the same actions you use un-crash your 4A ( reset switch, FCTN-=, power switch ) will restart the tipi.service that handles all requests from the TI.  Those actions all trigger the console to search devices and run the powerup code in their ROMs. The TIPI powerup code uses hardware controlled by a single crubit, that is connected to the PI GPIO like a button. A separate tipiwatchdog.service installs an interrupt handler on the GPIO pin from the PI. Minimal software is involved and the tipi.service can be in any sort of crazy state, when you go to a TI title screen, it will get restarted, and you'll have a fresh tipi.service process to handle the new round of requests. 

 

I've just added page to the wiki listing all the services that TIPI brings to Raspbian:  https://github.com/jedimatt42/tipi/wiki/Services

  • Like 1

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