Commander X16

12 hours ago, Cyber said:

As far as I understood @TomXP411 did not mean to break compatibility with IEC. Rather he proposed to make design be somewhat compatible with both IEC and CMD. Not all commands will work in both standarts anyways, so it would be just some compatability.

In re-reading Lorin's original post, I think the parent path symbol was not even mentioned. So I just wanted to get a note in there early. Obviously, the current convention is to use .. for the parent path, but since CMD went a different way in the 80s, I think a conscious choice needs to be made whether to support the CMD syntax, the DOS syntax, or both. I think the CMD syntax is most appropriate, since the machine will have an IEC port and so will work with SD2IEC and CMD hard drives. But I can also see people who have never used an SD2IEC or CMD drive being confused by the lack of "..". So having both work is probably the smartest choice. 

 

On 8/5/2020 at 10:37 PM, TomXP411 said:

The correct CBM-DOS syntax for renaming a file is "R0:New_Name=Old_Name". Copying a file is similar, but without the R in front: "New_File=Original_File" or "0:NewFile=0:Original_file" 



 

That's not correct. A command always starts with a command, in case of copying a file, it's "COPY" (or "C" for short). So it should be "C:New_file=Original_file", or even concatenating multiple files: "C:new_file=old_file1,old_file2,old_file3"

2 hours ago, Andre said:

That's not correct. A command always starts with a command, in case of copying a file, it's "COPY" (or "C" for short). So it should be "C:New_file=Original_file", or even concatenating multiple files: "C:new_file=old_file1,old_file2,old_file3"

You're correct. I went back and looked at another PDF version of the manual, and the C0: was there. So The first one I found apparently had a missing letter. 

I also tried it on VICE with a stock 64 ROM. The C is definitely required. 

OPEN 15,8,15, "FILE2=FILE1" gives an error. 

OPEN 15,8,15, "C:FILE2=FILE1" works as expected. 

On 8/17/2020 at 4:19 PM, TomXP411 said:

You're correct. I went back and looked at another PDF version of the manual, and the C0: was there. So The first one I found apparently had a missing letter. . 

We’re the fans and we get it mixed up.  All the more reason for the wedge shortcuts like CMD or whatever is preferred, in my opinion!  The mental load is not worth TYPICAL usage!

 

r38 has been released and contains the new "CMDR-DOS" features when you use the emulator with an SD card image.

 

Also, the following features are now included:

• 
  Open file for appending (,P,A).
  


• 
  Show/change disk name.
  


• 
  mkfs (N)
  


• 
  timestamp support
  

It still doesn't do

• 
  block read/write API
  

because I need to think about what API should be implemented. The Commodore one is very limited. And there's a better sd2iec-specific one.

And I don't plan to implement:

• 
  validate/fsck (V)
  


• 
  REL files
  

as these features are not very useful.

Regarding REL files, I used them VERY heavily back in the day, as that is how my C64 fig Forth based system did BLOCK files.

But there isn't anything to be gained by pursuing that for the xForth system, because with the High RAM, I can just allocate one or more high ram segments as a "first stage" buffer, and break block files into pieces sized to load into the buffer in one go. Most BLOCK file usage is fairly sequential, so two segment buffers per user will give good performance with individual blocks copied to 1k buffers in low RAM ($8000-9BFF is seven available buffers with one user task, six with three user tasks).

As far as block access, all I need for a much more efficient INCLUDE of script files is 128, 256 byte or 512 byte sequential access loaded to an arbitrary target address. Then complete lines can be interpreted in place, and incomplete lines can be copied to the beginning of the buffer and the next chunk loaded directly after them. My buffers are the same 1K buffers used by blocks, so anything more than 512 byte segments wouldn't be of much use to me.

 

On 8/28/2020 at 10:28 PM, BruceMcF said:

Regarding REL files, I used them VERY heavily back in the day, as that is how my C64 fig Forth based system did BLOCK files.

But there isn't anything to be gained by pursuing that for the xForth system, because with the High RAM, I can just allocate one or more high ram segments as a "first stage" buffer, and break block files into pieces sized to load into the buffer in one go. Most BLOCK file usage is fairly sequential, so two segment buffers per user will give good performance with individual blocks copied to 1k buffers in low RAM ($8000-9BFF is seven available buffers with one user task, six with three user tasks).



As far as block access, all I need for a much more efficient INCLUDE of script files is 128, 256 byte or 512 byte sequential access loaded to an arbitrary target address. Then complete lines can be interpreted in place, and incomplete lines can be copied to the beginning of the buffer and the next chunk loaded directly after them. My buffers are the same 1K buffers used by blocks, so anything more than 512 byte segments wouldn't be of much use to me.



 

The REL file handling in CBM DOS is fairly buggy. You have to work around a number of special conditions. (edit: see e.g. the test suite https://github.com/fachat/XD2031/tree/master/fwtests/relfiles )

But maybe you want to create a REL file driver for the high RAM?

On 8/30/2020 at 6:31 PM, Andre said:

The REL file handling in CBM DOS is fairly buggy. You have to work around a number of special conditions. (edit: see e.g. the test suite https://github.com/fachat/XD2031/tree/master/fwtests/relfiles )



But maybe you want to create a REL file driver for the high RAM?

No, the advantage of REL based BLOCKS was the ability to get random access to a 1K BLOCK quickly, because evern with the glacially slow 1541, loading a 1K BLOCK when a block buffer needed refilling was tolerable when editing different BLOCKs. When compiling a set of BLOCKs, you could go and make a cup of coffee and read a magazine article, because there was also room on the disk to save an image of the resulting system, so you didn't have to do it every time you needed to compile a set of BLOCKs. The direct-sector BLOCK file approaches were moderately faster, but you had to swap between BLOCK disks and normal disks, because the Commodore 1541 DOS would of course happily trash direct sector blocks that it thought were free sectors.

The advantages of the REL file approach outweighed it's awkwardness in a C64 with a stock 1541

But with the CX16, the advantages of the REL approach are rendered negligible, while their awkwardness remain. It's far cleaner to chop a set of BLOCKs into 8K or 32K chunks. ".BLK" chops up into .B00 .B01 .B02 ... .BFF, for 256 chunks, or a 4MB block space with 8K chunks, a 16MB block space with 32K chunks. And each chunk will load quite fast enough from the SD card to not really notice BLOCK buffering and replacement. It promises to be so fast that I don't mind double buffering, with my actual BLOCK buffers in Low RAM, to get the freedom to use High RAM for other things as well  -- holding the name dictionaries and holding code modules.

Edit: __________________________

xForth will in any event be using the "split it up" approach to .BLK files, with 8KB chunks, because there is going to be an xForth for the Commodore64, "x64th", and it will load the chunk file directly into the space underneath the BASIC ROM, $A000-$BFFF. So the word that juggles between dictionary and block High RAM segments in xForth will simply make sure that the BASIC Rom is turned off in xForth64, but their "chunks from the block file" data will be loaded into and saved from the same place in the memory map.

x64th have two BLOCK/BUFFERs, since one can write into one BLOCK and set it to be preserved, and write into another BLOCK and set it to not be preserved, so while using separate buffers requires double RAM movements, it eliminates redundant SAVEs of the edited chunk file. The minimum block buffer is one, but two is handy for reducing repeated RAM copies between chunk buffer and block buffer. Also a "group copy" of a chunk to a different part of the block space, such as copying a standard starter template for a type of wordset or database, can be done by just saving it under the appropriate new ".Bxx" name.

xForth will have two consoles tasks, with any other User tasks headless background tasks, but x64th will have only console, so with the data stack at $9Fxx, console user variables at $9Exx, and the various console buffers at $9C00-$9BFF, the blocks/buffers are at $9400 and $9800 and the top of free dictionary space is $93FF. xForth64 modules will be 4K modules loaded into $C000-$CFFF. Since blocks are optional in any event and you can get by with one block buffer if you need to, if xForth64 wants to start multi-tasking User tasks, the User pages will be taken from the 2K Block/Buffer space, so up to 8 background tasks are possible, and up to 4 background tasks are compatible with retaining use of one block buffer.

So code that fits x64th will always fit xForth, but the reverse will not always be true.