TIPI Usage and Support

[+arcadeshopper]

32 minutes ago, dhe said:

Given the header, something like purple wire up and closest to the console, black wire up and farthest away from the console. Once I know I have it properly connected, I'll probably take a silver sharpy and on the end facing up, slather it silver. I had to do that on my Myarc disk controller cables also, because for me, if it can be plugged in wrong, I probably will.

the nice thing is as long as you are on the USB END of the PI  you can't break anything. it just won't work if the connectors are incorrect..  IT'S the other end of the PI that is THE DANGER ZONE see diagram below, POWER is on the other end..

 

TIPI pinout:  PI pinout

TIPI pins                         PI GPIO

         1                           31

         2                           32

         3                           33

         4                           34

         5                           35

         6                           36

         7                           37

         8                           38

         9                           39

        10                          40

 

SO

one connector goes from TIPI pins 1,3,5,7,9 with the same color (say black) on pin 1 of the TIPI, to pins 31,33,35,37,39 on the PI with that color (black) going to pin 31 on the PI.. 

and the other goes From TIPI pins 2,4,6,8,10 goes to pi 32,34,36,38,40 with color (black) on pin 2 of the TIPI going to pin 32 of the PI

 

(for those of you with the all white cables, just color the wire on one side of each cable black with a sharpie..so you have the same method.. one side of the cable is easily identified) 

   

again, these are the pins CLOSEST TO THE USB PORTS on the PI.. make sure you are on the correct pins before powering on..   

 

this is all detailed here: https://github.com/jedimatt42/tipi/wiki/TIPI-to-PI-Wiring

 

Greg

 

[+jedimatt42]

Do these pictures help?  

 

 

 

-- 

More than a year ago, when I was making TIPIs I shipped them with a pair of 1x5 Dupont cables. 

 

You might have received different cabling since then... 

 

-M@

[+jedimatt42]

1 hour ago, dhe said:

Given the header, something like purple wire up and closest to the console, black wire up and farthest away from the console. Once I know I have it properly connected, I'll probably take a silver sharpy and on the end facing up, slather it silver. I had to do that on my Myarc disk controller cables also, because for me, if it can be plugged in wrong, I probably will.

 

The problem is as a project, I can't document wire coloring.  I don't control the building and distribution of these things.  If suppliers deviate from the original cabling, you are stuck with their documentation. I bought cables from a supplier in Taiwan. Sometimes they were multi-colored. Other times solid colored. I've seen IDC connector ribbon cables used. If they are crimped the standard way, then I can provide a ghost image of how they fit into the PI, and well they only go into the TIPI one way. 

 

-M@

[+jedimatt42]

I've updated the wiki to be specific about what pins on the Raspberry PI will cause damage to the TIPI board. Added the new diagrams I posted above. Updated the rootfs grow documentation: 

 

Old sd card images were 2GB, and needed to be grown or TIPI update processes typically failed. New images (as of about November 2019) are 4GB to start with, so growing the root filesystem is no longer fatal if forgotten. 

 

-M@

[+arcadeshopper]

@dhe any of this help?

Sent from my LM-G820 using Tapatalk

[HOME AUTOMATION]

I noticed the correlation of the pin numbers, is similar to the conversion of decimal to ASCII.

[+jedimatt42]

1 hour ago, HOME AUTOMATION said:

I noticed the correlation of the pin numbers, is similar to the conversion of decimal to ASCII.

 

Any linear sequence of numbers starting at 1 matched to another linear sequence of numbers starting at an offset not equal to 1 might trigger the same recognition of similarity. 

 

-M@  

 

[+9640News]

On 4/3/2019 at 12:21 PM, --- Ω --- said:

For those with CorComp real time clocks and a TIPI's installed, the program below should take the TIPI time from the Internet and save it to your CorComp card without the hassle of typing anything...

 

** REMOVED **

 

....of course this would be even better compiled into an E/A5 program we could run out of 4A/DOS or even made into a BIN file for the FR/FG99.

Does this code exist?  Looks like it was removed.

[Omega-TI]

1 hour ago, BeeryMiller said:

Does this code exist?  Looks like it was removed.

Yeah, I removed it because it refused to work.  I read everything properly, and even looked like it wrote properly, but it didn't.  The BASIC code was proper and there was no reason it should not have worked, so instead of leaving something online that was garbage, I killed it.

[+9640News]

15 minutes ago, --- Ω --- said:

Yeah, I removed it because it refused to work.  I read everything properly, and even looked like it wrote properly, but it didn't.  The BASIC code was proper and there was no reason it should not have worked, so instead of leaving something online that was garbage, I killed it.

Hmmmm.    I know Matt indicated access the time was through the DSR which confirmed what I read yesterday.  So, between what you posted, and what Matt indicated, it sounds like you were connecting with the internet to get the date/time presumably through a website versus using Matt's DSR?  

 

Could there have been the use of Greenwich mean time unaccounted for or does the PI need to have date/time manually setup after an established internet connection?  I know Windows does it automatically, just do not know about the Raspberry PI software. 

 

As I do not know all the nuances between basic linking to the DSR versus assembly linking to the DSR, would one expect basic and assembly language to return the same hex values, or has basic adjusted for a numerical ascii display offset that is returned back to the program?  What I am trying to figure out is if I read a record, will assembly language return a "text" value such as ascii 9 (0x39 or maybe 0x3039 for "09") or  hex 0x0009 that must then be adjusted to a 24 hour clock for a 9 AM time?  It has been years, but I seem to recall basic calls go through some kind of error manipulation for error codes and did not know how things got passed around.

 

Beery

 

 

 

 

[+arcadeshopper]

110 OPEN #1:"PI.CLOCK"
120 INPUT #1:A$,B$,C$
150 PRINT A$,B$,C$
160 CLOSE #1

 

so likely this would set the corcomp clock with the tipi clock

 

110 OPEN #1:"PI.CLOCK"
120 INPUT #1:A$,B$,C$
150 PRINT A$,B$,C$
160 CLOSE #1
170 OPEN #1:"CLOCK"
180 PRINT #1:A$,B$,C$
190 CLOSE #1

 

[+jedimatt42]

The sd card image should have the timezones set to Pacific. 

 

I suppose I should provide instructions for changing it.

 

-M@

[+jedimatt42]

3 hours ago, BeeryMiller said:

Hmmmm.    I know Matt indicated access the time was through the DSR which confirmed what I read yesterday.  So, between what you posted, and what Matt indicated, it sounds like you were connecting with the internet to get the date/time presumably through a website versus using Matt's DSR?  

 

Could there have been the use of Greenwich mean time unaccounted for or does the PI need to have date/time manually setup after an established internet connection?  I know Windows does it automatically, just do not know about the Raspberry PI software. 

 

As I do not know all the nuances between basic linking to the DSR versus assembly linking to the DSR, would one expect basic and assembly language to return the same hex values, or has basic adjusted for a numerical ascii display offset that is returned back to the program?  What I am trying to figure out is if I read a record, will assembly language return a "text" value such as ascii 9 (0x39 or maybe 0x3039 for "09") or  hex 0x0009 that must then be adjusted to a 24 hour clock for a 9 AM time?  It has been years, but I seem to recall basic calls go through some kind of error manipulation for error codes and did not know how things got passed around.

 

Beery

 

 

 

 

 

The record format is shown here: https://github.com/jedimatt42/tipi/wiki/PI.CLOCK

 

-M@

[+arcadeshopper]

4 minutes ago, jedimatt42 said:

The sd card image should have the timezones set to Pacific. 

 

I suppose I should provide instructions for changing it.

 

-M@

sudo timedatectl set-timezone Australia/Sydney  

 

or whatever your timezone is.. for a list  "ls /usr/share/zoneinfo/"

[Omega-TI]

This is what I had on my TIPI's SD card.  Maybe you can tell me why it's not working?

 

10 CALL CLEAR
20 OPEN #1:"CLOCK"
30 INPUT #1:C1$,C2$,C3$
40 CLOSE #1
50 PRINT "RTC: ";C2$,C3$
60 OPEN #2:"PI.CLOCK"
70 INPUT #2:A$,B$,C$
80 CLOSE #2
85 PRINT "RPI: ";B$,C$
90 D$=A$&","&B$&","&C$
100 OPEN #1:"CLOCK"
110 PRINT #1:D$
111 CLOSE #1
115 PRINT "----------------------"
120 PRINT "SET: ";B$;" ";C$
 

print_2020_01_21_T19_33_26.pdf

[HOME AUTOMATION]

5 hours ago, --- Ω --- said:

This is what I had on my TIPI's SD card.  Maybe you can tell me why it's not working?

 

10 CALL CLEAR
20 OPEN #1:"CLOCK"
30 INPUT #1:C1$,C2$,C3$
40 CLOSE #1
50 PRINT "RTC: ";C2$,C3$
60 OPEN #2:"PI.CLOCK"
70 INPUT #2:A$,B$,C$
80 CLOSE #2
85 PRINT "RPI: ";B$,C$
90 D$=A$&","&B$&","&C$
100 OPEN #1:"CLOCK"
110 PRINT #1:D$
111 CLOSE #1
115 PRINT "----------------------"
120 PRINT "SET: ";B$;" ";C$
 

print_2020_01_21_T19_33_26.pdf 74.23 kB · 0 downloads

Print separators need to appear, between the strings, exactly the way the "&" do, not within the strings!

 

 

don't know if you ever saw this, as I didn't QUOTE you.

 

#40

 

I still think the versions I provided after "maybe..." should work, although line 90, serves no purpose there.

Edited January 22, 2020 by HOME AUTOMATION

[Omega-TI]

The problem is: In message #40 the example given:  

 

results in an I/O error: 

 

The usage in line 90 ( D$=A$&","&B$&","&C$ ) was derived from the example listed in the original manual.

 

The second count apparently will never be accurate.

 

 

 

 

[+jedimatt42]

16 hours ago, arcadeshopper said:

sudo timedatectl set-timezone Australia/Sydney  

 

or whatever your timezone is.. for a list  "ls /usr/share/zoneinfo/"

It is actually much more complicated than that, maybe. raspi-config delegates to dpkg-reconfigure so any software that needs to know about the change gets updated. Anyway, I'll make a pass at upleveling more raspi-config operations to PI.CONFIG

[wierd_w]

(nevermind, atari-age was pointing me to an ancient page, and I was responding to old discussion.)

Edited January 22, 2020 by wierd_w

[+arcadeshopper]

Actually it was just added to pi.config in the latest update

Sent from my LM-G820 using Tapatalk

[Omega-TI]

Speaking of updates, has anyone else had any issues communicating with the TIPI via the browser since the updates?  I can load and save via Classic 99.  I can communicate via TI99Dir.  I can also communicate as a network drive, but every time I try to use the browser it just hangs. 

 

I've tried using: http://192.168.0.35:9900/files  (I've confirmed that is the proper IP#)

I've also tried using: tipi:9900/files

[+9640News]

Hmmm, that begs a question as I forgot about the PI monitoring some ports.  What port(s) is the PI already using such that a BIND and subsequent ACCEPT request would be problematic?  This past weekend, I was trying to BIND to *:23 for the "standard" telnet port however I kept having problems, so I went to another port at about the same time I made some other changes.  Between the two changes, my code worked.  I did not want to undo all the port forwarding stuff again, so I left everything alone.

 

My responses back if I remember correctly suggest I was BINDing to port 23 without error, but I could never get an ACCEPT to respond.  As I noted above, I made another change to some code while also changing the BIND connection to 9901 and changed port forwarding when things started to work.

 

Beery

 

[ElectricLab]

4 hours ago, BeeryMiller said:

Hmmm, that begs a question as I forgot about the PI monitoring some ports.  What port(s) is the PI already using such that a BIND and subsequent ACCEPT request would be problematic?  This past weekend, I was trying to BIND to *:23 for the "standard" telnet port however I kept having problems, so I went to another port at about the same time I made some other changes.  Between the two changes, my code worked.  I did not want to undo all the port forwarding stuff again, so I left everything alone.

 

My responses back if I remember correctly suggest I was BINDing to port 23 without error, but I could never get an ACCEPT to respond.  As I noted above, I made another change to some code while also changing the BIND connection to 9901 and changed port forwarding when things started to work.

 

Beery

 

Ports <1000 in Unix are privileged, and I’m not sure the recent Pi code that does sockets runs as root or not. I sure hope not for security’s sake.

[J-Data]

Hi All,

 

Sorry for the Noob question. 

 

In anticipation of getting my TIPI sometime soon (on the wait list), I downloaded the latest TIPI Pi images and loaded it on one of my Pis, as I wanted to start setting up my DSK files/folders, network configuration, and get password, Samba, and SSH setups in place to be ready for the hardware.  Unfortunately, it appears can't get the WiFi configured on the Pi to use my network without the TIPI attached, or at least without potentially affecting the TIPI Pi image in a negative way.  I tried manually editing the tipi.config file, but this does not appear to have any affect on the Linux iwconfig settings (without the TIPI).  I tried doing my normal Raspbian command line method to connect to WiFi, but not without issues/errors.  I tried on both a Raspberry Pi 3B and ZeroW, with the same results, although the wired Ethernet on the 3B works fine.  I have several other Pie's on my network, so something appears to be blocking about this Raspian image. 

 

Am I correct in assuming the WiFi set-ups can only be done through the CALL TIPI from the TI without breaking the TIPI's control of the network configuration?  Do I just need to wait for the TIPI hardware to set-up my Pi configuration?

 

Thanks,

 

JP

--

Edited January 23, 2020 by J-Data

[+arcadeshopper]

Hi All,
 
Sorry for the Noob question. 
 
In anticipation of getting my TIPI sometime soon (on the wait list), I downloaded the latest TIPI Pi images and loaded it on one of my Pis, as I wanted to start setting up my DSK files/folders, network configuration, and get password, Samba, and SSH setups in place to be ready for the hardware.  Unfortunately, it appears can't get the WiFi configured on the Pi to use my network without the TIPI attached, or at least without potentially affecting the TIPI Pi image in a negative way.  I tried manually editing the tipi.config file, but this does not appear to have any affect on the Linux iwconfig settings (without the TIPI).  I tried doing my normal Raspbian command line method to connect to WiFi, but not without issues/errors.  I tried on both a Raspberry Pi 3B and ZeroW, with the same results, although the wired Ethernet on the 3B works fine.  I have several other Pie's on my network, so something appears to be blocking about this Raspian image. 
 
Am I correct in assuming the WiFi set-ups can only be done through the CALL TIPI from the TI without breaking the TIPI's control of the network configuration?  Do I just need to wait for the TIPI hardware to set-up my Pi configuration?
 
Thanks,
 
JP
--

Nope you can set up the wifi like you do in any raspberry pi.

Sent from my LM-G820 using Tapatalk