TIPI - TI-99/4A to Raspberry PI interface development

[+jedimatt42]

I don't want it to block..  It will ideally just report what it finds... Internet access is intended to be optional.

 

I don't recall it blocking back at our last 'Fest-West' at Vancouver, or when the Portland gang used to meetup pre-pandemic... so I'll see.

[HOME AUTOMATION]

I noticed the same behavior GDMIKE, mentions, early-on in my usage. I have a first-run TIPI, side-car, and have switched to the first ROM update. I don't think that I noticed this behavior until after I traded ROMs, but I am unsure. I assumed that this might be normal, and didn't want to ...PYO.

[GDMike]

WHY is everyone afraid of Matt. I don't think he can get po. He's always answered our dumb questions, with a smile ?

[SkyPilot]

It's unclear, did you try hot spotting your cell phone?  That would supply an IP number. 

[+jedimatt42]

29 minutes ago, SkyPilot said:

It's unclear, did you try hot spotting your cell phone?  That would supply an IP number. 

The goal, as I understand, isn't to have an IP address, but to have TIPI software gracefully degrade when a network cannot be reached.

 

 

[+arcadeshopper]

On 7/28/2022 at 9:08 AM, xahmol said:

Just to check after glancing a lot of posts I missed I see the last couple of weeks:

Is my understanding correct that changing the TIPI DSR ROM for a new one is only needed for a very small subset of TI programs, s9 probably not worth the hassle for most users / me?

And if I would want to change the ROM by using this ( https://www.arcadeshopper.com/wp/store/#!/TIPI-DSR-Rom-upgrade-service/p/104220340/category=115338525?

- would that indeed get me this update?

- is that ROM socketed? Or is desoldering and soldering needed? (Can’t check as I am on a holiday now do far from my TIPI).

yes i send the latest rom with the upgrade service

roms are socketed on all the boards I sell .. ymmv if you get one somewhere else

[+9640News]

@jedimatt42

 

I have a question.  The PI has multiple USB ports.  Is there a way to connect a flash drive to the PI, and it be mapped as a subdirectory in the TIPI listing of files from the root directory?

 

I'm thinking of the process to share files between other PI's without networking the PI's together.  So, if for instance I am somewhere and want to share files, I can essentially copy the files to the flash drive, and hand off that flash drive to another individual and those files can then be copied to the other user's PI.

 

With @Shift838 PEBox and those pretty USB ports on the case, I am wondering about using them to connect to the PI and adding another method of exchanging files if the need arises.

 

Beery

[+mizapf]

There should be no problem mounting the flash drive to some mount point under /home/pi. However, the PI somewhere else also needs to mount that drive to that location when you plug in the drive. Unless you want to open a console and do the same mounting job on the target PI computer, you'd need something like a standard mount point, and then things become complicated. For example, what happens when you plug in two flash drives at the same time? In common Linux environments, the USB drives are mounted by their volume name or volume ID in /run/media/.

 

I think you can set up a udev rule to make the PI mount the drive at a fixed location unless there is already something mounted.

 

Or you can set up a defined volume name for that USB flash drive (e.g. you must name it "extflash") and then set up a symlink.

[+OLD CS1]

What about a symlink in /home/pi, say usb -> /run/media, where any flash drive would show up?

[Shift838]

21 hours ago, 9640News said:

@jedimatt42

 

I have a question.  The PI has multiple USB ports.  Is there a way to connect a flash drive to the PI, and it be mapped as a subdirectory in the TIPI listing of files from the root directory?

 

I'm thinking of the process to share files between other PI's without networking the PI's together.  So, if for instance I am somewhere and want to share files, I can essentially copy the files to the flash drive, and hand off that flash drive to another individual and those files can then be copied to the other user's PI.

 

With @Shift838 PEBox and those pretty USB ports on the case, I am wondering about using them to connect to the PI and adding another method of exchanging files if the need arises.

 

Beery

once the flash drive is mounted you can create a share to share it out to your network via SAMBA.  Make sure you change the permissions on the share with 777 permission to allow anyone on your network to be able to copy files to it.  You will have to edit your /etc/samba/smb.conf file for the share..  something like:

 

[SHARENAMEHERE]
path = /SHARED FOLDER PATH HERE
writeable = yes
browseable = yes
create mask = 0777
directory mask = 0777
public = no

 

Then you can just drag and drop from any PC on your network to it once connected.  

 

If you want to use the front USB ports that are connected to the 838-PEB, then you could simple get a USB A cable and chop off one end.  Then just wire up the D+ and D- to the USB header pins above the USB 3.0 connector on the 838-PEB board.  Plug one end into the raspberry pi.  You should be able to then connect it to the specific front USB on the case and it should see it.  Kind of a lot of work in my opinion.  I typically just do what I suggested at the beginning, just share it out once plugged in

[+jedimatt42]

The power of linux... and the problem of linux... there are 100 ways to skin this cat

 

@9640News

 

To use an external USB drive, on linux... is usually pretty easy, except that logic has primarily moved into the desktop environment of the OS, and we don't login to the desktop on the PI. 

 

There is a tool called usbmount that can be installed which tries to do this automatically... although the automatic part has yet to work for me. I can see it trying, but there is a silent failure somewhere. I was following some quick instructions found here: Raspberry Pi: Mount USB Drive - Automatically - ShellHacks

 

Manually I can ssh into my PI and mount a USB drive:  mkdir /home/tipi/tipi_disk/USB;  sudo mount /dev/sda1 /home/tipi/tipi_disk/USB

 

if you have multiple usb storage devices, it might not be /dev/sda1. Or if the usb drive is partitioned oddly.

 

If you have a system that automounts the device somewhere, you can instead softlink a directory under tipi_disk to the mount point. For instance, if usbmount worked correctly, it would mount the drive at /media/usb0, so I would: ln -s /media/usb0 /home/tipi/tipi_disk/USB

 

The only portion of this problem that is specific to TIPI is what I have shown in BOLD. 

 

And certainly you can run network storage and all that instead, but that isn't what you asked.

 

I've been trying to make this process easy and 4A friendly for a while, as I have a ZIP drive I want to use as my usb storage, cause it's retro. I got hung up on the removable media issue while the device is still attached... I was thinking of making something like a PI.MOUNT device to make it easy to write programs on the 4A or mdos that safely mount and unmount ... might not be necessary if that usbmount tool works correctly, as it disables write caching for the device to try and make it safe to just physically remove... 

 

[+9640News]

@jedimatt42

 

Thanks for the reply.  After the previous replies, and your reply as well, it looks like what I was inquiring about is not as TIPI/PI/Linux friendly as it is over on a Windows system.  I was really hoping a setup where a user plugged into the USB port, saved files onto the USB device, then could take that over to another PI setup, and copy things over.  Thinking more along the lines of one user to another user, versus accessing the PI's in my home network.  I did not know what the mount and unmount process would be to disconnect the drive.

 

After all that thinking, then I started thinking the flash drive would have to have some kind of linux image versus a FAT32 formatted image?  Just thinking out loud here as that seemed to make things even more complex and less likely to find another user to share files, etc.

 

Unless there is something obvious I overlooked, I do not think the average TIPI/PI user would be able to do all the mounting and unmounting necessary to use/manage a USB flashdrive.

 

Beery

[+jedimatt42]

The USB device can be a fat32 just fine. 

 

Don't give up on the dream!

 

With more effort and time, I'm sure I can make it as easy as you were thinking. It is just that right now, at the moment, the parts exist, but they aren't wired up by default.

 

I do intend to spend some more time on it. 

[+jedimatt42]

Ok, with a small change to a config file, I was able to get the usbmount package to work. 

 

I do notice some log messages indicating my usb drive is causing an undervoltage, however the PI seems to quickly recover. Anyway... I created an update that:

 

* installs the usbmount package

* replaces a config property

* changes ownership of /media/usb0 to the 'tipi' user

* creates a soft-link from /home/tipi/tipi_disk/USB to /media/usb0 ( where usbmount will mount the first usb device )

 

I only create the 1 softlink assuming the use case is for one removable media device... however if you need more, you can create additional links to /media/usb1, /media/usb2 etc... 

 

You'll find this in TIPI update 2.39.  

 

I haven't tried it yet with that zip drive of mine... but it seems to work fine with some thumbdrives. The usbmount package hooks in using the udevd system and looks for volumes on the discovered device to mount. It'll try mounting as vfat first. But it basically detects the type of filesystem on the drive, and does the right thing for that. 

 

On the TIPI. device, you'll see a directory named USB.  it is always there. This is linux... so if you write to it and do not have the drive mounted, it won't stop you. Then when you do plug in your usb drive, that will mount over the directory, and you'll only see the stuff on the usb drive. When you remove the usb drive, you'll see the other stuff again... It's a 'mount point' thing. 

 

The usb device filesystem is mounted with synchronous writes, so once a write operation is done, you should be able to just pull the device. Remember, that's unusual. On your desktop/laptop operating systems you have to do some 'safe remove' operation. So be mindful. Just cause you can yank it on the TIPI, doesn't mean you can do that on Windows or other Linux desktops.

[+9640News]

@jedimatt42

 

Thanks for the update.  Much appreciated.  I will try to do some testing tonight.

 

 

Beery

[+9640News]

Matt,

 

Going to throw a suggestion out there for something.  I have the AfterHours BBS program, and there are the 3 setups currently using it, however, I have another thought for something similar, but along a bit different line that may entice more telnet activity from the average user.

 

You already have URL support for, but that is for reading only for files.

 

What about the possibility of having a host, with a specific port or a range of ports the PI monitors, and this range of port triggers reading/writing/append that gives access to the tipi_disk folder of another TIPI/PI system?  A website URL does not offer this opportunity, but my thinking is wondering if there is the possibility to use a range of ports to the tipi_disk folder that would give this ability. 

 

My thinking here is a single host system with multiple message boards, so a user loads their client, and then reads everything from one universal message base.  

 

I am thinking here a range of ports would be necessary, and the client would try to access the range looking for an open port.  PI.CONFIG could even specify the range if need be.

 

The host system really only needs to keep their PI powered on.

 

Thoughts?  If it is even possible????

 

[+jedimatt42]

I personally don't think binding multiple extremely niche communities together will amount to more draw. It is too easy to use a phone to access a community like this Atariage or those other ones.

 

But I don't think you need TIPI extensions to accomplish what you are suggesting. It stops being TIPI when you suggest the 4A doesn't have to be involved.

[+jedimatt42]

This requirement is very application specific. 

I would try using a network distributed filesystem of some sort like webdavfs or ftpfs, and coax your coalition of sysops to either each setup a server service on their PI, or run one common webdav server all of you connect to, where all your collective message files and indices are saved and consequently accessible by all participating BBS' that mount that remote filesystem.

 

Then to your BBS they just look like files available through normal TIPI file access.

[+9640News]

Hmmm.  That's a bit beyond me.

 

It was an idea I had of possibly configuring a situation where one TI user could share a file on the TIPI system with another networked user.  I was thinking record access would require the file i/o structure "somehow" within the PI software interface with a TIPI.

 

I have no idea how many people would even make use of it, as it was just an idea.

 

Beery

[GDMike]

Msg#100

I've actually done this. I ran a program on Clasic99 that was always reading a file and checking for a 1 and if so created a file.

Then on my real hardware I was running a password entry program and it would look for the pass/fail from classic 99 via tipi share. It was obviously more to it and it's been more than a day so I don't remember everything off hand but everything did work.

I think I did everything in xb.

Edited November 3, 2022 by GDMike

[+FarmerPotato]

If the idea of file sharing between TIPI users is not retro enough, then how about UUCP. it’s as old as the 99/4.
 

Have the 4A software (BBS) copy the file to a destination TIPI.UUCP!Heatwave!shift838

 

On the PI end, when the file is closed, it executes uucp on it, with the given destination address. I checked that this is still a thing on Linux…

 

On the receiving end, the PI would copy the file into the TIPI directory where a 4A would check every now and then.

 

Once received, the 4A might identify it as messages to unpack (see MajorBBS message transfer format). Or , if a file, advertise the file by adding it to a BBS downloads area, or notifying a particular BBS user of its arrival. 

In this way, for example, a new build of MDOS could be distributed from one BBS to others, using TIPIs and UUCP.

 

This was UUCP’s original purpose.
 

Rather than rewriting UUCP on the 4A, the PI could be leveraged. The only concession to modernity (unless you really want to make your PIs use dialup?) is that, once in the UUCP queue, the PIs use internet to talk to each other. 
 

[+OLD CS1]

I second @FarmerPotato's proposal. but only if we can also search with Gopher.

[+9640News]

My whole thought here was to leverage the TIPI's DSR whether it be for the 4A or the Geneve, to come in via a "backdoor" (specific identified range of ports) to another remote PI that has Matt's image with all the knowledge of the TIPI DSR.  So, rather than the PI reading the communication from the GPIO ports, it picks everything up from a range of ports via a TCP connection.

 

This way, one could do record access to add additional records to a file as a user checked in or updated message pointers, etc. If I read and understand everyone else's proposal thus far, individual record access is not possible. This way, no file transfer of the message base file(s), only the specific record in a file.  That's for reading/writing of message bases.  Where/when needed, a "lock" file could be written that would prevent two or more people writing to the same record.

 

As far as distribution of files, then that is another benefit.  I actually think in this case, some kind of embedded ftp transfer would be needed to get the speed unless users would be receptive to xmodem transfers which aren't the greatest of speed as currently written as everything is transferred on a byte by byte, instead of a block segments.  What I did with both Mass Transfer and AfterHours was the simple approach with the Xmodem protocol.

 

Anyway, that was the background and my reasoning for my suggestion earlier this week.  Now, as Matt pointed out, he did not think many people would even use the ability to message.  I can't answer that question to know if it would be a hit or not.  As is, there are not a whole lot of people telnetting into BBS's, so I do not know if my proposal would draw more TIPI users into telnet world or not.  I just know that the software pieces for the route I was suggesting are mostly written with some minor changes needed to the DSR pab for a new, unwritten, route. 

 

 

[+jedimatt42]

You can write 4A software with multiple server sockets open, and multiple client sockets open already. Just update the BBS programs to know to 'call' each other, and either delegate to a remote board or synchronize as needed... There is no need for special TIPI features beyond the TCP stack that is already there. 

 

What I hear is a request to write a distributed filesystem. That requires a special passion.

 

There are already many to choose from in Linux land, and if mounted under /home/tipi/tipi_disk, then the client 4A software can use them, the same as if they are local. There are 99ers that are DevOps Engineers that should have the skills to do this without modifying the TIPI services at all.

 

You can also go old school and have the BBS programs connect to another BBS programs on another system and transfer messages between them. A well written 4A program, even in BASIC, can juggle multiple client and server sockets with what TIPI already provides. 

[RickyDean]

Could this work as a replacement for the pi?

 

https://jamesachambers.com/enable-raspbian-images-to-boot-on-libre-computers-boards/