Jump to content
jedimatt42

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

Recommended Posts

14 minutes ago, Omega-TI said:

For the first time in a long time, I'm going not going to immediately upgrade.  Things are working perfectly right now, so I'll hold off until the kinks get worked out an there is a reason I NEED to upgrade.

I have both versions available on my fg99.  If FC is going to reach its final finished form, I believe we need to help Jedimatt and run it through its paces.  

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Just now, dgrissom said:

I have both versions available on my fg99.  If FC is going to reach its final finished form, I believe we need to help Jedimatt and run it through its paces.  

 

I agree, but at the present time I have to squeeze in AA time here and there throughout the day when I have a few minutes, I don't have time to redo everything all the time.

Share this post


Link to post
Share on other sites
3 hours ago, dgrissom said:

I guess it may be a bug (or I don't understand the new scripting)?

 

In the past, I would call a script with:  "CALL WEAT"

 

WEAT is a DV80 files (contents):

  CLS

  CD TIPI.DEV

  XB WEATHER/TB  (WEATHER IS A TidBit file).

(All the above commands work when typed from the command line in the this version.)

 

Since "CALL" is removed, typing "WEAT" at the $ prompt returns:  "unknown command: WEAT"

CALL WEAT returns "unknown command: CALL"

Am I missing something? or scripting is off-line on this version?

 

My configuration:  (TIPI/32K - rPI zero w)

 

 

Maybe I broke the finding of files more than I thought... 

 

So, now there is a PATH environment variable, but it is supposed to look in your current directory first. Then search the device names or directories listed in the path. It is probably that I buggered that up after testing it last. 

There is a help PATH, which is mostly syntax help... I need to write the wiki page still.. 

 

And as for, near final... I have a whole set of criteria for what needs to be added to call it 2.0

 

  • Like 1

Share this post


Link to post
Share on other sites

Very similar to @dgrissom 's script scenario, I have a DV80 file, script called "EDIT" in my TIPI.FC.BIN. directory.

 

The contents are: 

LOAD TIPI.EDIT.EDIT80

if I go to that directory, and run the script, it is working for me.

 

CD TIPI.FC.BIN.
EDIT

 

Now, also if I have a DV80 file in my first drive called AUTOCMD ( my first drive is TIPI. ) and I have it setting a that directory as my PATH

AUTOCMD looks like:

 

PATH=TIPI.FC.BIN.
CLS
VER
TIPIBEEPS

 

Then I don't have to CD to the directory, I can just run EDIT and it will find the script and run it. 

 

[1000.TIPI.]
$ EDIT

 

This does appear to be working. 

 

There is nothing special about the directories I've chosen... 

 

I have another script in TIPI. called FBFORTH

 

TIPIMAP DSK1. TIPI.FB4TH210
FG99 FBFORTH

 

And with my PATH set or unset... if I cd to TIPI. I can just run FBFORTH and it works. 

 

There is a bug I found in unsetting PATH.  You should be able to 

 

PATH=

to unset a variable, just assign an empty value to it. It currently produces garbage if you do that. But that shouldn't get in the way... 

 

----

 

Oh, now these are filenames, and filenames on the 4A are case sensitive... while ForceCommand built-in command names are not.

  • Like 1

Share this post


Link to post
Share on other sites

@dgrissom, it is possible your issues are resolved with tweaks I made to TIPI : 

 

The trailing whitespace thing in name translation had very odd impact.

Share this post


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

@dgrissom, it is possible your issues are resolved with tweaks I made to TIPI : 

 

The trailing whitespace thing in name translation had very odd impact.

It seems that was the main problem.  It now recognizes my scripts.

 

I play with it over the next few days to see if other problems show up.   Fingers crossed. 😉 It's nice to not have to use the "CALL" before the script!

 

Thanks jedimatt42 for your hard work!

  • Like 2

Share this post


Link to post
Share on other sites

I've noticed we can't use the full path to a script anymore ( sad-face-with-slight-embarrassment emoji ) - I left a TODO in the code comments ... never got it to done. So that needs fixing. ( engineer-thinks-he-is-funny emoji )

 

P.S. I found an emoji system that works in CHATTI, and the myti99.com browser group chat. 

  • Like 1

Share this post


Link to post
Share on other sites
On 10/3/2020 at 4:53 AM, Vorticon said:

I realized yesterday that the RMDIR command does not work on non-empty directories. And the DELETE command does not accept * as an argument, so I have to delete all the files in a directory one by one before being able to delete the directory itself.

Therefore a wish list:

  • DELETE * to delete all files in a directory (with a confirmation prompt)
  • RMDIR with a switch for deleting all sub-directories and files in the requested directory

Easier said than done, hence the wish part :)

 

Ver 1.1 has the wildcard support for DELETE now, with an option to not be prompted for each file... 

 

Fixes the other bugs I found in 1.0 as well.

 

For the RMDIR option to recursively delete a tree, I think I'll add a new command DELTREE for that. I need to refactor my wildcarding code so it doesn't use global variables, put the context on the stack, then it should be able to be used in a recursive depth first manner. Maybe next week's release.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
On 10/9/2020 at 1:04 AM, jedimatt42 said:

 

Ver 1.1 has the wildcard support for DELETE now, with an option to not be prompted for each file... 

 

For the RMDIR option to recursively delete a tree, I think I'll add a new command DELTREE for that. I need to refactor my wildcarding code so it doesn't use global variables, put the context on the stack, then it should be able to be used in a recursive depth first manner. Maybe next week's release.

Delete * works well.

 

Will DELTREE be an external command?  (In DOS, I believe it was.)  Will we get a new subdirectory of externals?   "FCDOS" or such?  

 

A modified Editor (like Edit40/Edit80) that will take arguments will be next!

 

This is getting fun!

  • Like 2

Share this post


Link to post
Share on other sites

Some versions of EDIT have a contract with the EA cartridge, where the EA code seems to be responsible for the loading of the data, and then EDIT is executed. If this impression I have is true, maybe I can write an abstract wrapper around that, which is passed the file to edit on the commandline. 

 

I haven't looked very far into this. Could be memory map issues, etc.

  • Like 1

Share this post


Link to post
Share on other sites

It looks like a slightly sawtooth line on my computer (40 column stock TI).

I kind of like the look. 😉 

In BASIC my TI has a distinct dash in the underline position.  Compared to my PC's continuous line.

What should I expect?

Share this post


Link to post
Share on other sites
10 hours ago, dgrissom said:

It looks like a slightly sawtooth line on my computer (40 column stock TI).

I kind of like the look. 😉 

In BASIC my TI has a distinct dash in the underline position.  Compared to my PC's continuous line.

What should I expect?

It should be a dash in the bottom row. It is a mystery why it isn't correct. I'll brute force fix it. Just strange. Finally got tired of looking at it. 

Share this post


Link to post
Share on other sites

Matt,

 

Quick question.  What video mode(s) will Force Command recognize if a TI-99/4A has a configuration with a 9938 chip such as the EVPC card?

 

Beery

Share this post


Link to post
Share on other sites

Matt,

 Another quick question, arcadeshopper said this program no longer needs tipi. What's the requirements for a non-tipi, no Finalgrom system?

Thanks!

Share this post


Link to post
Share on other sites
Matt,
 Another quick question, arcadeshopper said this program no longer needs tipi. What's the requirements for a non-tipi, no Finalgrom system?
Thanks!
It needs a final Grom for full functionality but if you can burn the rom to an eprom and put it on say a red cartridge board it should work fine of course it gets updated all the time so you're going to be burning a lot of ROMs if you want to keep up to date

Sent from my LM-V600 using Tapatalk

Share this post


Link to post
Share on other sites
1 minute ago, arcadeshopper said:

It needs a final Grom for full functionality but if you can burn the rom to an eprom and put it on say a red cartridge board it should work fine of course it gets updated all the time so you're going to be burning a lot of ROMs if you want to keep up to date

Sent from my LM-V600 using Tapatalk
 

 

You're right, for full functionality it needs an FG99.  A Red Board would not give the user the full capabilities.  One thing that comes to mind is the ability to load a cartridge .BIN from the DOS environment.  Lately a few of us have been using it to load a version of Extended BASIC, and a program (like Weather 80) and upon exit go back directly back to the DOS environment. 

Share this post


Link to post
Share on other sites
4 hours ago, BeeryMiller said:

Matt,

 

Quick question.  What video mode(s) will Force Command recognize if a TI-99/4A has a configuration with a 9938 chip such as the EVPC card?

 

Beery

 

3 hours ago, dhe said:

Matt,

 Another quick question, arcadeshopper said this program no longer needs tipi. What's the requirements for a non-tipi, no Finalgrom system?

Thanks!

 

|

\-----------------------\

                               |

                               v

 

  • Like 1

Share this post


Link to post
Share on other sites

I'll add @BeeryMiller, I would like to support 8838 80 column mode. I do test in Mame and classic99 often enough that it would be nice...  

 

I don't know off hand how to detect 9938/58 - I do recall some chatter in the F18A threads about it though... - I assume I could use the 9th instead of 5th sprite limit to detect.

  • Like 1

Share this post


Link to post
Share on other sites
10 minutes ago, jedimatt42 said:

I'll add @BeeryMiller, I would like to support 8838 80 column mode. I do test in Mame and classic99 often enough that it would be nice...  

 

I don't know off hand how to detect 9938/58 - I do recall some chatter in the F18A threads about it though... - I assume I could use the 9th instead of 5th sprite limit to detect.

I thought years ago, Jeff White may have written some code to detect the difference between a 9918 and a 9938.  Not sure about detecting a 9958.  @InsaneMultitasker might know if there is a test routine somewhere. 


Thinking out loud here...... Would testing testing some route for RAM above 16K be a route?  Not sure how the 9938 and the F18A may or may not use/access RAM above 16K if there are any differences.

 

 

Share this post


Link to post
Share on other sites
44 minutes ago, BeeryMiller said:

I thought years ago, Jeff White may have written some code to detect the difference between a 9918 and a 9938.  Not sure about detecting a 9958.  @InsaneMultitasker might know if there is a test routine somewhere. 


Thinking out loud here...... Would testing testing some route for RAM above 16K be a route?  Not sure how the 9938 and the F18A may or may not use/access RAM above 16K if there are any differences.

 

 

I don't need smooth horizontal scrolling, so I don't need to know 9958 vs 9938... - and I already detect F18A, so just detect for that first... use best mode if detected... then detect Yamaha, use that if detected, or fall back on 9918. 

 

The yamaha chips will set a status bit if there is a 9th sprite on the same line as 8 others. A 9918 will set that bit at the 5th sprite. Probably have to wait for vertical blank interrupt to know that the VDP has observed the situation.

Share this post


Link to post
Share on other sites

Yes, there are some chip detection routines that Jeff had put together , IIRC, during the Delphi and Yahoo group days.  Is that info 99erpedia?

 

For the Infocom interpreter I chose the mundane method of comparing a value written to two vram banks.  The code is lazy by design and doesn't (yet) test for the F18a. For now I just assume an 80 column app with a binary choice.  The comment suggests I tested the routine in September.  Careful, vwtr is a BL subroutine with the usual byte order reversed. 

 

;
; check for 9938 by comparing byte in VRAM bank 1 vs bank 0
; flag==0==9938;  1=f18a
;

      li   r0,>000e     ;bank 0 to start (in case it got changed before load time)
      bl   @vwtr
      li   r2,>3000
      mov  r2,r0
      mov  r0,r1
      blwp @vsbw       ;load >30 into address >3000/bank 0        
      li   r0,>010e     ;set bank 1
      bl   @vwtr

      mov  r2,r0
      li   r1,>3100     ;load >31 into same address/bank1
      blwp @vsbw
      li   r0,>000e     ;restore to bank 0
      bl   @vwtr

      mov  r2,r0        ;read value at >3000
      blwp @vsbr
      cb   r0,r1        ;if >30 in bank 0, we have vram present in bank  1

      jne  SET38      ;and thus we assume 9938        ;9.5,  test  worked w/Geneve  9938

;set f18a mode if r0==r1

 

 

  • Like 2
  • Thanks 1

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