jedimatt42

That is a function of the storage device, and not a function of the program doing the storing. Some controllers provide that information back to programs reading the CATALOG file. Force Command will list the modified date of files for controllers that support it, such as TIPI, ( and probably IDE, HDX, and the HFDC ) - By executive decision, it only lists the file dates if you are on an 80 column display. Comparing your screen shots and mine, I'd say I haven't released this yet.

My loader is/was 95% that already... It has evolved away a little bit.... I have the luxury of running from ROM, and using my own dsrlnk code that handles my weird explicit crubase stuff. I do more things, now such as restoring the SAMS memory map, and VDP registers after being in 9938 or F18A specific modes...

I get the same numbers for XBADDR and I get different errors.. FinalGROM flashing light does not reproduce for me... this smells like an SD card problem. But I do get catastrophic crash for any of the entry points that load more... except if I recall correctly TML loaded from Force Command's XB command. The base entry point for XB 2.8 works fine. And an XBADDR value of 0, which just causes the console to BLWP @>0000 ( reset properly ) shows the cartridge loads and is functional... I'd recommend Omega set XBADDR to 0, until he resolves the flashing final grom light problem. But then, going right into something like T80XB needs more work. Force Command is 'returning' to GPL at those addresses after having completely altered the working environment... The fact that the cart menu works fine after loading, suggests there is a problem between current state departing FC, and entering any of XB28GEM's extra entries.

Have you tried the other slash (FCTN Z)? https://github.com/jedimatt42/fcmd/wiki/Variables#prompt and, case matters here, I reserve the right for \c to be different in meaning from \C, etc.

Force Command and the PATH... When you type a command and the first word is not one of the built-in commands known to Force Command, it will search the current directory, and then the list of device/directories in the PATH environment variable and see if it finds a file that matches the name. (case matters, files on the TI are case sensitive - This is the way) If it finds a file matching the name, it inspects the file. If it is a DISPLAY VARIABLE 80 file, it runs the file as a script of Force Command commands. If it finds a PROGRAM image, it checks to see if it starts with the Force Command API header, and if so, loads it as an cooperative Force Command executable. If it does not start with the API header, it reports command not found. The bundled FTP executable is one such PROGRAM. It does not automatically act on other PROGRAM image types, as there are many... BASIC, XB, CARTRIDGES (GK, etc), TI-Artrist pictures, Tunnels of Doom quests, Adventures...

@Omega-TI The only mistake you made in the video, was that you typed LOAD CALENDAR, instead of just plane simple CALENDAR. If you review the help for LOAD by entering HELP LOAD you see: ==Load EA5 Program== load <filepath> Load and run an EA5 program image file or files LOAD doesn't do batch files. The docs for scripting are here: https://github.com/jedimatt42/fcmd/wiki/Scripting, but it is basically like MSDOS, except I don't require your files to end in .BAT... If it is a DV80, I'll treat it like a script. So, what you did in your video would have worked, if you had run CALENDAR at the prompt, instead of LOAD CALENDAR. You were sooooo close. Your previous response says you've heard the instructions correctly... GIVE IT ONE MORE TRY!

Hex editing loaders is a pain, and not necessary. You can set PATH in your AUTOCMD file to a directory of little scripts. For example: PATH=TIPI.LOADERS.;TIPI.FC. Then create a little DV80 file in TIPI.LOADERS. to match your example, call it CALENDAR. It would contain: LOAD TIPI.APPS.REMIND --- as for things FC won't LOAD... I have fixed my LOAD command for anything that has been reported. (This is the way) I can't run everything you guys run, so unless it gets reported, FC will suck forever. A fix for one EA5 is likely a fix for an entire class of EA5s. Please retest the things that don't load and report them. Let's make FC not suck together!

I did finally get around to building a new SD-Card image, for TIPI 2.16. So it is there on my website to download when you need it. Uses latest Raspberry PI OS lite, plus latest Raspberry PI OS updates.

Those CALL LOADs are for the BASIC SAVE ____,PROTECTED option. Which has zero to do with file storage and is part of the content of the data. That's what I thought the disk management "protected" attribute was about, but I was wrong.

A nice way to tie some stuff together, would be for me to implement this protect flag properly and report all the magic native conversion type files as protected, since they are implicitly already, but the error handling is ... made up.

I may have to update that page if the cart menu for GEM has changed.

REQUEST: Anyone have page 22&23? This obvious file on whtech is my lacking source: http://ftp.whtech.com/datasheets and manuals/Hardware/Texas Instruments/PHP1240 Disk Controller Card/ti floppy controller card manual.pdf

Yes, I totally say that tongue-in-cheek. The reality though, is it has never been my intention to make the TIPI software perfect. But faced with a problem that is easier to solve than live with, I'll go for solve every time. (This is the way) I appreciate the opportunity to shore up the corner cases, along with learning more about the corner cases. Prior to TIPI, I had no experience with hard-drive like substance on a 4A. Just a general awareness of their existence, and the possibilities. The corner case fixes add up. There are dozens of things I've dismissed when brought to my attention, cause I'm judgmental, and quickly go to "why would you want to?" and rarely get a good answer. But then later someone had an adjacent use case, and a good answer, so a lot of the "stupid" LOL stuff just works now. (Edit: My boss hates it when I forget to state my point) So, thanks for all the bug reports! They just add up in a way that helps everybody involved!

In my defense, the documentation for DELETE in TI's "FILE MANAGEMENT SPECIFICATION", doesn't mention protection. And this is funny, my "Disk Memory Sytstem" printout, is missing page 22 & 23. It is page 22 that should be describing the file manager's option 4 MODIFY FILE PROTECTION function. None of the low level stuff describes its use. It is hard to tell if the controller enforces it or the disk manager software does.

And sure enough the BASIC reference for 'SAVE' says it's PROTECTED is not the same as Disk Manager's protected.

One of these days, we'll get to a point where TIPI is almost usable. LOL.

Oh well, nobody has any use for either -- filed a github issue...

I didn't realize protected meant you shouldn't be able to delete... I just thought it meant you couldn't LIST. Everything in the world of TI seems to be about "how do I get rid of this PROTECTED thing???" so, no I didn't implement deletion protection. I just carry the bit in the TIFILES if you want to set it or not... Can't stop you from deleting in the TIPI shared folder anyway... As for the ti_files.py:21 error, I saw that, it is benign.. exception handling that should be ignored instead of logged.

Update 2.16 - 2020-12-27 - fix a bug with status on PI.STATUS file - fix a bug in >17 set path operation ( shouldn't care what old path was, & TIPI device ( unit 0 ) shouldn't care about drive mappings )

I don't think I can figure out the screen issue. I don't have the screen issue. I've tried a things to see if I can cause the screen issue... I assume there are probably a couple screen issues, and they are upstream - Raspberry PI OS issues... So If people want the screen issue fixed, you guys are going to have to dig deep into the raspberry-interweb-linuxiverse and offer me the solution to incorporate. Or maybe it will just go away with upstream fixes. [email protected]

Edit the code. Make them both static if they aren't declared for consumption by other modules... Then they won't escape the modules. Or if they do the same thing, remove one and fix the code to understand that. If you are lucky it doesn't turn into a rabbit 🐇 hole. Mostly people have used cygwin and then moved over to WSL if they wanted this gcc on windows. The others have just used Linux directly. So by choosing ming32, you might be putting yourself on one of those bleeding edges. If you do get it to work, post a patch... Someone else will want it someday.

@InsaneMultitasker, lots of issues there. Unit 0 is being sent down the same code path as DSK1-4, deciding if the drive is mapped at all. But instead it is using the current subdir mapping instead of the lower level device mapping. Ick.

That is as designed. non-TIFILES files are not supported for LVL2 operations. They are treated in a polymorphic manner depending on how you interact with them at LVL3 IO... For instance, if you LOAD a text file ending in .TB it will be processed by TidBit, and xbas99.py to become a PROGRAM image file for BASIC before being sent to the TI. The treatment of them as at-all usable by the 4A, is to provide cross-development convenience. Really, you are supposed to use the file share and browser interface, and just manage your files on the modern computer. I supposed this could be supported, but I've always seen that issue as a problem for the 1%'ers. I'll log it. I really just have to make up some rules about how it would work... Do I turn things with BASIC extension into BASIC first, and present the PROGRAM image to the DIRECT IO routines? Similar question about txt files... or do I force, even the the stuff that shows up as a DV80 but aren't TI FILES to be file-managed as foreign format, so they end up DIS/FIX 128s if copied from TIPI to TI mediums, even though that's not how they are used? It's complicated, and depends on perspective... so I probably won't do anything.

The meeting invites for next year have been updated. Same links, same passcode. If you have relied on the "*.ICS" calendar import files from before, you will will need to go to post #1, and re-download/import them into your calendar. ( Note, there are 2 actual meetings for these alternating times, so 2 calendars to import... choose what works for you ) See you all in the new year!

The command history is in a page of SAMS memory if available, otherwise you only get last command, which is squirrelled away in VDP. Force Command native executables will load over top of each other into new pages in upper memory, using my exec api function. I am still working on more complex SAMS enablement. And better parent-child process api. A goal is for a child process to be able to discover the page set used by the parent for data/code sharing.