Please tell me if you run into any more issues.
Yep! The NMI problema has been sorted out. ZX-Uno DIVMMC implementation now uses 128K RAM.
I'm dealing with some weid behaviour regarding ESXDOS and SE Basic IV (Andrew Owen open source Spectrum ROM). Watching ESXDOS code and Sinclair ROM code, I'm wondering if traps work the same way in DIVMMC and DivIDE.
I mean: from DivIDE docs (and thanks to VELESOFT) I know that traps at $0000, $0008, $0038, $0066, $04C2 and $0562 cause ESXDOS to be mapped in after the current M1 cycle (actually, during the refresh cycle of the current M1 cycle) so the first byte at the trapped address is read from the main ROM, and the following ones, from ESXDOS.
This makes sense, for example, for NMI trap, as this behaviour ensures clean operation of NMI avoiding nesting NMI petitions (the byte at address $0066 in ESXDOS is C9 - RET - ) so a nested NMI call would return inmediately. The first NMI call would not return because the first byte read from the main ROM at address $0066 is not RET.
But... for the rest of traps, I see that all of them, except trap $0008, have the same instruction that is present also in main ROM. Trap $0008 is funny, because the instruction at $0008 in the main ROM is a multibyte instruction: LD HL,($5C5D), while in ESXDOS is JP $0985: a totally different one.
If I follow the same mapping logic with this trap, the instruction read and executed by the CPU would be:
Which doesn't make sense, does it? $0985 is an address from the first 8K, which is ROM at the moment of executing, so its contents don't vary.
So... does DIVMMC use the same trap logic as DivIDE? (delayed mapping, during the refresh cycle), or does it map ESXDOS at the beginning of the next instruction (not byte) following the current one, or does it map ESXDOS inmediately for all traps except the NMI trap?