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

[+jedimatt42]

2 hours ago, wolhess said:

Hi,

 

in my system, if I run a program from Force Command, I saw always access on my physical drive DSK1.

Today I tested it again to run the XB weather program on different way's.

 

What I think:

- The XB command ignores the current tipimap

- Force Command is mapping DSK1 to TIPI.FC for the XB command

- If Force Command see no TIPI in the path it deletes the current DSK1 mapping, so the physical DSK1 is used to load the program.

- The original TIPI.FC.LOAD program always deletes the DSK1 mapping so line 40 has to change from "D$=SEG$(A$,8,4)"  to "40 D$=SEG$(A$,9,4)"

- I can't use XB DSK1.PROGNAME or XB TIPIPATH.PROGNAME if PROGNAME itself will load something from the mapped DSK1.,
  so I have to start a loading program first, which maps the correct tipipath to DSK1.

 

@jedimatt42 
I'm using the new FC v12 and XB2.8 with the main address: 31435
Is it right that the XB command needs the full tipi path to find the program in the right tipi folder?
Is it right that the tipimap command is unnecessarry for using the XB command?

 

XB certainly always overrides the DSK1 mapping on TIPI. It must set it to TIPI.FC. so that XB will find the TIPI.FC.LOAD program and run it on startup.

 

XB also writes a second file TIPI.FC.FC/XB that contains the RUN "YOUR.PROGRAM.FULLY.QUALIFED"

As you've seen this is what TIPI.FC.LOAD runs. I think I assumed people would have AUTOMAP on, so DSK1 would get remapped to the folder containing the target basic program when that is loaded by the PI. 

 

The XB command should be able to take a file in the current directory, or a full path. These 2 cases seem to be what I do in practice. You should be able to use a relative path, but I'm guessing there is a bug with that. I'll test. There are a couple places in that code that could be going wrong. 

 

There is room for improvement in the mapping handling. The generated TIPI.FC.FC/XB program could be written to hold the code to reset the DSK1 mapping to what it is before the XB command ran. This way if AUTOMAP is off, you shouldn't have to write little shims to set the mapping... If AUTOMAP is on, this would get overridden again, consistent with TIPI behavior. But if AUTOMAP is off, then this would undo the transient mapping to TIPI.FC for the LOAD magic. So this is an improvement I will make. 

 

TIPI also has a feature where you can put a DV80 file in the directory of the PROGRAM file and if AUTOMAP is on, when that PROGRAM is loaded the mappings declared in that file loaded. 

 

I pretty much never use manually mapped DSK1 for anything, so I only tested XB where the path passed was from TIPI, or is DSK1 it expected the real floppy. I didn't try DSK1. where it is mapped. If I reset the mapping of DSK1 in TIPI.FC.FC/XB that should also fix the issue with XB DSK1.WEATHER3 using the real floppy instead of the TIPI path that DSK1. was mapped to. 

 

[+jedimatt42]

4 minutes ago, Omega-TI said:

It's only going to be temporary Matt... unless you are so fast you get done before I get home this evening.  Ha!  ?

 

Temporary stuff sticks around for months. If not years, and requires messaging campaigns to expunge. I think you are talking about @wolhess issue with XB, in which he clearly has a thorough understanding of what is going on and how to work around it. 

[Omega-TI]

If individuals develop methods to temporarily get something done/accomplished for themselves in the privacy of their own homes, I don't see the issue, especially if it works or "works for them".  Later, as things evolve, and working new functions appear, they can always choose to switch to the new prescribed method(s).  Whatever a person decides to do for themselves, be it for consistency, ease of use, or whatever seems cool to me.  Different strokes for different folks or as they old saying goes, "There's more than one way to skin a cat".  One example is the CALL command that has since been removed, remembering to use CALL for one thing and LOAD for another was, not optimal for me.    

[+jedimatt42]

25 minutes ago, Omega-TI said:

If individuals develop methods to temporarily get something done/accomplished for themselves in the privacy of their own homes, I don't see the issue

Yes! Yes! That is what I'm asking of you.

 

Now, to be clear, this forum is public.

Edited December 31, 2020 by jedimatt42

[Omega-TI]

18 minutes ago, jedimatt42 said:

Yes! Yes! That is what I'm asking of you.

 

Now, to be clear, this forum is public.

 

So basically, STFU Omega?  No need to share any information that others might find useful, to use in the privacy of their own homes if it goes against the beliefs and/or ideas of another.  Got it.

[+jedimatt42]

58 minutes ago, Omega-TI said:

 

So basically, STFU Omega?  No need to share any information that others might find useful, to use in the privacy of their own homes if it goes against the beliefs and/or ideas of another.  Got it.

 

PM sent.

[+jedimatt42]

7 hours ago, wolhess said:

...

 

What I think:

- The XB command ignores the current tippimap

- Force Command is mapping DSK1 to TIPI.FC for the XB command

- If Force Command see no TIPI in the path it deletes the current DSK1 mapping, so the physical DSK1 is used to load the program.

- The original TIPI.FC.LOAD program always deletes the DSK1 mapping so line 40 has to change from "D$=SEG$(A$,8,4)"  to "40 D$=SEG$(A$,9,4)"

- I can't use XB DSK1.PROGNAME or XB TIPIPATH.PROGNAME if PROGNAME itself will load something from the mapped DSK1.,
  so I have to start a loading program first, which maps the correct tipipath to DSK1.

 

@jedimatt42 
I'm using the new FC v12 and XB2.8 with the main address: 31435
Is it right that the XB command needs the full tipi path to find the program in the right tipi folder?
Is it right that the tipimap command is unnecessarry for using the XB command?

 

Back to on topic... 

 

I was attempting to handle the case of a real disk drive in all that code in TIPI.FC.LOAD. But even that was wrongly coded... the SEG$(A$,8,4) should actually have been SEG$(A$,1,4) as I'm trying to pull the device name off the front of the full file path.

 

But all of that is pointless if automap is on, DSK1 will get mapped again when the TIPI.FC.FC/XB is loaded. I need to simplify TIPI.FC.LOAD to 

 

10 RUN "TIPI.FC.FC/XB"

 

and change the generated TIPI.FC.FC/XB to handle the mapping restoration:

10 OPEN #1:"PI.CONFIG"
20 PRINT #1:"DSK1_DIR=<oldmapping>"
30 CLOSE #1
40 RUN "<yourpath>"

That way, I've undone the temporary mapping to get XB to load TIPI.FC.LOAD, and restore your explicit mapped or unmapped state of DSK1 prior to running the actual desired xb program.

 

That should allow running from mapped DSK1 or TIPI, or physical DSK1 without astonishment.

 

 

 

[+jedimatt42]

Hopefully, this is the last release in 2020... 

 

Update 1.13 - download in post #1 

 

- improve TIPI mapping as discussed for XB command. 

- include those modified times in the 80 column directory listing.

- I think this modified sysinfo to show 9929 for the PAL system if we think it is not a '38, '58 or F18A.

- A few bug fixes related to the bar.

[mr_gw454]

14 hours ago, jedimatt42 said:

Hopefully, this is the last release in 2020... 

 

Update 1.13 - download in post #1 

 

- improve TIPI mapping as discussed for XB command. 

- include those modified times in the 80 column directory listing.

- I think this modified sysinfo to show 9929 for the PAL system if we think it is not a '38, '58 or F18A.

- A few bug fixes related to the bar.

This just keeps getting better.  Thank you and Happy New Year!

 

[+wolhess]

On 1/1/2021 at 1:19 AM, jedimatt42 said:

Update 1.13 - download in post #1 

Hi @jedimatt42,

 

from FC 1.13, if I run a small XB program like WEATHER3 (see post #547) it is always working fine!

 

When I break the XB program and make a >NEW  and the OLD TIPI.MM.MM (a very large XB program)
the program will not load correct and shows an ERROR when I >RUN it.

 

The >LIST shows the following (not correct XB program)

 

If I reset the FG99 and load XB2.8 direct from the FG99 the command >OLD TIPI.MM.MM and LIST -200 shows the correct program and it is working correct.
 

 

 

 

During the more than 10 tests, after resetting the FG99, I have sometimes the following result:

 

I run the programs direct from the AUTOCMD script or from the command line with the same result.

The WEATHER3 program is running fine.
The Mega Menu program is freezing the TI. I can QUIT to the TI title screen and select 2 for XB2.8 and it loads the first part of the program and freeze the TI again:
 

 

 

I changed the XB to TI-XB and I got the same results!

I changed the TIPI configuration to AUTOLOAD=ON and I got the same results!

I changed back to FC v1.12 and I now get the same results as in v1.13; maybe I never tried to run my Mega Menu program from FC v1.12?

I changed back to FC v1.11 and my AUTOCMD is not running (as expected) but the command XB TIPI.MM.RESETMM runs my Mega Menu program fine!

I changed back to FC v1.10 and the loading of my Mega Menu program from FC and loading back and forth works fine!

 

 

After a reset of the FG99 and use the XB autoload to run the Mega Menu program it is always working fine!

 

In FC v1.13 I see no flashing cursor at the readkey command in the AUTOCMD! At the FC v1.12 prompt there is the flashing cursor

 

 

 

 

 

 

 

[+jedimatt42]

Thanks @wolhess, love the details!

 

Do you have SAMS? I suspect that since I started using SAMS, I am not restoring it the right state before jumping into cartridges. 

 

That would explain issues with the size of the XB program showing the symptom.

 

I also think this is why the XBGEM entry points like TML no longer work directly from Force Command.

 

This gives me some things to test

[+wolhess]

17 minutes ago, jedimatt42 said:

Thanks @wolhess, love the details!

 

Do you have SAMS? I suspect that since I started using SAMS, I am not restoring it the right state before jumping into cartridges. 

 

That would explain issues with the size of the XB program showing the symptom.

 

I also think this is why the XBGEM entry points like TML no longer work directly from Force Command.

 

This gives me some things to test

Yes, I have a 1MB SAMS-card.

 

Thank you for your answer and for testing this.

[+jedimatt42]

@wolhess regarding the flashing cursor from READKEY, I took the cursor away on purpose. It never printed the key that you pressed either. So I decided it was wrong to have READKEY act like a line input command. 

 

Version 1.14 fixes the SAMS mapping before launching a cartridge. Mega Menu works for me with XB GEM 2.8 via the XB TIPI.MM.MM command.

 

(Jumping directly into XB GEM 2.8's T80XB menu entry, and friends, still doesn't work.)

[+wolhess]

2 minutes ago, jedimatt42 said:

regarding the flashing cursor from READKEY, I took the cursor away on purpose.

@jedimatt42,

 

Too bad, for me that was a sign that FC is ready to press a button. If a key is pressed before the script is processed, it is not recognized or not always recognized.
But anyway, I can live without the cursor.

[GDMike]

It's nice to have feedback though, even subtle changes like, screen color change, a nice fragrance, you know...oh.. I've been spending way too much time on my computer...

[+jedimatt42]

I'm not opposed to restoring it. I just changed the cursor character to 0 which looks like a space. I think it is still blinking, LOL.

Edited January 3, 2021 by jedimatt42

[+wolhess]

11 hours ago, jedimatt42 said:

Version 1.14 fixes the SAMS mapping before launching a cartridge. Mega Menu works for me with XB GEM 2.8 via the XB TIPI.MM.MM command.

Yes it works. I can run first FC and run Mega Menu from the script and from the Mega Menu I can run Force Command.

And I can run first Mega Menu and run Force Command from Mega Menu. I can cycle this back and forth without a problem.

Thank you for doing the changes so fast!

 

Same I can do on my non tipi system with the 80 column card. Here too I can cycle between Force Command and Mega Menu.

There is also an improvement. I don't need to reset the FG99/TI after the first power on. It works from the first run.

 

 

 

 

 

[+jedimatt42]

Update 1.15

 

Readkey shows blinking cursor again... unless you pass /n to it... which I failed to document... I'll get that next time... 

Includes ED command now, that has built in editor.

command line editing is in INSERT mode by default.  It used to be in overwrite mode by default. I had a cursor crisis. 

 

The editor uses most of the upper 24k expansion for the buffer, I've set a semi-arbitrary limit of 250 lines, leaving me something like 3K of headroom for future needs in the editor before having to invoke SAMS. 

It scrolls over to the right on a 40 column display to support the 80 character records. 

It jumps to the left to the end of line when navigating up and down... This could be improved to overshoot a little and give context... 

 

Intentionally minimal features. 

 

It will not open if no filepath is specified. I'll probably fix that later, cause you can enter the filepath when you press ^S to save. Filepath given on commandline can be an aspirational filename. (the one you want to create)

[dgrissom]

1 hour ago, jedimatt42 said:

Update 1.15

 

Readkey shows blinking cursor again... unless you pass /n to it... which I failed to document... I'll get that next time... 

Includes ED command now, that has built in editor.

command line editing is in INSERT mode by default.  It used to be in overwrite mode by default. I had a cursor crisis. 

 

The editor uses most of the upper 24k expansion for the buffer, I've set a semi-arbitrary limit of 250 lines, leaving me something like 3K of headroom for future needs in the editor before having to invoke SAMS. 

It scrolls over to the right on a 40 column display to support the 80 character records. 

It jumps to the left to the end of line when navigating up and down... This could be improved to overshoot a little and give context... 

 

Intentionally minimal features. 

 

It will not open if no filepath is specified. I'll probably fix that later, cause you can enter the filepath when you press ^S to save. Filepath given on commandline can be an aspirational filename. (the one you want to create)

Whaaat? "ED"!!!    Best day ever!   Finally, easy to write/edit scripts within FC!

 

Any other special keys?   Ctrl+S = Save/Save As.  Ctrl+Q = Quit/Exit?

 

Thanks!  jedimatt42

 

DG

[dgrissom]

22 minutes ago, dgrissom said:

Whaaat? "ED"!!!    Best day ever!   Finally, easy to write/edit scripts within FC!

 

Any other special keys?   Ctrl+S = Save/Save As.  Ctrl+Q = Quit/Exit?

 

Thanks!  jedimatt42

 

DG

Never mind,  Found that it actually uses "AID" (Fctn+7).   Darn,  didn't check the HELP ED first!?

 

DG

[fabrice montupet]

Oh... Since v1.15  my V9958 VDP isn't detected. Sysinfo returns: TMS9918A NTSC ?

 

EDIT: Really strange: I have switched off the computer, powered on, and FC regognized my VDP and set the display to 80 columns. Since I tried 3 or 4 times and it is always recognized. Don't know what happened the fist time.

 

ED is great! very very useful !  Thank you ?

 

Edited January 11, 2021 by fabrice montupet

[+jedimatt42]

6 hours ago, fabrice montupet said:

Oh... Since v1.15  my V9958 VDP isn't detected. Sysinfo returns: TMS9918A NTSC ?

 

EDIT: Really strange: I have switched off the computer, powered on, and FC regognized my VDP and set the display to 80 columns. Since I tried 3 or 4 times and it is always recognized. Don't know what happened the fist time.

 

ED is great! very very useful !  Thank you ?

 

 

Maybe my VDP detection code is subject to the state left behind by prior software... 

 

It pretty much just reads VDP status register 4 to decide it is a Yamaha VDP...  Just before that, I use the GPU technique to identify the F18A.

 

I've double checked the c->assembly production, and it is using byte operations, movb and cb properly... 

 

Keep an eye on it. Maybe with some more evidence, it can be improved.

 

[+Vorticon]

I still have an issue with the XB command yielding a Syntax Error once XB is loaded any time I try to access XB after returning to FC from another program. I have TIPI 1.7 and the FC 1.15.

[dgrissom]

18 hours ago, jedimatt42 said:

Update 1.15

 

Includes ED command now, that has built in editor.

command line editing is in INSERT mode by default.  It used to be in overwrite mode by default. I had a cursor crisis. 

 

The editor uses most of the upper 24k expansion for the buffer, I've set a semi-arbitrary limit of 250 lines, leaving me something like 3K of headroom for future needs in the editor before having to invoke SAMS. 

It scrolls over to the right on a 40 column display to support the 80 character records. 

It jumps to the left to the end of line when navigating up and down... This could be improved to overshoot a little and give context... 

 

Intentionally minimal features. 

 

It will not open if no filepath is specified. I'll probably fix that later, cause you can enter the filepath when you press ^S to save. Filepath given on commandline can be an aspirational filename. (the one you want to create)

Don't know if it "by design" or ?

"ED" is GREAT... (but)  the "FCTN+ Left Arrow" acts as a Backspace with Delete.  

I am just starting to use this command.   As designed I don't know the best way to correct a script's line in the middle without deleting most of the line.

BTW, this is still way better than running an external editor!

 

DG

[fabrice montupet]

The VDP detection problem appeared again. In fact, it's random. I have successively reseted the computer without power-off it, and  in main cases the V9958 is well detected by FC but sometimes not. And when it is not detected by FC,  however I can launch programs that uses the V9938/58 VDP with no problem. So we can put aside a VDP issue or VDP adressing problem by the computer itself.