mateuszviste
commented
1 month ago implemented a dynamic buffer of up to 64K (minus 16 bytes) to speed up COPY operations and limit the amount of diskette swaps. The number of swaps is very much limited now, but still 8 swaps are necessary (versus 2 on MSDOS). This is probably because SvarCOM performs a couple of checks before the copy on both src and dst. I will have to look at this some more.
More importantly, this exhibited another issue, presumably related to the EDR kernel: https://github.com/SvarDOS/edrdos/issues/120
Copying a file from A: to B: on a single-diskette system makes EDR asks the user to swap the diskettes a LOT of time to copy a 20-or-so KB file. Under MS-DOS only one swap is required.
I think this is related to the size of the buffer used by COPY. SvarCOM uses a 4K buffer, so it is able to copy 4K from A: into memory, then tries to write it to B: and that's when EDR catches the write request and asks to swap the diskette. Then SvarCOM tries to read the next 4K from A: -> swap again. etc.
Instead of using the common BUFFER used by all SvarCOM subcommands, the COPY operation should probably try to allocate its own, short-lived buffer as big as possible, and use the common 4K buffer only as a fallback if dynamic allocation fails.