Fast cluster allocation in Nextor: reviewers/testers needed!

I can’t review the code but I wonder about what happens if the partition and as such FAT is modified ‘outside’ Nextor’s view. I mean I take the card/hard drive to a PC and do some modifications. Could this cause issues when the drive is in the MSX again?

I left github so I can't comment there, sorry.

I wanted to note that this:

is actually a necessary step and does not mean the algorithm has a flaw. It's perfectly possible that a cluster chain contains a cluster with a number lower than the first one in the chain.

Consider this scenario:

Entry index: 2   3   4   5   6   7   8   ...
FAT Content: 0   0   0   0   0   0   0   ...

Create file1 with 1 cluster:

Entry index: 2   3   4   5   6   7   8   ...
FAT Content: EOF 0   0   0   0   0   0   ...
Directory pointers:
file1 -> 2

Create file2 with 2 clusters:

Entry index: 2   3   4   5   6   7   8   ...
FAT Content: EOF 4   EOF 0   0   0   0   ...
Directory pointers:
file1 -> 2
file2 -> 3

Delete file1:

Entry index: 2   3   4   5   6   7   8   ...
FAT Content: 0   4   EOF 0   0   0   0   ...
Directory pointers:
file2 -> 3

Extend file2 by 2 clusters:

Entry index: 2   3   4   5   6   7   8   ...
FAT Content: 5   4   2   6   EOF 0   0   ...
Directory pointers:
file2 -> 3

Now file2's chain contains a cluster with a number lower than the first one, therefore when deleting file2, if UD_ACLU is initialized to the first cluster in the chain (cluster 3), there will be a free cluster with a lower value (cluster 2) which must be considered as the disk becomes fuller.

Whether it's worth checking for the lowest cluster in the loop that frees a cluster chain, instead of always taking the first one, I leave up for you to decide. It's not usual that files are extended, which is the only scenario I can imagine where that can happen.

And that's it! v2.1.1 alpha with the improved cluster allocation implemented. Please get it and give it a try! (as this is a significant change in how data is written to disk, please backup your data first, or use test data).

By the way, i succesfully built standalone driver with Konami SCC mapper, flashed it to spare flashrom, and use it together with Sharksym's MMC/SD - and it improved file copying so much. Even though MMC/SD itself is the DOS2 device, it works nicely with standalone Nextor, i removed executing OKEI's FAT16 driver from autoexec as unnessessary now

So far works great, thank you Nestor!

PS building took some effort because provided Makefile has troubles running on Linux due to lowercase/uppercase filenames thing, in Windows a.dat and A.DAT are the same files but in Linux they aren't, and cpm32 programs generate fies in uppercase while all deps in makefile use lowercase names. crazy thing, i eventually had to reboot to windows to actually do that, got tired with trying to fix quite big makefile...