Force Command : kinda like command.com from 1985 (no TIPI required!)

[+jedimatt42]

Oh... I wonder if I'm not allowed to delete on the IDE while I have the CATALOG file open.. The wildcard handling in ForceCommand performs the action such as delete, copy, etc while visiting each record in the CATALOG. Delete would probably screw that up for some devices. 

 

Anyone know if that is a real issue? 

 

The IDE controller returns error 224... 0xE0... which is a nice generic 'File Error' for a file operation... 

 

I'm pretty sure deleting worked for IDE before I added the wildcard support to the delete command... I guess I'll try and queue up the matching names first, so I can close the catalog before deleting.

Edited June 5, 2021 by jedimatt42

[rgjt]

As I mentioned in an earlier post, DELETE doesn't work under v1.18  on any of the IDE drive partitions regardless of any previous command that was excecuted.

For the time being, I have to revert back to DM2K in order to delete files or subdirectories.

 

[+jedimatt42]

1 minute ago, rgjt said:

As I mentioned in an earlier post, DELETE doesn't work under v1.18  on any of the IDE drive partitions regardless of any previous command that was excecuted.

For the time being, I have to revert back to DM2K in order to delete files or subdirectories.

 

Yep, I remember. It was just up there a little ways on the previous page of this thread. Sometimes, I'm just talking to myself here really, to share how the stuff works inside and the issues with supporting 'all the things'.  

 

And I've just found it is indeed because I have the CATALOG open during the delete request... if I queue the names, close the catalog, and then delete it works... now, I just have to tidy up the code. 

 

The workflow in ForceCommand for wildcard supporting operations is:

Open CATALOG
  skip volume record
  for each directory record:
     if matches glob pattern
       perform callback to operation (delete, or copy, etc) 
       count successful operations
close CATALOG
report on operation count.

 

So, I need to change it to:

Open CATALOG
  skip volume record
  for each directory record:
     if matches glob pattern
       add to name queue
close CATALOG
for each name in queue:
   perform callback to operation (delete, or copy, etc)
   count successful operations
report on operation count.

 

The IDE DSR appears to not allow me to mutate the data backing the CATALOG, as would happen if I deleted the file, while it was open.  This is a fun gotcha, cause many devices don't protect against this. Since CATALOG is a FIXED record file type thing, you could theoretically reset back to an earlier record, and get goofy information inconsistent with whatever might have already been read. maybe... TIFDC, Corcomp, TIPI don't care, and let you shoot yourself in the foot if you like.

 

Good things to know for developers.

[+jedimatt42]

Update 1.19 in post #1: 

 

 

Fixes the DIR for empty volume names issue... 

Fixes DELETE on IDE drives. 

Changes scroll pausing

 

There is a limit of something like 400-ish names that can match when using DELETE. It should degrade gracefully and skip the surplus matches but still delete the first 400. You can't have that many names on anything but TIPI I think, so good enough for now.

 

[rgjt]

Thanks for the quick revisions to address the issues. I will try it out tonight as I'm in the process of copying my 5.25" floppies to the IDE drive.

 

[rgjt]

14 hours ago, rgjt said:

Thanks for the quick revisions to address the issues. I will try it out tonight as I'm in the process of copying my 5.25" floppies to the IDE drive.

 

The DELETE commands is working. I haven't tried it on the factory TI DSK1 drive as my drive failed last night after it tried to access a 5.25" floppy that was partially seized. 

Time to look for a replacement drive I suppose.

[+jedimatt42]

Update 1.20 - (in post #1) 

 

fix script execution from IDE.

 

Previously I use lvl2 IO to read the 0 block of the file, and examine if it is a PROGRAM or not... and if not, try to load as a DISPLAY VARIABLE file/script... but using lvl3 OPEN after the lvl2 read operation fails on IDE... So, I don't really know why. But I swapped things around, and attempt to open as lvl3 DISPLAY VARIABLE first, and if that fails, attempt the lvl2 IO for ForceCommand executables... 

[+jedimatt42]

@Vorticon reports that there is something funny about the case sensitivity of the readkey command. 

 

I don't see anything looking at the code except I could be clearer in the docs that the value of variables are case sensitive, and the readkey uses kscan(5) and composes a single character string from that value to assign to the variable. 

 

The report reads like 'readkey' and 'READKEY' behave differently, but I don't see how that is possible from the code. 

[+Vorticon]

20 hours ago, jedimatt42 said:

@Vorticon reports that there is something funny about the case sensitivity of the readkey command. 

 

I don't see anything looking at the code except I could be clearer in the docs that the value of variables are case sensitive, and the readkey uses kscan(5) and composes a single character string from that value to assign to the variable. 

 

The report reads like 'readkey' and 'READKEY' behave differently, but I don't see how that is possible from the code. 

Well I'll be damned... After reading your reply, I went to the computer fully determined to make a video of the issue, and, ahh, it worked this time with both upper and lower case. I had spent nearly a half hour yesterday pulling my hair trying to figure out why readkey was not reading the keypresses properly until I changed the readkey command to lower case and it just worked. I don't know what to say here except it makes no sense. I should add that during editing with ED, there was one instance where every time I typed a character a string of random characters would follow as I was editing a previously entered line. I had to delete the line completely and retype it in order for that weird behavior to go away.

Thinking further, I had just tried the loader Greg had sent me and it did not work and I had not done a cold restart of the computer afterwards before working on the script, so I wonder if something in memory got messed up.

In any case, apologies for the incorrect report...

[+jedimatt42]

update 1.21. 

 

I've fixed someone's request to reset the F18A color palette on startup. 

 

and I've added a palette command..

 

To reset the palette (happens automatically once during ForceCommand startup)

PALETTE /R

To change the first 16 palette registers ( those used by default TI legacy graphics modes and text modes ) ( this will cause a kind of gray scale with no regard for the original colors )

PALETTE 000 111 222 333 444 555 666 777 888 999 AAA BBB CCC DDD EEE FFF

specify all the of 16 values as 12 bit rgb values. 4 bits red, 4 bits green, 4 bits blue.  Leading zeros are not needed. 

 

For example, to get a blue scale that looks horrible:

PALETTE 0 1 2 3 4 5 6 7 8 9 A B C D E F

 

See post #1 for download. 

 

 

Note, re-entering ForceCommand will restore the default 9918A palette. But you can launch your legacy titles from ForceCommand after mucking with the palette... you can also easily put a custom palette in a script to reload/edit whatever... 

Edited June 13, 2021 by jedimatt42

[webdeck]

9 hours ago, jedimatt42 said:

I've fixed someone's request to reset the F18A color palette on startup. 

Thanks!

[SkyPilot]

If I get retro TI, FC will make it behave like a retro PC? 

[+jedimatt42]

18 minutes ago, SkyPilot said:

If I get retro TI, FC will make it behave like a retro PC? 

From my perspective, the answer is 'no'. I try to embrace and expose the way the TI file system works. It still feels like a TI to me. It doesn't pretend to be anything different.

 

Many home computers prior to PC had command line file management, scripting and program launching tools. Atari 8 bit, Apple, most of the Z80 things... 

[+Vorticon]

8 hours ago, SkyPilot said:

If I get retro TI, FC will make it behave like a retro PC? 

If you want a retro PC experience, it's probably best to just get your hands on one. Anything else will likely be a pale imitation.

In my view, FC has immensely enhanced the functionality of the TI from a file management perspective, particularly when coupled with a TIPI. That said, there is no hiding the TI pedigree here...

[+jedimatt42]

Update 1.22 in POST #1

 

Added a bunch of function entry points to the rom for various string utilities and junk... 

There is a early TELNET executable that leverages all the stuff in the ROM, but I still can't seem to get arrow keys correct.

 

Making menus with scripts is slow and a little painful, and so added executable FCMENU, a much faster menu. 

- items defined in a simple DV80 config file.

- can run any ForceCommand command including FCMENU (with SAMS), FG99, XB, LOAD, or scripts to setup cartridges, or drive mappings before launching a program.

- 100 items per menu,

- CAN have as few as 1 items, with no junk showing in the other slots... 

- multiple pages per menu. 

- clock on screen.

 

- Binary is in the ForceCommand 1.22 Zip   https://atariage.com/forums/topic/290966-force-command-ver-122-kinda-like-commandcom-from-1985-no-tipi-required/

- Docs are here: https://github.com/jedimatt42/fcmd/tree/master/example/gcc/fcmenu

 

--- 

I mostly wrote this to prove to myself more general usefulness of the api for ForceCommand executables, and the fc_exec(char* command) for running a command in the shell from an executable. Also to poke the bear that is SAMS paging, as I use that for nested menus ( just run another FCMENU <alternate data file> ) 

 

Seems to work. Behavior isn't quite right if no SAMS is present. With only 32k, It is supposed to reject running executables if an executable is running already. So, happy path seems fine, but the error case is a little broken.

 

Screenshot of 40 column menu (in Classic99)

 

 

Config file in ED editor:

 

 

[+9640News]

Matt,

 

You mentioned telnet and arrow keys. If it is a navigation issue say connected to a BBS, I had a similar issue communicating with my BBS.  I had to send the three byte sequence as a string rather than a single character one at a time. I do not know if there was a timing issue, or if something else was going on.

[Rick Thornquist]

Great stuff!

 

- Rick

[+jedimatt42]

Update 1.23 - 

 

Main thing I did here was update the FCMENU to be friendlier to my lazy mind... meaning, you can just use arrow keys ( FCTN-ESDX ) to navigate the menu entries... and press ENTER to execute one. 

 

Current 'cursor' or selection is indicated with an   arrow character to the left of the hotkey.

 

separators in the menu are skipped when navigating with arrows.  Also, made keys for entries case insensitive... so pressing 'm' or 'M' work. For display, If a key in the config has a lowercase, it will get promoted to uppercase. 

 

 

[+jedimatt42]

Found a general issue in ForceCommand with executing scripts from scripts and executables from scripts.  

 

The script record number isn't on the stack ( poor choices when I implemented GOTO ) so when things return, the wrong thing happens... when executables return, I typically see scripts start over from line 0. When scripts return to scripts, the parent script assume the line number at the point of the end of the child script...  LOL... 

 

If your test scripts are just perfect enough that the record number of the last line in a child script is the same as the record number of the parent script that called the child, then you don't notice this... ( emoji-script: sad face, I'm a bad tester, laughing but crying inside )

 

It isn't new breakage... very old broken-ness.

[+jedimatt42]

Update 1.24 - Fix the script bug...

 

I discovered this because I wanted to launch FCMENU from my AUTOCMD, and when I'd exit, it relaunched FCMENU instead of dropping me to the command prompt.

Now the linenumber for the script is on the C stack, where it belongs. So popping out of scripts implicitly restores the context for the parent script. 

 

S1

ECHO START S1
S2
ECHO END S1

S2

ECHO START S2
S3
ECHO END S2

S3

ECHO S3 was here

 

This worked, output looked like:

START S1
START S2
S3 was here
END S2
END S1

 

 

[+9640News]

@jedimatt42,

 

Just thinking out loud here and wondering about the possibilities.

 

With Forcecommand and your telnet client and the F18A........

 

Can you log into your PI, and use a suitable editor/assembler/compiler to generate executable code on the 4A?  If I understand things, I think the editor may be the biggest challenge as I think everything else may run from the command line.

 

Anyways, curiosity at the moment.  If it is possible, perhaps someone can put together the necessary installation, tools with instructions and a couple of test/demo programs with C and/or assembly source code without breaking anything on the TIPI/PI that takes everything to a final program file that can be launched as file from Forcecommand or Editor/Assembler.

 

Beery

 

[+jedimatt42]

16 minutes ago, 9640News said:

@jedimatt42,

 

Just thinking out loud here and wondering about the possibilities.

 

With Forcecommand and your telnet client and the F18A........

 

Can you log into your PI, and use a suitable editor/assembler/compiler to generate executable code on the 4A?  If I understand things, I think the editor may be the biggest challenge as I think everything else may run from the command line.

 

Anyways, curiosity at the moment.  If it is possible, perhaps someone can put together the necessary installation, tools with instructions and a couple of test/demo programs with C and/or assembly source code without breaking anything on the TIPI/PI that takes everything to a final program file that can be launched as file from Forcecommand or Editor/Assembler.

 

Beery

 

 

I don't condone using the PI attached to TIPI for things other than being a TIPI. 

 

You could in theory go to any linux machine that allows ingress through telnet. However, currently, my telnet has too many bugs to operate editors like NANO or VI... it's mostly ok at operating bash... I'm interested in it being better at that. Recently set up a comparative system to prove to my self that an 'ansi' term can be used in linux.

 

[+Vorticon]

I tried to load this morning an XB program with long lines saved as a DV\80 text file from FC and it would not work. I tried this using both Stevie and Preditor.

There are no issues when the XB lines are kept at or under 80 characters. 

Retroclouds said that Stevie does not append a CR/LF to a line when Return is pressed to continue to the next line, and I assume Preditor does the same. So could it be that FC is only expecting 80 character lines when tokenizing XB programs? Come to think of it, I can see where the difficulty lies here because how would FC know when the end of a particular XB code line is without some end of line indicator if the line exceeds 80 characters?

 

[+jedimatt42]

This is a TIPI bug. Force Command doesn't actually load basic programs. 

 

I'll need to figure out how to join lines before sending them to xbas.py of Ralph's xdt suite.

 

Linking this issue over to the correct thread.

[+jedimatt42]

As a TIPI usage issue ->