jgharston wrote:Coming to this late, but...
unplug_table = &39F/&3A0 - what ROMS should be unplugged
You may as well use locations that other ROM managers use for an unplug bitmap.
Remember, I wrote that ROM in the 90s. Who says that "D6E/D6F" is properly usable memory? That would seem to be very dependent whoever had the NMI space not using memory that high. I picked locations the AUG claimed were unused.
extended_osbyte = &3A4/&3A5 - Old extended OSBYTE vector
This is part of saving BYTEV, WORDV, WRCHV and RDCHV, and you're using it because there's only three SPAREV vectors which you've stored WORDV, WRCHV and RDCHV in.
Do you need to be chaining WRCHV and RDCHV? Does your code absolutely have to continue via anybody else who may have happened to have claimed WRCHV and RDCHV? If not, that's what UnVectoredWRCH and UnVectoredRDCH are for. Instead of jumping through hoops to daisy-chain along previous claimants, if you know that your code is going to be the final claimant, exit by jumping to NVRDCH at &FFC8 or NVWRCH at &FFCB.
My ROM isn't the final claimant. I intercept these calls to ensure the right memory bank is paged in (WRCHV so printing is sent to the screen, rather than the shadow bank; RDCHV so the cursor COPY reads from the screen and not the shadow bank). I do bank switching, call the original routine, then bank switch back again. I wanted these routines to work as transparently as possible, so chained. Probably 99.999% of the time I could have just done a JSR to the NV versions... but I wanted to be better than the original Solidisk ROM that broke lots of things.
That just leaves you with srdata_status, ramdisk_present, status_byte. The SRAM utilities that live in the DFS ROM steal 18 bytes from the DFS's private workspace at (&0DFX)00. Somewhere I noted down where the Master keeps the SROM/SDATA flags.
Which won't necessary work with Solidisk DDFS or OPUS DDOS or other ROMs.