ESXDOS in the ZX-Uno hardware: NMI not working.

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:
LD HL,($0985)

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?

Thanks

Thanks for the info. Andrew Owen is working now to try to fix the issues btw ESXDOS and SE Basic IV.

Today, while I was trying the create-snapshot feature of the NMI handler, I've come with an issue. ESXDOS detects whether the machine is a 128K or 48K one, and generates the SNA file accordingly, but for 128K snapshots, the last byte written to port $7FFD is kept in the SNA so it must be somehow known. As this port cannot be read back in an original 128K machine, how does ESXDOS to figure out its value? Does it use a software approach, or does it use some kind of hardware feature of DIVMMC (for example, a port that keeps a copy of the byte written to port $7FFD) ?

Thanks!

I've discovered that my issue has nothing to do with port $7FFD. However, the snapshots I'm getting when I use the "S" command from inside the NMI handler are not being loaded by Spectaculator. It claims that the snapshot has some feature it cannot emulate (??). Specemu loads them but it reports a Pentagon 128. Sometimes when I create the snapshot, in 128K mode, I get an ERROR 18, but the next time, I can create it.

Browsing the SNA with an hex editor, I've just seen that the byte at offset 49182d (TRDOS mapped in flag) has the value 02h, when it should be 00h. After changing that, Spectaculator no longer refuses it. Of course I haven't used TRDOS at all.

Awesome - this thread answers some of the questions I had re: ESXDOS rom page-in/out conditions.

I'm implementing ESXDOS and DivMMC on ZX Prism

Just wiring up the MMC sockets to the FPGA at the moment; I have the ESXDOS ROM on-chip and thanks to this thread I should have the logic I need to page it in and out configured soon!

Looks like I'll have to give the DivMMC implementation 128K of memory then? ZX Prism's got 512K right now, so sharing 128K of that with DivMMC isn't going to be a problem.

Anyway, thought you'd like to hear about another piece of hardware using ESXDOS - I may have some questions later!

Cheers

Jeff Braine
http://zxprism.blogspot.com.au/

Hi Jeff,

I can't help you much with the hardware side of things, but the DivMMC is basically a DivIDE with MMC replacing the IDE bits, and with access to 128k->512k of SRAM instead of 32k. Checkout the original DivIDE documentation as it should help you: http://baze.au.com/divide/files/pgm_model.txt

JeffB: I must correct myselft a little bit.

there are 2 types of entry points on divide. first type is like i wrote, reading first byte of instruction at entry point from zx rom and other bytes from divide eeprom/ram. second type is when divide maps its memory before reading of first byte of instruction, so whole instruction is read from divide ram, it is for compatibility with trdos system. and there is also one type of exit points, which maps back zx rom and they behave similar as entry points of first type, when cpu reach exit point, it reads first byte of instruction from divide ram and if it is multibyte instruction, the rest is readed from zx rom.

entry points of 1st type are: 0h (reset), 8h (print error msg), 38h (im 1), 66h (nmi), 4c6h (save to tape) and 562h (load from tape)
entry points of 2nd type are every byte of 3d00h-3dffh
exit points are from range 1ff8h-1fffh

there is also conmem bit of control byte, which connects divide eeprom/ram immediately when set