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

[+dhe]

The backup function is awesome, and I'd like to request a feature enhancement.

 

 My use case scenario is I do most of my development (a bit grandiose of a term for what I do) under emulation on my laptop - geneve / mame / with a real RPI connected to save files.

 

 I'd like to be able to save the whole backup to a file, like is done now. 

 

Then take that file to my  desktop PC and do a selective restore (pick specific directories, overwrite / no overwrite) to the RPI connected to my real Geneve (or vice versa).

 

On the support side - in the upload via the web browser, is there a way to strip or utilize TI file headers on a file during the upload step of the web gui?

[+jedimatt42]

9 hours ago, dhe said:

The backup function is awesome, and I'd like to request a feature enhancement.

 

 My use case scenario is I do most of my development (a bit grandiose of a term for what I do) under emulation on my laptop - geneve / mame / with a real RPI connected to save files.

 

 I'd like to be able to save the whole backup to a file, like is done now. 

 

Then take that file to my  desktop PC and do a selective restore (pick specific directories, overwrite / no overwrite) to the RPI connected to my real Geneve (or vice versa).

 

On the support side - in the upload via the web browser, is there a way to strip or utilize TI file headers on a file during the upload step of the web gui?

 

I think, in combination with the CIFS share on each TIPI, there are far better tools available already to facilitate these workflows.

 

You can download the backup archive from the TIPI web-ui, and then open the archive in a tool like 7zip for Windows or anything handling .tar.gz files.. 7zip makes it look like there is just one file... double click it, and it'll decend into the .tar part of the .tar.gz... you should then see a 'tipi_disk' folder in the archive... you can go into that, and then subselect any of the good items you want to extract, and extract them directly to the TIPI share on your Geneve's tipi. 

 

--

 

As for general management of TIFILES headers, if the file is in the other FIAD format, you can select it in the TIPI web-ui, and use the actions pull down menu to convert to TIFILES.  If it has no emulation header, then TIPI allows use of the file without a header for a lot of common cases. If it needs a special treatment, I'd need to build a crap ton of options into a web dialog to handle creating the correct header. So, again, I'd use something like xdm99.py, TiImageTool, or Ti99Dir to import or export the raw file with the options they've already built so nicely. 

 

Maybe with a more specific use case, something more automatic can be inferred... 

 

[+jedimatt42]

On 7/21/2022 at 9:26 AM, jedimatt42 said:

Yep... The fuse is still fine! LOL... but the PSU is dead.. hopefully the pcode card didn't take out all my other cards too. 

Since I know you all are concerned, my 838IO, SAMS, TIPI, and Corcomp FDC are all still fine... tested in a second PEB. 

 

Plato required crubase >1100... didn't even blink at the TIPI sitting at >1000... Gonna see if I can hack a version of the module to work with >1000... Howmany times can LI R12,>1100 happen ? LOL ( or the million other ways to express that... ) 

[+dhe]

>Maybe with a more specific use case, something more automatic can be inferred...

 

Many (most/some) of the files I pull down from whtech have a TIFILES header (https://www.ninerpedia.org/wiki/TIFILES_format).

 

When I do web uploads the file header sticks and makes the file unusable from the Geneve's file system? -- or maybe I'm missing something?

 

I ended up using ti99dir to save the file out with out the header, and then uploading.

 

  If that doesn't help, next time I'll take a video of the steps.

 

thanks!

[+jedimatt42]

TIPI expects you to upload FIADs with TIFILES headers... So you shouldn't have to remove the header.

 

I hadn't found TIFILES format files on whtech... Maybe a link to an example problematic file, and then I can see what is going wrong.. 

[+9640News]

14 hours ago, jedimatt42 said:

TIPI expects you to upload FIADs with TIFILES headers... So you shouldn't have to remove the header.

 

I hadn't found TIFILES format files on whtech... Maybe a link to an example problematic file, and then I can see what is going wrong.. 

Likely, the files at Index of /Geneve/9640news (whtech.com) will have TIFILES headers as they came from TI Uploads to GEnie back in the day and were for BBS use.

[+dhe]

I think this is the file I was fiddling with. It was extracted from a hard drive image, using TI Image Tool.

NEOP.tfi

[+arcadeshopper]

3 hours ago, dhe said:

I think this is the file I was fiddling with. It was extracted from a hard drive image, using TI Image Tool.

NEOP.tfi 896 B · 0 downloads

and if you look at that file in notepad it says: 

 

TIFILES ú   NEOP        ÿÿn ,ôn ,ô     

 

obviously a tifiles header..   you can also look at it in tidir

 

[+dhe]

Right. And when I upload it via the web gui  - the header stays. I though it should be stripped and the correct type of file be derived from the contents of the header.

[+jedimatt42]

I haven't tried it yet, cause my system is in a bit of a state...  

 

TIPI does keep TIFILES headers. It wants them. But the name of the file is under your control, and it does not rename them on upload... So you should ditch the .tfi suffix before uploading. 

 

If you upload it with the suffix, it'll be seen by the 4A as NEOP/tfi but should also list as a PROGRAM just fine.. 

 

The header stays, cause that is where the correct type of the file is stored. TIPI uses a loose set of FIADs that are self describing very similar to classic99

[+arcadeshopper]

13 hours ago, dhe said:

Right. And when I upload it via the web gui  - the header stays. I though it should be stripped and the correct type of file be derived from the contents of the header.

Says right here in the wiki that all files are stored as TIFILES https://github.com/jedimatt42/tipi/wiki/TIFILES

 

 

 

[+jedimatt42]

yep, NEOP.tfi uploads fine... the web-ui confirms it by showing that the file is a PROGRAM instead of implicitly a DIS/FIX 128... 

 

Maybe the feature request here should be to rename files upload if they arrive with a .tfi or .tifiles suffix.

[+jedimatt42]

Back to sector support...

 

So, TI-FORTH works fine. 

fbForth DIR, and TIFVU were tested fine. 

 

I even peeked in on Texas Instruments Disk Manager II - which succeeded with its sector operations, such as changing the volume name of a disk / cataloging a disk the sector way... and then it fell down on direct-input and direct-output as I have strict bounds checking. It appears to ask for upto 11K of a file regardless of how large the file is. I haven't seen that anywhere else. So a low priority thing to fix... I never expected DMII to work anyway... 

 

I've written some things down about this sector read/write support in the TIPI WIKI. 

 

The biggest limitation I observe, is users have to be mindful that if their software writes to sectors, then those changes are not reflected in a possibly corresponding FIAD. 

 

For 99.99% of the use cases we have, that's not an issue. The things that write data in sectors directly, tend to read back from those sectors directly.

 

The most logical use that that isn't supported, is using a 4A sector editor and expecting it to just update your file. The user would have to download the sector dump, and re-upload it, or extract the FIADs themselves... There are some really nice sector editors on Windows, and linux users always have vi :%!xxd and :%!xxd -r

 

Closed a bug I filed in 2018. So, we've gone more than 4 years without this feature. 

 

Wasn't there a SAMS version of Don't Mess With Texas that loaded from DISK? I seem to recall it didn't load off TIPI way back then...   (Edit: Found the thread, seems to load fine, seems to strictly use PROGRAM image LOAD... so good enough)

[Tursi]

19 hours ago, jedimatt42 said:

Wasn't there a SAMS version of Don't Mess With Texas that loaded from DISK? I seem to recall it didn't load off TIPI way back then...   (Edit: Found the thread, seems to load fine, seems to strictly use PROGRAM image LOAD... so good enough)

IIRC the non-SAMS disk version will try to use sector access first, then falls back to record access if that fails. That was something I worked on in it. I thought the SAMS version would have run through the same interface, since the final disk didn't have PROGRAM images on the disk - we condensed them all to one big file so that we weren't losing so many sectors to the allocation tables. Unless I've forgotten something

 

[+jedimatt42]

44 minutes ago, Tursi said:

IIRC the non-SAMS disk version will try to use sector access first, then falls back to record access if that fails. That was something I worked on in it. I thought the SAMS version would have run through the same interface, since the final disk didn't have PROGRAM images on the disk - we condensed them all to one big file so that we weren't losing so many sectors to the allocation tables. Unless I've forgotten something

 

I'll have to try all the disks in that thread then... there are several.

[Tursi]

5 hours ago, jedimatt42 said:

I'll have to try all the disks in that thread then... there are several.

Yeah... it could be we did that only to fit it on single density disks or something... I definitely remember that the number of files was becoming an issue for the smaller disk size (whether single or double sided I don't recall), so I came up with that loader instead.

 

I could look I suppose...

 

Double sided.

 

We had 36 files, so the allocation tables alone were up to 9k. We had about 167k worth of demo code, so that's already up to 176k out of 180k. We weren't sure if it was going to bite us so the final scheme uses DEMOA as the loader (or LOAD or SAMSDEMO), and DEMOB contains all the other files with a little index at the start for easy loading.

 

DEMOB is padded to 256 byte boundaries so that it can be read a sector at a time, or as 128 byte records. Sector load is faster, of course, since it's half as many DSR calls and there's more cheating we could do.  It uses direct disk sector access, not the per-sector file access, so that it doesn't need to open the file.

 

It looks like DEMO0 can be built with or without the expectation of the packed file... and the build scripts look like they build both versions depending on whether you run "makedisk" or "makepackdisk". We intended our pack loader to also be quicker - we cache the index in RAM so each new load should be able to go direct to the file without any further index lookups after the first one. I don't know that we benchmarked it but I'd expect it's not TOO much faster than PROGRAM image loads.

 

It's a little fussy too... it tests the controller to see whether it can use sector reads at all, and tests the file allocation table to make sure DEMOB is not fragmented on the disk. If either test fails, it'll fall back to normal record reads.

 

[SkyPilot]

What is the last version of TIPI one can run without the ROM upgrade?  Is that version still available anywhere?

[+jedimatt42]

1 hour ago, SkyPilot said:

What is the last version of TIPI one can run without the ROM upgrade?  Is that version still available anywhere?

You can still use the latest PI side update with even the oldest ROM.

 

The ROM update consists of an additional subroutines in the DSRLNK-able BASIC subroutines linked list for sector read/write code 0x10.  This is what a small amount of 4A programs look for to directly read or write sectors. 

 

You can see how isolated the change is here: https://github.com/jedimatt42/tipi/commit/1e50d8254eb3b345ec97cf96cc50c4bb989073a6

 

When this code in the ROM is called it sends a message to the PI python code that leads with this 0x10 value. The python code switches on this to execute the message specific handler. 

 

This is a new handler on the python side. But it cannot be reached without the linked list entry in the ROM exposing and proxying it to the PI. 

 

So without the ROM update the python handler is just dormant. 

 

There are supporting changes in the tipimon.service that detects if a disk image is uploaded and keeps the image squirrelled away. Along with tipiweb.service changes to expose these images more prominently, along with better browser based mapping UI.

 

But none of the pre-existing routines utilize these sector dumps. The TIPI treats record level and direct-input access as FIAD only operations. 

 

This is why if you are performing sector writes, your FIADs will be left out of date. (I could fix that with more code, but haven't seen a value in it yet)

[xahmol]

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).

[+jedimatt42]

If you were required to update the ROM, I would rig the update to stop showing up for users without the ROM update. 

 

My previous post in this thread explains the situation to the best of my ability.

 

I am highly motivated to not create the problem that you fear.

 

Regarding the hardware, yes the ROM is socketed. 

 

I cannot speak to the link you provided. Anyone can download the ROM from my website. Arcadeshopper is aware of it. I know first hand he has tested it. I would assume that is what he would provide, but you can communicate with him to ensure you get what you are looking for. He is very accommodating in my experience.

[GDMike]

I noticed that the TI console, running TIPI PEB card will not allow me to make setting changes until the ip address is obtained.

Is that normal? I saw this when I went to add paths at the call tipi screen, but wouldn't accept my changes until after the ip was gathered.

Of course I didn't have internet access during my attempt to use TIPI due to location of the computer and the wireless signal and distance for throwing a cable down. 

So is this a normal action for the tipi program?

Just wondering, of course my workaround is to get connected. But I just didn't know that was normal.

 

 

 

Edited July 29, 2022 by GDMike

[xahmol]

15 hours ago, jedimatt42 said:

If you were required to update the ROM, I would rig the update to stop showing up for users without the ROM update. 

Thanks. Thought I understood as much from your last post, so you explained well ?just wanted confirmation, also because I saw Gregory posting on Facebook he was now selling those new ROMs, which made me think I might need it.

 

On the other hand, for just USD 5 and with a socketed ROM (so even clumsy me can do it), I might still change ROM anyway.

[+jedimatt42]

6 hours ago, GDMike said:

I noticed that the TI console, running TIPI PEB card will not allow me to make setting changes until the ip address is obtained.

Is that normal? I saw this when I went to add paths at the call tipi screen, but wouldn't accept my changes until after the ip was gathered.

Of course I didn't have internet access during my attempt to use TIPI due to location of the computer and the wireless signal and distance for throwing a cable down. 

So is this a normal action for the tipi program?

Just wondering, of course my workaround is to get connected. But I just didn't know that was normal.

 

 

 

 

TIPICFG doesn't go into the user input loop until it succeeds in reading the PI.STATUS virtual file from the TIPI. The PI.STATUS file does try to enumerate the network devices on your PI and produce the mac addresses, and ip addresses. The first ip address is displayed in TIPICFG.  I've never tried not having a network... so it could very well be that the code fetching the IP address is blocking... I can probably simulate such a situation with simply using a non-existent SSID... I'll see what I learn.

[GDMike]

16 minutes ago, jedimatt42 said:

 

TIPICFG doesn't go into the user input loop until it succeeds in reading the PI.STATUS virtual file from the TIPI. The PI.STATUS file does try to enumerate the network devices on your PI and produce the mac addresses, and ip addresses. The first ip address is displayed in TIPICFG.  I've never tried not having a network... so it could very well be that the code fetching the IP address is blocking... I can probably simulate such a situation with simply using a non-existent SSID... I'll see what I learn.

Thx. I'm wondering because I do plan on taking a smaller unit footprint someday to work with me, but have zero internet access available there.

 

I'm assuming that just because I don't have internet doesn't stop Tipi from functionality, it's just a "CALL TIPI" that would be non functional, right?

 

I know raspberry pi doesn't like to do anything until a minute or 2 timeout of lack of IP then it boots. Well, that's what I found..

Is it an issue..NO, i just thought, oh... Tipi is waiting on the raspberry and the raspberry is waiting on ip.

Is that about right?

 

 

 

Edited July 29, 2022 by GDMike

[GDMike]

I edited the previous post as my phone is really screwy...