Mensajepor mcleod_ideafix » 25 Mar 2014, 16:31
While you are on that, I'm seeing something weird here...
DIVMMC / DivIDE traps allow the CPU to read the first byte of the trapped address from the main ROM (during the M1 cycle), and then, while in the refresh period of the current M1 cycle, ROMs are switched and the following bytes are read/executed from the ESXDOS ROM. At least, this is what I read from VELESOFT docs and others.
This works, at least with the Sinclair ROM. But I've just seen something funny: traps at $0000, $0038, $04C2 and $0562 (RESET, INT IM1, SAVE, LOAD) replicate the same byte of instruction that is present in the Sinclair ROM, so these traps would work either if I map ESXDOS during the very M1 cycle, just before reading the byte (which would be read from ESXDOS), or if I map it after the byte is read, during the refresh cycle. Either case, the byte read is the same.
Traps at $0008 and $0066 (ERROR, NMI) are different: the NMI trap has a RET instruction at address $0066 in ESXDOS ROM. This is, as I read, to avoid nesting NMI petitions that might trash the stack. As the ESXDOS ROM is mapped in after the byte from $0066 is read, the first time $0066 is reached, the NMI handler is executed because the byte read and executed from address $0066 is not RET, because it has been read from the main ROM. If during its execution, an spurious NMI signal is triggered again, it will execute $0066 again, but this time from ESXDOS ROM, which has a RET instruction at this address, returning inmediately to where it came from. So, for $0066 trap, it's not the same if I map ESXDOS in during the M1 cycle or during the refresh cycle. It has to be mapped in after the byte has been read in the M1 cycle.
And, finally, for the $0008 trap: this trap begins with a multibyte instruction, which is LD HL,($5C5D) (store current value of CH_ADD pointer into HL) in the Sinclair ROM (and SE Basic IV), and a totally different instruction in ESXDOS: JP $0985
If I map ESXDOS during the refresh cycle, as I'm doing now, the instruction read by the CPU is: LD HL,($0985) ... which doesn't make sense, as $0985 is an address within the first 8K, so it's ROM, so its contents cannot vary.
But if I map ESXDOS during the M1 cycle, before the first instruction is read, the instruction executed is JP $0985, which may have sense.
It can also make sense if I decide to map ESXDOS in, not during the refresh period of the current M1 cycle, but at the beginning of the next M1 cycle following this. In other words, if I map ESXDOS in after the current instruction is completely read and executed.
Well... after this tech chitchat, what I'm going to try is to change the DIVMMC module so traps at $0000, $0008, $0038, $04C2 and $0562 will cause ESXDOS ROM to map inmediately, as it is being done with TRDOS traps, while the trap at $0066 will cause a delayed ESXDOS mapping in as it is currently being done.
EDIT: changed, not worked neither with the Sinclair ROM, nor SE Basic IV.
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista
OpenSE Basic 3.1.2 does the same things as SE Basic IV.