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.