Jump to content
Lorin Millsap

Major updates coming in next emulator release

Recommended Posts

I’m not posting this as an official update announcement as it’s not finished but wanted to whet your appetites. Also big shoutout to @Michael Steil and @Frank van den Hoef. Frank wrote the main driver which was way faster and more complete than the old one and Micheal extended its functionality. The next emulator release has major improvements to the DOS for the SD card filesystem. The main ones are:

A lot of progress has been made with the X16 DOS. It's almost feature complete, and almost has feature parity with CMD floppy and hard drives.

• Long filename support

• You can open files for reading (OPEN2,8,2,"FILE") or for writing (OPEN2,8,2,"FILE,P,W"), read and write data, have four of them open at the same time, etc. etc.

• Overwriting files is done with "@:".

• You can copy files (DOS"C:BACKUP=ORIGINAL"), concatenate files (DOS"C:ALL=FILE*"), all with wildcards.

• You can rename files (DOS"C:NEW=OLD").

• You can delete files (DOS"S:R*,Q*").

• You can lock/unlock files (DOS"L:R*" or DOS"F-L:R*"/DOS"F-U:R*").

• Like on CMD devices, create directories (DOS"MD:DIR), delete them (DOS"RD:DIR), change them (DOS"CD:DIR).

• You can use paths everywhere (DOS"C//BACKUP/:FILE.TXT=FILE.TXT", DOS"$//BACKUP/:A*")

• All commands and paths support drive/media numbers (DOS"$1:*"), but only 0 (current) and 1 (only supported partition) work.

• You can get partitioning info (DOS"GP"+CHR$(1)) like on CMD hard disks.

• You can even read/write DOS memory and execute code in a DOS context (M-R, M-W, M-E). Yeah, not that useful.

• All error messages on the status channel (just type "DOS") are consistent with 1541/1571/CMD drives, e.g. 01, FILES SCRATCHED,05,00 etc.

What's missing:

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

• Show/change disk name.

• mkfs (N)

• fsck (`V')

• timestamp support

What's missing that I'm not sure should be added:

• REL files

• block read/write API

Sent from my iPhone using Tapatalk

 

  • Like 14
  • Thanks 1

Share this post


Link to post
Share on other sites

The keyboard (and mouse) driver is being improved and yes there are a couple ideas bouncing around on that but the most prevalent is to set the driver to have two modes. The main default mode works like the setup we have now. Then the RAW mode pushes the actual RAW PS/2 data to the buffer instead of the interpreted codes. So to see if a certain key is being pressed you need only check the buffer. However that code hasn’t been written yet as the dev team has been very busy on other projects.


Sent from my iPhone using Tapatalk

  • Like 2

Share this post


Link to post
Share on other sites

Great news! Thanks for the update. Will this build include a fix so that the banked area of memory $A000-$BFFF can be saved to a file?

Share this post


Link to post
Share on other sites

Sweeeeeet.  This is just awesome.  I've put sequential files on hold until OPEN was supported.

Of course, now I'm just enjoying loading binary data straight into RAM banks!   But being able to save small pieces of data will certainly be welcome!  

Thank you!

 

Share this post


Link to post
Share on other sites
Posted (edited)

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

Also, to be compatible with the CMD hard drive and SD2IEC, the left arrow should usable as backpaths. Specifically, it should be syntatically identical to the ".." in Unix or Windows. 

"cd ←" should go up one directory, as should "cd .."

CMD did not allow for embedded backpaths, so LOAD "←/file_in_parent.prg" does NOT work on a CMD drive. I'm not sure about SD2IEC, but it generally uses the same syntax as CMD hard drives. 

Here is a shot of the CMD hard drive manual, showing usage of the left arrow:

image.png.fb070a35b75df32a7668ee09c0df831f.png

https://www.lyonlabs.org/commodore/onrequest/cmd/CMD_Hard_Drive_Users_Manual.pdf

Subdirectory command start on page 68, or 9-17.

*** edit 8/17 - the first manual I read apparently had missing text, due to a poor PDF conversion.

Edited by TomXP411
changed Copy info.

Share this post


Link to post
Share on other sites

Very valid points. Making it MSDOS like May seem more familiar but will break compatibility with legacy IEC devices which is a design goal even if that doesn’t resonate with everyone. So I think these are excellent points to bring up and any mistakes do need to be corrected.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
35 minutes ago, Lorin Millsap said:

Making it MSDOS like May seem more familiar but will break compatibility with legacy IEC devices

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.

Share this post


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

 

Share this post


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

Share this post


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

Share this post


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

 

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
Posted (edited)
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?

Edited by Andre
add link to rel file testsuite

Share this post


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

Edited by BruceMcF
  • Like 1

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.


×
×
  • Create New...

Important Information

Please review our Terms of Use