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

[+jedimatt42]

1 hour ago, WhataKowinkydink said:

Well, that would explain why i thought the wiki was on the terse side: i had missed the "Index" with additional details in the upper right.  ?

 

I found the details on Extended BASIC, and hopefully that should clear everything up.   Thanks again ?

 

You are not the first one to report that the index is not obvious... I'll get creative and bring the page list to the fore-front. 

[+jedimatt42]

Update 1.32  - attached in this thread to post #1.

 

I've been working on allowing executables like VIRGIL99 to use SAMS bankswitching for code. I've adapted and improved the cartridge bank switching mechanisms I use for gcc to SAMS... 

 

It's now more natural to use. function declarations are stashed inside an inline function with the name you declared, the inline function decides to call your decorated actual function either directly if you are calling from the same bank, or through a trampoline in the cartridge. The gcc optimizer removes the code path not taken, so for same-bank calling, it is zero overhead. 

 

The exe loader in ForceCommand looks at a header word that indicates if the exe wants SAMS banking. If so it indicates the number of pages of code that will be loaded and organized as pairs of 4k banks... processes have a base page on the stack so exes can be called from others, and the page ids are still just relative within the exe.   My loader loads the indicated amount of 4k pages this way, and then maps the 1st two into A000 and B000. The remainder of the executable file is loaded into C000 - F000. If the exe is larger (the banked code + 16k of data), it will load all remaining pages into additional banks.

 

For my gcc based Makefile, I use a file naming convention where the 8k bank id is prefixed on the module names (.c files) so b0_main.c b1_utils.c, etc.. and then the linkfile understands through wildcards what to include in each overlay address space. And the makefile extracts the binary form and links it into a PROGRAM image file. ForceCommand uses direct-read lvl2 io to load these executables in pieces instead of the LOAD PAB opcode. The exe sams banks are expected to be padded so there is some wasted disk space... 

 

A small example is here: https://github.com/jedimatt42/fcmd/tree/main/example/gcc/samshello

 

A big complicated example is here: https://github.com/jedimatt42/fcmd/tree/main/example/gcc/virgil

 

Executables that have zero as the sams page count still overlay into SAMS if present, such as FCMENU launching another instance of FCMENU and being able to pop back.

 

There are no new external features. I'm releasing this as a milestone after quite a bit of restructuring. The executables from previous releases are not compatible with this release, so update all the files to keep a coherent system.

 

This is probably a release candidate for 2.0 (the version from which I will only make additive/compatible api changes)

[dgrissom]

1 hour ago, jedimatt42 said:

Update 1.32  - attached in this thread to post #1.

 

I've been working on allowing executables like VIRGIL99 to use SAMS bankswitching for code. I've adapted and improved the cartridge bank switching mechanisms I use for gcc to SAMS... 

 

I...

 

This is probably a release candidate for 2.0 (the version from which I will only make additive/compatible api changes)

Sounds like this is gonna be "much mo' better"!  ?

 

Thanks, Matt for your dedicated work on this wonderful software!

 

DG

[+Vorticon]

I upgraded to version 1.32 and now I cannot seem to access Plato set up as URI2 (http://ti99.irata.online). 

LOAD URI2.PLATO just resets FC.

Could someone please verify that this works on their end?

[+retroclouds]

Today I was able to solve a long standing stevie bug. The problem was that Stevie locked up while starting. 
This only happened if I loaded the Stevie cartridge in FG99 after I ran the FC cartridge before.

 

The problem was, that Stevie expected SAMS banks to be in the order of transparent mode
SAMS Regs: >2:>02 >3:>03 >A:>0A >B:>0B >C:>0C >D:>0D >E:>0E >F:>0F 

 

Now, if I run FC and then type "exit", the TI-99/4a returns to the title screen, but SAMS banks stay in the order:
SAMS Regs: >2:>00 >3:>01 >A:>04 >B:>02 >C:>03 >D:>00 >E:>00 >F:>00 
(Tested with FC 1.32)

 

I now changed Stevie in such way, that upon startup and exit it sets the SAMS registers in the order
SAMS Regs: >2:>02 >3:>03 >A:>0A >B:>0B >C:>0C >D:>0D >E:>0E >F:>0F 
I also set SAMS in transparent mode upon exit.

 

I can imagine, that you want to keep the SAMS banks in a particular order when you call an "external" program from FC, but perhaps on FC exit, banks can be reset to the standard order? Could imagine it might solve some hard to find bugs in older software.

[+jedimatt42]

1 hour ago, retroclouds said:

Today I was able to solve a long standing stevie bug. The problem was that Stevie locked up while starting. 
This only happened if I loaded the Stevie cartridge in FG99 after I ran the FC cartridge before.

 

The problem was, that Stevie expected SAMS banks to be in the order of transparent mode
SAMS Regs: >2:>02 >3:>03 >A:>0A >B:>0B >C:>0C >D:>0D >E:>0E >F:>0F 

 

Now, if I run FC and then type "exit", the TI-99/4a returns to the title screen, but SAMS banks stay in the order:
SAMS Regs: >2:>00 >3:>01 >A:>04 >B:>02 >C:>03 >D:>00 >E:>00 >F:>00 
(Tested with FC 1.32)

 

I now changed Stevie in such way, that upon startup and exit it sets the SAMS registers in the order
SAMS Regs: >2:>02 >3:>03 >A:>0A >B:>0B >C:>0C >D:>0D >E:>0E >F:>0F 
I also set SAMS in transparent mode upon exit.

 

I can imagine, that you want to keep the SAMS banks in a particular order when you call an "external" program from FC, but perhaps on FC exit, banks can be reset to the standard order? Could imagine it might solve some hard to find bugs in older software.

 

My LOAD command does set them up in the legacy order. But 'EXIT' doesn't restore them there. I thought the FG99 command to jump into another cartridge performs the same setup as LOAD, but I'll have to check. 

 

Thanks for pointing this out. 

[+jedimatt42]

7 hours ago, Vorticon said:

I upgraded to version 1.32 and now I cannot seem to access Plato set up as URI2 (http://ti99.irata.online). 

LOAD URI2.PLATO just resets FC.

Could someone please verify that this works on their end?

This appears to be working fine for me. 

[+Vorticon]

5 hours ago, jedimatt42 said:

This appears to be working fine for me. 

Ok thanks. I'll keep digging.

[+jedimatt42]

16 hours ago, Vorticon said:

Ok thanks. I'll keep digging.

 

Since it is such a small URL, from FCMENU, I use the URL directly:

 

LOAD PI.HTTP://TI99.IRATA.ONLINE/PLATO

 

From the command line, I've tested:

 

LOAD PI.http://ti99.irata.online/PLATO

 

TIPIMAP URI2. HTTP://ti99.irata.online/

 

LOAD URI2.PLATO

 

Force Command's TIPIMAP for URI aliases, requires the URL scheme ( HTTP or HTTPS ) to be in allcaps...   

 

The hosting webserver requires the path portion to match case... so the "PLATO" part after the hostname... or in the URI2.PLATO must be allcaps. 

 

There might be some noise in the TIPI log file.. The magic for this is in the TIPI. You might get a better TI side error code out of EDITOR ASSEMBLER. When going into legacy mode, Force Command resets the 4a if there is any problem with the file access.

[+Vorticon]

16 hours ago, jedimatt42 said:

 

Since it is such a small URL, from FCMENU, I use the URL directly:

 

LOAD PI.HTTP://TI99.IRATA.ONLINE/PLATO

 

From the command line, I've tested:

 

LOAD PI.http://ti99.irata.online/PLATO

 

TIPIMAP URI2. HTTP://ti99.irata.online/

 

LOAD URI2.PLATO

 

Force Command's TIPIMAP for URI aliases, requires the URL scheme ( HTTP or HTTPS ) to be in allcaps...   

 

The hosting webserver requires the path portion to match case... so the "PLATO" part after the hostname... or in the URI2.PLATO must be allcaps. 

 

There might be some noise in the TIPI log file.. The magic for this is in the TIPI. You might get a better TI side error code out of EDITOR ASSEMBLER. When going into legacy mode, Force Command resets the 4a if there is any problem with the file access.

Turns out the PI needed a reboot. I almost never have to do that, but we did have a brief power outage a few days ago so that might have messed up something.

All good now

[+jedimatt42]

Ok.  Release what I'm calling 2.0 

 

Fixes the issue @retroclouds pointed out. FG99 seems to work with an old version of STEVIE now, which I know didn't work before. 

 

Lot of stuff around the public API documented, and SDK bundled. Check out the Wiki to learn more. 

 

Home · jedimatt42/fcmd Wiki (github.com)

[+arcadeshopper]

Ok.  Release what I'm calling 2.0 
 
Fixes the issue [mention=16219]retroclouds[/mention] pointed out. FG99 seems to work with an old version of STEVIE now, which I know didn't work before. 
 
Lot of stuff around the public API documented, and SDK bundled. Check out the Wiki to learn more. 
 
Home · jedimatt42/fcmd Wiki (github.com)

Totally awesome

Sent from my Pixel 6 Pro using Tapatalk

[+retroclouds]

Thanks for the update. Browsed through the API. That’s some impressive stuff you have going on there.

[+jedimatt42]

I think I've updated all my known broken links now, between the wiki, atariage, source readmes, etc... so if anyone detects another, feel free to call it out.

 

Thanks.

 

[+jedimatt42]

FYI:

 

When stacking applications like FCMENU that then spawns something like VIRGIL99, ForceCommand currently relies on reading the SAMS mapper registers and storing them on the gcc stack so they can be restored when the child process exits.

 

I have learned from another thread that this is insufficient.

 

Since 'nobody' (in pragmatic terms) has access to anything more than a 1meg SAMS card, this is OK for now... Hopefully I'll fix this before that situation changes. 

[+jedimatt42]

Do people have character set files, such as CHARA1, or fbForth format files that they wish Force Command was using instead of the default-ish hybrid taken from my own ANSI graphics, libti99's lowercase set, and the console? 

 

If so, can you send some of them to me?

[+arcadeshopper]

Do people have character set files, such as CHARA1, or fbForth format files that they wish Force Command was using instead of the default-ish hybrid taken from my own ANSI graphics, libti99's lowercase set, and the console? 
 
If so, can you send some of them to me?

There's a ton in xB gem in disk files for load

Sent from my Pixel 6 Pro using Tapatalk

[+jedimatt42]

Well my emphasis was meant to be on 'if' you guys having a 'wish' for such a feature, due to some subjective opinion you all might like to share with me.

[pixelpedant]

Since I happen to have them handy, here are the 60 fonts that come with XB GEM for consideration: 

 

 

Only a few are good 40 column fonts (which can probably be intuited by their width). 

 

Some are only really good with custom spacing in bitmap mode.  As a result, note that this display is using 9px spacing (in TML).

 

[+jedimatt42]

Handily, these are 768 byte files with no header, starting with the definition for ' ' space containing 96 pattern definitions. 

 

They can be used with DSR op LOAD, straight into the pattern definition table in a well behaved way, with a 32*8 address offset. 

 

I've written an executable that will be bundled in next drop of FC, that can load offset 0 files (fbForth style) as the default, or these as /w (for Wilhelm) format. They have to be 40 column 6x8 friendly to be usable.

[+jedimatt42]

Update v2.1 - post #1 for attachment

 

added, in a non-breaking way, PROGRAM image file load and save routines to the API, fc_prg_save, fc_prg_load.

Also fixed executable loading to use it's own shadow of SAMS registers instead of reading from the 74'612 directly, as this isn't supported on SAMS boards greater than 1 meg. 

fixed a small issue with the clock-bar. 

 

This includes a FONT executable in the FC.BIN. directory for loading and saving fonts.. it can load partial or full 0-127 or 0-255 headerless PROGRAM images into the pattern definition table, or with the /w option, load the 32-127 headerless PROGRAM image fonts that are bundled with XB256. Force command only uses the 6x8 40/80 column pattern modes, so many things floating around are not very applicable. 

 

If you load the partial fonts, they leave the previous full font patterns in place. 

 

Ok, for grins... yesterday @Beery shared with me the MDOS source definitions of the font, so now I also have a couple full 0-255 definition sets. 

 

Force Command also now understands a FONT environment variable you can set, and from there, whenever the screen is reset (width 80, or width 40 commands) the font will be loaded from the file specified by it's value, if that fails to load, then the font in my ROM will be loaded. These must be 0-127 or 0-255 format files. 

 

Here is another executable that with show a grid of all the characters: CHARSET

 

But, here are a couple screen caps of the difference between my ANSI font, and the MDOS ANSI font:

 

Force Command builtin:

 

 

 

From MDOS:

 

[pixelpedant]

For further reference, here are three fairly conventional XB GEM fonts which are suited to 40 column mode (all characters 5px wide or less, left-aligned).

 

Viewed here in 40 column mode:

 

[dgrissom]

22 hours ago, jedimatt42 said:

Update v2.1 - post #1 for attachment

...

This includes a FONT executable in the FC.BIN. directory for loading and saving fonts.. it can load partial or full 0-127 or 0-255 headerless PROGRAM images into the pattern definition table, or with the /w option, load the 32-127 headerless PROGRAM image fonts that are bundled with XB256. Force command only uses the 6x8 40/80 column pattern modes, so many things floating around are not very applicable. 

 

If you load the partial fonts, they leave the previous full font patterns in place. 

...

I know that there is no such things as stupid questions just stupid people!   (That don't look right ?) 

I think I am one of them!

 

I can load the @BEERY supplied fonts.  They look fine on screen and with the CHARSET program.   I don't understand the concept of "partial or full 0-127 or 0-255 headerless PROGRAM images".  Is there a "TI Fonts for Dummies book available?

 

DGrissom

 

 

[+jedimatt42]

4 hours ago, dgrissom said:

I know that there is no such things as stupid questions just stupid people!   (That don't look right ?) 

I think I am one of them!

 

I can load the @BEERY supplied fonts.  They look fine on screen and with the CHARSET program.   I don't understand the concept of "partial or full 0-127 or 0-255 headerless PROGRAM images".  Is there a "TI Fonts for Dummies book available?

 

DGrissom

 

 

 

sorry, I think I'm making up terminology based on searching Atariage. I don't think these are official terms... I can classify them better by source:   

 

(all of these are stored on a TI as PROGRAM image type files)

 

CHARA1, such as for TI-Writer - A header-ful font that defines characters 0-127, is 1K is size... however the first 6 bytes are an EA5 header even though that isn't very useful.

XB256 fonts - They define characters 32-127, there are no header bytes at the beginning. 

fbForth fonts - They define characters 0-127, with no header at the beginning. Lee introduced this, I believe, because it just makes more sense from a programming point of view when compared to the CHARA1 format which just seem like a mistake from TI, that they lived with.

ForceCommand fonts - no header. Define characters 0-255 (or less if the file is shorter) 

 

The XB256 fonts are really meant for the bitmap graphics mode. But as pixelpedant points out, a handful of them work well enough in 40 and 80 column text modes. 

There are other TI font types for desktop publishing and art applications... I know nothing about them. 

 

Hope that helps.

[dgrissom]

3 hours ago, jedimatt42 said:

 

sorry, I think I'm making up terminology based on searching Atariage. I don't think these are official terms... I can classify them better by source:   

 

(all of these are stored on a TI as PROGRAM image type files)

 

CHARA1, such as for TI-Writer - A header-ful font that defines characters 0-127, is 1K is size... however the first 6 bytes are an EA5 header even though that isn't very useful.

XB256 fonts - They define characters 32-127, there are no header bytes at the beginning. 

fbForth fonts - They define characters 0-127, with no header at the beginning. Lee introduced this, I believe, because it just makes more sense from a programming point of view when compared to the CHARA1 format which just seem like a mistake from TI, that they lived with.

ForceCommand fonts - no header. Define characters 0-255 (or less if the file is shorter) 

 

The XB256 fonts are really meant for the bitmap graphics mode. But as pixelpedant points out, a handful of them work well enough in 40 and 80 column text modes. 

There are other TI font types for desktop publishing and art applications... I know nothing about them. 

 

Hope that helps.

Thanks  Jedimatt!

 

It wasn't the terminology; it was my complete lack of knowledge regarding TI fonts.  I'm too used to Windows Stuff.

Your explanation helped quite a bit.  I was able to use the font program to load the CHARA1 font. (CHARSET shows the differences.) 

 

I'll try to find and play with the Wilhelm fonts. 

 

David G