Jump to content
jedimatt42

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

Recommended Posts

Posted (edited)

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 by jedimatt42

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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.

  • Like 3

Share this post


Link to post
Share on other sites

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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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.

  • Sad 1

Share this post


Link to post
Share on other sites

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

  • Like 3

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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...

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by jedimatt42
  • Like 6

Share this post


Link to post
Share on other sites
9 hours ago, jedimatt42 said:

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

Thanks!

  • Like 1

Share this post


Link to post
Share on other sites
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... 

  • Like 6
  • Thanks 1

Share this post


Link to post
Share on other sites
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...

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...