Hi, I know this isn't exactly a solution to the problem, but it might be a workaround:
By using ab HDD cache, you can spare the DOM more often.
So there will be less likely a situation in which it gets being overburdened.
On the other hand, though, a HDD cache like SmartDrive usually costs precious conventional memory.
Luckily, the Helix Multimedia Cloaking package has one SmartDrive alternative included that doesn't take up much conventional memory (it uses Extended Memory).
The cloaking manager and compatible utilities once were sold but sometimes also bundled for free with other software, like mice driver software.
If that's not being an option, there is still Central Point PC-Tools (v7 etc), which comes with a tiny HDD cache that's still smaller than SmartDrive.
Maybe it will do good enough.
Edit: This is just an idea, of course. No one is forced to try this.
It just came to mind, because the IDE HDDs of my youth/childhood usually featured a "sector cache".
The cache was about 64 KB in size, sometimes smaller.
It was intended to make sure that the HDD didn't require multiple revolutions to read a whole sector.
In addition, these HDDs also had a debug port on the PCB.
By attaching a serial cable (TTL levels, not RS-232 levels !), it was possible to read the data of the HDD's on-board computer.
Example:
https://stason.org/TULARC/pc/hard-drives-hdd/ … -SL-IDE-AT.html
By contrast, CF cards do have a very little cache (1KB, maybe 2KB), if at all.
It's more of an i/o buffer, though, as with a serial port.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//