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

[+Lee Stewart]

8 hours ago, jedimatt42 said:

I'd like to add commands to list the volume names on a nanopeb, and manipulate the mounts... I see the code in the fbForth manual for manipulating the mounts, but I cannot find any data on how to list the volumes. 

 

Does anyone have specification or code that details how to list the volumes? 

 

As you probably know, the fbForth manual only knows how to temporarily mount nanoPEB/CF7+ volumes. There is code in block #69 of the current FBLOCKS for permanently mounting volumes, but you must know which volume you want to mount, which still does not answer your question.

 

Fred Kaal (@F.G. Kaal) is the person to contact for this information. It has been more than a year since I last looked at his code and, even then, I was a little asea. I can tell you that his code uses a subset of the IDE interface to read 512-byte sectors, half of which are not used for actual TI sectors. The permanent mounts are recorded somewhere in the beginning of the CF, but I am not much help with the details. I do not think there is a table of volumes. I think that each volume’s header must be read to discover its name and format status, but my memory is not as good at my present age as it used to be.

 

...lee 

[+jedimatt42]

13 minutes ago, Lee Stewart said:

 

As you probably know, the fbForth manual only knows how to temporarily mount nanoPEB/CF7+ volumes. There is code in block #69 of the current FBLOCKS for permanently mounting volumes, but you must know which volume you want to mount, which still does not answer your question.

 

Fred Kaal (@F.G. Kaal) is the person to contact for this information. It has been more than a year since I last looked at his code and, even then, I was a little asea. I can tell you that his code uses a subset of the IDE interface to read 512-byte sectors, half of which are not used for actual TI sectors. The permanent mounts are recorded somewhere in the beginning of the CF, but I am not much help with the details. I do not think there is a table of volumes. I think that each volume’s header must be read to discover its name and format status, but my memory is not as good at my present age as it used to be.

 

...lee 

 

Yep, I looked at the code there in fbForth first.. that's cool info... I'll borrow for part of this mission... 

 

That fits what I imagine... It would be interesting to learn to talk to an IDE device... Oh, look Fred is quietly up to more stuff with TiBus -    

I'll have to reach out and see if he wants to share some knowledge on the nanopeb with me. I'm surprised I don't find --- oh, well looking closer at the nanopeb website, there is contact info for the designer now... 

[GDMike]

8 hours ago, jedimatt42 said:

 

Wrong audience I guess. I'll take this question back to the top...

I have a piece of assy source code, it was a call from extended basic to allow changing nanopeb drives and volumes.

I'm not sure if it's going to help but I can post it when I dig it out. It's all I have. And I know it works once compiled and then called from ext basic.

 

Edited June 6, 2020 by GDMike

[dgrissom]

9 hours ago, jedimatt42 said:

 

Wrong audience I guess. I'll take this question back to the top...

I used to pray a lot when I would write code as well!  

 

Possible BUG report (or User Error):

I am loading EDIT40 from  AUTOCMD.  (That works the editor starts).

• However, when I try to "load" a file from it I get an "ERROR 0007". 
• It worked for a while however I added some features to my AUTOCMD it.   I've looked  for this error in my few TI books and can't locate it.  (Maybe I am channeling James Bond?).
• I've removed most of the extra code and the problem persists. 
• I've tried branching to separate script that just calls  the Editor with the same result.
• Maybe, I've run out of RAM?... address conflict?... too much or too little coffee? 

 

By the way I have the call link mount assembly routines code is on: https://gtello.pagesperso-orange.fr/ti99_e.htm

I would have provided this yesterday.  However, you appeared to be beyond this in that you were trying to access the disk catalog?

[GDMike]

Yup. Same code I have as well..I couldn't find anything other than this.

[+jedimatt42]

1 hour ago, dgrissom said:

I used to pray a lot when I would write code as well!  

 

Possible BUG report (or User Error):

I am loading EDIT40 from  AUTOCMD.  (That works the editor starts).

• However, when I try to "load" a file from it I get an "ERROR 0007". 
• It worked for a while however I added some features to my AUTOCMD it.   I've looked  for this error in my few TI books and can't locate it.  (Maybe I am channeling James Bond?).
• I've removed most of the extra code and the problem persists. 
• I've tried branching to separate script that just calls  the Editor with the same result.
• Maybe, I've run out of RAM?... address conflict?... too much or too little coffee? 

 

By the way I have the call link mount assembly routines code is on: https://gtello.pagesperso-orange.fr/ti99_e.htm

I would have provided this yesterday.  However, you appeared to be beyond this in that you were trying to access the disk catalog?

 

The "GPL Interface Specifications for the TI/99-4 Disk Peripheral" says that 7 indicates a File Error, either the file doesn't exist, or it is not of the type that matches the open mode... ( such as fixed vs variable record, or incorrect record length... ) -- I'll test this out.. I have to admit, I've loaded EDIT80 and saved a file, but never loaded one.  I have a bug in my 'type' command I'm also working on...  I have fixes for the CLS and ECHO already.. 

 

It is interesting, it looks like from this code and Lee's forth code, mounting volumes is just stuffing the values into VDP ram correctly.. 

 

[dgrissom]

There must be a write location as mounted disks using the original CALL M OUNT(X, Y) and F.Kaal's cf2k mounts are persistent even after powering off the console and nano.  It really would not matter on Force Command as I would use unmounted 1-3 for menus and base utilities.  

Hopefully, all other disks (1000+) would act like psuedo folders?  I can only dream ? .

[+jedimatt42]

For CF7/nanopeb, to set the volume for DSK1-3, write the volume number to the corresponding VDP address

 

DSK1 - VDP address 0x3FFA

DSK2 - VDP address 0x3FFC

DSK3 - VDP address 0x3FFE

 

Read the VDP addresses to get the currently mapped volumes.

 

To detect the CF7/nanopeb, read 2 bytes from VDP address 0x3FF8, they should be 0xAA03 if the device is present. 

 

[+jedimatt42]

3 minutes ago, dgrissom said:

There must be a write location as mounted disks using the original CALL M OUNT(X, Y) and F.Kaal's cf2k mounts are persistent even after powering off the console and nano.  It really would not matter on Force Command as I would use unmounted 1-3 for menus and base utilities.  

Hopefully, all other disks (1000+) would act like psuedo folders?  I can only dream ? .

 

I am not ambitious enough to change the nature of the device... My goal was to be able to allow scripting to mount volumes ahead of launching programs... and as an interactive user, be able to list the volumes so you know what to put where. I emailed the designer, we'll see if he is willing to provide the volume layout info and allow me to open source it... If I can't open source it, it'll have to wait until we have external command support in Force Command, then he can make a binary available... 

 

I imagine people have printouts or whatever they work off of today... volume numbers scribbled on envelopes... without volume listing it isn't the end of the world, it ends up being like the FG99 command... 

 

As for persistence, I'm unsure how that works if we are just scribing into VDP memory... I have to figure how to get files onto the device, then I can play with the experience... Neither of these example implementatoins call the MOUNT subroutine... I wouldn't be surprised if persistence doesn't happen until the CF/nanopeb powerup routine is performed. 

 

[dgrissom]

No need for feature creep. <some of the comments below are for other nano cf7 users>

 

A simple non-persistent command will work fine as the DSK1 (nano - DISK 1) will act as a root directory to mount volumes on the fly (to branch to other volumes). I would be lucky to work with 10-30 disks (if that many) accessed routinely.  <as you stated> IMO, persistence would be an undesirable feature.

 

A script with:

 <cmd> to mount(3,20)

  call DSK3.MENU (or AUTOCMD on that volume)

 

would work: 

DSK3.MENU would do some stuff and return with a call DSK1.(call "branching menu")  or a reboot back to Force Command DSK1.AUTOCMD.

 

A main directory may be nice, but it isn't necessary as the existing tool can be loaded from  fg99 or ea5.

Edited June 6, 2020 by dgrissom
Sorry some of this was covered in your post. Need new glasses.

[+Lee Stewart]

7 hours ago, jedimatt42 said:

It is interesting, it looks like from this code and Lee's forth code, mounting volumes is just stuffing the values into VDP ram correctly.

 

6 hours ago, jedimatt42 said:

As for persistence, I'm unsure how that works if we are just scribing into VDP memory... I have to figure how to get files onto the device, then I can play with the experience... Neither of these example implementatoins call the MOUNT subroutine... I wouldn't be surprised if persistence doesn't happen until the CF/nanopeb powerup routine is performed. 

 

Here is an expanded version of Block #69 of the current FBLOCKS, with detailed explanations. Of particular note is CFPMOUNT (and the words it requires), which permanently/persistently MOUNTs CF7+/nanoPEB volumes. This should allow you some insight into how Jaime managed it without also needing to know the inner workings of the DSR:

Spoiler

\ Compact Flash Mount Utilities for nanoPEB/CF7+..LES 12DEC2018 
\    "S:" appearing in comments represents the data/parameter stack

\ Verify CF7+/nanoPEB authentication bytes
: CF? ( -- f)  
   3FF8 VSBR SWPB 
   3FF9 VSBR + 
   AA03 = 
;               
\ Verify CF7+/nanoPEB presence, aborting if absent
: CFCHK ( -- )    
   CF? 0= ABORT" No CF7+/nanoPEB!"  
;               
\ Get currently mapped volumes
: CFVOLS ( -- d1 d2 d3)    
   CFCHK             \ verify CF7+/nanoPEB presence
   SP@ 6 - 8312 !    \ reserve stack space for 3 cells (R9-SP)
   SP@ 3FFA SWAP 6   \ S:vaddr addr count
   VMBR              \ get d1 d2 d3 volume numbers to stack
;  
\ Insure DSK # is 1..3, leaving d on stack
: DSKCHK ( d -- d)   
   DUP 1 < OVER 3 > OR                
   ABORT" DSK# not 1-3!" 
; 
\ MOUNT CF7+/nanoPEB volume v as DSKd
: CFMOUNT ( v d --) 
   CFCHK             \ verify CF7+/nanoPEB presence
   DSKCHK            \ insure DSK # is 1..3, leaving d on stack
   1- 1 SLA 3FFB + OVER SWPB OVER 1- VSBW VSBW 
; 

\ This PAB for CF7+/nanoPEB DSR's "MOUNT" subprogram actually is part
\ of the TI Basic line that gets stored in VRAM when a user types 
\ "CALL MOUNT(3,50)" to mount volume #50 as DSK3. The subprogram name,
\ DSK number and volume number are all ASCII counted strings separated
\ by 2-byte separations as follows for the above CALL MOUNT():
\     5,'MOUNT','(',200,1,'3',179,200,4,'0050'
\     ...DSK# is 1, 2 or 3 in one ASCII digit
\     ...volume# is a 4-digit decimal number in ASCII digits
\ Once the MOUNT subprogram is invoked, it expects to find the rest of 
\ the TI Basic line following the '(' formatted exactly as above. Though,
\ technically not part of the PAB, we store the line into VRAM as above
\ and point DSRLNK to this PAB:

054D VARIABLE CFMOUNT-PAB 
   DATA[ 4F55 4E54 28C8 0100 B3C8 0400 0000 0000 ]DATA 
      \ 5,'M','OU','NT','(',200,1,DSK,179,200,4,volume are stored here,
      \ with space for DSK reserved with 1 zero byte and volume with 4.
      \ The extra zero byte at the end is an artifact of DATA[ ... ]DATA
   DROP DROP   \ drop address & count

\ Per Jaime Malilong (designer of CF7+/nanoPEB), the following Scratchpad
\ RAM addresses are used by the CF7+/nanoPEB DSR's MOUNT subprogram:
\     >832C  <--TI Basic line pointer to MOUNT command line (length byte)
\     >8342  <--this location in inner interpreter needs save/restore
\     >8354
\     >8356
\     >8358
\     >8366

\ Save part of inner interpreter at >8342 trashed by MOUNT
8342 @ VARIABLE SV8342 

\ This word is equivalent to the following ALC
\  BLWP @DSRLNK
\  DATA 10
\  MOV  @SV8342,@>8342
: DSR-MOUNT ( -- ) 
   0A 0E SYSTEM      \ DSRLNK 10 for subprogram execution
   SV8342 @ 8342 !   \ restore inner interpreter
; 
\ Write DSK number to CFMOUNT-PAB as 1 ASCII digit
: PUTDSK ( d -- ) 
   0                 \ make d a double number
   <# # #>           \ converts to 1 ASCII digit, S:adr 1
   CFMOUNT-PAB 9 +   \ point to DSK string byte,  S:adr 1 pabadr+9
   SWAP              \                            S:adr pabadr+9 1
   CMOVE             \ copy 1 char to pabadr+9
; 
\ Write volume number to CFMOUNT-PAB as 4 ASCII digits
: PUTVOL ( v -- ) 
   0                 \ make v a double number
   <# # # # # #>     \ converts to 4 ASCII digits, S:adr 4
   CFMOUNT-PAB 0D +  \ point to VOL string bytes,  S:adr 4 pabadr+13
   SWAP              \                             S:adr pabadr+13 4
   CMOVE             \ copy 4 chars to pabadr+13
; 
\ Copy CFMOUNT-PAB to VRAM
: CFPAB>VRAM ( -- ) 
   PABS @ DUP              \ where PABS start in VRAM  S:vadr vadr
   CFMOUNT-PAB OVER 012    \ S:vadr vadr pabadr vadr 18
   \ copy 18 bytes from CFMOUNT-PAB to its VRAM location
   VMBW                    \ S:vadr vadr
   8356 !                  \ point to length byte of PAB  S:vadr
   832C !                  \ "TI Basic line pointer" (our PAB)
;  
\ Permanently MOUNT CF7+/nanoPEB volume v as DSKd
: CFPMOUNT ( v d --) 
   CFCHK          \ verify CF7+/nanoPEB presence
   DSKCHK         \ insure DSK #d is 1..3, leaving d on stack
   PUTDSK PUTVOL  \ copy ASCII values of d and v to CFMOUNT-PAB
   CFPAB>VRAM     \ copy CFMOUNT-PAB to VRAM & set up pointers for MOUNT
   DSR-MOUNT      \ perform the permanent/persistant MOUNT
;   
  
DECIMAL

 

 

...lee

Edited June 6, 2020 by Lee Stewart
CORRECTED ERROR IN CODE

[+jedimatt42]

Yep that is what Mr. Malilong replied with, just invoke the MOUNT basic subroutine with the parameters setup in VDP... like BASIC does... 

[+jedimatt42]

On 6/3/2020 at 7:54 PM, jedimatt42 said:

 

No, and apologies to @Tursi I broke libti99 when I added the 80x30 column mode, as I extended a precarious pattern, and it got confusing... I owe him some more testing and fixing... there are still problems with his fixes to my mistakes, but his approach is superior.  I'm hoping it just missed a spot... conio crashes anytime line wrapping happens..   

 

Thankfully, Tursi fixed my libti99 breakage before I got back to it... The remaining bug I thought was in libti99 is actually in my code somewhere and only happens when I read a full 80 character record from a D/V 80 file, and then try to print that... 

 

Nanopeb support, and the intended usage of a mount command will also require some restructuring.. when running a script, I currently run them one record at a time. I don't load the entire script into memory. Changing a mount out from under a script would be catastrophic.. fixing this will also speed up looping scripts considerably. 

 

(I am mostly just giving myself a pep-talk here...)

[dgrissom]

"tipimap" issue (Probably a user problem)

 

I received my TIPI/32K this week and am trying out Force Command with it.

 

In a simple script I am using:

script/batch filename  "ASSM"

tipimap DSK1 TIPI.EA  (EA = a folder to hold EA files)

fg99 EAG       (Edit / Assembler on FG - root directory <- This works)

 

tipimap resets the system (crash / restart to TI Main Screen)

 

Tried Uppercase/Lowercase .  Tried from command line.

Mapping will work from TI BASIC "CALL TIPI"

Arcadeshopper's "TIPIMAP" program works.

 

signed:  Puzzled in Prattville  ?

 

 

[+arcadeshopper]

"tipimap" issue (Probably a user problem)
 
I received my TIPI/32K this week and am trying out Force Command with it.
 
In a simple script I am using:
script/batch filename  "ASSM"
tipimap DSK1 TIPI.EA  (EA = a folder to hold EA files)
fg99 EAG       (Edit / Assembler on FG - root directory   
tipimap resets the system (crash / restart to TI Main Screen)
 
Tried Uppercase/Lowercase .  Tried from command line.
Mapping will work from TI BASIC "CALL TIPI"
Arcadeshopper's "TIPIMAP" program works.
 
signed:  Puzzled in Prattville  [emoji846]
 
 

TIPIMAP is an extended basic program that is interactive you can't run it from a script

Sent from my LM-G820 using Tapatalk

[+jedimatt42]

5 minutes ago, arcadeshopper said:

TIPIMAP is an extended basic program that is interactive you can't run it from a script

Sent from my LM-G820 using Tapatalk
 

 

Well there is a builtin command in Force Command named TIPIMAP, that controls the mappings...

 

[+jedimatt42]

14 minutes ago, dgrissom said:

"tipimap" issue (Probably a user problem)

 

I received my TIPI/32K this week and am trying out Force Command with it.

 

In a simple script I am using:

script/batch filename  "ASSM"

tipimap DSK1 TIPI.EA  (EA = a folder to hold EA files)

fg99 EAG       (Edit / Assembler on FG - root directory <- This works)

 

tipimap resets the system (crash / restart to TI Main Screen)

 

Tried Uppercase/Lowercase .  Tried from command line.

Mapping will work from TI BASIC "CALL TIPI"

Arcadeshopper's "TIPIMAP" program works.

 

signed:  Puzzled in Prattville  ?

 

 

 

Arrg.. I need use the scripting to create a set of regression tests  It appears to be out-write broken... 

 

[+jedimatt42]

It works now...  silly mistake on my part

 

[dgrissom]

I downloaded ver. 0.h.  It works like a champ!

• cls
• echo
• tipimap
• ... all working perfectly.

I will be hooking my NanoPEB to the "chain" and test it as soon as I get a switch to toggle the TIPI's 32K on/off.

 

I appreciate the work that you are doing!

David...

[+jedimatt42]

3 hours ago, dgrissom said:

I downloaded ver. 0.h.  It works like a champ!

• cls
• echo
• tipimap
• ... all working perfectly.

I will be hooking my NanoPEB to the "chain" and test it as soon as I get a switch to toggle the TIPI's 32K on/off.

 

I appreciate the work that you are doing!

David...

 

Glad that's working for you. 

 

The jedimatt42 style 32k board the sideport TIPI plugs into, can have the 32k disabled by simply removing the 74HCT245 chip. Or you could rewire the output-enable signal on that same chip by switching the input to either be the normal point at the socket, or a 5v pullup to disable it. 

 

I've got a couple weird bug I want to fix next - some commands change the current directory/device behind the scenes, or at least that is consistent with the symptom.. and the TYPE command crashes if the line read is exactly 80 characters in a DV80 file. That is most likely how I'll spend my day tomorrow. 

 

If I get through that, then I may start on the nanopeb MOUNT support..

[dgrissom]

On 6/14/2020 at 1:45 AM, jedimatt42 said:

 

Glad that's working for you. 

 

The jedimatt42 style 32k board the sideport TIPI plugs into, can have the 32k disabled by simply removing the 74HCT245 chip. Or you could rewire the output-enable signal on that same chip by switching the input to either be the normal point at the socket, or a 5v pullup to disable it. 

 

I've got a couple weird bug I want to fix next - some commands change the current directory/device behind the scenes, or at least that is consistent with the symptom.. and the TYPE command crashes if the line read is exactly 80 characters in a DV80 file. That is most likely how I'll spend my day tomorrow. 

 

If I get through that, then I may start on the nanopeb MOUNT support..

Hope you are doing well.  Don't work too hard on this stuff.  If you do, I hope you are having fun!

 

I found a problem (initially) with the "drives" command.  It hangs on my 40 column. stock TI (standard VDP).

It looks like if the return data is = 40 columns? (related to your 80 column bug?)

 

[1000.TIPI.GAMES.]

$ DRIVES

1000 - TIPI DSK0 DSK1 DSK2 DSK3 DSK4 PI (hangs)

 

(This has occurred with some other commands.  However, it is difficult to reproduce. I'll continue to try to get an example.)

 

The help and help w/<cmd> and  dir /w all work fine. (wrapping works)  

 

This is not hurting my use of this software.  For me, this is the absolutely the best way to navigate and interact with the TIPI file system!

 

[+jedimatt42]

1 hour ago, dgrissom said:

Hope you are doing well.  Don't work too hard on this stuff.  If you do, I hope you are having fun!

 

I found a problem (initially) with the "drives" command.  It hangs on my 40 column. stock TI (standard VDP).

It looks like if the return data is = 40 columns? (related to your 80 column bug?)

 

[1000.TIPI.GAMES.]

$ DRIVES

1000 - TIPI DSK0 DSK1 DSK2 DSK3 DSK4 PI (hangs)

 

(This has occurred with some other commands.  However, it is difficult to reproduce. I'll continue to try to get an example.)

 

The help and help w/<cmd> and  dir /w all work fine. (wrapping works)  

 

This is not hurting my use of this software.  For me, this is the absolutely the best way to navigate and interact with the TIPI file system!

 

I believe I fixed that issue in my current build. I'll verify and share after things get settled with the day job.

[+jedimatt42]

It is all for FUN!!! 

 

 

[dgrissom]

5 minutes ago, jedimatt42 said:

It is all for FUN!!! 

Sweet! Better and Better!

[dgrissom]

FIRST ?  I am probably the only person in the world using this combination of hardware at this time! 

Note: This is not criticism!

 

These are a few observations with the both NanoPEB and TIPI/32K attached to my console.

(If this has been covered in previous TIPI threads, I apologize in advance as I am still "catching up" on my reading.)

 

J-Data provided a way to jumper the last set of pins on his TIPI/32K board to set the CRUBASE to 1800 and disable the TIPI's on-board 32K.  (This allows me a way of using both the TIPI and NanoPEB using an external toggle switch without a RAM conflict.)

 

This works.  However, it causes a few peculiarities using Force Command.

 

DSK1,DSK2, and DSK3 drives always map to the NanoPEB. The Nano is being mapped as CRUBASE 1100. 

 

Force Command's "tipimap" command only seems to work with DSK's 1-3.  DSK4 throws an error: "error, bad drive specification". (DSK0 throws the same error.  I can see this as being by design as it always points to "TIPI".)

 

Since DSK1-3 are overridden by the Nano, this prohibits assigning a TIPI drive folder before running a cartridge from the TIPI using a batch/script while the Nano is attached.  I can type the full TIPI path - "TIPI.GAMES.TOD.QUEST" while in the game (TOD) and this will work.  If I set up DSK4 using TIBASIC's  CALL TIPI prior to running the cartridge (or file) then DSK4.QUEST will work.

 

In the "For what its worth, department"

Not related to the above and may be covered in previous discussions.   This has no real impact on my use of the software.

 

With a stock TI's 40 column screen in Force Command.  The maximum command length is 37 characters (40 characters minus the prompt). This is more than I would normally use!  Using EDIT40, It appears that I can create a command that is up to 80 characters long in a script file.  I am assuming that a 80 character display would provide a similar increase from the command line?