TIPI Usage and Support

[J-Data]

3 hours ago, jedimatt42 said:

If it isn't working after that, send us the /home/tipi/post-upgrade.log

Hi Matt, Sorry for making more work for you.  That wasn't my intention.  I was just curious if anyone else was seeing this, but apparently its just me. 

 

Unfortunately, everything is exactly as it should be in all the checks:

 

 

I reran the full upgrade again, and still no joy.   See attached log file and below. 

 

 

 

I'm seeing this on both an old image I've upgraded over time and an fresh image I just burned from the 1.43 ISO and it does this on two different Pi ZeroW's units.  I did noticed the Apache HTML server fails to start with this image, but it does this both on the ZeroW's and the 3B, but the 'files' web page seems to work fine on the 3B anyway. 

 

Its got to be something dumb I'm doing, but I can't figure out what.  I love the TIPI's web page capabilities, but can live without it, or go back to 1.43 if needed. 

 

Thanks again for all the help.

 

post-upgrade.log

[+jedimatt42]

Beery mentioned the apache server fails too... but I don't use the apache server, so that just came along for the ride with the base raspbian lite...

 

In the post-upgrade it rebuilds the virtual env for the web-ui but it finds all of them in the site-packages, which is odd... 

 

This isn't a bother, I'm curious what the cause is, and if one person sees something, others will eventually.

[+jedimatt42]

Well, I changed my upgrade code for the htdocs folder to work the way I thought it did, and now it fails the way yours is failing... So, I can reproduce the problem! Extremely weird... effectively I deleted the python virtual-env and recreated it... now it fails.. and I'm seeing a few updated libraries that I didn't see earlier, so the caching gods of python have finally made it to the west-coast maybe? ... lol... I should probalby re-'freeze' the requirements.txt so things stay reproducable...

[+jedimatt42]

Hey good news, we aren't crazy... the bug is intermittent... and my fix was rubbish... It can fail on the PI3 now too... 

 

Working on a real fix.. the flask people are opinionated against supporting single-threaded mode, so much so that the option I used is a noop, does nothing, placebo... and sqlite doesn't support threads... we'll see if the documented strategy works... with a couple decades of highly concurrent distributed systems programming, I've learned to not allow concurrency if it won't pay dividends, now I have to give in. 

 

Anyway, should have a real fix by tomorrow.

[+jedimatt42]

update: 1.60 - 2020-04-25

 

Fixes for web-ui breakage due to upgrade to flask - and changed relationship with sqlite3

Fix dependency upgrade process for web-ui to match the approach used by the main services, and my mental model.

 

Addresses the issue reported by @J-Data

 

 

[J-Data]

2 hours ago, jedimatt42 said:

update: 1.60 - 2020-04-25

 

Awesome, I'm two for two TIPIs working now. One updated from the console, one updated from SSH.  Took a very long time to update, but the web files interface is working great now.  Thank you!

[curtludwig]

Hey Folks, I posted this as a general topic but was redirected here. My TIPI seems to be sick, it worked back in 2018, then life intervened and it sat.

I'm getting BAD NAME when I try CALL TIPI.

SIZE in Extended BASIC suggests the RAM expansion is working okay. The power supply for the RAM expansion seems to be putting out 5v as its supposed to.

I put an HDMI cable on the PI and it seems happy enough.

I've reseated everything, the sidecar into the computer, the TIPI into the RAM expansion, all the cables multiple times and at Arcade Shopper's suggestion the ROM in the TIPI. The cable between the TIPI and the PI is correct, it was still connected when I first tried it out and I reconnected it by the instructions several times.

The light on the TIPI blinks briefly when I issue CALL TIPI.

 

I had hoped to play some ToD tonight. Oh well, the fun of 37 year old computers...

 

Edit: Staring at the output of the PI booting up I realized it had gotten a different IP address than the one in my notes. I've now discovered that I can access the PI through its webpage. It seems to suggest the TIPI is ready but I'm wondering if that just means the service is running.

Is there a way to ping the TIPI from the PI side?

 

Edit 2: reading back through this thread I noticed the thing about tones. No special tones coming from my TIPI. At first boot I don't hear anything, FCTN= gets the normal single beep.

I put a good multimeter on the RAM expander power supply, solid 4.98v

Edited May 2, 2020 by curtludwig

[+jedimatt42]

Bad name means the ROM on the TIPI board isn't showing up.. 

 

The PI can be fine be, but with the driver in the ROM, it won't go far...  Somewhere I have some low level diagnostic process written, I think on the wiki... 

 

The fire is lit on the stove or I would dig up more details...

[+jedimatt42]

And now it is on simmer... 

 

Review this and see what you can learn, provided you have some means to use mini-mem's easybug...

 

https://github.com/jedimatt42/tipi/wiki/Troubleshooting

[+jedimatt42]

Oh, and you might just check that the eprom is well socketed first. 

[wolhess]

I had a same problem, as I changed my tipi sd card on my tipi peb card. call tipi = bad name.

 

I simply powered down the peb and the tipi and pulled the tipi card out of the peb and put it in again.
After power on, all was good.
 

Maybe I had a bad contact to the socket in the peb. Since then, it was about 8 weeks ago, the tipi system works fine every day.

[fimbulvetr]

I just got my PEB tipi set up today, and everything seems to work great but for one thing: my Plato cartridge just locks up with the tipi board in the PEB. I've been using a Lotherek drive as Disk 1 for all the Plato modules. I can access the Lotherek and my 3.5" floppy no problem with disk managers and whatnot, but no luck with the Plato module. The floppy controller light just turns on continuously and the computer locks up on a blue screen. Any ideas how I can get the thing running? Or is Plato just incompatible with the tipi?

 

This wouldn't be a big deal except for the fact that my kids have been using Plato every day since the whole coronavirus lockdown started. 

[+jedimatt42]

FYI:

 

The special TIPI boot tones were removed from the ROM some time ago... There is version info in the EPROM, but if you are getting BAD NAME when you CALL TIPI, your EPROM isn't readable for any of a number of reasons... 

 

Being able to access the web-ui for TIPI is a completely separate software process on the PI that has nothing to do with the TI talking through the TIPI board to the PI... 

 

As for interacting with the TIPI board from the PI, there is a little interactive test program here: https://github.com/jedimatt42/tipi/blob/9074c4aa2668a37cabad9f02730c07ed940c8d52/services/tipi/TipiPorts.py#L41

you'd have to SSH into the PI, as 'tipi'.. 

cd /home/tipi/tipi/services
sudo systemctl stop tipi.service
. ./ENV/bin/activate
python tipi/TipiPorts.py

 

Then you'd need to go into Mini-memory on the 4A's EASY-BUG, and enable the TIPI ( C1100  1 ) then look at or write to the memory addresses the script is talking about... to see if the shift registers in the CPLD are working.

 

 

 

 

[+jedimatt42]

12 minutes ago, fimbulvetr said:

I just got my PEB tipi set up today, and everything seems to work great but for one thing: my Plato cartridge just locks up with the tipi board in the PEB. I've been using a Lotherek drive as Disk 1 for all the Plato modules. I can access the Lotherek and my 3.5" floppy no problem with disk managers and whatnot, but no luck with the Plato module. The floppy controller light just turns on continuously and the computer locks up on a blue screen. Any ideas how I can get the thing running? Or is Plato just incompatible with the tipi?

 

This wouldn't be a big deal except for the fact that my kids have been using Plato every day since the whole coronavirus lockdown started. 

 

I wouldn't expect PLATO to be incompatible with TIPI just being installed, unless your TIPI is also set for CRUBASE >1100 like your floppy controller, in which case I would expect lots of random failure modes. 

 

I think I've heard that PLATO does not use the TI filesystem, just sector-io... which TIPI does not implement... Normally a PEB TIPI is shipped with CRUBASE set to >1000 ( no jumper, or the jumper just across any 2 of the front most 'common' pins on that header block.. )

 

You can try setting your TIPI CRUBASE above >1100, but you'll lose being able to intercept file system access to DSK1 mapping to the TIPI, it will instead always go to your real disk controller.  Accessing 'TIPI.' and other tipi messaging based applications will still function. You could even make it externally selectable with a SPDT switch.

 

[fimbulvetr]

Yes, it was set at the default setting of >1000. I put a jumper to set CRUBASE to >1400, and Plato works fine. Must be some sort of weird incompatibility?

[+retroclouds]

For those who it might concern.

I had some stability issues with the TIPI when loading large files.

It worked fine for normal operations, but as soon as I started loading large files the TI-99/4a locked up after 30 seconds to two minutes and appeared to hang.

 

What happened was that the Raspberry rebooted. Checking journalctl on the Raspberry showed that it very frequently went into an “undervoltage” situation and then quickly normalized. I threw away my USB power plug (one of my old mobile phones) and replaced it with a more powerful one, and problems disappeared.

[+jedimatt42]

13 hours ago, fimbulvetr said:

Yes, it was set at the default setting of >1000. I put a jumper to set CRUBASE to >1400, and Plato works fine. Must be some sort of weird incompatibility?

 

I've not tried TI PLATO myself (since maybe I was your children's age)...  every program on the TI gets the opportunity to bring their own DSRLNK... Most GPL programs just use the one in the console ROM. 

 

I'll add testing TI PLATO to the list of things to explore... maybe a TIPI DSR ROM update can properly get out of the real floppy controller's way without having to mess with the jumpers.. 

[+jedimatt42]

Note:

 

In another thread, someone asserted that they thought TIPI wouldn't work without 32k RAM expansion. That isn't technically true. 

 

TIPI itself does not need expansion ram. However, most disk based software, including TIPICFG does. 

 

All of the important features of TIPICFG can be performed in plain TI BASIC, by interacting with the "PI." special file set.

[+InsaneMultitasker]

On 4/11/2020 at 9:23 PM, InsaneMultitasker said:

My primary reason for updating the CPLD is to test my TIPI with a Geneve computer in the near future.  Thank you and everyone who has offered advice/help!  Much appreciated.

 

Today I had the time and opportunity to put a standard Geneve into the PEB with my updated TIPI.  Before the CPLD update, the Geneve locked up during the boot process.  Today it booted normally.  I loaded the TI mode emulation (GPL) program, set the speed to 2, and selected the ROMPAGE option. I was momentarily surprised when the ramdisk TITLE program displayed a picture! I had forgotten to turn the ramdisk switch to OFF; now I know that ROS still works with the Geneve in rompage mode.  Anyway, I crossed my fingers and typed in the path to a program on the TIPI... and it loaded!  I then reset GPL to speed 5 and executed the same steps.  As expected, everything was a bit faster and seemed to work just fine. I haven't done any hard-core testing but overall things are looking good.   Even the updated 9640menu catalog routine functioned as expected, allowing me to traverse the tipi directory structure.

 

[curtludwig]

On 5/2/2020 at 8:40 PM, jedimatt42 said:

FYI:

 

As for interacting with the TIPI board from the PI, there is a little interactive test program here: https://github.com/jedimatt42/tipi/blob/9074c4aa2668a37cabad9f02730c07ed940c8d52/services/tipi/TipiPorts.py#L41

you'd have to SSH into the PI, as 'tipi'.. 

cd /home/tipi/tipi/services
sudo systemctl stop tipi.service
. ./ENV/bin/activate
python tipi/TipiPorts.py

 

Then you'd need to go into Mini-memory on the 4A's EASY-BUG, and enable the TIPI ( C1100  1 ) then look at or write to the memory addresses the script is talking about... to see if the shift registers in the CPLD are working.

 

 

 

 

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.

[+jedimatt42]

1 hour ago, 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.

 

You should never have to power cycle the TIPI to reboot the 4A. Even if crubits are left high... the CPLD isn't functioning correctly... 

 

We could get more specific with diagnosis, like C1000 must be 1 for any of the M commands to work.. if M5FFF would take a change, then the script on the PI should show it... but given the intermittent cru addressing, and bus getting stuck until you power cycle, you need a new one or to arrange repair.. 

PM me if you want to talk about repair. 

[fimbulvetr]

 

2 hours ago, jedimatt42 said:

 

You should never have to power cycle the TIPI to reboot the 4A. Even if crubits are left high... the CPLD isn't functioning correctly... 

 

We could get more specific with diagnosis, like C1000 must be 1 for any of the M commands to work.. if M5FFF would take a change, then the script on the PI should show it... but given the intermittent cru addressing, and bus getting stuck until you power cycle, you need a new one or to arrange repair.. 

PM me if you want to talk about repair. 

Since I set the CRUBASE for my TIPI to >1400, and I’ve also tried >1200, to be able to use the Plato cartridge, I’ve had to power cycle the PEB to reboot my 4a if I mess up or make a typo on a call to the TIPI. It seems really sensitive to capitalization as well. When the CRUBASE is at default with no jumpers, I don’t have to power cycle the PEB, it works just fine and never hangs.  It looks like the problem is with hanging on the disk controller, as that light stays on and the whole system freezes at a blue screen.

[+jedimatt42]

4 hours ago, fimbulvetr said:

 

Since I set the CRUBASE for my TIPI to >1400, and I’ve also tried >1200, to be able to use the Plato cartridge, I’ve had to power cycle the PEB to reboot my 4a if I mess up or make a typo on a call to the TIPI. It seems really sensitive to capitalization as well. When the CRUBASE is at default with no jumpers, I don’t have to power cycle the PEB, it works just fine and never hangs.  It looks like the problem is with hanging on the disk controller, as that light stays on and the whole system freezes at a blue screen.

The TIPI is as most parts of the TI, 100% sensative to capitalization. The file system on the TI is case sensitive. Some disk controllers had duplicate device names in caps and lower case. File names and directory names must match case. "WHATEVER" and "whatever" are 2 different filenames. TIPI device names must also match case ( PI. TIPI. DSK. DSK1...etc ) 

BASIC 'keywords' are converted to caps before compared.. so you do get away with CaLl TiPi ... but if you do Call Tipi("DsK3.WHATEVER")  that won't find anything... some floppy controllers might have both a 'DSK3.' and a 'dsk3.' but none have a 'DsK3.'  TIPI only has the all-caps versions. 

 

Normally if CALL TIPI("bad input") happens, the console should reboot. The powerup routines for all the peb cards run... if you are having to power cycle the TIPI cause of an input error, I'd like to know exactly how to reproduce it. 

 

One thing, I can think of if you are having situations where mid-message the TIPI is locked up... and TIPI 'ON' at a crubase after other boards, is ROM conflicts.. you'll have rom conflicts, and I didn't think of that until now... the powerup routine uses a dedicated pin to reset the PI side, but if the cru-bit 0 of the TIPI is on, and the first card is a real floppy controller, TIPI's ROM will respond concurrently while the console runs through the scan of all powerup routines to execute.. When TIPI's crubase is 1st, then the console turns TIPI off before going to subsequent cards...  When I designed this thing, I had trouble utilizing the RESET signal on the bus, so I backed away from that... those problems were probably bread-board related.. 

 

Fixing that, would require a patch wire soldered to the CPLD and reprogramming the CPLD...   The cru bits need to be zero'ed when the reset signal occurs.  This is a serious flaw I overlooked. 

 

You lose a ton of TIPI functionality running it in the PEB at anything other than crubase >1000... If you really want it out there, you should probably smudge out the DSK devices from the DSR ROM... In my experience other controllers that have DSK devices do not allow the cascade behavior to eventually get to the TIPI. 

 

After I find some Plato stuff to test, maybe we can solve your motivation for running at the odd crubase.  

 

[fimbulvetr]

Yeah, I’m used to capitalization sensitivity with the 4a, I was just surprised it was locking up the computer and requiring a hard reset with the TIPI.

 

i think my long term solution will be a switch on the jumper. Right now I just put the jumper on as needed, and that works perfectly. Plato is a weird edge-case, and as soon as my kids can go back to school they will probably never look at it again.

[fimbulvetr]

7 hours ago, jedimatt42 said:

Normally if CALL TIPI("bad input") happens, the console should reboot. The powerup routines for all the peb cards run... if you are having to power cycle the TIPI cause of an input error, I'd like to know exactly how to reproduce it.

For me it seems to be when CRUBASE is not set to>1000 and I make any bad call, whether a typo or mistake in capitalization. A soft reset isn’t good enough, I need to power cycle the PEB and sometimes the 4a if I use the reset button on my Ubergrom. I have to be careful setting the URI shortcuts as some cause a lockup if the URI is capitalized and vice versa. I have been setting CRUBASE to >1200 or >1400 when using Plato. My setup includes a ti disk controller, a new SAMS card, Corcomp rs232, and the TIPI with a pi zero w. I also have a sidecar speech synth plugged in. 

 

That said, with CRUBASE at >1000 it works and resets on its own when I make a bad call, so it really is only a problem when I mess with the jumpers.