TIPI Usage and Support

[+jedimatt42]

I know the Adafruit PiOLED - 128x32 Monochrome OLED Add-on for Raspberry Pi is used to be a status display for the TiPi. Some months back, Matt had to update the OLED library as something changed. So it makes me wonder based on the update would other OLED such as an OLED 128x64 (HERE) work with out if wired correctly to the Pi3 for status without having to hack the current tipi image?

Different OLED displays are not software compatible.

 

The same technique and often library can be used to address a family of them, but they have different i2c addresses, and you're going to want to render the image displayed differently for the alternative form factor.

 

Instead of hacking it, you could contribute it.

 

-M@

[+Lee Stewart]

...

I have been wondering who really cares about copying from TIPI to physical floppies... except to run those gems that require true >10 - sector read write.

 

-M@

 

TI Forth requires sector I/O for blocks (4 sectors each) and fbForth uses it if reading/writing TI Forth blocks.

 

...lee

[Omega-TI]

Okay, this old dog needs to learn a new trick on TIPI's RPi.

How do you, using the TELNET program, set the RPi's time to PACIFIC instead of the default UTC/GMT? Or has someone already written an EA/5 or BASIC program to accomplish this task already?

[Shift838]

Okay, this old dog needs to learn a new trick on TIPI's RPi.

How do you, using the TELNET program, set the RPi's time to PACIFIC instead of the default UTC/GMT? Or has someone already written an EA/5 or BASIC program to accomplish this task already?

 

Are you talking about the Telnet program for the TiPi or a telnet program for the raspberry??

 

for the Tipi, just save the files to a directory. I call mine 'NET'

 

I can then load it up via TI-BASIC with

 

CALL TIPI("TIPI.NET.TELNET")

 

To change the time of the raspberry you will have to go into the rapsberry config.

 

So SSH into the tipi and once logged in, issue a sudo raspi-config

 

you will have to go to internalization options I believe, change the timezone. This is where you change the keyboard layout too. then save and reboot the pi.

[+arcadeshopper]

so unfortunately raspi-config wants a terminal it recognizes.. the standard terminal type for TIPI.NET.TELNET is "network" and if I set that to ansi or vt100 neither work exactly right with the screen controls due to lack of arrow key support as well as the 23 line screen instead of 24 lines.. SO use putty from a PC and ssh in to pi@tipi and run sudo raspi-config and select localization or do sudo dpkg-reconfigure tzdata

 

both do the same thing

 

Greg

[Omega-TI]

Yeah, well... dunno if it's my blasted memory or what, but it looks like I'm locked out.

 

 

[+jedimatt42]

If you didn't change passwords, then look here: https://github.com/jedimatt42/tipi/wiki/tipipeb-installation

 

you don't need to use the 'pi' user... use the tipi user.

 

-M@

[Omega-TI]

If you didn't change passwords, then look here: https://github.com/jedimatt42/tipi/wiki/tipipeb-installation

 

you don't need to use the 'pi' user... use the tipi user.

 

-M@

 

Thanks Matt, I'll go check it out now.

[Omega-TI]

Qapla!

[+9640News]

Along the lines of questioning here about telnetting into the PI. I was on my Geneve, running MyTerm with the WiModem232. I established a connection with the PI (connected to TIPI), however, about 5 to 10 seconds later, it disconnected.

It appears one can use PuTTy to get in from the above comments. Is there something different, or a keypress or command the PI is expecting to get a login prompt, etc?

 

Was curious along the lines that if a connection could be established from another TI or Geneve computer to the PI, if I could then find a tool that would run on the PI I could launch that would initiate a file transfer. Thus, moving files from the Geneve in my example over into a directory preferably under the TIPI framework.

 

Beery

[+arcadeshopper]

Along the lines of questioning here about telnetting into the PI. I was on my Geneve, running MyTerm with the WiModem232. I established a connection with the PI (connected to TIPI), however, about 5 to 10 seconds later, it disconnected.

It appears one can use PuTTy to get in from the above comments. Is there something different, or a keypress or command the PI is expecting to get a login prompt, etc?

 

Was curious along the lines that if a connection could be established from another TI or Geneve computer to the PI, if I could then find a tool that would run on the PI I could launch that would initiate a file transfer. Thus, moving files from the Geneve in my example over into a directory preferably under the TIPI framework.

 

Beery

 

geneve with terminal and wifi modem,then you can use xmodem with the linux tool https://linux.die.net/man/1/rz if that's not installed already its just sudo apt-get install rz

[+jedimatt42]

I believe TIPI's Telnet service is bound to the loopback adapter only. So for external access you must use SSH.

 

-M@

[+9640News]

 

geneve with terminal and wifi modem,then you can use xmodem with the linux tool https://linux.die.net/man/1/rz if that's not installed already its just sudo apt-get install rz

 

I logged in as a TIPI user, and typed the sudo apt-get install rz into the command line and I get "Unable to locate package rz"

 

sudo ap

[+jedimatt42]

There is a huge internet of support around Raspbian. The tipi sd-card image is based on Raspbian linux.

 

Back up your stuff, cause my support for this will be "reflash the sd card"

 

But a hint: package names and executable names are not 1:1 and package names vary across linux distributions.

 

Back up your stuff, cause my support for this will be "reflash the sd card"

 

 

-M@

[+9640News]

Gotcha Matt!

[+arcadeshopper]

 

I logged in as a TIPI user, and typed the sudo apt-get install rz into the command line and I get "Unable to locate package rz"

 

sudo ap

 

sorry package is sudo apt-get install lrzsz

[Omega-TI]

Hey guys, I seem to remember something about about running the TIPI at 1800 instead of the 1000 that I currently have it set to. Can someone refresh my memory about why that would 'better'. Don't get me wrong, other than the TI FDC copying issue from TIPI to DSK1 it works, I just don't remember WHY it's supposed to have an advantage either way (if any).

[+Lee Stewart]

Hey guys, I seem to remember something about about running the TIPI at 1800 instead of the 1000 that I currently have it set to. Can someone refresh my memory about why that would 'better'. Don't get me wrong, other than the TI FDC copying issue from TIPI to DSK1 it works, I just don't remember WHY it's supposed to have an advantage either way (if any).

 

Well...The routine (DSRLNK in Assembler) that searches for device names (DSK1, DSK2, DSK, SCS, TIPI, ...) and links to a peripheral controller card’s Device Service Routine (DSR) starts searching the DSR space of peripheral cards at CRU address 1000h and proceeds to higher addresses in 100h increments until the device name is found or CRU address 2000h is reached (no card contains the device name). If there are multiple cards that contain the device name, the one with the lowest CRU address is the one that will service the request, forever preventing cards at higher CRU addresses from ever having a chance.

 

You set a card to a low CRU address (1000h, say) when you want to insure it will be the one to service your device, particularly when more than one DSR in you system can service a given device name. If you are certain your device name (TIPI, say) is unique to one card or you want that card to serve your device name (DSK1, say) only as a last resort, you would set it to a higher CRU address (1800h, say).

 

...lee

[RXB]

I thought there was a patch to make it search DSR names from >1F00 backwards to >1000?

 

I remember someone did this for a good reason, but do not remember who did it.

 

(DEBUGGER CARD at >1F00 ?)

Edited September 29, 2018 by RXB

[Omega-TI]

 

Well...The routine (DSRLNK in Assembler) that searches for device names (DSK1, DSK2, DSK, SCS, TIPI, ...) and links to a peripheral controller card’s Device Service Routine (DSR) starts searching the DSR space of peripheral cards at CRU address 1000h and proceeds to higher addresses in 100h increments until the device name is found or CRU address 2000h is reached (no card contains the device name). If there are multiple cards that contain the device name, the one with the lowest CRU address is the one that will service the request, forever preventing cards at higher CRU addresses from ever having a chance.

 

You set a card to a low CRU address (1000h, say) when you want to insure it will be the one to service your device, particularly when more than one DSR in you system can service a given device name. If you are certain your device name (TIPI, say) is unique to one card or you want that card to serve your device name (DSK1, say) only as a last resort, you would set it to a higher CRU address (1800h, say).

 

...lee

 

Ahh soo! Thanks Lee!

I might consider doing that when I next open my P-Box. (No telling when that will be though!)

I do keep DSK1 set as the HxC with 2 & 3 on the TIPI, but for the most part I use the actual path names for most things within 4A/DOS, that way I don't have to keep resetting drives or having to remember what is where and when.

 

Following what you just told me, I have a TI RS-232 I'm not currently using, but I did the resistor mod to facilitate use as RS-232/3 and RS-232/4. Is it safe to assume without a non modified RS-232 working as /1 & /2 that it'll work normally without having to re-position the resistor if I ever want to use it again?

[Omega-TI]

I thought there was a patch to make it search DSR names from >1F00 backwards to >1000?

 

Dunno...

[+Lee Stewart]

 

Ahh soo! Thanks Lee!

I might consider doing that when I next open my P-Box. (No telling when that will be though!)

I do keep DSK1 set as the HxC with 2 & 3 on the TIPI, but for the most part I use the actual path names for most things within 4A/DOS, that way I don't have to keep resetting drives or having to remember what is where and when.

 

Following what you just told me, I have a TI RS-232 I'm not currently using, but I did the resistor mod to facilitate use as RS-232/3 and RS-232/4. Is it safe to assume without a non modified RS-232 working as /1 & /2 that it'll work normally without having to re-position the resistor if I ever want to use it again?

 

I believe the resistor mod to the TI RS-232 changes its CRU address from 1300h to 1500h and sets it up to respond as RS232/3 and RS232/4 at the new address. As long as 1500h does not conflict with other cards, I should think the card would work as RS232/3 and RS232/4 regardless of whether there is a card present to service RS232/1 and RS232/2.

 

...lee

[atrax27407]

It doesn't need a resistor. The modification to change the CRU address involves unsoldering and resoldering a link on the card from one position to another. A dip switch could also be used.

[+arcadeshopper]

Hey guys, I seem to remember something about about running the TIPI at 1800 instead of the 1000 that I currently have it set to. Can someone refresh my memory about why that would 'better'. Don't get me wrong, other than the TI FDC copying issue from TIPI to DSK1 it works, I just don't remember WHY it's supposed to have an advantage either way (if any).

 

1000 makes it answer DSK1-4 before the disk controller

1800 makes it answer AFTER the disk controller (ie, never)

 

I put a jumper out of my pbox so I could leave it at 1000 for most applications and switch it to 1800 when I need to copy data to the disk drives with DM2k etc. without opening everything up every time.. just move the jumper from one wire to the other. other than copying with a disk manager there is no reason to not allow TIPI in front of the disk controller imho..

 

Greg

[+InsaneMultitasker]

There are some programs that start their scans at 0x1200 to skip the disk controller, then wrap back around to 0x1000 and 0x1100 purposely, so that other disk-related devices have a chance of responding first. This had to do with other conflicts that people were experiencing with ramdisks and the various other controllers. Archiver is one prominent example of a program that starts scanning at 0x1200. I don't think this was practice was used too often.