TIPI Usage and Support

[+arcadeshopper]

1 hour ago, J-Data said:

Great suggestions.  As always, thanks. 
 
I'm running the burn in test now and will let you know in an hour.  The short version passes just now, but is not very conclusive.  I suspect this could be the cause of the reset issue.  
The behavior is exactly the same on a Pi ZeroW and Pi 3B.  I don't have any Pi 4Bs to try. I don't think this is Pi ZeroW related. 
I replaced the TIPI connector on the Pi ZeroW, to go from right angle to straight and there was no change in behavior (Did this for access purposes, but was a good clue)
The log file was intentionally short.  I restarted and ran the following:
 
CALL TIPI" (cart in and failed)
CALL TIPI (cart out and passed)
CALL TIP ("URI1.SNEK") (Failed)
CALL TIPI("DSK2.SNEK") (Failed)
 
By the way, I realized last night from the log the reason the DSK2 SNEK load failed was because I only copied "SNEK" to DSK2, not "SNEL", which the loader was clearly looking for.  However, I checked "myti99.com" and I can't find a copy of "SNEL" so could that be the issue with SNEK?  The second file is simply missing from myti99.com?
 
Stand by on the burn-test results. 

It's not missing you are just loading from local instead of from the web try loading PI.HTTP://www.myti99.com/SNEK

if you don't have URI1. set to www.myti99.com that's your issue.. there was a big hubabllaoo about www. with the ti browser and that screwed everything up. 


 

[J-Data]

Well... the RAM burn-in test failed after 18 and 8 cycles, so I suspect either my 32K sidecar or my console's A/D bus is at fault on the resets.  When I built my 32K board, I did a 100% net check twice, and inspected every solder joint under magnification, so not sure that's the issue.   I did use the Alliance AS6C62256-55PCN SRAM rather than the Cypress CY62256L-70PC due to part availability.  This is the part used in Matt's assembly pictures, so I assumed it was an acceptable alternate. 

 

By the way, I double checked myti99.com and "SNEK" is there but "SNEL" is definitely inaccessible for me (http://myti99.com/files/SNEL).  Can someone try running SNEK direly from myti99.com or try downloading the file to see if you get the same results? 

 

[+arcadeshopper]

Please follow my instruction above you need the www  i just loaded it here fine with that.

 

[+arcadeshopper]

 not sure about that ram but I'd say that's the issue
 

[J-Data]

Understood on the SRAM, I'll change and retry.  Hopefully that's it.

 

Thanks for all the help.

[J-Data]

Quick update, it looks like the file HTTP://www.myti99.com/SNEL is there but HTTP://myti99.com/SNEL is not!

 

Omitting the www. seems to be this issue.  Odd that SNEL is the only file missing with this abbreviated path.

 

I'll report back when I get the Cypress part.  Thanks again for all the help. 

 

 

[PeteE]

I found the solution to my problem: there was a file "/home/tipi/tipi_disk/TIPI" that seemed to be causing the trouble with CALL TIPI.  I renamed it and all is well.

[twoodland]

Arcadeshopper, M@,

 

Is there a diagnostic program for the TIPI?  It would be great to be able to check for connectivity/functionality before presuming a TIPI issue.

[tuf]

1 minute ago, twoodland said:

Arcadeshopper, M@,

 

Is there a diagnostic program for the TIPI?  It would be great to be able to check for basic connectivity/functionality before presuming a TIPI issue.

What does CALL TIPI do on your end?

[twoodland]

36 minutes ago, tuf said:

What does CALL TIPI do on your end?

I have had two issues loading programs/data so far where TIPI appears to be functional (ONLY two and I use this alot ?).  I can CALL TIPI and it looks normal, and can even load programs.  In both cases, (Issue #1 TEII Speech intermittent) (Issue #2 Music Maker loading song files) I took the 32k and TIPI boards out of my custom case, cleaned, then re-seated the connections/chips and the issues were mitigated.  Aside from ID10T errors, where I need to do more troubleshooting before posting,  I am hoping that there is a more comprehensive TIPI diagnostic that could assist in troubleshooting.  If not that is okay too, I just thought I would ask.

[+mizapf]

11 hours ago, J-Data said:

Quick update, it looks like the file HTTP://www.myti99.com/SNEL is there but HTTP://myti99.com/SNEL is not!

 

It is indeed interesting to see that many people assume that "www." could be omitted. "www.domain.com" and "domain.com" are two different DNS names, and they may be assigned different "A records", which means different IP addresses. On the other hand, if you have a DNS name like "comp.domain.com", some people assume this must be prefixed by "www.", similarly wrong. It is just a convention that www.domain.com and domain.com are assigned the same addresses.

 

The ugly point here is that many browsers treat those addresses as equivalent, which is a really BAD thing. Even worse, as I heard, Chrome starts to remove the www subdomain from the presented URL.

 

I am concerned about similar developments that seem to be motivated by some weird concept of comfort, which are in fact violation of specifications.

 

(this is not against you in particular )

Edited February 25, 2020 by mizapf

[+jedimatt42]

14 hours ago, J-Data said:

Well... the RAM burn-in test failed after 18 and 8 cycles, so I suspect either my 32K sidecar or my console's A/D bus is at fault on the resets.  When I built my 32K board, I did a 100% net check twice, and inspected every solder joint under magnification, so not sure that's the issue.   I did use the Alliance AS6C62256-55PCN SRAM rather than the Cypress CY62256L-70PC due to part availability.  This is the part used in Matt's assembly pictures, so I assumed it was an acceptable alternate. 

 

By the way, I double checked myti99.com and "SNEK" is there but "SNEL" is definitely inaccessible for me (http://myti99.com/files/SNEL).  Can someone try running SNEK direly from myti99.com or try downloading the file to see if you get the same results? 

 

I think when I used the Alliance ram, I also had to use an 74LS245 for reliability. I never new why. 

 

4 hours ago, tuf said:

What does CALL TIPI do on your end?

 

In response to the question: is there a TIPI tester:  @tuf is correct.  CALL TIPI is the simplest program that exercises the most functionality: 

1. The address decoding, ROM enable, ROM banking, and buffer enable in the CPLD all have to work, so you can get to the extension to BASIC ( the CALL TIPI command )

2. The program you see is just TIPI.TIPICFG being loaded from the PI from a TI_FILES using the LOAD disk io operation - it only takes 2 seconds, but streams 16k of program program data from the PI to the TI. This exercises the communication with the PI quite well. 

3. Once the program is running it lives in the 32k memory, and continues to gather more information: Reading the ROM (which also performs a CRU scan) to get the DSR build timestamp. Examines some cru bits. Loads records from 2 files PI.STATUS and PI.CONFIG just like any other TI program would load records from a file. 

 

So it exercises all of the TIPI boards, and most of the fundamental PI side functionality. 

 

If I need to look lower level, I use EASY BUG from mini-memory cartridge. 

knowing the crubase of the TIPI ( usually >1000 with no jumper when I'm testing, >1100 if meant as a side port replacement for floppies )  

C1000 - this command lets me see state of crubits. TIPI has 4. you can press enter 3 more times and should see them all zero initially. If any are already 1, then there is usually something wrong with the soldering on the bottom edge of the CPLD. 

C1000 again, and enter 1 - this enables the DSR ROM, you should see the TIPI LED activate. 

M4000 - go to the memory address for DSR ROMS. The bytes for the tipi should be there.. Press enter a bunch to see several of the bytes. first 2 should be >AA and >01 - I usually look at 12 bytes or so, and check that I'm seeing both odd numbers and even numbers and nothing that looks like a particular bit is stuck on the databus.. If you don't see anything resembling good - like just some >00, or simply an echo of the LSB of the address, like >01, >02, >03, >04 values in sequence, then there is likely something wrong with the soldering on the 74HCT245 chip. If you do see something that looks like stuck bits, it is probably the soldering on the right hand side of the CPLD. 

M5FFF - this is one of the registers we can write to from the 4A and read back. So enter a value like >55 and >AA ( alternating bit patterns 01010101 and 10101010 ) If you don't get the value back that you entered ( by entering '.' and then 'M5FFF' again to read that address ) but the DSR ROM seems fine, then 99% of the time, this is the soldering on the right hand side of the CPLD. 

 

If the 4A won't boot when a TIPI is in, it is usually a short across pins on the bus transceiver chips, the '245, and 3 '244s causing interferance with other addresses in the system. Or an unprogrammed CPLD.. If I recall, that seems to leave the databus active. 

 

I should copy this into one of my github wiki pages. 

 

-M@

 

(PS: 'should' doesn't mean 100% of the time it is that side of the chip... just most of the time... )

[pixelpedant]

Well, I finally got around to installing my TIPI today, after its sitting on the shelf for a hell of a long time waiting for me to get finished with various RS232 projects that necessitated a NanoPEB.  And sadly, I seem to have ended up stumped. 

 

What I have (to the extent that things are working) at present is

 

- A Raspberry Pi 3b which boots up successfully via the TIPI SD image, to a login prompt (can log in as tipi/tipi and do normal shell things)

- A 32K JediMatt sidecar which functions to the extent that it shows expansion RAM present via SIZE in XB and 32K-dependent apps run successfully. 

 

But starting with the TIPI board connected results in odd behaviour.  XB will not launch (sits at a blue screen for a while, then restarts), and "CALL TIPI" from BASIC freezes the system.  32K-dependent games still launch, however.

 

When either of these things occurs (CALL TIPI or launching XB), the TIPI's LED illuminates for the first time, for whatever that signifies. 

 

I tried repeating these procedures with the 32K connected via a speech synth module, to make sure the 32K was really drawing power from DC and not the console, and results were identical. 

 

I've tried a different 5V source, but with the same result (and the 32K was working in both cases with switch at EXT regardless). 

 

I've also stared daggers at the GPIO pin connections based on the enduring suspicion that I might somehow have got them mixed up.  But they really are wired as per the directions. 

 

I've got a keyboard and a screen attached to the Pi, in case any diagnostic exercises are helpful there. 

 

Any suggestions?

[+9640News]

Do you have separate power supply cables to the 32K and to the PI?

 

Beery

[+arcadeshopper]

Photo of your gpio connections please and the TIPI side too

Sent from my LM-G820 using Tapatalk

[tuf]

2 hours ago, arcadeshopper said:

Photo of your gpio connections please and the TIPI side too

Sent from my LM-G820 using Tapatalk
 

My money is on the headers.  Even with the docs it's tricky and I checked it about 100 times before firing up.

 

[pixelpedant]

Based on these suggestions and an inclination I'd considered initially but not followed through on, I pulled the GPIO wires and rewired it using 10 distinctly coloured jumpers (just easier to annotate and be absolutely sure of what's going where).  Also would make it easier to take a picture that can actually be discerned meaningfully.  Anyway, probably, it was indeed wired incorrectly, originally, and my brain just refused to see it.  Because that did it.  I knew it almost certainly wouldn't be a hardware defect, since I know you guys both test these things assiduously, and I appreciate that a lot. 

 

I've now got it all up and working, and my NanoPEB volumes transferred over. 

 

That took far too long to pull the trigger on.  But as I say, I had been doing a lot of RS232 stuff (got a room full of mostly RS232-controlled signal processing devices).  So the NanoPEB had been key, for a while there.  But since I've got a PC functioning as a (one to many) RS232 command router, there's no reason my service scripts there couldn't also support accepting messages from the TIPI in some other form (than RS232 itself), and only distribute them via RS232 at that point.  Also suppose I could just install a PL2303 adapter in the Pi, and set up a script there to pass things along, which would allow it to use the same wiring as the NanoPEB. 

[J-Data]

On 2/24/2020 at 8:57 PM, J-Data said:

I'll report back when I get the Cypress part.  Thanks again for all the help. 

Nope...   I replace the Alliance AS6C62256-55PCN SRAM with the Cypress CY62256L-70PC and I still have the exact same rebooting issue.  Every SRAM burnin test I run is successful to 256 cycles, but no joy on the flaky CALL TIPI behavior.  I did a very through inspection of all solder joints under a microscope at work, and all look good.

 

The one new observation is the longer the setup is powered up, the better it behaves.  From a cold start, nothing works, and the console will barely boot.  After being powered for an hour or more, I can boot it reliably, Run CALL TIPI, load EA5s from the web, and can even do this with a cart installed.  The unit being warmed-up really seems to help, and I saw the same behavior last week.  I'm suspecting a timing issue as propagation delays increase over temperature, although it could also be a power integrity issue.  Either way, I think its my console, not the TIPI or 32K side car.  (Hopefully I'll have my other console back together shorlty).

 

Any thoughts or suggestions?

[+InsaneMultitasker]

Lately I'm finding that the TIPI web client at http://tipi:9900/  is unreachable more often than it is reachable.

 

I /am/ able to access the PI via File explorer (via \\tipi) and if I PING "tipi", the pi3 responds (though only with the IPv6 address). 

 

On a whim I flushed the DNS resolver cache and attempted once again to browse to the TIPI web client and it immediately displayed.  Coincidence?  Is the PI3 dynamically changing something windows is expecting or is Windows the culprit here?

 

For reference I am using Win10 build 1809.  I did not restart the PI between its last working browsing session and the unreachable messages I ran into again today.

 

Thx

[+arcadeshopper]

When it doesn't work try pinging the IP..

Sent from my LM-G820 using Tapatalk

[+InsaneMultitasker]

On 2/29/2020 at 3:59 PM, arcadeshopper said:

When it doesn't work try pinging the IP..

Sent from my LM-G820 using Tapatalk
 

OK, today the web client is again not showing up. I went into TIPICFG, found the IP address, pinged it, and it replied. Ping also resolved to TIPI (using -a parameter).   Pinging TIPI results in "Pinging tipi.local [::28xxxxxxxxx]" and responses. I can access the TIPI share vie File Explorer.  

 

However, neither the IPV4 IP (192.168.x.x)  nor DNS (http://tipi:9900) will bring up the web page in the browser.  Flushing the DNS cache had no effect on the latter.  I tried from three different machines / browsers with no success.

 

So, I loaded TIPICFG again and re(B)ooted the PI.   Tried the web admin and it is working again with the reboot. Browsing some folders gives it pause for 3-4 seconds.  I don't see that delay in File Explorer. 

 

 

[+arcadeshopper]

Are you using a new sd card? It really sounds like some sort of pi issue what does dmesg say any errors?

Sent from my LM-G820 using Tapatalk

[+InsaneMultitasker]

I'm not familiar with what to look for with dmesg or how to use it.  Yes, the sd card is new for the tipi/rpi.  Everything works as expected except for the web UI. Does that point to a script or service halting on the pi?  When the web admin stops responding I can still use TIPI and the TI, and browse the TIPI share. The console is responsive.  If you have steps I can follow I'll poke at it.  

[+arcadeshopper]

I'm not familiar with what to look for with dmesg or how to use it.  Yes, the sd card is new for the tipi/rpi.  Everything works as expected except for the web UI. Does that point to a script or service halting on the pi?  When the web admin stops responding I can still use TIPI and the TI, and browse the TIPI share. The console is responsive.  If you have steps I can follow I'll poke at it.  

Errors would be obvious

Also TIPI has a log at /var/log/tipi/tipi.log

Sent from my LM-G820 using Tapatalk

[+jedimatt42]

7 hours ago, InsaneMultitasker said:

OK, today the web client is again not showing up. I went into TIPICFG, found the IP address, pinged it, and it replied. Ping also resolved to TIPI (using -a parameter).   Pinging TIPI results in "Pinging tipi.local [::28xxxxxxxxx]" and responses. I can access the TIPI share vie File Explorer.  

 

However, neither the IPV4 IP (192.168.x.x)  nor DNS (http://tipi:9900) will bring up the web page in the browser.  Flushing the DNS cache had no effect on the latter.  I tried from three different machines / browsers with no success.

 

So, I loaded TIPICFG again and re(B)ooted the PI.   Tried the web admin and it is working again with the reboot. Browsing some folders gives it pause for 3-4 seconds.  I don't see that delay in File Explorer. 

 

 

 

The web admin interface is the tipiweb.service and is indeed a separate service than the one that the 4A communicates with. Explorer access is through the linux smbd (samba) service. 

 

The web admin interface is backed by a sqlite database of the details inside the TIFILES files. This is normally kept up to date with some inotify hooks ( tipimon.service ), but if there are bunches of files that aren't populated in the database, then the service will actually open each TIFILES file and examine it as it builds the webpage.. It should write that back to the database so it is faster in the future, and eventually fully cached/up-to-date.  In one of the recent updates, I needed to delete this cache on you all, so that long-form XB programs would show up as BASIC programs in the web ui. It kind of sounds like this is failing to repopulate. 

 

For some reason the tipiweb.service is crashing... probably best source of info on that is /var/log/daemon.log  you'll have to ssh into the PI after the issue is present, to get it. The logs are stored on tmpfs ( ramdisk ) so as to not thrash your SD cards, so if you reboot the PI, the logs are gone.  From another linux machine or knowing how to use your own favorite ssh and sftp clients on windows do the equivalent of this when the failure occurs again:

 

ssh tipi@tipi
--- password dance ---
sudo cp /var/log/daemon.log /home/tipi/
--- password dance ---
exit

 

sftp tipi@tipi
--- password dance ---
get daemon.log

 

Only the primary tipi.service which is the one that does the real stuff in response to the 4A asking it to do the real stuff, logs to the /var/log/tipi/tipi.log - and that is configured within the service, so if that doesn't get far enough, the /var/log/daemon.log is where early failures get logged. 

 

-M@