Jump to content
IGNORED

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


jedimatt42
 Share

Recommended Posts

2 hours ago, arcadeshopper said:

Ok well I tried it and I found that I had to have the latest ROS.   838 and 840 didn't work right 842c did fine

 

Greg

Ok, it must be something with my particular setup.  I am using ROS 842c and I have set POWERUP to "N" on HRZN. Will stick to ver 0M.

Link to comment
Share on other sites

3 hours ago, arcadeshopper said:

Ok well I tried it and I found that I had to have the latest ROS.   838 and 840 didn't work right 842c did fine

 

Greg

It's good that 842c works but I do find it strange the earlier versions failed as the visible high level operations have not really changed since 8.32.  ROS initializes cartridges to bank 0 (via MOVE @>6000,@>6000) but that has been present since 8.32.  Only thing I noticed in the non-working picture is that two CALLs were included in the device list. Doubt that is a problem but it caught my attention.  and sometimes ROS just needs to be reloaded. ;)

 

Link to comment
Share on other sites

3 hours ago, InsaneMultitasker said:

It's good that 842c works but I do find it strange the earlier versions failed as the visible high level operations have not really changed since 8.32.  ROS initializes cartridges to bank 0 (via MOVE @>6000,@>6000) but that has been present since 8.32.  Only thing I noticed in the non-working picture is that two CALLs were included in the device list. Doubt that is a problem but it caught my attention.  and sometimes ROS just needs to be reloaded. ;)

 

 

The bank normalization on startup shouldn't impact Force Command, it has starting point replicated in all banks, that does that also.

 

Those ROS names setup in the CFG1 program are in the device names in the Device Service Routine entry list... my DRIVES command only lists things in the DSR lists, not the subroutine/CALLs lists. It also only lists 4 letter things ending in numbers along with special cases for TIPI, and PI - I have a separate LVL2 command that list the BASIC subprogram names, but only the ones with single character names. But I have to admit, maybe CALLs doesn't mean TI BASIC CALL... cause I've never bothered to learn ROS. I assumed they are some sort of shortcut device names like Gazoo had in XB2.7 Suite to trigger different cartridges with DSRLNK names, but that doesn't seem to be the case. - I'll have to go read. ( manual found and read... My assumptions are correct, just didn't realize I have to put stuff on the first ramdisk for them to do anything ) 

Link to comment
Share on other sites

ArcadeShopper also noted the SAMS memory conflict with ROS CFG1 and the Force Command LOAD command. 

 

I configure SAMS if detected, so that the first 8 pages are mapped into the 32k memory expansion without page number gaps.. This is different from transparent mode. So, I needed to restore transparent mode before loading an EA5 type program that has no expectation of other programs having gone before it... Otherwise when it turns sams mapping on, the loaded program gets swapped out/re-arranged and crashes. 

 

so, this is fixed in version 1.3 - as usual, see post #1.

  • Like 5
Link to comment
Share on other sites

10 hours ago, jedimatt42 said:

hose ROS names setup in the CFG1 program are in the device names in the Device Service Routine entry list... my DRIVES command only lists things in the DSR lists, not the subroutine/CALLs lists. It also only lists 4 letter things ending in numbers along with special cases for

Cool.  That makes sense except for the entry "DM2K" which I presume is a shortcut/call (it's not a device) though it doesn't end in a number and is not one of the special cases referenced above.  Not sure what the "failing" command is doing (opening the device name to test validity?) or why the CALL would matter, or even if the two are related. For me its been a week of chasing rabbit holes at work so I'm not keen on suggesting new potential RHs for hobby stuff. 

Link to comment
Share on other sites

39 minutes ago, InsaneMultitasker said:

Cool.  That makes sense except for the entry "DM2K" which I presume is a shortcut/call (it's not a device) though it doesn't end in a number and is not one of the special cases referenced above.  Not sure what the "failing" command is doing (opening the device name to test validity?) or why the CALL would matter, or even if the two are related. For me its been a week of chasing rabbit holes at work so I'm not keen on suggesting new potential RHs for hobby stuff. 

Maybe I didn't special case 'TIPI' and just allowed any 4 letter names... when Arcadeshopper shares a screenshot with the SNUG voice card, it lists a pile of other stuff... maybe I should just let the future happen when/if it happens and add a known device name list.

  • Like 1
Link to comment
Share on other sites

On 11/12/2020 at 9:34 PM, klrw111-78 said:

Ok, it must be something with my particular setup.  I am using ROS 842c and I have set POWERUP to "N" on HRZN. Will stick to ver 0M.

 I decided to do some experimentation and wanted to report my observations in case anyone might be interested.  My system has the following in the PEB:  SAMS, TI FDC 80-TRKmod, TI RS232 with HDX, HRD4000B with 8MB, TIPI, and IDE.  I had installed FC 0.9 on the FG99 a while back and have been using for a while.  The IDE was set with CRU 1000, HRD400B with CRU 1200, TIPI with CRU 1400.  The DSK and DSK1 emulation was off on IDE and HRD4000B.  I upgraded FC to 1.1 and 1.2 failed to recognize the HRD4000B, but other software worked fine.  I went back to FC 0M worked fine all cards and all disks worked with it.

I decided to swap the CRUs on the IDE and HRD4000B and tried FC 1.3.  FC 1.3 recognized and worked with the HRD4000B and the IDE but stopped recognizing TIPI and HDX.  It would not take "cd" or "dir" commands to 1400.DSK4, TIPI or 1300.HDX1 or HDX1.  Changed CRU on TIPI to 1200 and IDE to 1400.  After the change FC recognized HRD and TIPI but not HDX1 or IDE.  Changed IDE back to 1200 TIPI to 1800 and tried again.  FC recognized HRD and IDE but not HDX1 or TIPI.  Pulled the TIPI card and restarted.  FC now recognized all remaining cards and devices.

The only DSK mapped on TIPI was DSK4 to "."

Link to comment
Share on other sites

3 hours ago, klrw111-78 said:

 I decided to do some experimentation and wanted to report my observations in case anyone might be interested.  My system has the following in the PEB:  SAMS, TI FDC 80-TRKmod, TI RS232 with HDX, HRD4000B with 8MB, TIPI, and IDE.  I had installed FC 0.9 on the FG99 a while back and have been using for a while.  The IDE was set with CRU 1000, HRD400B with CRU 1200, TIPI with CRU 1400.  The DSK and DSK1 emulation was off on IDE and HRD4000B.  I upgraded FC to 1.1 and 1.2 failed to recognize the HRD4000B, but other software worked fine.  I went back to FC 0M worked fine all cards and all disks worked with it.

I decided to swap the CRUs on the IDE and HRD4000B and tried FC 1.3.  FC 1.3 recognized and worked with the HRD4000B and the IDE but stopped recognizing TIPI and HDX.  It would not take "cd" or "dir" commands to 1400.DSK4, TIPI or 1300.HDX1 or HDX1.  Changed CRU on TIPI to 1200 and IDE to 1400.  After the change FC recognized HRD and TIPI but not HDX1 or IDE.  Changed IDE back to 1200 TIPI to 1800 and tried again.  FC recognized HRD and IDE but not HDX1 or TIPI.  Pulled the TIPI card and restarted.  FC now recognized all remaining cards and devices.

The only DSK mapped on TIPI was DSK4 to "."

I bet I know what I did... I think I decreased the number of drives I have crubase indexes for. I can fix that.

  • Like 2
Link to comment
Share on other sites

Updated - 1.4 should fix @klrw111-78 issue. 

 

I dug out some computer science data structures courses I never took, and implemented a global system dictionary, and a heap. This is all internal, but the benefit, is removing artificial caps on device names, and environment variables. I should apply it to the LABELs in scripts too.

 

< 1.0, I allowed something like 40 pre-allocated slots in .bss for device entries that I pre-fetch. An un-TI like thing I do to make generic storage easier for me. 

in 1.0, I asked myself, who in their right mind would have more than 20 drives? that seemed like a lot of ramdisk space, and plenty of hard drive and TIPI mappings, etc... But it turns out someone actually has it all. 

I also had pre-allocated ~90 bytes per environment variable slot, with slots allocated for 20 variables. All of this is linked into the system in the block storage section.   

 

So, in 1.4, I've added heap, so I can dynamically track allocation after .data and .bss (all the statically allocated junk) fill the bottom of lower memory expansion. Then I initialize all the things that need to be on heap. Right now that is the device index. Then I treat the top of that as the global system dictionary. The c stack is at the top of lower expansion memory and grows down. This dictionary is growing up from approximately 2k from the bottom (depends on the number of devices). The dictionary entries have a type byte, so I can move the script LABEL system into it as well without name collision. The dictionary compacts if you replace or remove an item. 

 

Quite satisfying. 

  • Like 3
Link to comment
Share on other sites

2 hours ago, jedimatt42 said:

Updated - 1.4 should fix @klrw111-78 issue. 

Thanks much.  I don't really plan to use all the storage.  I'm a retired EE so I enjoy building some of the newer versions of cards that I could only dream about when I had a TI back in the 80's.  Although one I card that I did buy at the time (CorComp DSDD disk controller) won't be coming around again.  

Link to comment
Share on other sites

1 hour ago, klrw111-78 said:

Thanks much.  I don't really plan to use all the storage.  I'm a retired EE so I enjoy building some of the newer versions of cards that I could only dream about when I had a TI back in the 80's.  Although one I card that I did buy at the time (CorComp DSDD disk controller) won't be coming around again.  

I've seen a few CC9900 FDC's pop up on ebay over this past year.  collecting for the TI is all about patience.  I waited about 7 years to snag my SCSI controller and when it became available I jumped on it.

 

 

Link to comment
Share on other sites

Updated - 1.5 - See post #1

 

For SAMS users, there is a history command, and !<number> to recall into the command line edit buffer. UP and DOWN arrows work to navigate also.. This is an in-memory history, using a single 4K sams page. Items will fall off the far end of the list to make room for new items at the front. items use 2 bytes + length of the command

 

For not SAMS, the history command works. !1 should work. but you only have a single item history list in VDP (that REDO buffer from a few releases back)

 

For everyone, added CTRL-c, FCTN-4 support to break out of all the commands that loop through stuff and print stuff. Already had support in 'TYPE' for this. It is generalized and applied to everything from listing environment variables to deleting files with a wildcard pattern.

 

 

  • Like 5
Link to comment
Share on other sites

5 hours ago, Omega-TI said:

It actually seems like a "real computer" now...

It's definitely less clunky from a file access standpoint at the command line. But... there is also the risk of losing the authentic "character and feel" of the old TI, which is after all a big part of the reason why we are still using that machine.

While I certainly wholeheartedly welcome the utility of FC, I also don't want the TI to become PC-like. Now where that fine threshold resides is wholly a matter of personal opinion with no right answer. As far as I am concerned, I have not yet crossed that threshold ?

  • Like 1
Link to comment
Share on other sites

5 hours ago, Vorticon said:

While I certainly wholeheartedly welcome the utility of FC, I also don't want the TI to become PC-like. Now where that fine threshold resides is wholly a matter of personal opinion with no right answer. As far as I am concerned, I have not yet crossed that threshold ?

I agree, there is no right and wrong way.  It's different strokes for different folks,.  People are in this hobby for different personal reasons and we all have our opinions on how we want to enjoy our hobby.  I love having an ever increasing amount choices and options.  Now me, I would not mind the TI being even more PC-like... when I want it to be that way.  Truth is, I use Force Command A LOT OF THE TIME , but there are other times I simply want to play a game or two, so I use the FinalGROM for that.  Lately I've even been reverting back to the UberGROM for individual games.  Heck, sometimes I'll use one TI, and another time I use the another.  It all depends on my mood at the time.  But GAWD, the way Force Command brings it all together is bloody wonderful!

 

One of my goals is to get the TI to do as much stuff as possible and actually be able to get by a day or two WITHOUT turning on the PC.   Force Command working with the FinalGROM, the F18A and T80XB is bringing that reality closer month by month.  I even envision a day when it might be possible to use a text based browser on the World Wide Web like Lynx with a combination of the FinalGROM, F18A or it's future successor and the SAMS card and TIPI.  

 

 

 

  • Like 1
Link to comment
Share on other sites

I am yet again learning about cool TI-99/4A projects. This one looks really cool, and useful! I tried to compile the current version in github (to test drive my fresh build of gcc for the TMS9900), and ran into a few issues. The good news is that gcc compiled a whole lot of stuff, so that was good, but python3 was not happy: Initially I was using python 3.5.3 (on Debian stretch running under WSL) and it does not support the f"..." style strings. Upgraded python to 3.9, but next I ran into this problem:

python3  -D "CART=>601e" -o FCMDG.bin gpl-boot.g99  
Unknown option: -D
usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...  
Try `python -h' for more information. 

Which version of python I should be using? 

 

EDIT: My bad. I should have cloned the repository with

git clone --recurse-submodule https://github.com/jedimatt42/fcmd.git  

instead of straight clone. In addition to this, I needed to edit xdm99.py so that it uses python3, so I modified the first line of xdm99.py:

#!/usr/bin/env python3 

With these changes it appears that on the TIPI the compile was successful.

Edited by speccery
Link to comment
Share on other sites

I was about to ask how I should get this working with the TIPI. I am testing Force Command with icy99. After some head scratching I should kick myself, I forgot to load the DSR for TIPI. Once that was done Force Command seems to work fine, and it talks with TIPI too. This is the version I compiled from source, so very cool.

At last as far as the "dir" command is concerned; it gives me the home directory of the user tipi listed, but I don't seem to be able to change to change directory to DSK1... Need to learn how to actually use this.

It is interesting that a reset throws me directly to Force Command - cool and unexpected! A whole new computer!

 

Edited by speccery
  • Like 4
Link to comment
Share on other sites

Can you grab the last bit of the TIPI log off of the the pi when you try to go to that folder?

Is in /var/log/tipi

Or you should be able to pull it up from the website by pulling open TIPI:9900 from a browser on your PC and then finding the log in the menu

Sent from my LM-V600 using Tapatalk

Link to comment
Share on other sites

@speccery

 

case matters for device and file/directory names on the TI and TIPI.

Force Command won't let you cd to a destination that doesn't look like a device or directory ( cd actually opens the catalog to verify ) so if DSK1 isn't mapped, you'll have trouble. 

 

TIPIMAP command in ForceCommand will list your mappings just like TIPICFG (CALL TIPI) did.

 

Regarding building it - You'll run into bugs... I publish bugs to the master branch in github... I publish tested builds to post #1 in this thread. You shouldn't need 

--recurse-submodule

I'm curious what symptom indicated you needed that? If that is needed, I broke something bad. 

 

the python3   -D (notice the extra spaces) was just because xdt99 suite of tools wasn't found.  ( I should probably write some build docs. )    and I should fix my makefiles so you don't have to edit Ralph's xdt99 programs.

  • Like 1
Link to comment
Share on other sites

Thanks @jedimatt42 for your comments. I clearly jumped into conclusions too fast.

The reason for my messy conclusions were that I didn’t have enough time to properly go through things step by step again. The root cause is probably the lack of xdt99 on path, which manifests it self with the weird python3 command line. The reason I was thinking that recurse submodules was necessary was simply that for some projects it is, so it’s one of things I try when something is not working. Here it appeared something was lacking (what was lacking was knowledge how to build fcmd) so I tried it out, while apparently also adding xdt99 suite to the path at the same time.

 

I first thought fcmd is built by running make, only to later discover that there was the build.sh script. Secondly, I was building for the first time gcc simultaneously on both my desktop and on the TIPI. I wasted some time not realising the installation script for gcc, which took care of all steps in one go (apart from installing the few unusual dependencies). It was not obvious to me that the gcc can built and installed simply the installation script, I was scrambling the patches first.

 

In other words, I was working on multiple projects I am not familiar with. Still, miraculously the outcome was a seemingly working fcmd. I loaded both the cartridge ROM and GROM, but is it so that only the cartridge ROM is needed?

 

My preference is to build things from source, that way I can more easily change something if needed. As one example currently the width command of fcmd does not recognize icy99 (which is not surprising), so I cannot get 80 columns to work yet. It will be interesting to see how it detects the VDP type.

Link to comment
Share on other sites

I'll fix up the building instructions. :) that'll help, and can fix all my references to xdt99 tools so no editing is required. 

 

80 column in Force Command is built explicitly for the 9938 80x26.5 mode, and the F18A 80x30 with extended color attributes mode. So it doesn't work in classic99 emulator either. 

 

VDP detection is here: https://github.com/jedimatt42/fcmd/blob/master/b10_detect_vdp.c

 

And in this file:  https://github.com/jedimatt42/fcmd/blob/fef52275be9ff6e69c439e14b275246329bdeae4/libti99/b8_vdp_settext80.c#L12

 

You can remove the register 8 and 9 setting, and change the 25 and 26 in that file to 23 and 24 to get a 80x24 2-color display. 

 

 

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...