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

[snume]

15 hours ago, jedimatt42 said:

The initial device not found error is not impactful. I should hide that message.. 

 

FCMENU <menu-file>

 

What output do you get when you try to run it? What does your menu data file look like? 

 

If you run ENV, what does your PATH look like? Does it include the directory that has FCMENU in it?  Are you using a full path name to the menu file? Or is it in the current directory?

 

I wasn't even able to get it started. I think I just jumped in with both feet before fully understanding HOW it worked.

 

14 hours ago, jedimatt42 said:

I use an AUTOCMD file in TIPI. 

 

https://github.com/jedimatt42/fcmd/wiki/Scripting#autocmd---running-a-script-on-startup

 

With something like this in it to set the PATH:

 

PATH=TIPI.FC.BIN.;TIPI.BIN.

 

https://github.com/jedimatt42/fcmd/wiki/Variables#path

 

If I remember correctly, without a PATH set, executables are only looked for in the current directory.

Thank you so much Matt for the gentle nudge. Knowing the device error is not something to worry about and using this info has got me rolling. Still kinda bummed I couldn't figure it out on my own.

 

I've still got a lot to learn and look forward to it but at least I can save myself from spinning my wheels.

 

Great work on all of this (TiPi, Force Command, FCMENU, etc) by the way.

[mvancopp]

Hi @jedimatt42,

I have been putting my older TI systems back online and part of that was the Myarc 512k card for use with MyBasic. This system also contains a TIPI and when I try to copy TO or FROM the 512 card, Force Cmd fails to make the file copy. When copying to the 512 card no file(s) are created but success is reported. When transferring files from the 512 card to the either a TI drive or the TIPI a 1 sector file is created (the file contents are not copied, just the FAT entry).

I realize there are a limited numbers of Myarc 512k cards in the wild so I don't expect this to be any kind of priority but I thought I'd report the issue.

 

Thanks for the all the hard work!

 

Mark

 

[+jedimatt42]

41 minutes ago, mvancopp said:

Hi @jedimatt42,

I have been putting my older TI systems back online and part of that was the Myarc 512k card for use with MyBasic. This system also contains a TIPI and when I try to copy TO or FROM the 512 card, Force Cmd fails to make the file copy. When copying to the 512 card no file(s) are created but success is reported. When transferring files from the 512 card to the either a TI drive or the TIPI a 1 sector file is created (the file contents are not copied, just the FAT entry).

I realize there are a limited numbers of Myarc 512k cards in the wild so I don't expect this to be any kind of priority but I thought I'd report the issue.

 

Thanks for the all the hard work!

 

Mark

 

I think MAME emulates the Myarc ram disk... I'll take a look when I get a chance... I enjoy the opportunity to increase compatibility.

[+jedimatt42]

9 minutes ago, jedimatt42 said:

I think MAME emulates the Myarc ram disk... I'll take a look when I get a chance... I enjoy the opportunity to increase compatibility.

Actually, I have a Foundation card with the Myarc ROM, so I should be able to test/fix for that two... I never thought to try the Ram disk function.   RD. 

 

I cannot find docs on file management routines for it... That is the LVL2 single character BASIC subroutines in the DSR, that I imagine it uses... If anyone has such docs, that'd be helpful.

[+9640News]

8 hours ago, jedimatt42 said:

Actually, I have a Foundation card with the Myarc ROM, so I should be able to test/fix for that two... I never thought to try the Ram disk function.   RD. 

 

I cannot find docs on file management routines for it... That is the LVL2 single character BASIC subroutines in the DSR, that I imagine it uses... If anyone has such docs, that'd be helpful.

Likely, this is the only information on the Myarc 512K card.

 

Myarc Memory Expansion Card.pdf (whtech.com)

 

Actually, come to think of it, I think I uploaded to Atariage a couple of years ago, the source code for the Myarc Eprom.  I will do some searching to see if I can find it.

[+9640News]

Found the source code for the eprom.  It is at 

 

Index of /source (whtech.com)

 

[+jedimatt42]

I set the myarcmem up in mame for a hoot, and to try and explore this... the manual suggests that it was compatible with TI DMII, so a DSKn device at crubase 1000 instead of 1100, with the same lvl2 IO routines... "RD." device name is unknown to Force Command, but if there is no CRUBASE conflict, then I would expect copying files to work between TIPI and the MEXP-1... 

 

I however, cannot get the CALL PART(400,80) command to work per the manual in mame... maybe cause my VDP stack is offset as a result of having not configured a floppy controller. I get an 'INCORRECT STATEMENT' error (and not a BAD NAME) so it is getting into the PART code. Nope, adding a tifdc to the config didn't help.

 

IDK...

 

@mvancopp, I assume you are using the CALL EMDK(x) routine to set the myarc ramdisk to be one of the floppy drives, such as DSK1. Typically TIPI peb cards have the crubase set to >1000, and the Myarc ramdisk also has it fixed at >1000... What crubase is your TIPI running at? if there is no jumper closed on it, or it is set to >1100 ( conflicting with your floppy controller ) move the crubase jumper on the TIPI to the '8' jumper so crubase becomes >1800 

 

https://github.com/jedimatt42/tipi/wiki/crubase

[mvancopp]

13 hours ago, jedimatt42 said:

I set the myarcmem up in mame for a hoot, and to try and explore this... the manual suggests that it was compatible with TI DMII, so a DSKn device at crubase 1000 instead of 1100, with the same lvl2 IO routines... "RD." device name is unknown to Force Command, but if there is no CRUBASE conflict, then I would expect copying files to work between TIPI and the MEXP-1... 

 

I however, cannot get the CALL PART(400,80) command to work per the manual in mame... maybe cause my VDP stack is offset as a result of having not configured a floppy controller. I get an 'INCORRECT STATEMENT' error (and not a BAD NAME) so it is getting into the PART code. Nope, adding a tifdc to the config didn't help.

 

IDK...

 

@mvancopp, I assume you are using the CALL EMDK(x) routine to set the myarc ramdisk to be one of the floppy drives, such as DSK1. Typically TIPI peb cards have the crubase set to >1000, and the Myarc ramdisk also has it fixed at >1000... What crubase is your TIPI running at? if there is no jumper closed on it, or it is set to >1100 ( conflicting with your floppy controller ) move the crubase jumper on the TIPI to the '8' jumper so crubase becomes >1800 

 

https://github.com/jedimatt42/tipi/wiki/crubase

The Call Part depends on which EPROM you are running. The CALL PART (400,80) works for the original EPROM but for M21B, the one for MyBasic, requires CALL PART(128,384,0) or CALL PART(32,400,80) (or some variation). I use the XBII EPROM with CALL PART(128, 384, 0). CALL EMDK(5).

My setup: Myarc 512k at >1000, TI Disk Controller at >1100, TIPI at >1800, TI RS232 at >1300 (from my memory). 

Yes I use CALL EMDK(5) for accessing the RAMDISK in the 512k card.

 

Thanks for looking into this. Let me know if you need any more information.

 

Mark

 

Edited June 13, 2022 by mvancopp

[+jedimatt42]

I've made some progress on the Myarc MEXP-1... I've disassembled the ROM and found that the LVL2 IO routines like rename, protect, direct-input, direct-output expect a PAB in VDP ram. Well, a name really, the PAB part doesn't matter. 

 

This might sound odd... but I have found that none of the other systems I've used actually expect a PAB in VDP for LVL2 routines... so I haven't been using one... You have to stuff your parameters for the LVL2 routines in scratchpad, and their contracts are pretty complete. This was sufficient for TIFDC, Myarc HFDC, Corcomp Floppy, HRD, SCSI, IDE, TIPI...  The PAB is typically used to find the routines in a DSRLNK, but I don't 'scan' when calling LVL2 sub-programs because I did that once at startup. 

 

The myarcmem DSR ROM appears to use the same subprogram address for several of the LVL2 routines, and then use the name from the PAB name length pointer to decide which routine was called...

 

There is no contract for the rest of the PAB with respect to LVL2 subprogram calling, so I should be able to fake it, and stuff the name in the right spot, etc, without too much change to my code. 

 

 

[+jedimatt42]

That worked. For PROTECT, RENAME, and DIRECT-INPUT... have to setup more devices in emulation to test the other stuffs... 

[+jedimatt42]

Update 2.23 

 

update LVL2 subprogram calling to set PAB requirement for Myarc EXP-1 Ramdisk.

improve initialization so the 'device not found' message that is seen on startup since I added the font support should stop showing up.

 

See thread attachments, or Post #1 

 

 

 

@mvancopp - This was an educational adventure... tracing through the DSR for the MEXP-1 helps me appreciate it more. It was interesting to see that for the DSR to work, one of the 32k sized pages holds meta-data in lower-exp ram... such as if partitioning has happened, and the size, etc... the DSKx DSRs all enter, set a register to the unit number, then jump to a common entry point. It then checks that the value set with CALL EMDK matches the unit number used.

 

Copying to and from ramdisk seems to work now... checksum works, protect, rename, etc... the high level stuff like DIR already worked... OH.. I should have made ForceCommand aware of the RD. device name...  "RD." will work in some contexts, but not all...  Not a problem if you are used to using it after CALL EMDK has set a drive number...  Getting RD. to work fully will take more trolling through the disassembly... It is unclear what the valid drive 'unit' number would be for this device name. It is possible file management was not supported unless EMDK drive alias is used.

 

--- 

 

I think in a future update, I'll add the "RD." device name, and a command to wrap calling PART/EMDK/VOL so those things can be scripted. If that were in place, you could hop into ForceCommand on first powerup, and run a TIPI.RAMDISK script or something that partitions, and loads an AUTOCMD and other goodies for fast startup.

[mvancopp]

21 hours ago, jedimatt42 said:

Update 2.23 

 

update LVL2 subprogram calling to set PAB requirement for Myarc EXP-1 Ramdisk.

improve initialization so the 'device not found' message that is seen on startup since I added the font support should stop showing up.

 

See thread attachments, or Post #1 

 

 

 

@mvancopp - This was an educational adventure... tracing through the DSR for the MEXP-1 helps me appreciate it more. It was interesting to see that for the DSR to work, one of the 32k sized pages holds meta-data in lower-exp ram... such as if partitioning has happened, and the size, etc... the DSKx DSRs all enter, set a register to the unit number, then jump to a common entry point. It then checks that the value set with CALL EMDK matches the unit number used.

 

Copying to and from ramdisk seems to work now... checksum works, protect, rename, etc... the high level stuff like DIR already worked... OH.. I should have made ForceCommand aware of the RD. device name...  "RD." will work in some contexts, but not all...  Not a problem if you are used to using it after CALL EMDK has set a drive number...  Getting RD. to work fully will take more trolling through the disassembly... It is unclear what the valid drive 'unit' number would be for this device name. It is possible file management was not supported unless EMDK drive alias is used.

 

--- 

 

I think in a future update, I'll add the "RD." device name, and a command to wrap calling PART/EMDK/VOL so those things can be scripted. If that were in place, you could hop into ForceCommand on first powerup, and run a TIPI.RAMDISK script or something that partitions, and loads an AUTOCMD and other goodies for fast startup.

Thanks @jedimatt42 2.23 allows me to copy to and from the 512 card (tested as DSK5).

 

I think I found an unrelated bug. 

1. Start FC. For me this defaults to 1000.DSK1

2. CD 1100.DSK  - Successful

3. DIR - Successful

4. Use up arrow to bring back previous cmd, DIR. This brings back a combination of DIR and the CD from #2. It appears the previous cmd buffer holds the longest cmd inserted, but some characters in the longer cmd are corrupted (not always what was entered).

 

I did not test if the above issue was in 2.2b.

 

Thanks again for updating FC for the Myarc 128/512!!

 

Mark

 

[+jedimatt42]

The command history without SAMS is very different code, and I haven't tried it in a while.. so I probably broke it.  Thanks for reporting that!

 

(reproduces easily)

[+jedimatt42]

Update 2.4 - June 25th, 2022.

 

I fixed the 32K mode command recall ( to be clear, this is a single previous command in a VDP buffer, where SAMS mode provides an aging out 4k list )

Added Myarc EXP-1 support commands ( requires 128KOS version of ROM ) 

- RDPART <ram> <disk> <spool>  - partition the card for either 32 or 128 kilobytes of memory expansion, and some portion of ramdisk, plus spool size ( total must equal 128 or 512 )

- RDEMDK <drive>  - set the emulation drive number for the ramdisk... 0 turns off emulation, 1 - 5 for DSK1-DSK5.

- RDVOL <name> - set the volume name of the ramdisk

 

These are all non-destructive, except RDPART if the parameters are different from the previous call.. so they should be safe to unconditionally include in an AUTOCMD script.

 

Of course, ForceCommand only runs the AUTOCMD script from the first device listed by DRIVES ( DSR declaration order ), so for initial power on, it'll never find one, but subsequent reboots of the console with the PEB still powered can find an AUTOCMD in the ramdisk... 

 

To partition in support of 128KOS with 352k ramdisk and 32k of print spool:

[1000.DSK1.]
$ RDPART 128 352 32

To assign to DSK1:

[1000.DSK1.]
$ RDEMDK 1

To give it a volume name:

[1000.DSK1.]
$ RDVOL ZIPPY

 

"RD." device shows up in drives now, but LVL2 IO routines do not operate against RD, and must be used with a disk number emulation enabled. There is no logic in the DSR to translate "RD." to a unit number that I could find. You can cd to "RD." and TYPE or ED record based files, or LOAD EA5 files, but direct-input operations like COPY, CHECKSUM, or ForceCommand executables need LVL2 IO... 

[+jedimatt42]

I've now tested these (RDPART/RDEMDK/RDVOL) commands with the Foundation 128k board using the adapted Myarc DSR ROM, and they work as expected.

[+jedimatt42]

Update 2.5 - ( download in attachements, or link in first post )

 

Extend cartridge ROM API to include sector read and write routines.

 

Add external executable command to create sector dump files as DIS/FIX 128 - DISKIMAGE docs

 - DISKIMAGE executable ( in the loose FIADs of the zip, and on the included FCMD.DSK )

- There are notes in the wiki regarding how to name the target filepath so it is created without FIAD header on a TIPI, and how to avoid or intentionally name the file so it expands into a TIPI directory. 

- can read a disk, and produce a sector dump, or read a sector dump and write to a disk.

 

 

[+jedimatt42]

Oops, I broke the disk read when I was working on the disk write... New/fixed executable attached in post #1 next to the 2.5 update archive.