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

[+Atari2600PAL]

If this is the wrong thread for this query, my apologies and mods please delete

 

I've copied the force command bin files to my fg99 and the FC folder to my tipi (via the tipi web interface) but have a few issues

 

If I choose the auto version it just cycles me back to the 99 start up menu

 

If I choose the force version I can do things like DIR ok though

 

But if I try fg99 ALPINER (for instance) the screen changes colour and the 99 hangs

 

Likewise if I try something like load TIPI.FC.BIN.TELNET it just hangs

 

EDIT: sorry, load telnet (or anything else in the bin folder) just causes the 99 to return to the start screen

 

(I should say my 99 currently boots to the CC9900 start up screen, in case that could be an issue)

 

Am I just being stupid please?

 

Many thanks

 

[+Atari2600PAL]

The fg99 problem was because I was using the cart name as it appears in the menu, when fg99 actually wants the filename on the SD (so BIGFOOT should have been bigfootG). Maybe time to rename the files on my SD.

 

But I do notice it takes me back to the start screen and I have to select the cart from the cc9900 menu, so am wondering if this is also why the AUTOCMD just seems to loop around

 

Maybe this will all be resolved once I change the EPROMS on the CC9900

[+jedimatt42]

I've used this with a Corcomp floppy controller, but not with the Corcomp eproms... The 'auto' cartridge menu item run the GROM powerup routine to launch into the cartridge rom. Sounds like there are some conflicts with the Corcomp powerup routine and my cartridge powerup routine. ForceCommand is fully functional without the GROM, as it only provides that powerup routine to auto-run the cartridge ROM. 

 

Be careful renaming binaries on the FinalGROM99 SD card. The filename is used to determine the emulation type for the file. Instead of renaming my files, I create list scripts in a directory on my PATH that I can run to go to the desired cartridge. Then I can name the script whatever makes more sense to me. 

 

The other thing, the binaries in TIPI.FC.BIN. are ForceCommand executables. The LOAD command is for EA5 PROGRAMS. 

 

To run a ForceCommand executable or script, Just enter the filename, or directory and filename if it isn't on your path or in the current directory.

 

 

[+Atari2600PAL]

7 hours ago, jedimatt42 said:

I've used this with a Corcomp floppy controller, but not with the Corcomp eproms... The 'auto' cartridge menu item run the GROM powerup routine to launch into the cartridge rom. Sounds like there are some conflicts with the Corcomp powerup routine and my cartridge powerup routine. ForceCommand is fully functional without the GROM, as it only provides that powerup routine to auto-run the cartridge ROM. 

 

Be careful renaming binaries on the FinalGROM99 SD card. The filename is used to determine the emulation type for the file. Instead of renaming my files, I create list scripts in a directory on my PATH that I can run to go to the desired cartridge. Then I can name the script whatever makes more sense to me. 

 

The other thing, the binaries in TIPI.FC.BIN. are ForceCommand executables. The LOAD command is for EA5 PROGRAMS. 

 

To run a ForceCommand executable or script, Just enter the filename, or directory and filename if it isn't on your path or in the current directory.

 

 

Many thanks for the info & advice. Will give it all a try thanks

 

[+Atari2600PAL]

I decided to create an AUTOCMD which just contains PATH=TIPI.FC.BIN.

 

When I load Force cmd it's running the script as it's setting my path as specified (can see it with env) and I can simply type TELNET (or whatever) and it runs ok

 

However, since making the AUTOCMD it gives me a continuous beep on startup until I issue a tipibeeps command which then stops the noise

 

Would this just be because I created the file using echo PATH=TIPI.FC.BIN. > AUTOCMD from terminal on my Macbook please? (I don't have an editor on the 99 yet)

 

Many Thanks

[+Atari2600PAL]

Managed to use the Editor/Assembler editor (using fg99, and creating floppy disk part A via force command) and that has resolved the beeping issue

 

Thanks 

[+jedimatt42]

The beep is a bug. I thought I fixed a while ago, but I guess I missed something.  Placing tipibeeps in the AUTOCMD script likely works around the issue. 

 

I'll have to reinvestgate.

 

There is an editor built into ForceCommand, try 'help ed' and from within ED, try FCTN-7 (AID) 

 

Apparently I forgot to add ED to the wiki documentation. Oops. (update: added ED to wiki: https://github.com/jedimatt42/fcmd/wiki/Commands#editor)

Edited May 18 by jedimatt42
added ed docs to ForceCommand wiki

[+Atari2600PAL]

5 minutes ago, jedimatt42 said:

The beep is a bug. I thought I fixed a while ago, but I guess I missed something.  Placing tipibeeps in the AUTOCMD script likely works around the issue. 

 

I'll have to reinvestgate.

 

There is an editor built into ForceCommand, try 'help ed' and from within ED, try FCTN-7 (AID) 

 

Apparently I forgot to add ED to the wiki documentation. Oops.

Many Thanks, that's a lot easier

[JasonACT]

Hi.  I'm developing my own Pi Pico Peripheral Expansion Box in the format of a speech synthesizer board, and have just about finished the disk DSR ROM.  In my implementation, DSK is the special root access point on my FAT32 SD card, it can look up whole disks by name via the directories on the SD card.  DSK1 (etc.) just check if a directory exists (in root) with that name.  I.E. I've tried to make this work along the lines of the original TI disk controller DSR, and for LVL2, DSK is drive 0.

 

But I don't think FCMD knows about this original TI feature for finding a disk in one of the drives?  Is it something you might consider adding?

[+jedimatt42]

14 minutes ago, JasonACT said:

Hi.  I'm developing my own Pi Pico Peripheral Expansion Box in the format of a speech synthesizer board, and have just about finished the disk DSR ROM.  In my implementation, DSK is the special root access point on my FAT32 SD card, it can look up whole disks by name via the directories on the SD card.  DSK1 (etc.) just check if a directory exists (in root) with that name.  I.E. I've tried to make this work along the lines of the original TI disk controller DSR, and for LVL2, DSK is drive 0.

 

But I don't think FCMD knows about this original TI feature for finding a disk in one of the drives?  Is it something you might consider adding?

The "DSK." device name was never used for LVL2 type IO, but ForceCommand just has a condition block to handle unusual device names and unit numbers.. 

 

I am open to extending ForceCommand to understand your device. It currently has a strong opinion about what a drive device name is. I can work up a beta for you to test. 

 

ForceCommand won't let you 'cd' to a place that cannot be opened as a Catalog File. That really  bothered me in the old 4ADos. So you wouldn't be able to CD to "DSK." on a normal TI Floppy Controller. But I believe you can CD to "DSK.VOL1." if it exists. 

 

Also, the drive that ForceCommand 'boots' from ( looks for AUTOCMD script on ) is the first device in the DSR list, so if you want that to be "DSK.", it should be first in your list. If you want that to be "DSK1." then that should be first. 

[JasonACT]

30 minutes ago, jedimatt42 said:

So you wouldn't be able to CD to "DSK." on a normal TI Floppy Controller. But I believe you can CD to "DSK.VOL1." if it exists. 

That's cool, I didn't check how CD worked.  You can certainly open "DSK." as a catalog file in my implementation too, so that's all good.

 

Thanks for the info, and FCMD, I do like it a lot.

[+jedimatt42]

20 hours ago, JasonACT said:

That's cool, I didn't check how CD worked.  You can certainly open "DSK." as a catalog file in my implementation too, so that's all good.

 

Thanks for the info, and FCMD, I do like it a lot.

Floppy disks on the TI don't generally support subdirectories... but ForceCommand supports all those harddrive type things including TIPI. The Myarc hard drive extensions gave us directories, where there is a LVL2 IO routine to set the unit #'s directory before performing unit # based operations, since all of those original TI LVL2 routines just take a 10 character file name... There are additional routines for creating, and removing a directory. Anyway... 

 

I sent you a private message with an alpha of ForceCommand that will support treating 'DSK.' as a drive. I can't really support this on TIPI, cause 'TIPI' is unit 0. It makes all kinds of things ambiguous... I might follow up with making sure ForceCommand disallows 'DSK.' if it has already seen 'TIPI.', otherwise direct-input and direct-output operations on TIPI would get very confused. 

[JasonACT]

This is awesome, thanks again Matt!

[+jedimatt42]

I've dropped an update in post #1 of this thread, that allows TIPIMAP command to support CS1 and DSK5-9 mapping... 

 

@JasonACT this does not have the beta 2.6 change I sent you to support cataloging 'DSK.' and treating it like a full drive. I think we only want to do that if your device is the lone provider of 'DSK.'  So I'm curious if there a designated way to identify your device. Such as a device name unique to it, or some other consistently discoverable attribute in the ROM? 

[JasonACT]

Hi Matt, you could enable it if the 2nd DSR byte (after >AA) for the version number is some reasonably high value that doesn't conflict with anyone else's hardware.  Something like >AA72?

 

Edit: Oh, I added an initial "TIPI" device too, because various programs check for that to add mouse support, which I've copied for the Pi Pico...  So a TIPI device with DSR ROM version >72 should be totally unique.

Edited August 20 by JasonACT
Add details of TIPI device

[JasonACT]

Hi Matt, I'm seeing something strange happening with my latest setup.  I have my device at CRU >1100 but I've assembled a modified version of Thierry's disassembled DISK DSR (a wonderful job by him done too) to implement reading/writing sector dump files...  It's installed at >1200.  This seems to work well, I can use the default of having a DSK1 directory in the SD card's root, or I can map a directory elsewhere as desired, and I can now map a .DSK file and pass-off to the next DSR (returning "error" code 0 [bad device name]) and everything except Force Command can see that DSK1.

 

I can use "CD 1200.DSK1" to get to the newly mapped virtual disk, but without adding the CRU base, all I see is "error, device/folder not found: DSK1."

 

Do you have any ideas why?

[+Atari2600PAL]

Not sure if it's by design, but I noticed today that if you try a command like

 

COPY DSK2.* DSK1.

 

then FC overwrites files of the same name on the destination without prompting to overwrite

[+jedimatt42]

7 hours ago, JasonACT said:

Hi Matt, I'm seeing something strange happening with my latest setup.  I have my device at CRU >1100 but I've assembled a modified version of Thierry's disassembled DISK DSR (a wonderful job by him done too) to implement reading/writing sector dump files...  It's installed at >1200.  This seems to work well, I can use the default of having a DSK1 directory in the SD card's root, or I can map a directory elsewhere as desired, and I can now map a .DSK file and pass-off to the next DSR (returning "error" code 0 [bad device name]) and everything except Force Command can see that DSK1.

 

I can use "CD 1200.DSK1" to get to the newly mapped virtual disk, but without adding the CRU base, all I see is "error, device/folder not found: DSK1."

 

Do you have any ideas why?

Most of the time my DSRLNK is bound so it does not search devices. For paths with an unspecified crubase, I should fix it to find the first valid device. This worked at one time, but probably broke when I fixed something else.

 

I will take a look.

[+jedimatt42]

2 hours ago, Atari2600PAL said:

Not sure if it's by design, but I noticed today that if you try a command like

 

COPY DSK2.* DSK1.

 

then FC overwrites files of the same name on the destination without prompting to overwrite

I think I added prompts for delete, but frankly I haven't used a shell that prompts for overwrite in 20 years. So, by lack of design, I would say.

[JasonACT]

On 10/11/2023 at 2:05 AM, jedimatt42 said:

I will take a look.

Thanks Matt.

 

Since I brought it up nearly a month ago, I've now merged my DSR with the custom TI DSK DSR (it uses a trampoline system to switch ROM banks if needed) so everything is now on the same CRU address.  This seemed important, so my device would work with a real TI DSK Controller, given the original ROM has pass-through issues for unmapped drives.  I only switch to the custom TI ROM if I know a sector file is mapped.  I've kept a copy of the old code though, in case any testing is needed for the issue.

 

My current hiccup is with my PI.CLOCK implementation...  It works well enough, and FCMD's DATE command tells me the time (the Pi Pico W syncs its clock with my main computer on the home WiFi) but when I add the CorComp "CLOCK" device name to my DSR, FCMD no longer correctly reads the date and time.  I get "0-0-0 12:00am" even though I am able to run TI BASIC programs and read the clock as described in the CorComp manual for either "CLOCK" or "PI.CLOCK.  I'm using the 19 byte format (I see you have a 24 byte version in the TIPI python code, but I don't think that matters).

 

Do you have any ideas what's going wrong?

 

EDIT: Looks like this one is on me, FCMD opens "PI.CLOCK" which I support, but it first tries to open "CLOCK." (ending with a period) for the CorComp device name (which is standard practice) and I wasn't expecting the difference (the end 'period' character).  I've fixed my code, sorry for the disturbance Matt.

Edited November 4 by JasonACT