TIPI Usage and Support

[globeron]

27 minutes ago, jedimatt42 said:

 

TIPI does not support sector IO, and I have no intention to do so... It is not meant to emulate a floppy or other spinny disk thing... There are no sectors as the files are individually contained as TIFILES files.  Sector IO is not the same as Direct Read and Direct Write LVL2 operations, those are supported as they refer to blocks of data within a file.  

 

 

For DSK. device usage ( volume name searching ) ( My TIPI wiki docs are wrong, lacking, and hard to find on this subject ) 

 

TIPI.TIMP. can be referred to as DSK.TIMP.

if directory TIPI.BUSINESS.TIMP is mapped to DSK3, then it can be referred to ask DSK.TIMP.

 

Mapped drives are searched first from 1 to 3, and then directories immediately under TIPI. are searched second.  If no name match is found, it should then attempt your subsequent storage devices.

 

-M@

 

 

Thank you for the clarifications! 

 

(I will try to load these files via a NanoPEB to see if I get it to work).

 

[globeron]

24 minutes ago, jedimatt42 said:

 

  @ElectricLab will have to address this issue with TIPI Chess v.003

 

-M@

 

Oh yeah...hahaha, sorry for posting it here...that's what happens when things get connected to the internet ?

[+jedimatt42]

Looks like there is another third party dependency that has broken out from under the TIPI upgrade process. 

 

People should hold off on upgrades, or take the latest SD Card image, until I can post a fix.

 

-M@

[mr_gw454]

3 hours ago, jedimatt42 said:

Looks like there is another third party dependency that has broken out from under the TIPI upgrade process. 

 

People should hold off on upgrades, or take the latest SD Card image, until I can post a fix.

 

-M@

Thanks for looking into this.  I really enjoy the TIPI and appreciate your ongoing support.

 

[+jedimatt42]

On 7/6/2019 at 10:34 AM, jedimatt42 said:

Looks like there is another third party dependency that has broken out from under the TIPI upgrade process. 

 

People should hold off on upgrades, or take the latest SD Card image, until I can post a fix.

 

-M@

Ok, seems it was just a bad dependency download that got stuck in the pip cache...  and sounds like manually deleting the python pip cache and manually re-running the upgrade script fixed it.

 

-M@

 

[+jedimatt42]

On 7/8/2019 at 7:05 AM, jedimatt42 said:

Ok, seems it was just a bad dependency download that got stuck in the pip cache...  and sounds like manually deleting the python pip cache and manually re-running the upgrade script fixed it.

 

-M@

 

Just to clarify, upgrades are not broken. 

There are no changes to address this specific issue. It was an individual anomaly not likely to impact users in general. 

 

-M@

[+9640News]

Matt,

 

I have an observation from some programming with the TIPI on the Geneve. This is more of a timing issue.  It is unknown if this can be duplicated on a TI-99/4A.  This could very well be a  non TI-99/4A issue since the 4A is slower.

 

I'm using my XOP that has various opcodes for MDOS programming.  One is to close a connection, another to open a connection, another to reset a connection, pass bytes or strings, etc.

 

In my work with modifying Tim's PORT program to use the TIPI which I do have running, I was working with the "phone dialer" capability to connect to various telnet servers.  I had similar code working within MyTerm, and when I thought I was using nearly identical code with PORT, I could not reset the connection and open another connection like I expected.  

 

When I looked at the coding differences, I discovered MyTerm had a few more instructions between the "reset" socket function and the "open" socket connection.  When I added a DEC register and JNE instruction loop of a count of 10, the problem disappeared.  I did not try the "close" socket function again, but suspect something similar was happening as well.

 

There appears to be a lag, possibly on the RPI side of things, that if a reset and a subsequent open connection is sent too quickly, the TIPI is caught in a hold.  Without the timing loop, the TIPI would finally return from the "open" socket connection with a connection to the server, however, it is somewhere around 30 seconds or so.  With the timing loop I added, to the user it is near instantaneous.

 

The Geneve (MEMEX/GenMOD system) is running faster than a TI-99/4A, so I am not sure if this is a behavior even seen on a TI-99/4A.  I know on the Geneve, from the time the XOP is called until the actual message is passed to the paged in TIPI DSR there are probably another 50 instructions called in addition to that timing loop I added.

 

If there was a timing/delay loop following a reset or close socket call in the TIPI messaging system, or perhaps some kind of "test" for the RPI to indicate to TIPI the connection was reset or closed, then it may be worth adding.  

 

Anyways, wanted to let you know what I observed.  I've solved it on my end by programming outside of TIPI, and this message will alert others to the potential issue should anyone else come across the same behavior.

 

Beery

 

 

 

[minty]

Hi all! Just received my TIPI PEB and I'm falling at the first hurdle - a 'call tipi' just returns 'bad name'. I'm not sure where to start debugging this. 

 

The PEB currently has four cards - the flex cable controller, 32K, RS232 and the disk controller. The Tipi is in slot 3 - the slot works, as I tested another card in that slot.

Would you expect 'call tipi' to work if the Pi wasn't working? (I originally tried this with a Pi Zero that I'm not sure works, but it's currently using a Pi 3 that I do know works).

Would you expect 'call tipi' to work if the CPLD were dead? (I had to make my own cable to connect the Pi - I accidentally swapped two pins, 37&39 I think, when I first tried - but I didn't do anything seriously fatal, like connect up the power to it).

 

Any pointers as to what I should try first? Many thanks in advance!

[+arcadeshopper]

Hi all! Just received my TIPI PEB and I'm falling at the first hurdle - a 'call tipi' just returns 'bad name'. I'm not sure where to start debugging this. 
 
The PEB currently has four cards - the flex cable controller, 32K, RS232 and the disk controller. The Tipi is in slot 3 - the slot works, as I tested another card in that slot.

Would you expect 'call tipi' to work if the Pi wasn't working? (I originally tried this with a Pi Zero that I'm not sure works, but it's currently using a Pi 3 that I do know works).
Would you expect 'call tipi' to work if the CPLD were dead? (I had to make my own cable to connect the Pi - I accidentally swapped two pins, 37&39 I think, when I first tried - but I didn't do anything seriously fatal, like connect up the power to it).
 
Any pointers as to what I should try first? Many thanks in advance!

Check the ROM chip and make sure it's seated firmly in the socket. It may have come loose in shipping.

Also if you have any issues with something you get from me contact me directly please. I am happy to help you resolve it.

Greg

Sent from my LM-G820 using Tapatalk

[HOME AUTOMATION]

6 hours ago, minty said:

Would you expect 'call tipi' to work if the Pi wasn't working?

This for me, causes the screen to freeze, while TIPI waits for a response from the PI.

[+arcadeshopper]

Correct the TI isn't seeing the DSR otherwise it would be waiting for the PI

Turns out he got the tipi from someone else.. I suggest looking for bad solder joints next on the surface mount chips and cpld

Sent from my LM-G820 using Tapatalk

[+jedimatt42]

On 8/28/2019 at 7:06 AM, BeeryMiller said:

Matt,

 

I have an observation from some programming with the TIPI on the Geneve. This is more of a timing issue.  It is unknown if this can be duplicated on a TI-99/4A.  This could very well be a  non TI-99/4A issue since the 4A is slower.

 

I'm using my XOP that has various opcodes for MDOS programming.  One is to close a connection, another to open a connection, another to reset a connection, pass bytes or strings, etc.

 

In my work with modifying Tim's PORT program to use the TIPI which I do have running, I was working with the "phone dialer" capability to connect to various telnet servers.  I had similar code working within MyTerm, and when I thought I was using nearly identical code with PORT, I could not reset the connection and open another connection like I expected.  

 

When I looked at the coding differences, I discovered MyTerm had a few more instructions between the "reset" socket function and the "open" socket connection.  When I added a DEC register and JNE instruction loop of a count of 10, the problem disappeared.  I did not try the "close" socket function again, but suspect something similar was happening as well.

 

There appears to be a lag, possibly on the RPI side of things, that if a reset and a subsequent open connection is sent too quickly, the TIPI is caught in a hold.  Without the timing loop, the TIPI would finally return from the "open" socket connection with a connection to the server, however, it is somewhere around 30 seconds or so.  With the timing loop I added, to the user it is near instantaneous.

 

The Geneve (MEMEX/GenMOD system) is running faster than a TI-99/4A, so I am not sure if this is a behavior even seen on a TI-99/4A.  I know on the Geneve, from the time the XOP is called until the actual message is passed to the paged in TIPI DSR there are probably another 50 instructions called in addition to that timing loop I added.

 

If there was a timing/delay loop following a reset or close socket call in the TIPI messaging system, or perhaps some kind of "test" for the RPI to indicate to TIPI the connection was reset or closed, then it may be worth adding.  

 

Anyways, wanted to let you know what I observed.  I've solved it on my end by programming outside of TIPI, and this message will alert others to the potential issue should anyone else come across the same behavior.

 

Beery

 

 

 

 

This is probably related to my not understanding python socket nuances.. https://stackoverflow.com/questions/23733719/python-socket-close-does-not-work-until-the-script-exit

 

I'll try the proposed solution in that stackoverflow link..

 

-M@

 

[+jedimatt42]

A free design for those who like to print things themselves:

 

https://www.thingiverse.com/thing:3919115

 

-M@

 

[jrhodes]

46 minutes ago, jedimatt42 said:

A free design for those who like to print things themselves:

 

https://www.thingiverse.com/thing:3919115

 

-M@

 

 

You could paint that up to look like a baby PEB stuck to the side of your TI

Edited October 16, 2019 by jrhodes

[Nick99]

9 hours ago, jrhodes said:

 

You could paint that up to look like a baby PEB stuck to the side of your TI

Wow, where can I buy a "baby PEB"? ?

I need a home for my 32Kb and TIPI cards...

[+arcadeshopper]

I can see about printing these, will print a prototype to test with current production boards

 

[+jedimatt42]

On 10/16/2019 at 12:34 PM, arcadeshopper said:

I can see about printing these, will print a prototype to test with current production boards

 

I need to take the time to design these better for other's to be successful printing... I have my 3d printer dialed in with minimal 'squish' so the face down printing isn't a problem. But I believe I should turn it around, and also make the face the part that comes off, instead of the back side... we'll see. Just had to refurbish my printer today for other reasons... 

[+jedimatt42]

@arcadeshopper asked about TIPI and Raspberry PI 4 compatibility.  ( I hear 3's are getting more expensive that 4's at this point ) 

 

I have a PI 4, but it has spent the summer in the box. .  So I just took it out today to look into this.  Currently, the answer is:  TIPI does NOT work with the PI 4. 

 

My SD card image is based on raspbian stretch lite, and the PI 4 won't boot that. 

I have started making a raspbian buster lite image, but I've encountered errors with my scripts that install the necessary prerequisites for the TIPI services.  So I'll need to debug that.  I didn't see any errors, except with the sqlite install.  So hopefully once that is remedied, it'll all just work. 

 

-M@

[wierd_w]

Hey Matt,

 

Have you given any thought to building TIPI disk images that have partitions aligned on 4, 8, and 16MB boundaries, and with EXT4 parameters with matching stripes?

(SDcards bigger than 16GB have erase block sizes at powers of 2, between 4MB and 16MB, depending on how big the card is.  A 16GB card probably has a 4MB erase block, A 32GB one probably has an 8MB one, and a 64GB one probably has a 16MB one, but this is not always the case. To be sure, you have to interrogate the card.)

 

It complicates matters for end users somewhat by given them choices, but appropriate images for their SDCard media would greatly improve not only read and write performance, but also card life.  To do writes smaller than the erase unit size, the microcontroller inside the SDCard accepts the data to be written into a small RAM buffer, reads the contents of the erase unit, applies the change in that memory, then blanks and overwrites the whole erase unit to incorporate the change. As you can imagine, this is harmful to SDCard media if the allocation units being written are small. It's better to queue up writes in the computer and write whole erase units at a go. That's what happens when you set up the stripe and stride-width parameters correctly.  The SDCard foundation wants people to use ExFAT because it can set the cluster size to obscene values like these.  EXT4 with stripes enabled is superior, because it does not introduce slack space (logical cluster is still 4k in size.) The kernel just writes more intelligently. (queues up writes until the stripe buffer is full, then writes the whole stripe.)

 

(For nitty gritty details, see this blog post- not mine, just useful.)

https://thelastmaimou.wordpress.com/2013/05/04/magic-soup-ext4-with-ssd-stripes-and-strides/

 

SDcard is basically just a wimpy SSD.

 

 

It was always my intention to custom-make my own TIPI image from your supplied one with these parameters and partition alignments in place, but I was just curious if you had ever considered this.

[+jedimatt42]

3 hours ago, wierd_w said:

Hey Matt,

 

Have you given any thought to building TIPI disk images that have partitions aligned on 4, 8, and 16MB boundaries, and with EXT4 parameters with matching stripes?

(SDcards bigger than 16GB have erase block sizes at powers of 2, between 4MB and 16MB, depending on how big the card is.  A 16GB card probably has a 4MB erase block, A 32GB one probably has an 8MB one, and a 64GB one probably has a 16MB one, but this is not always the case. To be sure, you have to interrogate the card.)

 

It complicates matters for end users somewhat by given them choices, but appropriate images for their SDCard media would greatly improve not only read and write performance, but also card life.  To do writes smaller than the erase unit size, the microcontroller inside the SDCard accepts the data to be written into a small RAM buffer, reads the contents of the erase unit, applies the change in that memory, then blanks and overwrites the whole erase unit to incorporate the change. As you can imagine, this is harmful to SDCard media if the allocation units being written are small. It's better to queue up writes in the computer and write whole erase units at a go. That's what happens when you set up the stripe and stride-width parameters correctly.  The SDCard foundation wants people to use ExFAT because it can set the cluster size to obscene values like these.  EXT4 with stripes enabled is superior, because it does not introduce slack space (logical cluster is still 4k in size.) The kernel just writes more intelligently. (queues up writes until the stripe buffer is full, then writes the whole stripe.)

 

(For nitty gritty details, see this blog post- not mine, just useful.)

https://thelastmaimou.wordpress.com/2013/05/04/magic-soup-ext4-with-ssd-stripes-and-strides/

 

SDcard is basically just a wimpy SSD.

 

 

It was always my intention to custom-make my own TIPI image from your supplied one with these parameters and partition alignments in place, but I was just curious if you had ever considered this.

 

That's more work than I'll ever care to care about. SD cards are cheap, plan to burn them out, every couple years... my advice to anyone would be to learn Linux and implement a backup system. 

 

I have put effort into ensuring that /var/log, /tmp/ and /var/tmp are all ramdisk(tmpfs) so the OS isn't destroying the cards actively. 

 

-M@

 

 

[+jedimatt42]

4 hours ago, jedimatt42 said:

@arcadeshopper asked about TIPI and Raspberry PI 4 compatibility.  ( I hear 3's are getting more expensive that 4's at this point ) 

 

I have a PI 4, but it has spent the summer in the box. .  So I just took it out today to look into this.  Currently, the answer is:  TIPI does NOT work with the PI 4. 

 

My SD card image is based on raspbian stretch lite, and the PI 4 won't boot that. 

I have started making a raspbian buster lite image, but I've encountered errors with my scripts that install the necessary prerequisites for the TIPI services.  So I'll need to debug that.  I didn't see any errors, except with the sqlite install.  So hopefully once that is remedied, it'll all just work. 

 

-M@

 

Ok, I finished getting it working on PI 4... Raspbian Buster..    A new image marked as such is on my downloads page.  

 

So now, TIPI does work with the PI 4.

 

-M@

 

[jrhodes]

18 hours ago, jedimatt42 said:

 

Ok, I finished getting it working on PI 4... Raspbian Buster..    A new image marked as such is on my downloads page.  

 

So now, TIPI does work with the PI 4.

 

-M@

 

Good to know!

I'll keep using my PI 3B for as long as it keeps chugging along, but when or if i ever need to get a replacement, may as well go for the PI 4.

[+jedimatt42]

28 minutes ago, jrhodes said:

Good to know!

I'll keep using my PI 3B for as long as it keeps chugging along, but when or if i ever need to get a replacement, may as well go for the PI 4.

 

TIPI services only run the PI at 1% or 2% CPU load, except for brief 100% bursts when transferring data.  So if you treat your PI 3 with respect, I would expect it to last as long as a TI-99/4A. 

 

(Hyperbolic statement shared only for amusement) 

 

-M@

[jrhodes]

I'm pretty sure this is not a issue with my TI or TIPI, but it is still the best place i have to ask this question:

I was playing some games from my FinalGrom99, when i decided to go mess around in Extended Basic, so i selected it from the FinalGrom99, but all i got was a blank blue screen.

I know what causes it, Extended Basic is looking for DSK1.LOAD and not finding a DSK1. , because the Pi is not responding.

My Pi is connected correctly and is booted up as confirmed by the output of the mini monitor i have connected to it.

The power (red) and activity (green) LEDs are both on solid and bright, but the Pi will not respond to keyboard input like it should.

I searched "raspberry pi 3b+ steady green light no response" and it seems the always on green light means it can not read bootcode.bin at bootup time.

But i am past boot up, the Pi is booted and had been running for more then 20 minutes prior to the lock up.

I ended up pulling the power and resetting it, now it works like it should.

Any ideas why it locked up? is there a sleep time setting or something i should look at?

[wierd_w]

From what I was reading, the IO timing with the Pi is pretty tight. It might have been the GPIOs being in a "not-sane" state.