Re: New NMI handler / .commands

david_ps wrote:

Uto,There's not empty space, all room is used. And code execution is always in one direction: from low addresses to upper addresses, lower alignment it's the only relevant

Well, I don't pretend the code to run backwards of course, I'll try to explain in different way.I don't exactly know how it works internally as I can't see the code, but I belive you face two issues here:

1) The modules/overlays use routines in you main code, so if those routines change their position, any call made by the module code is affected.

2) The main code (everything that is not the overlays) has different size each version, so overlay area may start at a different address each version.

The first issue is easy to solve, if you have a limited number of avaliable functions, just make NMI.SYS have a vector list at the beginning of your code:

Now module author , in case he needs to call readKey press can get the address from vector table:

LD HL, (Vectors + 2)
CALL Caller

The adventage is vector table is allways located at same address, so modules writer can easily get to the functions. The disadvantage is you have to use some room for the vectors tables and for the initial JR and the JP (HL).

Of course you can still make direct calls in your own overlays, as you will recompile them all, but any custom overlay, or any replacement of your modules (i.e. replacing hexview as you said) may use the vector table.

The second issue is the overlays are probably loaded at different address depending on NMI version, cause depending of main code size, the overlay zone starts at a different address.

Ok, lets suppose, as I don't have the real values, that the NMI.SYS code loads at address 1000 (decimal), and can take 2000 bytes, so last address you can use is address 2999. Let's imagine also the space reserved for loading modules/overlays takes 200 bytes, from 1800 to 1999. It is like that cause the main code takes up to 1799 in this version, but it may change in next version, cause you can change main code and then it may end at 1788 or 1920.

Ok, at this very moment, when you load the "delete" module, it is loaded at address 1800, and then you jump to 1800 to run it. When you load the "reset" module it´s loaded at 1800 too, then you jump to 1800.

My proposal is the main code does not load the modules at 1800, but at 2000 - <module size>, and then you jump to 2000 - <module size>. For instance if you load a module whose size is 100, instead of loading it at 1800 and jump to 1800, you load it at 1900 and jump to 1900. If the module size is 120, you load it a 1780 and jump to 1780.

The adventage of this approach is module writers, included custom module writers, know its code will be loaded at 2000 - <module size> no matter which version of the NMI handler is running. If you load them all at 1800 like you do now, then every new version. That way the know exactly at which address they would be loaded, and you don't have to recompile them every time a new version appears.

I hope I have explained it well this time.

PS: There are places in the 48K rom were a JP (HL) can be found, so maybe you can save that byte. Not sure though as not sure if that part of the ROM is paged when executing NMI.SYS.

Re: New NMI handler / .commands

david_ps wrote:

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.

I'll check later, but if that config file exists, would you mind providing its format? I may do an utility for changing the avaliable settings :-)

Re: New NMI handler / .commands

Hmmm... Don't know if it's only me but with last version I can't delete files (you press E, a "Deleting" message appears but nothing happens) nor poke (you press P, you type in the address, press enter and you cannot type anymore, only break to get back to menu)

PS: I can delete from basic prompt so it's not a write protection issue. Also, I have deleted the whole NMI.SYS and NMI folder and installed again from 0.1.15 zip file.

PS2: Nevermind, it's fixed, I installed your rm dot command and it started working, anyway if the nmi menu relies on it I think ut should be included in the package. About poke, it was my bad, I forgot how to use it.

Re: New NMI handler / .commands

Uto wrote:

PS2: Nevermind, it's fixed, I installed your rm dot command and it started working, anyway if the nmi menu relies on it I think ut should be included in the package. About poke, it was my bad, I forgot how to use it.

Launch NMI navigator, press P, enter up to five digits to decimal address, press ",", enter up to three digits to decimal value, press Y to apply poke or any other key to discard.

Re: New NMI handler / .commands

Uto, the main problem of the table of vectors is the space occupied. Navigator functions, GUI functions and Overlay system add about 60 functions. 60 functions x 2 bytes/vector = 120 bytes, it's a lot of space. There is very little space for NMI navigator code and eficient and compact code is not relocatable, I'm sorry.

Re: New NMI handler / .commands

david_ps wrote:

Uto, the main problem of the table of vectors is the space occupied. Navigator functions, GUI functions and Overlay system add about 60 functions. 60 functions x 2 bytes/vector = 120 bytes, it's a lot of space. There is very little space for NMI navigator code and eficient and compact code is not relocatable, I'm sorry.

Oh, I see, they are just too many, I din't think there were that much :-)

-f ignore nonexistent files and arguments, never prompt-i prompt before every removal-r remove directories and their contents recursively-d remove empty directories-v explain what is being done-? display this help and exit

Re: New NMI handler / .commands

I have one idea. Add to NMI support for possibility show also other picture formats than SCR.Browser may detect files with lenght 6144 and 6912 bytes and both show as screen.Files *.IMG or .SCR with length 13824 bytes (2x 6912) show as interlaced screen (gigascreen, hi-res picture,etc..)Files with lenght 12288 (2x 6144 bytes) show as Timex multicolor or Timex HI-RES screen.I don't know if exist any fileformat for ULA PLUS pictures....