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

[J-Data]

Wow, Force Command, where have you been my whole life?  I guess I've been living under a rock.  Absolutely love this program (OS?).

 

A few dumb questions:

-On the "FG99" command, rather than going to the cart, it ALWAYS sends me be back to the TI boot screen.  The odd thing is the CART is preloaded into the selection menu but does need to be selected.  The "XB" command seems to work fine and launches into the XB cart and the selected program, but using the "FG99" to launch XB always sends me to the start screen, not XB.  Is this normal or am I doing something wrong? 

 

-In the FinalGrom99 menu, I see AUTOCMD and FORCE CMD.  Can't identify the difference in behavior or find documentation of when or why to choose one verse the other.  Any hints?

-Why does everyone's screen shots show a nice text graphic at the top of the FC start screen, and I don't see it.  Is this only available in 80 column or in older version of FC?

 

-Am I the only one who wishes there was an alias from "LS" to "DIR"?  I've typed the wrong one a thousand times. 

 

-It would also be nice if you could launch directly into a text editor (VI) with the file to be edited as a parameter from FC and then exit back into FC when done.  (I know, "CALL EDIT40")

 

Thanks for the help!

 

[dgrissom]

4 minutes ago, J-Data said:

Wow, Force Command, where have you been my whole life?  I guess I've been living under a rock.  Absolutely love this program (OS?).

 

A few dumb questions:

-On the "FG99" command, rather than going to the cart, it ALWAYS sends me be back to the TI boot screen.  The odd thing is the CART is preloaded into the selection menu but does need to be selected.  The "XB" command seems to work fine and launches into the XB cart and the selected program, but using the "FG99" to launch XB always sends me to the start screen, not XB.  Is this normal or am I doing something wrong? 

 

-In the FinalGrom99 menu, I see AUTOCMD and FORCE CMD.  Can't identify the difference in behavior or find documentation of when or why to choose one verse the other.  Any hints?

-Why does everyone's screen shots show a nice text graphic at the top of the FC start screen, and I don't see it.  Is this only available in 80 column or in older version of FC?

 

-Am I the only one who wishes there was an alias from "LS" to "DIR"?  I've typed the wrong one a thousand times. 

 

-It would also be nice if you could launch directly into a text editor (VI) from FC and then exit back into FC when done.  (I know, "CALL TEXT40")

 

Thanks for the help!

 

Not Dumb questions!  Can answer some (hopefully correctly):  Jedimatt: Correct me if I am wrong.

• AUTOCMD / FORCE CMD - Both work.  If you have F18 I believe it shows the pretty banner with ANSI graphics? (I don't have F18)
• FG99 = Syntax to run a specific FinalGrom99 file in the FG99 root directory (This can run EA, XB, Games, etc.).  FG99 "Foo" (runs the Foo .bin file).
• Text Graphics = 80 col. F18 only (am in the same boat as you - not as pretty)  ?
• DIR = Based on DOS MSX I believe? 
• Return to FC after Editor - I use EDIT40 (load TIPI.XX.EDIT40)  Hit X to exit. Usually restarts FC.  Also note, a "CALL batch/script" with the load command will usually work?  I think an internal Editor is "waiting in line" when after the API is available and someone codes or adapts one to the FC environment?

[+arcadeshopper]

Not Dumb questions!  Can answer some (hopefully correctly):  Jedimatt: Correct me if I am wrong.

• AUTOCMD / FORCE CMD - Both work.  If you have F18 I believe it shows the pretty banner with ANSI graphics? (I don't have F18)
• FG99 = Syntax to run a specific FinalGrom99 file in the FG99 root directory (This can run EA, XB, Games, etc.).  FG99 "Foo" (runs the Foo .bin file).
• Text Graphics = 80 col. F18 only (am in the same boat as you - not as pretty)  [emoji846]
• DIR = Based on DOS MSX I believe? 
• Return to FC after Editor - I use EDIT40 (load TIPI.XX.EDIT40)  Hit X to exit. Usually restarts FC.  Also note, a "CALL batch/script" with the load command will usually work?  I think an internal Editor is "waiting in line" when after the API is available and someone codes or adapts one to the FC environment?

Auto loads fc automatically with auto start at reset vs force command just gives you the menu and you have to hit 2 to load it



Sent from my LM-V600 using Tapatalk

[Omega-TI]

Like @arcadeshopper said, if you choose AUTOCMD it'll take over the FG99 cartridge, so whenever you exit an E/A5 program, it'll pop you directly back into Force Command.  There is a different method for Extended BASIC programs to accomplish the same thing.  Cool beans for sure...

 

[dgrissom]

Thanks for clarification guys.  Never really figured that one out.

[J-Data]

23 minutes ago, arcadeshopper said:

FG99 = Syntax to run a specific FinalGrom99 file in the FG99 root directory (This can run EA, XB, Games, etc.).  FG99 "Foo" (runs the Foo .bin file).

Doesn't work for me for some reason. "FG99" command always sends me back in the TI splash screen.  It does however queue up the chosen CART in the "Press 1 for Basic" selection screen.  Exact same behavior on both my consoles and both my FG99's. 

 

I suspect its related to my FG99 image(s).  Does the cart .bin file name need to match the program name in the .bin file?  I notice these don't exactly match on the ones I have in my FG99 root directory. 

 

The odd thing is XB launches fine from the "XB" command. 

[+arcadeshopper]

Just now, J-Data said:

Doesn't work for me for some reason. "FG99" command always sends me back in the TI splash screen.  It does however queue up the chosen CART in the "Press 1 for Basic" selection screen.  Exact same behavior on both my consoles and both my FG99's. 

 

I suspect its related to my FG99 image(s).  Does the cart .bin file name need to match the program name in the .bin file?  I notice these don't exactly match on the ones I have in my FG99 root directory. 

 

The odd thing is XB launches fine from the "XB" command. 

it needs to be the exact file name on the sdcard  for instance if your xb is xb_g.bin its xb_g

 

[J-Data]

1 minute ago, arcadeshopper said:

it needs to be the exact file name on the sdcard  for instance if your xb is xb_g.bin its xb_g

That's what I was doing (in my case using "FG99 EXBASICG" for a file named exbasicg.bin).  Tried this with about 10 different FG99 .bin files with no luck.  If I put an invalid .bin file name I get a completely different behavior, the FG99 LED just keeps flashing red.   That's not the issue I'm seeing here. 

 

I tried changing the .bin file name to match the program name shown on the FG99 menu, but still no joy.  Always takes me to the splash screen. 

 

I'm sure I'm doing something dumb. 

[Omega-TI]

I'm not home at the moment to test, to confirm, but does the BASIC .BIN need to be in the ROOT directory?  Do you by chance have it in a sub-directory/folder?  I know mine is in the ROOT, but that might not mean anything.  Check it out and see.

[+jedimatt42]

18 minutes ago, J-Data said:

Doesn't work for me for some reason. "FG99" command always sends me back in the TI splash screen.  It does however queue up the chosen CART in the "Press 1 for Basic" selection screen.  Exact same behavior on both my consoles and both my FG99's. 

 

I suspect its related to my FG99 image(s).  Does the cart .bin file name need to match the program name in the .bin file?  I notice these don't exactly match on the ones I have in my FG99 root directory. 

 

The odd thing is XB launches fine from the "XB" command. 

Sorry, yes, the FG99 command doesn't know the entry point of your cartridge, so it just resets the console after instructing the FG99 to load the bin. 

I haven't been ambitious enough yet to scan the cartridge headers after the FG99 has loaded it... to determine the target address myself.

 

XB, requires you to set XBADDR (or defaults ot the value for TI Extended BASIC v110) and that is why it is able to launch right into XB.  

[+jedimatt42]

1 hour ago, J-Data said:

Wow, Force Command, where have you been my whole life?  I guess I've been living under a rock.  Absolutely love this program (OS?).

 

A few dumb questions:

-On the "FG99" command, rather than going to the cart, it ALWAYS sends me be back to the TI boot screen.  The odd thing is the CART is preloaded into the selection menu but does need to be selected.  The "XB" command seems to work fine and launches into the XB cart and the selected program, but using the "FG99" to launch XB always sends me to the start screen, not XB.  Is this normal or am I doing something wrong? 

 

-In the FinalGrom99 menu, I see AUTOCMD and FORCE CMD.  Can't identify the difference in behavior or find documentation of when or why to choose one verse the other.  Any hints?

-Why does everyone's screen shots show a nice text graphic at the top of the FC start screen, and I don't see it.  Is this only available in 80 column or in older version of FC?

 

-Am I the only one who wishes there was an alias from "LS" to "DIR"?  I've typed the wrong one a thousand times. 

 

-It would also be nice if you could launch directly into a text editor (VI) with the file to be edited as a parameter from FC and then exit back into FC when done.  (I know, "CALL EDIT40")

 

Thanks for the help!

 

 

The answer to a few of these questions is that it is only version 0.something. There is a roadmap many posts back... Give it a year.

 

[J-Data]

38 minutes ago, jedimatt42 said:

the FG99 command doesn't know the entry point of your cartridge, so it just resets the console after instructing the FG99 to load the bin. 

OK, so normal behavior. 

 

Looking forward to seeing this evolve.  Thanks for the great program (shell?).

[HOME AUTOMATION]

2 hours ago, J-Data said:

-On the "FG99" command, rather than going to the cart, it ALWAYS sends me be back to the TI boot screen.

If you modify the HEADER of the cartridge you wish to load, by moving the address in the PROGRAM word, over to the POWER-UP word. It should boot directly!

[dgrissom]

34 minutes ago, J-Data said:

OK, so normal behavior. 

 

Looking forward to seeing this evolve.  Thanks for the great program (shell?).

 

1 hour ago, Omega-TI said:

I'm not home at the moment to test, to confirm, but does the BASIC .BIN need to be in the ROOT directory?  Do you by chance have it in a sub-directory/folder?  I know mine is in the ROOT, but that might not mean anything.  Check it out and see.

Basic in root and case sensitive.

[+Vorticon]

I've noted an issue with FCMDXB.

When starting up an XB program from FC, it runs fine. However, if I return to FC via the FCMDXB program and then try to run any XB program, XB gets loaded and I get a SYNTAX ERROR and there is no program present. I am using RXB 2015 as my main XB. Not sure if this is related to RXB or FC.

Could someone using another XB please try this out an report back?

[+jedimatt42]

3 hours ago, Vorticon said:

I've noted an issue with FCMDXB.

When starting up an XB program from FC, it runs fine. However, if I return to FC via the FCMDXB program and then try to run any XB program, XB gets loaded and I get a SYNTAX ERROR and there is no program present. I am using RXB 2015 as my main XB. Not sure if this is related to RXB or FC.

Could someone using another XB please try this out an report back?

 

This sounds similar to a problem reported earlier by Omega... Hmm. Or was this the inverse of the problem he had... He was using RXB also... and so I tested with it... but I never got to the bottom of it. I don't think I was able to reproduce. There were all kinds of other questions raised that probably had nothing to do with anything, but led me to dismiss it as something unique to him. 

 

You could check for me, and see what is being written to the DV80 file:  TIPI.FC.FC/XB 

 

It should be a single line like: 10 RUN "TIPI.SOMEDIR.WMEXP732", where the thing in quotes is the full path to whatever experiment you are running...

 

There is some accounting in the /var/log/tipi/tipi.log 

[+Vorticon]

7 hours ago, jedimatt42 said:

 

This sounds similar to a problem reported earlier by Omega... Hmm. Or was this the inverse of the problem he had... He was using RXB also... and so I tested with it... but I never got to the bottom of it. I don't think I was able to reproduce. There were all kinds of other questions raised that probably had nothing to do with anything, but led me to dismiss it as something unique to him. 

 

You could check for me, and see what is being written to the DV80 file:  TIPI.FC.FC/XB 

 

It should be a single line like: 10 RUN "TIPI.SOMEDIR.WMEXP732", where the thing in quotes is the full path to whatever experiment you are running...

 

There is some accounting in the /var/log/tipi/tipi.log 

The FC/XB file shows the correct path for the XB program I am trying to load

The log files have entries only till 7/19/20 even though I have been actively using the tipi daily and I don't see any errors logged.

[RXB]

14 hours ago, Vorticon said:

I've noted an issue with FCMDXB.

When starting up an XB program from FC, it runs fine. However, if I return to FC via the FCMDXB program and then try to run any XB program, XB gets loaded and I get a SYNTAX ERROR and there is no program present. I am using RXB 2015 as my main XB. Not sure if this is related to RXB or FC.

Could someone using another XB please try this out an report back?

I wonder it if could by RXB has a initialization routine I added for a cart?

[3829]               ***********************************************************
[3830]               * RXB PATCH FOR GAZOO HARDWARE CART TO SET ROMS

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0072 
EDIT-359
[3831] 7EA3 86,AF,35 NOMENU CLR   V@>35D7       Clear menu flag
       7EA6 D7
[3832] 7EA7 BF,A8,CE         DST   >994A,V@2254 Set loader flag
       7EAA 99,4A
[3833] 7EAC 31,00,0A         MOVE  10,G@DSCLOD,V@>2256
       7EAF AF,22,56
       7EB2 63,51
[3834] 7EB4 5E,D1            BR    MENUGO
[3835]               ***********************************************************
[3836] 7EB6 00,00,7E MENU   DATA  0,MENUUP
       7EB9 CC
[3837] 7EBA 11              BYTE  17
[3838] 7EBB 52,58,42        TEXT  'RXB 2015  MENU   '
       7EBE 20,32,30
       7EC1 31,35,20
       7EC4 20,4D,45
       7EC7 4E,55,20
       7ECA 20,20
[3839] 7ECC BE,AF,35 MENUUP ST    >F0,V@>35D7   Set MENU/REDO flag
       7ECF D7,F0
[3840] 7ED1 87,8F,DD MENUGO DCLR  @>6000        SET ROM BANKS FOR GAZZO CART <<<<<<<<<<<<<<< could be this ?
       7ED4 00
[3841] 7ED5 43,72           BR    TOPLEV        Restart but below CLR bytes
[3842]               ***********************************************************
[3843]                      END

 Could it be that line [3840] MENUGO DCLR @>6000  SET ROM BANKS FOR GAZZO CART   ????

[+jedimatt42]

Just an update on my progress, as it has been a couple months almost... 

 

I have restructured the ROM to be 128k. 

I have moved all the code into ROM - no longer copying 8k of libti99 up into expansion ram. And removed a number of pre-allocations to stack as needed.

So now the system only uses the lower expansion ram. There is about 4k of stack space.

If detected, SAMS mapping is turned on and the first 8 pages are mapped into the 32k lower and upper expansion in sequence.

 

And I have created an API table in bank_0. -- So, I'd like to describe the approach and welcome criticism.

 

Loading PROGRAM images that have a ForceCommand header is performed by searching device/directories specified by the PATH environment variable. If the file matching the name is found, and it is a PROGRAM and the first word is 0xFCFC then it'll load. 

 

The program image is not a split EA5 binary. It would be more like a cartridge image, but on the TI file system as a PROGRAM file. When loaded, up to the first 24k will be loaded into 0xA000 -> 0xFFFF, including the 8 word header. 

The last word in the header is the program entry address. 

 

Basically the gcc calling convention is used. But this is pretty easy to cope with from raw assembly in my opinion. So I'll describe in terms of assembly...

 

When your program is called with a BL, the cartridge will be in bank_0, so the API indirection table is available. 

R11 will be the return address to resume into the cartridge.

R1 will be the address of command parameter string - if you type HELLO /B WORLD, and your program is HELLO, then R1 will be the address of "/B WORLD" (which will be a zero terminated string)

R10 will be the stack pointer - to put an int on the stack: AI R10,-2, mov yourthing,*R10

Programs are responsible for popping the stack on the way out.. So when you return to cartridge space, it is expected that R10 is the same as when your program was entered. 

R1 should be an integer return value set to 0 if the program ran without error, or non-zero if an error was encountered. 

Workspace Pointer will be 0x8300. 

 

The API in the cartridge is callable using data in the table starting at 0x6080. 

0x6080 is the address of the address of the system call routine ( to enter into the bank switching world of the cartridge space. ) 

then the table consists of a function address and bank address pair.

An equate file, and gcc header file will be provided. 

But for instance, the first entry in the API is the terminal output fc_tputs - table entry 0x6082

So, to call that, do something like:

 

    DECT R10      ; push R11 on the stack
    MOV R11,*R10
    ...           
    LI R0,>6082   ; load API index into R0
    LI R1,MSG     ; set R1 points to the c-string to send to the terminal display
    LI R11,>6080  ; call the api
    BL *R11
    ...
    MOV *R10,R11  ; pop from the stack and restore R11
    INCT R10
    CLR R1        ; set program to return 0 to force command
    RT            ; return to force command

 

API functions are likely to use most, or all the registers. You are free to stash registers you need to preserve on the stack, or use a different workspace, or whatever other TMS9900 assembly techniques you like.

API parameters are passed as R1 - R9. R0 is the API index you'd like to call. R10 must be a stack space ( grows down ). The stack space can be the same stack space given when the PROGRAM was executed.

 

I am working on API calls to make sure they are useful.. and to provide access to things like the current device/directory, and where the program was found and executed from. And current display attributes will be needed to be available. 

 

The header as I've defined it, is 4 words... 1st is just a ForceCommand flag. 2nd is either 0x0000, or the number of SAMS pages that should be loaded from the program image... 3rd is a promise from your program, if 0xFCFC then ForceCommand will not reset the screen when your program returns. If anything else, then the previous display mode will be re-established. The 4th word in the header is the entry point address of your program. 

 

Most of this is implemented, but it's proof of concept level right now... There are i's to cross and t's to dot , but that's the plan... 

 

For gcc programs, it is even easier, you just include my header file for the api, and call the functions.

 

[+retroclouds]

Thanks.

 

I’d like to integrate my Stevie Editor in FC, so I’ll be taking a close look at this.

 

The thing is that Stevie is a cartridge image itself with multiple banks and using most of the 32K memory space and some SAMS banks. Having said that, don’t see this as being impossible, guess it’s a matter of setting up the proper environment on startup and doing a proper exit.

[+jedimatt42]

23 hours ago, retroclouds said:

Thanks.

 

I’d like to integrate my Stevie Editor in FC, so I’ll be taking a close look at this.

 

The thing is that Stevie is a cartridge image itself with multiple banks and using most of the 32K memory space and some SAMS banks. Having said that, don’t see this as being impossible, guess it’s a matter of setting up the proper environment on startup and doing a proper exit.

 

Well, there is only one cartridge in the system at a time, but FG99 does allow switching which cartridge that is. 

 

Could write a ForceCommand launcher program that uses the FG99 features to bounce to another cartridge. The launcher could take the parameters, and stuff them in a mailbox in memory that Stevie would look for. Stevie, would consume the mailbox, and then mark(erase) it so it knows not to use it again, until unmarked. Stevie could then bounce back to ForceCommand by switching cartridges again.  I've thought about adding a feature in ForceCommand if TIPI is present, to use TIPI storage as a mailbox for returning to the same directory... 

 

[Omega-TI]

_{Future Feature Request for Force Command}

^{(Once you start taking them of course)}

 

^{CALL SAY filename  - A method for playing short voice files from the command prompt or embedded into scripts.}

 

^{1) Storage space for sound files on a TIPI system is not a problem, as there can quite literally be gigabytes of unused space on an SD card.}

^{2) I propose by default all sound files reside in a TIPI.AUDIO. subdirectory for organizational neatness.}

 

^{A PC based program to easily record and save the audio files would be necessary.  Naturally once a recording program such as this is developed, it would not be limited to Force Command, I'm pretty sure people would start adding their own sounds into games or other programs a well leading to an explosion of new programs.}

 

^{As for the coding of such sound files, that is up for grabs.  I know this is probably a "chicken and egg endeavour", but I bet our resident audio guru could release a "new standard" that could easily be adopted by the entire community.}

[+jedimatt42]

13 hours ago, Omega-TI said:

_{Future Feature Request for Force Command}

^{(Once you start taking them of course)}

 

^{CALL SAY filename  - A method for playing short voice files from the command prompt or embedded into scripts.}

 

^{1) Storage space for sound files on a TIPI system is not a problem, as there can quite literally be gigabytes of unused space on an SD card.}

^{2) I propose by default all sound files reside in a TIPI.AUDIO. subdirectory for organizational neatness.}

 

^{A PC based program to easily record and save the audio files would be necessary.  Naturally once a recording program such as this is developed, it would not be limited to Force Command, I'm pretty sure people would start adding their own sounds into games or other programs a well leading to an explosion of new programs.}

 

^{As for the coding of such sound files, that is up for grabs.  I know this is probably a "chicken and egg endeavour", but I bet our resident audio guru could release a "new standard" that could easily be adopted by the entire community.}

Counter proposal:

 

Part 1: I release the API, and then anyone who has a favorite sound format and the will, can write a command to play sounds from whatever storage they want organized however they want. There can even be multiple players. The command could take the full path or a relative path to the sound file to play. Then if people want to organize them differently, they can. There is no reason for it to make assumptions about a TIPI being present.  

 

Part 2: Anything named 'SAY' remains specifically about speech on the 4A, and not generically sound.

 

---------

 

This reminds me, CALL will probably go away, now that I've implemented PATH searching. I will more likely detect if the file is a PROGRAM image and treat it as a command, or if it is a DV/80, treat it like a script.

[webdeck]

I'm loving Force Command.  I've been using it to copy files off of my somewhat flaky Seagate ST-225 drive and onto my TIPI.  I have a few questions:

1. It sounds like it reads one sector at a time from the hard drive, re-seeking after each sector, which takes a very long time.  Is there any way to make it copy faster (e.g. use a larger buffer in RAM)?
2. Right now, I have to copy the files in each directory separately, including subdirectories.  Is it possible to do a recursive copy?
3. It gives an error when trying to copy an empty file.  Why is that an error as opposed to copying the empty file?
4. My hard drive is not reliable - is there any way to have it keep retrying sectors some number of times before giving up with an error?

Thanks again for the awesome tools!

[+jedimatt42]

35 minutes ago, webdeck said:

I'm loving Force Command.  I've been using it to copy files off of my somewhat flaky Seagate ST-225 drive and onto my TIPI.  I have a few questions:

1. It sounds like it reads one sector at a time from the hard drive, re-seeking after each sector, which takes a very long time.  Is there any way to make it copy faster (e.g. use a larger buffer in RAM)?
2. Right now, I have to copy the files in each directory separately, including subdirectories.  Is it possible to do a recursive copy?
3. It gives an error when trying to copy an empty file.  Why is that an error as opposed to copying the empty file?
4. My hard drive is not reliable - is there any way to have it keep retrying sectors some number of times before giving up with an error?

Thanks again for the awesome tools!

 

It does indeed copy one sector at a time. I do plan to address that at some point.

 

There is no way to change these behaviors without modifying the software. I don't have bad hard drives to test against, or any hard drives to test against... so I'm not going to implement anything to deal with retries. I have no way of testing that my code would work. If you want to submit a Pull Request in Github, I would entertain it. 

 

I have been revamping the memory model, and am in a position to apply more memory to the file copy issue... I don't have any spinny disks, or things that seek, so I never noticed this overhead... it will be some weird balance, between seek time, and duplicate memory copying. Does anyone know the magic number of sectors that pays for a seek? Hmm. maybe 2 sectors at a time cuts seeks in half? 4 reduces seeks to 25%. Once you are doing any copying from VDP to RAM, you are doing that twice per sector anyway... Right now, I don't have to copy the sector out of VDP and back in, and it is optimal for my seekless drives. 

 

Regarding empty files... You can have empty files? like... 0 sector files? I assumed that's an error state.