Jump to content
jedimatt42

Force Command ver 1.4 : kinda like command.com from 1985

Recommended Posts

7 hours ago, arcadeshopper said:

I'll try it

Sent from my LM-V600 using Tapatalk
 

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

  • Thanks 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
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. ;)

 

Share this post


Link to post
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 ) 

Share this post


Link to post
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

Share this post


Link to post
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. 

Share this post


Link to post
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

Share this post


Link to post
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 "."

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.  

Share this post


Link to post
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.

 

 

Share this post


Link to post
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...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...