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

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:

Start jr RealStart
Caller        JP (HL)
Vectors           DW waitKey
                  DW readKey
                  DW clrScr
                  DW ....
RealStart  ....    ;Main Loop goes here
...
...
waitKey LD A, ... ; Code of each function here
....
readKey SRL ... ; Code of the function here
....
....
....

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.

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.

Format of nmi.cnf (currently 6 bytes):
addr 0 (byte): flag to control splash screen. 0-skip splash screen, anything else, show splash screen.
addr 1 (byte): default left key. 08h (CURSOR LEFT).
addr 2 (byte): default right key. 09h (CURSOR RIGHT).
addr 3 (byte): default down key. 0Ah (CURSOR DOWN).
addr 4 (byte): default up key. 0Bh (CURSOR UP).
addr 5 (byte): default intro key. 0dh (ENTER).
---
Next release:
addr 6 (byte): flag to control OUT 255, (0). 0-skip OUT, anything else, do OUT.

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

Cool! Very useful! Thanks!
I'd like to ask... how about the README in the custom distribution? The one that would explain how to make/use a custom module?

Hey David, just sent a PM, not sure it arrive, please let me know!

New release of dot command, rm, v0.2:
https://www.dropbox.com/s/tm1dm75q0az04qt/rm?dl=0
Corrected a bug that did not allow deleting files with hyphens in the name.

rm v0.2 By Dr. Slump 2018

Usage: rm [OPTIONS]... [FILE]...

Remove the FILE(s)

-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

Dear david_ps

how about adding .ownrom option to load .rom-Files via your NMI.SYS?

.ownrom listet here: http://board.esxdos.org/viewtopic.php?pid=338#p338

Regards,

Luzie

Hi,
if .ownrom is used then Allram-Mode is switched, right?
Is a return to ESXDOS still possible?
Bye for now,
Günter

After small patches in software is very easy possible switching between more systems/roms, etc... No problem.

OK. Does this mean, even BS-DOS 3.09 can be bootet from? (divIDE, or divMMC too?)

I can release small routine for switch between systems on DIVMMC.