Incompatibilidades Churrera y DivMMC

[Turrican]

I´ve talked with Velesoft and the NMI is not from him but from a friend of him - UB880D (or DUSKY).

Yep! I said the author is a guy I don't remember his nick, but I remembered that Velesoft knows him. That is why I said I would contact the author "via" Velesoft (through Velesoft), which is what you seem to have done already

Sorry for my misunderstood!
Let´s wait UB880D.

[velesoft]

Hi. Where is problem ? Any link to problematic games ? Theoretically I can make unofficial patch...
Can help loading games on DIVMMC direct from 128kB menu ?

[velesoft]

Miquel Guereiro planned support starting esxdos to 128 menu, but it's not so easy, because exist too much versions of zx128 roms (original zx128,zx128+2 spanish,zx128+2 english,....). Divide/DIVMMC memory automatic mapping is designed for 48rom only. 128basic rom is different and incompatible with this mechanism.

ESXDOS may run snapshots with running 128 basic or with 128menu on screen. Only is impossible write basic commands because 128rom use own syntax controll routines and esxdos crash...

[Turrican]

Hi Velesoft!
There is a game here: http://www.worldofspectrum.org/forums/d ... 1/car-wars
The original TAP file doesn´t work with DivMMC but there is a patch here that works: https://mega.nz/#!ZVhhWRyD!p2dmeJGMbDfd ... taR9ia6yFk

What I understood: if you can make a patch that makes a POKE 23388,16 before the load of a game using NMI menu, this problem will not occurs.
Why I don´t know... it´s to mcleoad_ideafix to say. something related to USR0...

[mcleod_ideafix]

I will try to explain the present issues of ESXDOS:

ESXDOS forces the machine to boot straight into USR 0 mode. This is not bad. You still have access to 128K memory, AY, etc.

However, there are games that load blocks into different memory banks. To do this, they have to page in each bank, load something in it, then go to the next page, and at the end, jump to the start of the game.

To change the bank to page in, the loader should issue an OUT to port 32765, but this port is write only, so most of them use the value of sysvar BANKM as a starting value. They do something like this, for example to page in bank 4

Código: Seleccionar todo

ld a,(BANKM)
and 0f8h
or 4
ld (BANKM),a
ld bc,7ffdh
out (c),a

This works well provided that BANKM (at 23388) has a value that match the one presently stored in register 7FFDh, but ESXDOS changes that value and doesn't update BANKM. And even if it would do, the normal 48K reset procedure that is called after ESXDOS initialization would reset BANKM again, as it falls under the printer buffer area, which is zeroed as a part of the initialization routine.

What if a loader uses BANKM and this is set to zero? Well, that would mean that the moment the loader issues an OUT with the updated value (as in the previous code), ROM 0 (or ROM 2 on +2A/+3 systems) will be paged in, losing the BASIC runtime, the loading routine, etc, resulting in a hang or reboot.

Fortunately, we know that the value ESXDOS writes to 7FFDh is always the same: 10h. So the idea is to give loaders that same value. This is why we do a POKE 23388,16 just before doing a LOAD ""

This procedure works for almost all games that present this issue. There are some others that don't work even with the POKE. These games usually have their loaders written in BASIC and rely on the system interrupt handler to perform the actual OUT. While in 128K BASIC, the maskable interrupt handler reads the value at BANKM and out's it to port 7FFDh, so to page in a certain bank, say bank 4, one just have to do a POKE 23388,16+4: PAUSE 1 (to ensure an interrupt happens before going on with the rest of the program). These games will need a true 128K environment in order to load.

Ideally, the NMI.SYS routine should check whether it is running on a 128K machine or +2A/+3 machine, and after mounting the tape, page in ROM 0 writting to appropiate registers and jump to a point in which the loader has just been called from the start menu. That is, it should do something similar to what Carmeloco program does.

Not so ideally, but easier to implement is that NMI.SYS pokes the memory address at 23388 with the value 16 just before jumping to the point in ROM 3 which the loading is initiated.

[velesoft]

Currently we can use this:
1) jump to NMI menu and select TAP file via key " i ".(select TAP file without reset)
2) and now load from NMI menu 128 menu with automatic loading: http://velesoft.speccy.cz/zx/divide/sof ... ivide).zip

[Uto]

Currently we can use this:
1) jump to NMI menu and select TAP file via key " i ".(select TAP file without reset)
2) and now load from NMI menu 128 menu with automatic loading: http://velesoft.speccy.cz/zx/divide/sof ... ivide).zip

The problem is neither of these solutions are automatic, so the average user that only wants to play that game, and lacks technical skills, don't read retro forums too much, etc. just finds that game not working and either skip it or post in forums saying "this game doesn't work with DivIDE". Despite the many forum posts, tutorials, etc. talking about doing that POKE before loading game, this issue is recurrent and comes back every now and then. Sadly, it seems that loader described above is used by a ZX-Spectrum game engine "La Churrera" used by many games developed during the last 5-6 years.

So far is clear this is not an ESXDOS fault, but software fault, but the question is if ESXDOS may be changed to stop this bleeding of posts about ESXDOS incompatibilities (sometimes described by extension as DivIDE/MMC incompatibilities, Zx-Uno incompatibilities, and probably soon as ZX-Next incompatibilities, though neither of those are actually true).

Asking developers to patch heir games is possible also, but is not possible for them all, and it's difficult to get rid of non-patched tap files avaliable in many sites.

[velesoft]

Or modify DIVMMC memory paging in ZX-UNO.
- if is active 48 rom, then zxmmc memory mapping is without change/same.
- if in ZX128 is set 128editor rom (rom 0 on port 7FFD) then you must disable/ignore some DIVMMC mapping points...

Exist also next way - use modified ZX128 rom for compatibility 128 rom with ESXDOS: http://www.worldofspectrum.org/forums/d ... ent_685860

[mcleod_ideafix]

Or modify DIVMMC memory paging in ZX-UNO.
- if in ZX128 is set 128editor rom (rom 0 on port 7FFD) then you must disable/ignore some DIVMMC mapping points...

I was going this way, but I saw that ESXDOS uses a callback RST to call standard ROM routines from within ESXDOS, then I assumed this was going to fail. How could I achieve it?
- If a ROM other than ROM 3 is in use, should I ignore trap at 0000h? I can't, because this is when ESXDOS initializes, detects the SD card, etc.
- But if I let ESXDOS to initialize, it will page ROM 3 in so I won't be able to return to ROM 0 after ESXDOS initialization (when it jumps to address 0001h to resume standard initialization) so besides modifying the hardware, I should have to patch ESXDOS, shouldn't I?
- Let's say I let the trap at 0000h to happen and ESXDOS is modified to not force the ROM to ROM 3. Then, the machine performs ESXDOS initialization, followed by the standard 128K initialization, but while in ESXDOS initialization, it uses routines (for example, PRINT-CHAR, RST 10h) from ROM 3, which is not paged, as we haven't paged ROM 3 in. How can I fix this?
- Let's say this is fixed too. Then, when NMI is triggered, the trap at 0066h should not be ignored no matter what ROM is active. The NMI handler uses stndard ROM routines as well AFAIK, so we are in the same problem as when performing ESXDOS initialization. Does NMI.SYS need to be patched too?
- I understand that the only traps I don't active while in ROM other than ROM 3 are LOAD and SAVE traps, and possibly, TRDOS traps (possibly?)

As you see, it's my understanding that just enhacing the paging mechanism of DivMMC to enable some of its traps only for ROM 3 doesn't solve the issue... or am I wrong?

[velesoft]

DIVMMC use old memory mapping from DIVIDE interface. DIVIDE is originally designed for 48 rom only then use fixed addresses for maping points. Some points are unused in 128rom (rom 0) but is possible make compatible divide system with 128 rom. See my FATWARE 128. True, mapping area for tr-dos is used for compatibility with 128 rom and is impossible support tr-dos emulation, but in fatware system is it O.K.
ESXDOS support TR-DOS emulation via mapping area #3D00-#3DFF then is impossible call syntax controll in 128basic. 128 editor rom use own syntax controll and can't be used esxdos commands, only standard LOAD/SAVE/VERIFY.
If we need full compatible device with all ZX models, then must be used this features:
- add different rom+ram DIVMMC memory for each different zx rom type/page. If zx128 set rom 0 then also DIVMMC must switch to different memory with different mapping points and code... Only this is true correct way. And for ZX128+3 use 4x different DIVMMC memory. Each ZX model/zx rom (zx48,zx128,zx128+2,zx128+3) need different DIVMMC code and number of pages/blocks. For 128basic must be writed new mapping point at begin of syntax controll routine and after detection esxdos syntax jump to syntax controll in 48rom instead return with error to 128 basic.

After init esxdos must system jump to 128rom from address 0 instead using OUT 32765,16 and jump to reset.