+9640News Posted January 4, 2018 Share Posted January 4, 2018 Thinking a bit outside the box here as I am sure there could be multiple applications and new paths to development opportunities with the TIPI project. I am not presently doing so as it is on a Win10 machine, but I have software I could run on the Raspberry PI. I'll use a specific example, Mystic BBS software. The Mystic BBS software can interface with other BBS's and grab both files in what it calls Fileecho's or Fileareas as well as various message topics. The message topics can be each separated by a separate data thread. One such thread is comp.sys.ti. Will the use of the TIPI with a Raspberry PI 3 allow two things. 1) First, will the software allow both Mystic BBS software and the file interface for TIPI to run simultaneously? I think the answer is yes, just not 100% sure with multitasking, etc. as I am just not that familiar enough with the hardware and software side of things for it. 2) Will the TIPI be able to "Open" with read/write access of these data files on a Mystic folder and basically do record access? As a sidenote to this, what would happen if software on the PI side of things was adding/updating information to the file while the TI was accessing it through TIPI? If that is possible, then one could interface with usenet newsgroups or any other networked groups without having to deal with the nntp protocols, etc. My thinking here is vary narrowed for where my interest is, however, I could see others accessing all kinds of other data files for use on their TI systems that may have been too large to handle otherwise. Beery Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 4, 2018 Share Posted January 4, 2018 (edited) ... Edited January 4, 2018 by Opry99er Quote Link to comment Share on other sites More sharing options...
+9640News Posted January 4, 2018 Author Share Posted January 4, 2018 Please note I have been following in the other thread the TIPI discussions and I am just trying to grasp how powerful the DSR is as it stands. I am not asking for anything extra, etc., rather, just trying to get a good grasp on what the capabilities of the Raspberry PI / TIPI interface is with the DSR. And should there be an "Ah ha" moment, well, "Ah ha". Back years ago, I explored video playing on the Geneve. I had a PC card, Computer Eyes RT, that had a file format that was 256x212x256 as I recall. There was some mild compression, but not anything major. I was able to display the first video frame, but never understood why the second and subsequent frames would not show. With all the MAME/MESS tools out there now for debugging, it would be easier to chase down. While that was a one-off format, at the time I thought it opened up the capability of video playback. Trying to do that on a disk based system would be useless as not enough storage room. Even a hard drive would have some significant limitations. Retrieving that information from a TIPI server may open opportunities though I am sure speed of access would be of concern. Anyways, that is why I am asking about what the data access possibilities are for a non TI file on another system is. Beery Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted January 4, 2018 Share Posted January 4, 2018 There are other posts in this thread I haven't read yet... so forgive me if you have answered this already... Thinking a bit outside the box here as I am sure there could be multiple applications and new paths to development opportunities with the TIPI project. I am not presently doing so as it is on a Win10 machine, but I have software I could run on the Raspberry PI. I'll use a specific example, Mystic BBS software. The Mystic BBS software can interface with other BBS's and grab both files in what it calls Fileecho's or Fileareas as well as various message topics. The message topics can be each separated by a separate data thread. One such thread is comp.sys.ti. Will the use of the TIPI with a Raspberry PI 3 allow two things. 1) First, will the software allow both Mystic BBS software and the file interface for TIPI to run simultaneously? I think the answer is yes, just not 100% sure with multitasking, etc. as I am just not that familiar enough with the hardware and software side of things for it. I am distributing the software for TIPI in the form of an raspbian SD card image with the TIPI services pre-installed. However, 1 of my beta testers has successfully just checked out the code from github, and run through the prereqs and setup scripts to install on a PI sd-card he already had setup. This is what I would call Developer Mode! You will have problems, and I will be able to help you work them out. But NOT what I'm recommending to consumers. Speed of the PI does make a difference... The TIPI is designed to run on an OS that is not a real-time OS... so I expect the SAMBA share or WebUI to steal compute resources while you are in the middle of loading/saving files from the TI. This has not shown any problems so far... But speed is evident... There was a 50 griggle delay in-between GPIO signalling for the PI-3, to make it stable. On the PI Zero W, which has much less horse power, I set the griggles down to 0 to get back to almost the same bandwith to for the TI. (griggles really means grins-and-giggles, I have a hot cpu loop... don't know what else to call it.) Also when not servicing a request from the TI, the python side backs off and sleeps/yields cpu as it polls the GPIO looking for a new request from the TI. 2) Will the TIPI be able to "Open" with read/write access of these data files on a Mystic folder and basically do record access? As a sidenote to this, what would happen if software on the PI side of things was adding/updating information to the file while the TI was accessing it through TIPI? If that is possible, then one could interface with usenet newsgroups or any other networked groups without having to deal with the nntp protocols, etc. My thinking here is vary narrowed for where my interest is, however, I could see others accessing all kinds of other data files for use on their TI systems that may have been too large to handle otherwise. Beery When the TI opens a file, the service reads a snapshot of the file in. External changes to the file will be clobbered when the file is close, if the file was written to by the TI. It does allow opening external files for read. files ending in .TXT or .BAS or .XB or .A99 can be opened as DV/80 files ( the TI needs you to refer to them as /TXT etc... ) You can 'Load' a .BAS or .XB ascii file as a program image right into basic, and it will use Ralph's xbas99 to transform it on 'load' or on 'save' Foreign files that do not have TIFILES headers, besides those file extensions mentioned above, are treated as DF/128 files, and I have only implemented read access. I could add write access with just some python changes... but haven't seen the need... I use that to load .SID files, without having to put a TIFILES header on them. -M@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted January 4, 2018 Share Posted January 4, 2018 Oh, gotta go, but typical PROGRAM images files are loading at about 7k/sec. -M@ Quote Link to comment Share on other sites More sharing options...
+9640News Posted January 4, 2018 Author Share Posted January 4, 2018 Thanks for the feedback. There are ways to control external processes from updating the file while the TI has a file open if the TI had write capability. Basically, it is creating an empty file with a particular filename that will hold off other processes from doing anything until it is released. Interesting......... Beery Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted January 5, 2018 Share Posted January 5, 2018 Thanks for the feedback. There are ways to control external processes from updating the file while the TI has a file open if the TI had write capability. Basically, it is creating an empty file with a particular filename that will hold off other processes from doing anything until it is released. Interesting......... Beery You can create and delete files from the TI to use as lock files if you want. You can put softlinks under in from the linux side, to link other parts of the filesystem into what is visible to TIPI. The one thing TIPI falls short of, and I don't intend to fix anytime soon, is Level 2 routine >10 : sector read/write. The filesystem is complete without it. >14 and >15 are implemented for raw block transfers of files. the 'Catalog' file is implemented... I know Tursi has implemented a sector IO facade over FIAD in Classic99... But that falls really far down to the lowest priority for me. This creates a compatibility issue with some software. -M@ Quote Link to comment Share on other sites More sharing options...
+9640News Posted January 5, 2018 Author Share Posted January 5, 2018 You can create and delete files from the TI to use as lock files if you want. You can put softlinks under in from the linux side, to link other parts of the filesystem into what is visible to TIPI. The one thing TIPI falls short of, and I don't intend to fix anytime soon, is Level 2 routine >10 : sector read/write. The filesystem is complete without it. >14 and >15 are implemented for raw block transfers of files. the 'Catalog' file is implemented... I know Tursi has implemented a sector IO facade over FIAD in Classic99... But that falls really far down to the lowest priority for me. This creates a compatibility issue with some software. -M@ OK, sounds like the possibility exists! Beery Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 6, 2018 Share Posted January 6, 2018 You can create and delete files from the TI to use as lock files if you want. You can put softlinks under in from the linux side, to link other parts of the filesystem into what is visible to TIPI. The one thing TIPI falls short of, and I don't intend to fix anytime soon, is Level 2 routine >10 : sector read/write. The filesystem is complete without it. >14 and >15 are implemented for raw block transfers of files. the 'Catalog' file is implemented... I know Tursi has implemented a sector IO facade over FIAD in Classic99... But that falls really far down to the lowest priority for me. This creates a compatibility issue with some software. -M@ TI Forth is definitely a casualty here. fbForth should be fine—except, of course, for the TI Forth viewing/copying routines in FBLOCKS. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted January 6, 2018 Share Posted January 6, 2018 See, you've already fixed it so the future doesn't need sectors fbForth works well. I've had that working for quite a while (last April)... long before any of the Level 2 IO routines were implemented. But yes, the new TI BLOCK file support would not be expected too, and the CAT word does not. The DIR word works well... I haven't used TurboForth much, but basic block file access worked. --- The Infocom games on WHTECH all have an XB LOAD program on the disks that has a sector io based EA5 loader. That's a near zero value piece of software (in my opinion). CALL TIPI("DSK1.DEADLINE") works just fine as a replacement. --- TIPI isn't about preservation. There is MAME for that. -M@ 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.