Force Command ver 1.17 : kinda like command.com from 1985

[Force Command ver 1.17 : kinda like command.com from 1985]

1 hour ago, Omega-TI said:

Regarding future development of Force Command...

 

Since you've included the time in the BAR and have made it possible to use clock information in the prompt, and you also support multiple clocks, are you planning on supporting time and date information on files saved with/via Force Command?  If not, is it because of a lack of space in the file information storage area or because it would screw up existing software?

 

 

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. 

[Force Command ver 1.17 : kinda like command.com from 1985]

2 minutes ago, Tursi said:

That's just yet another version of the scratchpad loader, you could always just port that. It sets up the PABs, looks up the DSR, then does all the actual loading from scratchpad.

 

all_scratchpad_loaders.zip 29.08 kB · 1 download

 

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

 

[Extended BASIC G.E.M.]

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.

[Force Command ver 1.17 : kinda like command.com from 1985]

On 12/28/2020 at 1:14 AM, wolhess said:

Hi @jedimatt42,

 

with the version v1.12 of Force Command the prompt command does not work as described in the wiki.

 

Now I can make all character after the "prompt=" to the system prompt.

 

Is this right? What about the crubase or the drive/path information?

 

 

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 ver 1.17 : kinda like command.com from 1985]

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

 

 

[Force Command ver 1.17 : kinda like command.com from 1985]

@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!

 

[Force Command ver 1.17 : kinda like command.com from 1985]

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!

[TIPI Usage and Support]

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.

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

29 minutes ago, RXB said:

Hmm 

CALL LOAD(-31931,0) ! Unprotected flag

CALL LOAD(-31931,128) ! Protected flag

 

Load a program and CALL LOAD(-31931,0) ! Unprotected flag then save it as unprotected.

 

That flag is almost useless.

 

 

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. 

 

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

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. 

[Force Command ver 1.17 : kinda like command.com from 1985]

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

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

35 minutes ago, jedimatt42 said:

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.

 

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

 

 

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

31 minutes ago, InsaneMultitasker said:

Seems (to me) many/most of the recent items are edge case scenarios that few people will encounter.  For example, I'm not particularly concerned about the file protection as I have little use for it myself and it is almost always an inconvenience when encountered, so if you were to say it will be ignored, I couldn't care less    

 

I think you say this tongue in cheek yet I still want to say the positive usability point was reached long ago.  Many of us are doing things with TIPI that we couldn't dream of in the near past and integrating it into how we use the TI and emulation, e.g., sharing files between real TI and Classic99 via TIPI.   It is certainly a "necessity" for me these days. 

 

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!

 

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

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.

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

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

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

2 minutes ago, jedimatt42 said:

 

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

 

 

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

 

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

4 minutes ago, arcadeshopper said:

Oops no the disk protect is delete protect
There is no way to tell if an xb program has the protection flag saved from a disk catalog level

Sent from my LM-V600 using Tapatalk
 

 

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

 

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

53 minutes ago, InsaneMultitasker said:

The fix you posted seems to be working nicely, well done and thank you.

 

There is one more item I came across this evening.  It has to do with protected files and the DELETE opcode >07 seemingly ignoring protection.  I didn't  see anything in the wiki that suggests this is expected. 

 

2020-12-27 19:38:21,746 LevelTwo    : INFO     set path request
2020-12-27 19:38:21,748 LevelTwo    : INFO     unit: 0, path: TIPI.
2020-12-27 19:38:21,748 tinames.tinames: INFO     TIPI. -> /home/tipi/tipi_disk
2020-12-27 19:38:21,749 LevelTwo    : INFO     set unit 0 path to TIPI.
2020-12-27 19:38:21,750 LevelTwo    : INFO     protect request
2020-12-27 19:38:21,753 LevelTwo    : INFO     unit: 0, filename: PISTAT, prot: 255
2020-12-27 19:38:21,753 tinames.tinames: INFO     TIPI.PISTAT -> /home/tipi/tipi_disk/PISTAT

 

(The TIPI log reports this error for every folder during creation of the catalog. I don't think this is related to the protection but I don't recall seeing error 21 a few days ago, so I've included an excerpt just in case)
2020-12-27 19:38:26,952 TipiDisk    : INFO     Opcode 0 Open - TIPI.
2020-12-27 19:38:26,952 Pab         : INFO     opcode: Open, fileType: Relative, mode: Input, dataType: Internal, recordType: Fixed, recordLength: 0, recordNumber: 0
2020-12-27 19:38:26,953 tinames.tinames: INFO     TIPI. -> /home/tipi/tipi_disk
2020-12-27 19:38:26,953 ti_files.CatalogFileTimestamps: INFO     Creating catalog with timestamps
2020-12-27 19:38:26,957 ti_files.ti_files: ERROR    [Errno 21] Is a directory: '/home/tipi/tipi_disk/MDOSBM'
Traceback (most recent call last):
  File "/home/tipi/tipi/services/ti_files/ti_files.py", line 21, in isTiFile
    fh = open(filename, 'rb')
IsADirectoryError: [Errno 21] Is a directory: '/home/tipi/tipi_disk/MDOSBM'
2020-12-27 19:38:26,960 ti_files.ti_files: ERROR    [Errno 21] Is a directory: '/home/tipi/tipi_disk/TIPI12232020'
Traceback (most recent call last):
  File "/home/tipi/tipi/services/ti_files/ti_files.py", line 21, in isTiFile
    fh = open(filename, 'rb').

(continues for all directories)
 

Using ROMPAGE to check status and attempt a delete:

A directory shows attribute "P" for protected file.  Fred's DM2K reports the file as protected.

I dropped into Extended BASIC and typed DELETE "TIPI.PISTAT".  The protected file was deleted successfully.  Confirmed by looking at the folder via the TIPI Share.

 

2020-12-27 19:39:04,430 TipiDisk    : INFO     Opcode 7 Delete - TIPI.PISTAT
2020-12-27 19:39:04,431 Pab         : INFO     opcode: Delete, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 0
2020-12-27 19:39:04,431 tinames.tinames: INFO     TIPI.PISTAT -> /home/tipi/tipi_disk/PISTAT
2020-12-27 19:39:04,435 TipiService : INFO     Request completed.
 

 

 

 

 

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.

 

[TIPI Usage and Support]

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 )

 

 

[TIPI Usage and Support]

On 12/14/2020 at 6:13 PM, jedimatt42 said:

 

...

 

And I'd like to figure out this screen issue... cause that'll be a configuration well outside the TIPI software domain.

 

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]

[GCC for the TI]

1 hour ago, Kal El said:

Hi all,

 

when I tried to build GCC, an error showed up when compiling the binutils:

 

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: dwarf.o:D:\Download\TI-99\gcc\binutils-2.19.1\binutils/dwarf.c:56: multiple definition of `do_wide'; readelf.o:D:\Download\TI-99\gcc\binutils-2.19.1\binutils/readelf.c:169: first defined here
collect2.exe: error: ld returned 1 exit status

 

My environment:
Windows 10
msys2
mingw32_64 10.2.0

 

The variable do_wide is defined in both dwarf.c and readelf.c. When linking, you then get the error because the generated file readelf.exe consists of, among others, dwarf.o and readelf.o.

 

Does anybody know a workaround or a solution for it?

 

Thanks in advance.

 

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.

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

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

 

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

3 hours ago, BeeryMiller said:

Matt,

 

Not sure if you want to consider this an issue or not.  Letting you know about it, as there are already work around tools for it.

 

I came across the issue, and after working with Tim, we isolated what is happening as it was not immediately obvious.

 

If there is a native file on a TIPI folder because it was dropped their natively, then it does not have a TIFILES header.  I had some GIF and VOC (sound files) from back in the 90's that were playable on the TI that were downloadable from a MS-DOS PC BBS program back in the day.  When those files were downloaded, the TI would save them as a DIS/FIX 128 file.  However, these files were not downloaded to a TI and never got the TIFILES header as I had them in their original PC format when they made their way to the TIPI.  These files were still useable by our programs; they just could not be copied.

 

With DM2K, and the other catalog programs, these programs present as a DIS/FIX 128.  However, when you try to copy them to another path, you get an error that TIPI logs report as a Level 2 Error, not TIFILES.  I know you indicate these files are readable only as a native file and can not be written.  There is no intention on my part to writing back out to the file itself.  Not sure how, or if you would allow copying the file to another path.

 

Now, a user using DM2K may not realize these are native files since they present as a DIS/FIX 128 file and may struggle a bit to understand why they can not copy the file.  I'm guessing this could include .TXT files as well.  Your WebUI and programs like TIDIR solve the issue by converting and adding the TIFILES header, but only if the user realizes the situation.  I don't use Force Command, so I don't know how you may (or may not) handle it.

 

Again, just pointing out the observation.

 

From the logs, opening the FILEID of the file, the following error occurred.  The lines in Yellow are in the case of the Geneve debug code passing information back out to a terminal with the Pab going in and the Pab that is passed back out for your information.

 

Pab In : 0A00 0001 2000 0000 0000 0000 0000 0013 TIPI.DL1.04DEAD-VOC
Pab Out: 0A00 A001 2000 0000 0000 0000 0001 0013     TIPERR: C000

 

Inspecting the TIPI log shows the following: 

 

2020-12-26 11:46:30,625 LevelTwo    : INFO     unit: 0, blocks: 0, filename: 04DEAD-VOC, startblock 0
2020-12-26 11:46:30,626 tinames.tinames: INFO     TIPI.DL1.04DEAD-VOC -> /home/tipi/tipi_disk/DL1/04DEAD-VOC
2020-12-26 11:46:30,627 LevelTwo    : ERROR    not TIFILES

 

Anyways, just wanted to alert you to the observation.  After I saw what was happening, I converted the files to DIS/FIX 128 TIFILES format and all was well.

 

Beery

 

 

 

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.

 

[Zoom-TI-99ers Pandemic 4A Club Online Virtual Meetup]

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!

[Did you get anything for your TI for Christmas?]

10 hours ago, Ksarul said:

SAMS-aware software is always a good thing. . . 

 

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.