New NMI handler / .commands (Page 10 of 16)

It's possible to use a dot command for it, there're more room for code and data. On the other hand, we must be careful when using certain functions of the ROM and the esxDOS API that do not work without a correct BASIC environment, for example when we have a game loaded. I will keep it in mind for future NMI navigator releases.

As far as I know, it only allows access / modify the date and time via dot command. If you intend to modify the date and time of the files, it is only possible to do so if the esxDOS API implements it. At the moment I have not found any function that does it.

Thanks! I´ll try!

From which path is MON loaded? I copied it to \bin but on pressing G i get esxDOS Error 5 (="No such FILE or DIR")

It´s there (and can be manually run with .mon), but I get this Error 5.

I will try on real hardware or look further whats wrong...

Should be an error with my script with creates a .HDF-File for testing on Emulators.

I have just tried new NMY.SYS version with Nextipede game, a game using Timex HiColor mode, cause a I had a terrible feeling after reading changelog, and my feeling was confirmed:

That OUT 255,0 Velesoft asked for - not sure why - is not a good idea in my opinion. That OUT sets normal video mode, but if you try to use the NMI menu while playing a non standard video mode game - to poke or to make an snapshot for instance - the menu will be ok, but when you get back to game the screen mode is lost. So unless you find a way to determine which mode was active before the menu is called to restore it before returning to game - which I belive is not possible - I don't think that OUT should be there.

At least in the previous versions you could poke and save snapshots, even if the NMI menu was not well looking, but now those games cannot be saved or poked properly anymore.

Velesoft, if you can point out the reason behind your request maybe I change my mind, but at the moment to be honest I only see bad effects on that OUT.

Note: I've tried Nextipede in ZX-Uno, that does also support Timex Modes.

PS: it also affects any games using bank selector to use by the horizontal MMU in Timex machines and ZX-Uno, or screen in shadow RAM, what implies at least one in development I know.

AGD games and problems with graphic modes

Now AGD support also Timex graphic mode (hardware multicolor with attributes size 8x1 instead 8x8). Graphic modes are switchable via writing to port 255. On real Timex computers is port 255 also readable, but on real ZX is port 255 used for synchronisation screen in some games. SLAM PLUS ula replacement add Timex graphic modes to original ZX computers, bus port 255 is here only for writing. As I know, then is impossible read back which graphic mode is set. Next problem is graphic incompatibility with other interfaces as DIVIDE/DIVMMC, etc... All original ZX software and ZX hardware (with own systems) is designed for original ZX graphic mode. If AGD game set multicolor mode and you jump to NMI menu i system ESXDOS, then multicolor mode is set and browser is bad visible thanks to different attributes positions.

Here is result:
- for full compatibility (only visual problems..) must system before own screen access (if need original ZX mode, for example for show file browser) use OUT 255,0 for set standard ZX mode.
- if system also support return from own menu/browser back to game/program, then don't need any next modifications, but if AGD game is designed for run in multicolor mode then must always set multicolor. Not exist any correct way for 100% software detection which graphic mode is set, but AGD may eliminate all this problems if set multicolor graphic mode after each interrupt. Then after return from ESXDOS filebrowser will game set always correct GFX mode.

Short result:
- add OUT 255,0 after jump to NMI code
- add OUT 255,xx (multicolor) at begin of interrupt code in AGD games.

Velesoft: the ULAplus specification allows for an alternative method to read back the contents of port 255. See here: https://faqwiki.zxnet.co.uk/wiki/ULAplus . SLAM probably already implements that.

ZX-UNO doesn't implement that port mirroring yet, but does implement proper port 255 read when Timex MMU is enabled.

Hi Velesoft,

In my  opinion NMI handler should be transparent to games and since that OUT 255,0 it isn't.  I understand your intention was making the NMI handler be always visible without strange effects due to attributes position, but that solution is interferring with the game itself, what should be against any NMI handler, and I think the remedy is worse than the disease.

Yes, you can patch games, but it's a very bad idea having to patch games cause that was added to NMI menu. Most people won't ever find your patched version of Nextipede, nor will even realize a patched version exist for this or any other future games, if any patch does ever exist for future games.

Also, is not only about graphic mode, that OUT 255,0 also clears bits 0 and 7, what may change the video RAM active and also the MMU paging. Imagine a game has the proper game screen in shadow RAM (bit 0 = 1) and an inventory at normal video RAM (bit 0 = 0), when you get back to the game, inventory would be main screen!

Really, I belive that OUT 255,0 is a very bad idea unless you can read the port before, and then set it to same value it was before exiting. As it seems that is impossible for many devices, including I'd rather remove that OUT 255,0 from the NMI handler, or at least make it optional somehow.

Is that possible DrSlump? (making that out optional, like having a settings file)

I belive the standard should be making the port readable at hardware level for all devices, or any standar mode to get the current configuration. A "good practices" standar only becomes a will, you depend on developers who first must follow the standard - what for sure won't happen always - and then they need to have time in each interrupt to "refresh" the graphic mode, which for some games may be as simple as sending an OUT, and for other games may imply checking first which video RAM option was selected, or if MMU bit was on/off, what may lead to longer interrupt routine, what is not always possible, specially in Timex modes where you have to write almost twice more information per frame than in normal mode.

I know is late for hardware solutions, if SLAM ULA does not support it, and unless SLAM ULA contains some kind of CPLD that may be rewritten, but IMO it's better to fix that in hardware (real Timex computers already support it, ZX-Uno does not completely but most probably is possible, and it should also be possible as well on Prism, Next, and whatever other clone to come). So if we talk about standars, I'd rather go the hardware way, not the software way :-)

On the other hand, any hardware standard may be expanded to include other modes as the radastan mode from ZX-Uno and other non standard modes like those on Prism, ZX-Evo, Next, etc.

Hi, it's possible to control execution of OUT (255),0 by a flag on nmi.cfg. Please edit byte 0 of nmi.cfg and change value 0 by 1 and load NMI navigator It's possible to do something similar for the OUT instruction.

This is due to the internal structure of the NMI navigator:

+---------------------------+
| Init code                 |
| Main loop                 |
| Exit code                 |
+---------------------------+
| Navigation functions      |
| GUI functions             |
| Overlay system            |
+---------------------------+
| Data area                 |
|    ...                    |
|    Overlay buffer         |
+---------------------------+

I can put Overlay buffer after Init code, just before Main loop, but the problem persists.  For example, all code related to OUT instruction is in Init code area.