Dunno... there is Veronika, there is F7, Bob's XL accelerator and probably others.
What would be nice is for an existing one to get a high adoption rate at an affordable price.
Throwing more in muddies the waters and makes it harder for those already out there.
And as nice as it'd be to have a cartridge with 200 MHz RISC which can run it's own program and present the Atari with near unlimited objects mapped to memory that Antic just displays and the 6502 can run a kernal for colour and PM changes - it just becomes a case of the Atari itself becoming a peripheral of something bigger.
Has Phaeron (amplified by Rybags) not already fully described the reason behind this issue?
Precisely. The problem and cause has been described. And it was a known issue which the Setup.com program actually warned you about (though it doesn't tell you exactly why).
Device handlers, hardware etc. have little/nothing to do with it. It's all down to the buffers running into workspace which happens to corrupt the filespec that's used during copy and probably some other operations as Phaeron described earlier.
Case closed. There's absolutely no point arguing or complaining about it. It is what it is.
In any case, if you're a "power user" who needs to use 3 or more drives at a time, Atari's DOS 2.x is about the last thing you should be using.
Throw away the training wheels and use SpartaDos instead.
.dumpsnap command issued from the debugger console.
.dumpsnap Create bootable snapshot image
Create a bootable snapshot image from the current simulator state.
.dumpsnap [-u] <path.atr>
-u Disable compression and use uncompressed blocks
Records hardware and memory state to a disk image with a loader that
restores the state on boot. The snapshot image contains the base 64K
of memory and requires a 128K system to boot (the extra memory is
used by the loader). The loader attempts to reconfigure the hardware
to match the snapshot state and then resume the running program.
Not all state is restored precisely and load success depends on the
exact state and program code. For best results, the same OS ROM
should be used, no cartridge should be present, and the snapshot
should be taken at the beginning of the NMI handler for the vertical