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

[+mizapf]

If you open a file for output and close it directly, it will have 0 content, just the File Information Block (1 sector).

[+Vorticon]

Yeah copying the contents of floppies to the TIPI is a slow process that really exercises the read head of the drive. Probably not a good thing for its long term health either I would think...

[+arcadeshopper]

Yeah copying the contents of floppies to the TIPI is a slow process that really exercises the read head of the drive. Probably not a good thing for its long term health either I would think...

Dm2k works great for this just use DSK0. for the TIPI drive..

Sent from my LM-V600 using Tapatalk

[+Vorticon]

Just now, arcadeshopper said:

Dm2k works great for this just use DSK0. for the TIPI drive..

Sent from my LM-V600 using Tapatalk
 

Yes it does. However, I will have to exit FC to do this which is a bit inefficient. I prefer to use to COPY command in FC directly. Not a deal breaker by any means though.

[+jedimatt42]

So, I keep thinking about memory usage, and seeking... and realize every lvl2 direct read/write has seek to go find the file in the filesystem layout, and then seek to the file block location to get some data or write some data... So to reduce this seeking, and stick with direct read/write, only using more VDP memory will help at all. 

 

My current VDP memory map is pretty adhoc... 

| Address | Size in bytes | Description         |
| ------- | ------------- | ------------------- |
| 0x0000  | 0x0960        | Image table         |
| 0x0A00  | 0x0100        | Sprite table        |
| 0x1000  | 0x0800        | Pattern table       |
| 0x1800  | 0x0960        | Color attributes    |
| 0x2160  | n/a           | free space          |
| 0x3000  | 0x0100        | IO Buffer           |
| 0x3200  | 0x010A        | PAB                 |
| 0x3FF8  | 0x0008        | Nanopeb stats       |
| 0x4000  | 0x0034        | Fast scroll routine |

 

I'm sure I can push some of that around and get a 4K VDP buffer. Something like:

 

| Address | Size in bytes | Description         |
| ------- | ------------- | ------------------- |
| 0x0000  | 0x0960        | Image table         |
| 0x0960  | 0x00A0        | /free space-------/ |
| 0x0A00  | 0x0100        | Sprite table        |
| 0x0B00  | 0x010A        | PAB                 |
| 0x0C0A  | 0x03F6        | /free space-------/ |
| 0x1000  | 0x0800        | Pattern table       |
| 0x1800  | 0x0960        | Color attributes    |
| 0x2160  | 0x1000        | 4K IO Buffer        |
| 0x3160  | varies        | /free-vdp stack---/ |
| 0x3FF8  | 0x0008        | Nanopeb stats       |
| 0x4000  | 0x0034        | Fast scroll routine |

The perfect balance might be just over 4k, so that those 8k + header EA5 files are only 2 operations instead of 3.

[webdeck]

Silly question - is there a way to repeat the previous command?  I'm thinking like the up arrow in linux which lets you go back in history and either redo a command or edit it.  I'm guessing there isn't enough memory to maintain a full history stack, but repeating the last command would be useful in some situations.

[+jedimatt42]

39 minutes ago, webdeck said:

Silly question - is there a way to repeat the previous command?  I'm thinking like the up arrow in linux which lets you go back in history and either redo a command or edit it.  I'm guessing there isn't enough memory to maintain a full history stack, but repeating the last command would be useful in some situations.

 

I actually have 24k of RAM I'm not using.  I desire to support a 256 byte command line... so that's almost 100 lines of history. but if I get smarter, and use a circular linked list, with variable length entries, a new command might kick 2 out, or maybe several small commands fit in the space of one old one. And then 4k of history could look like 100 lines... 

 

with SAMS, I can move history out of the memory map while executing an external command program. And then map it back in when returning to the command prompt. But, without SAMS, I might have to pull an AtariDOS trick and page it out to a file so external programs can use that fixed set of 24K ram. The bit unique to AtariDOS was the intelligence to only do that if a ramdisk was present... I could use TIPI as suitably fast storage for that, or allow an environment variable to configure a different location... or fall back on single line history only, if no TIPI and no config.

 

A lot of TI software is not Force Command aware, ( how could it be, Force Command is new and under development ) so I'm thinking any multi-line history would be beneficial if flushed to disk on key events like FG99, XB, or LOAD, all events where Force Command has to give up control of the machine.

 

( I always forget BASH supports arrow keys... set -o vi ) 

 

[+InsaneMultitasker]

58 minutes ago, jedimatt42 said:

So, I keep thinking about memory usage, and seeking... and realize every lvl2 direct read/write has seek to go find the file in the filesystem layout, and then seek to the file block location to get some data or write some data... So to reduce this seeking, and stick with direct read/write, only using more VDP memory will help at all. 

 

My current VDP memory map is pretty adhoc... 

| Address | Size in bytes | Description         |
| ------- | ------------- | ------------------- |
| 0x0000  | 0x0960        | Image table         |
| 0x0A00  | 0x0100        | Sprite table        |
| 0x1000  | 0x0800        | Pattern table       |
| 0x1800  | 0x0960        | Color attributes    |
| 0x2160  | n/a           | free space          |
| 0x3000  | 0x0100        | IO Buffer           |
| 0x3200  | 0x010A        | PAB                 |
| 0x3FF8  | 0x0008        | Nanopeb stats       |
| 0x4000  | 0x0034        | Fast scroll routine |

 

I'm sure I can push some of that around and get a 4K VDP buffer. Something like:

 

| Address | Size in bytes | Description         |
| ------- | ------------- | ------------------- |
| 0x0000  | 0x0960        | Image table         |
| 0x0960  | 0x00A0        | /free space-------/ |
| 0x0A00  | 0x0100        | Sprite table        |
| 0x0B00  | 0x010A        | PAB                 |
| 0x0C0A  | 0x03F6        | /free space-------/ |
| 0x1000  | 0x0800        | Pattern table       |
| 0x1800  | 0x0960        | Color attributes    |
| 0x2160  | 0x1000        | 4K IO Buffer        |
| 0x3160  | varies        | /free-vdp stack---/ |
| 0x3FF8  | 0x0008        | Nanopeb stats       |
| 0x4000  | 0x0034        | Fast scroll routine |

The perfect balance might be just over 4k, so that those 8k + header EA5 files are only 2 operations instead of 3.

Sticking with VDP is the only option for some floppy controllers e.g., TI and Corcomp,  however, some of the later peripherals do not lock you into VDP RAM buffers.  Leveraging existing DSR CPU buffer support is relatively straightforward, even if few people use it.    If you don't want to fork your routines to add CPU buffering, a VDP buffer of (17 "TI sectors" * 256 bytes/TI sector) works well to cover the 8k+ image scenario in two passes.  For years that was my chosen buffer size for terminal emulation to cover the GRAM Kracker format and others that had just enough residual data to be annoying.

[+Vorticon]

I realized yesterday that the RMDIR command does not work on non-empty directories. And the DELETE command does not accept * as an argument, so I have to delete all the files in a directory one by one before being able to delete the directory itself.

Therefore a wish list:

• DELETE * to delete all files in a directory (with a confirmation prompt)
• RMDIR with a switch for deleting all sub-directories and files in the requested directory

Easier said than done, hence the wish part

[+jedimatt42]

On 10/2/2020 at 11:41 PM, InsaneMultitasker said:

Sticking with VDP is the only option for some floppy controllers e.g., TI and Corcomp,  however, some of the later peripherals do not lock you into VDP RAM buffers.  Leveraging existing DSR CPU buffer support is relatively straightforward, even if few people use it.    If you don't want to fork your routines to add CPU buffering, a VDP buffer of (17 "TI sectors" * 256 bytes/TI sector) works well to cover the 8k+ image scenario in two passes.  For years that was my chosen buffer size for terminal emulation to cover the GRAM Kracker format and others that had just enough residual data to be annoying.

 

I have implemented the 17 sector thing, after moving my VDP usage around, and remembering today that my memory map in 40 column mode is greatly different from my 80 column mode...  But I've easily found a compromise that gives me that larger buffer size. 

 

I don't ever copy it out of VDP, so the CPU RAM support for some DSR's would actually hurt if both the source and target device are not capable of the CPU RAM feature.  

 

I'll probably drop an update soon, tonight still maybe... I'm trying to track down the empty file issue... So far it doesn't seem to be a ForceCommand issue.

[webdeck]

Quote

I'm trying to track down the empty file issue... So far it doesn't seem to be a ForceCommand issue.

To fix the empty file issue, in b9_handleCopy.c, remove the totalBlocks == 0 check and error.  Should just work if you remove that.

[+jedimatt42]

Just now, webdeck said:

To fix the empty file issue, in b9_handleCopy.c, remove the totalBlocks == 0 check and error.  Should just work if you remove that.

Thanks, I was trying to go back and see what the actual usage situation was... I mis-remembered and thought it was an issue cataloging with empty files.. Anyway, I'll take a swing at that now!

[+jedimatt42]

Ok, this seems to work for me. Months of rearranging code. I'm going to take an incremental approach to making each API function 'public'. So this isn't the public API release. There may be new bugs, but I thought I did a pass at retesting all of it. 

 

The larger buffer work is in, and the empty file fix is in. 

 

CALL was removed... so it's not compatible with some scripts, if your scripts called other scripts...  0.M is still in post #1, and I'll leave it there for a while.  

 

It's free hobby software, so 1.0 doesn't mean it's bug free. LOL... download links in post #1

 

 

 

[+jedimatt42]

It just dawned on me that I control the implementation of TIPI, so while it never produces errors for good data, I could introduce random errors while trying to implement some retry logic in the Force Command copy read code.

[+jedimatt42]

On 10/3/2020 at 4:53 AM, Vorticon said:

I realized yesterday that the RMDIR command does not work on non-empty directories. And the DELETE command does not accept * as an argument, so I have to delete all the files in a directory one by one before being able to delete the directory itself.

Therefore a wish list:

• DELETE * to delete all files in a directory (with a confirmation prompt)
• RMDIR with a switch for deleting all sub-directories and files in the requested directory

Easier said than done, hence the wish part

 

Out of curiosity, what devices are you deleting from? I seem to recall you had an IDE controller, and now a TIPI. The TIPI way to do this would be to open up the share on a modern PC, and use that modern PC for what it is good for. 

 

But I see the value of these in spinny disk situations. They are added to the github issues list.

[+jedimatt42]

On 9/30/2020 at 2:19 AM, mizapf said:

If you open a file for output and close it directly, it will have 0 content, just the File Information Block (1 sector).

Interestingly, classic99 creates a FIAD that has a data sector with no records in it... so 0xFF, followed by all 0x00s  , when run the following in BASIC: 

 

10 OPEN #1:"DSK1.EMPTY",OUTPUT
20 CLOSE #1

 

➜  DSK1 hexdump -C EMPTY 
00000000  07 54 49 46 49 4c 45 53  00 01 80 03 00 50 01 00  |.TIFILES.....P..|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  ff 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000180

 

I'll take your word for how it behaves on a real disk. 

[+Vorticon]

1 hour ago, jedimatt42 said:

 

Out of curiosity, what devices are you deleting from? I seem to recall you had an IDE controller, and now a TIPI. The TIPI way to do this would be to open up the share on a modern PC, and use that modern PC for what it is good for. 

 

But I see the value of these in spinny disk situations. They are added to the github issues list.

I'm deleting a directory in TIPI. I no longer have the IDE card.

Yes of course I could go to a modern PC and do all that, but I like using the TI as much as possible

[+jedimatt42]

Could someone test the COPY command with HDX?

 

It would be good to know if Force Command can copy files from or to the HDX device. I fixed some HDX related issues a while back. But don't recall the final outcome, and I have a github issue open still. Hoping I fixed it along the way, and just forgot to close the issue. 

[+arcadeshopper]

Could someone test the COPY command with HDX?
 
It would be good to know if Force Command can copy files from or to the HDX device. I fixed some HDX related issues a while back. But don't recall the final outcome, and I have a github issue open still. Hoping I fixed it along the way, and just forgot to close the issue. 

I will tomorrow am

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

So, previously, all my scripting work for ForceCommand has been in the form of native linux files that TIPI serves up as DV80. Well, that's not working with ForceCommand now, as TIPI doesn't offer Level2 IO for native files, and Force Command is using the metadata read from the Direct-Read lvl2 routine to determine the file type..  So, I either need to loosen that up, or fix TIPI.. 

 

But it seems to work with real DV80 files.

[Tursi]

7 hours ago, jedimatt42 said:

Interestingly, classic99 creates a FIAD that has a data sector with no records in it... so 0xFF, followed by all 0x00s  , when run the following in BASIC: 

Classic99's DSR does not attempt to replicate a TI Disk Controller.

 

(Edit: since the emulator includes the real TI disk controller, you can also test that. But don't use the Classic99 DSR to guess how a TI controller works.  )

 

 

Edited October 5, 2020 by Tursi

[+mizapf]

8 hours ago, jedimatt42 said:

I'll take your word for how it behaves on a real disk. 

Test with DDCC-1, same result for TI controller (but it does not have a CALL DIR ? )

[+jedimatt42]

Both approaches are correct with regard to level 3 io specifications, at least for variable length records. Just good to know where there are differences in the tools. 

 

Also just realizing I didn't do anything on purpose in this regard for TIPI, and that I didn't properly test the empty file fix in Force Command. But, TIPI seems to handle 0 sector FIADs. So now I've tested Force Command a bit more thoroughly. 

 

 

 

 

[dgrissom]

On 10/4/2020 at 8:37 PM, jedimatt42 said:

Ok, this seems to work for me. Months of rearranging code. I'm going to take an incremental approach to making each API function 'public'. So this isn't the public API release. There may be new bugs, but I thought I did a pass at retesting all of it. 

 

The larger buffer work is in, and the empty file fix is in. 

 

CALL was removed... so it's not compatible with some scripts, if your scripts called other scripts...  0.M is still in post #1, and I'll leave it there for a while.  

 

It's free hobby software, so 1.0 doesn't mean it's bug free. LOL... download links in post #1

 

I guess it may be a bug (or I don't understand the new scripting)?

 

In the past, I would call a script with:  "CALL WEAT"

 

WEAT is a DV80 files (contents):

  CLS

  CD TIPI.DEV

  XB WEATHER/TB  (WEATHER IS A TidBit file).

(All the above commands work when typed from the command line in the this version.)

 

Since "CALL" is removed, typing "WEAT" at the $ prompt returns:  "unknown command: WEAT"

CALL WEAT returns "unknown command: CALL"

Am I missing something? or scripting is off-line on this version?

 

My configuration:  (TIPI/32K - rPI zero w)

 

[Omega-TI]

For the first time in a long time, I'm going not going to immediately upgrade.  Things are working perfectly right now, so I'll hold off until the kinks get worked out an there is a reason I NEED to upgrade.