You are not logged in. Please login or register.
esxDOS BBS → Development → New NMI handler / .commands
I'm working on a new version...
v009 of NMI.SYS looks good for reaching "final" status to me :-)
One thing I may ask for is: What do you think about possibility to add support for long final names (LFN)? Or do we have to wait for esxDOS v0.9 for this?
Kindest Regards,
Luzie
v009 of NMI.SYS looks good for reaching "final" status to me :-)
One thing I may ask for is: What do you think about possibility to add support for long final names (LFN)? Or do we have to wait for esxDOS v0.9 for this?
Luzie
I think that support for LFN must be in esxDOS kernel, not in NMI navigator.
With the release of version 0.9 and related API, I guess with a few adjustments in the program, I can assemble it with LFN support.
Hard competition on the horizon
https://www.youtube.com/watch?v=qPQow_0C08M
Would be very good if the NMI.SYS could also be used by Gary.
I'm a fan of the +3e system 
Ouch,
see you soon
Günter
Would be very good if the NMI.SYS could also be used by Garry.
I'm a fan of the +3e system
NMI module is independent of speccy mode (48k, 128k, +3), it only depends of esxDOS API. It's esxDOS who will support it. If next esxDOS release support it, NMI module supports too 
May I ask for another thing to add to new NMI.SYS?
Described here: http://board.esxdos.org/viewtopic.php?pid=255#p255 is the problem that COPY command don´t support drive letter. How do you think over adding an option to copy actual selected file (where cursor is) just with one keypress to HD1:?
Hard competition on the horizon
https://www.youtube.com/watch?v=qPQow_0C08M
Would be very good if the NMI.SYS could also be used by Garry.
I'm a fan of the +3e system
Ouch,
see you soon
Günter
Garry released a NextOS File Browser:
https://drive.google.com/file/d/0B_yQO7 … NMM1k/view
https://www.facebook.com/groups/specnex … 777797447/
For esxDOS "Dr Slump / david_ps New NMI.SYS" rulez for me :-)
May I ask for another thing to add to new NMI.SYS?
Described here: http://board.esxdos.org/viewtopic.php?pid=255#p255 is the problem that COPY command don´t support drive letter. How do you think over adding an option to copy actual selected file (where cursor is) just with one keypress to HD1:?
My NMI browser is intended to be able to change the active disk drive, but the tests I have done with the different versions of esxDOS fails: it is not possible to work with a drive other than the sys drive. I'll try to do more testing, but without proper API documentation it's going to be hard.
My NMI browser is intended to be able to change the active disk drive, but the tests I have done with the different versions of esxDOS fails: it is not possible to work with a drive other than the sys drive. I'll try to do more testing, but without proper API documentation it's going to be hard.
Thanks for your answer. Maybe future esxDOS .CP command will also be extended to support file-copying from drive to drive.
Another question on your NMI.SYS: How do you detect esxDOS-Version? Is there an API-Call for it?
Thanks for your answer. Maybe future esxDOS .CP command will also be extended to support file-copying from drive to drive.
Another question on your NMI.SYS: How do you detect esxDOS-Version? Is there an API-Call for it?
In theory there is a call to the API to report the version, BUT all the tests I have done have been unsuccessful.
Actually, I check certain values in certain addresses:
; version msg address
; -------------- -------
; Version: 0.8.0 $00bb (187)
; v0.8.5-DivIDE $00b8 (184)
; v0.8.5-DivMMC $00b8 (184)
; v0.8.6-DivIDE $00a8 (168)
; v0.8.6-DivMMC $00a8 (168)-Are improved SNAps compatible with Spectaculator emulator, please?
Old were not! Was not possible to open them...
-Tip for future improvement:
Add possibility to jump (continue) in ROM on NMI adresse.
I have ovn routine in ROM started by NMI signal and can not to activate, because is not possible to retunr there.
Add item to menu “Jump to ROM NMI routine” or jump there by press CAPS SHIP + NMI when activated or so...
Hello, here is the new version: https://www.dropbox.com/s/lea9c4ixzffl6k7/NMI.sys?dl=0
It can save 48k/128k snapshots, detecting existing files and autoincrementing filename numbering for avoid esxDOS error 18
S-Save snapshot, P-Poke, L-Lock page register, V-View screen (only .scr)
The NMI navigator is able of list directories with 3982 entries, but I limit it to 990
Please test it!!!Luzie, I'm working on joystick navigation. It's not possible use Sinclair 1/2 because it maps key presses (it would be necessary to change the current navigation keys: 0, 5, 6 , 7, 8), but Kempston is possible! I'm working too on rename/delete options, the next version will incorporate them. Finally, regarding to direct starting/loading file, I do not find it useful enough to spend space on it. Can you tell me exactly what you need and find a really useful solution?
Velesoft, your ideas are always welcome, your reputation precedes you. How do I contact you?
-Are improved SNAps compatible with Spectaculator emulator, please?
Old were not! Was not possible to open them...
What happens, if you load them into Spectaculator? Any error-messages displayed?
A great work! Finally we can POKE without complicated workflows :-)
I've been testing the NMI handler and I have some suggestions and something that looks like a regression (at least compared to original NMI.SYS):
1) Sometimes when entering or exiting some of the features as "rename" you get the previous keypress still active, so sometimes after pressing N for rename you get an "N" already typed in the new name, or when trying to cancel rename or poke using break, you get out of the NMI handler as break is read twice. Some way to check break has been released before exiting, and no keys are pressed after entering those handlers would be great.
2) When you scroll down in a long list you need to press right to go to next page. On original NMI handler pressing down on last item of each page would lead you to next page, so you can just scroll down all the way by pressing down. Same for up.
3) I allways found very annoying that after loading a game in the 5th page of scroll for a given folder, when entering the NMI handler again you were back on page 1 of that folder. Would it be possible to stay on same page (and if possible to stay over same item, much better)
4) I don't know how to say this, but the blue splash screen is annoying. Yes, I know it appears just the first time (or after each reset) and I think you should get credit for your work but... would it be possible that you show that screen over the file browser, at the bottom, first time and let it fade out after 2 or 3 seconds? Same credit given, but better UX.
Apart of that, what's the point on 64 columns if only a few are used? Would it be possible to make two columns listing or use that extra space for something (like showin help there).
-Are improved SNAps compatible with Spectaculator emulator, please?
Old were not! Was not possible to open them...-Tip for future improvement:
Add possibility to jump (continue) in ROM on NMI adresse.
I have ovn routine in ROM started by NMI signal and can not to activate, because is not possible to retunr there.
Add item to menu “Jump to ROM NMI routine” or jump there by press CAPS SHIP + NMI when activated or so...
Hi NuClear235, everything depends on esxDOS, NMI.sys is just a piece of code that the kernel of esxDOS calls and that can make use of certain functions (API). There is no way (or I do not know it) to call the original code on ROM. The only thing I can do (in my NMI.sys) is to load a piece of code of 512 bytes in size in an internal buffer an call it.
NuClear235 wrote:-Are improved SNAps compatible with Spectaculator emulator, please?
Old were not! Was not possible to open them...-Tip for future improvement:
Add possibility to jump (continue) in ROM on NMI adresse.
I have ovn routine in ROM started by NMI signal and can not to activate, because is not possible to retunr there.
Add item to menu “Jump to ROM NMI routine” or jump there by press CAPS SHIP + NMI when activated or so...Hi NuClear235, everything depends on esxDOS, NMI.sys is just a piece of code that the kernel of esxDOS calls and that can make use of certain functions (API). There is no way (or I do not know it) to call the original code on ROM. The only thing I can do (in my NMI.sys) is to load a piece of code of 512 bytes in size in an internal buffer an call it.
Calling code while paging out ESXDOS is done via rst $18 this way:
rst $18
dw 45000
(that code is for jumping to address 45000 and restore original ROM at the same time. I've never tested it for calling the ROM but I guess it will work. Also I have never tested within an NMI handler, but it works from a dot command.
Edit: On the other hand, if the NMI handler calls 66h, then DivIDE/MMC will page in ESXDOS ROM again, so calling the original NMI handler is not possible. See notes below.
So if you want to have your own NMI handler, in a custom ROM, it would have to be in some other address (i.e. 69h) and then let NMI.SYS have an option to jump to 69h instead of 66h.
Notes: (quoted from some documentation, I think Velesoft's one)
Memory mapping could be invoked manually (by setting CONMEM), or automatically (CPU has fetched opcode form an entry-point). Automatic mapping is active only if EPROM/EEPROM is present (jumper EPROM is closed) or bit MAPRAM is set. Automatic mapping occurs at the begining of refresh cycle after fetching opcodes (M1 cycle) from 0000h, 0008h, 0038h, 0066h, 04c6h and 0562h. It's also mapped instantly (100ns after /MREQ of that fetch is falling down) after executing opcode from area 3d00..3dffh. Memory is automatically disconnected in refresh cycle of the instruction fetch from so called off-area, which is 1ff8-1fffh.
A great work! Finally we can POKE without complicated workflows :-)
Thanks
I've been testing the NMI handler and I have some suggestions and something that looks like a regression (at least compared to original NMI.SYS):
1) Sometimes when entering or exiting some of the features as "rename" you get the previous keypress still active, so sometimes after pressing N for rename you get an "N" already typed in the new name, or when trying to cancel rename or poke using break, you get out of the NMI handler as break is read twice. Some way to check break has been released before exiting, and no keys are pressed after entering those handlers would be great.
I will try to reproduce the error and correct it in the next version.
2) When you scroll down in a long list you need to press right to go to next page. On original NMI handler pressing down on last item of each page would lead you to next page, so you can just scroll down all the way by pressing down. Same for up.
3) I allways found very annoying that after loading a game in the 5th page of scroll for a given folder, when entering the NMI handler again you were back on page 1 of that folder. Would it be possible to stay on same page (and if possible to stay over same item, much better)
4) I don't know how to say this, but the blue splash screen is annoying. Yes, I know it appears just the first time (or after each reset) and I think you should get credit for your work but... would it be possible that you show that screen over the file browser, at the bottom, first time and let it fade out after 2 or 3 seconds? Same credit given, but better UX.
You're right, I'll correct it in the next version.
Apart of that, what's the point on 64 columns if only a few are used? Would it be possible to make two columns listing or use that extra space for something (like showin help there).
They are intended for long final names (LFN), on next esxDOS release. I was planning to use it for three columns, but LFN is better.
-Are improved SNAps compatible with Spectaculator emulator, please?
Old were not! Was not possible to open them...
The saving snapshot function uses mainly info passed by esxDOS when calls NMI.sys. v0.8.5 has a documented bug that has been corrected in v0.8.6. What the exact problem that you have? I detected problems with active screen bank mapped in 128k mode that produces a black screen after load the SNA.
-Tip for future improvement:
Add possibility to jump (continue) in ROM on NMI adresse.
I have ovn routine in ROM started by NMI signal and can not to activate, because is not possible to retunr there.
Add item to menu “Jump to ROM NMI routine” or jump there by press CAPS SHIP + NMI when activated or so...
I don't have a ROM with a usable NMI routine. I will add code to do a
rst $18
dw $0066when CS are pressed simultaneously with NMI button. You must be test it on next release.
Some roms with NMI routine in the attach at this post here:
http://www.zxuno.com/forum/viewtopic.ph … 6657#p6657
From all the roms in the file, all that include "po" in the name have a very simple poke NMI function (it just waits for you to type in address, enter, then value, enter, and then again addres, enter, value, etc. When you want to get out, just press enter when address should be typed without entering any address.
Some roms with NMI routine in the attach at this post here:
http://www.zxuno.com/forum/viewtopic.ph … 6657#p6657
From all the roms in the file, all that include "po" in the name have a very simple poke NMI function (it just waits for you to type in address, enter, then value, enter, and then again addres, enter, value, etc. When you want to get out, just press enter when address should be typed without entering any address.
rst $18
dw $0066does not work, I think because of the one-instruction delay (http://velesoft.speccy.cz/zx/divide/doc … del-en.txt) used to avoidance of nested NMI. Sugestions are welcomed.
There is some address in the ROM -I can’t remember where right now , where you can find a JP (HL)
Just set HL to 66h and the jump to that address using RST $18.
Anyway, I still belive if that works, DivIDE will page in again and your own NMI routine will be run again.
http://velesoft.speccy.cz/zx/divide/doc … del-en.txt
http://velesoft.speccy.cz/zx/divide/divide-memory.htm
According to the documentation I have been reading, I think that it is impossible to call the NMI handler in the original ROM. The problem is not the one-instruction delay but the inability to disable automatic mapping from code.
The only way is EPROM/EEPROM not present (jumper EPROM opened) and bit MAPRAM cleared. In this conditions, neither of esxDOS / NMI.sys will loaded / are usable.
Yes, calling original NMI code is impossible. On the other hand, all this talk has led me to another suggestion:
What if the same way P loads /sys/nmi/poke file, pressing C (for custom, or any other free letter) loads /sys/nmi/custom only if file exists?
That would allow other people loading custom modules, or even loading a whole new menu that loads itself other modules. That way everybody can create a new handler, and you just would need to explain how the nmi folder files work and their limits (for instance define where they are loaded, how much room is avaliable, how to print text or read keyboard, etc.
The "only if file exists" is important so normal users don't get affected and only those really wanting to load a new "service" can do it.
Yes, calling original NMI code is impossible. On the other hand, all this talk has led me to another suggestion:
What if the same way P loads /sys/nmi/poke file, pressing C (for custom, or any other free letter) loads /sys/nmi/custom only if file exists?
That would allow other people loading custom modules, or even loading a whole new menu that loads itself other modules. That way everybody can create a new handler, and you just would need to explain how the nmi folder files work and their limits (for instance define where they are loaded, how much room is avaliable, how to print text or read keyboard, etc.
The "only if file exists" is important so normal users don't get affected and only those really wanting to load a new "service" can do it.
Hi,
there´s already a Fast-ramp-Function in this new NMI (Key F)) where you can start a user-defined-program.
Key C is reserved for attaching a .TRD-Image to Drive C
Yes, calling original NMI code is impossible. On the other hand, all this talk has led me to another suggestion:
What if the same way P loads /sys/nmi/poke file, pressing C (for custom, or any other free letter) loads /sys/nmi/custom only if file exists?
That would allow other people loading custom modules, or even loading a whole new menu that loads itself other modules. That way everybody can create a new handler, and you just would need to explain how the nmi folder files work and their limits (for instance define where they are loaded, how much room is avaliable, how to print text or read keyboard, etc.
The "only if file exists" is important so normal users don't get affected and only those really wanting to load a new "service" can do it.
This option is possible, the only problem is that the address where the overlay is loaded and the internal functions may vary from one version to another of NMI.sys. It would be necessary to reassemble the module to work on the new version.
On the other hand, C key is in use, we could use the M key for it.
I have patch for ESXDOS for possibility jump to original NMI code in ZX rom, if you hold SHIFT during pressing NMI button.
but work only if first instruction on ZX rom at address #66 is PUSH AF and return incorrect R register. All can be fixed later.
NMI PATCH
;new code for esxdos rom
RET ; 0066 C9
NOP ; 0067 00
LD ($3DF4), HL ; 0068 22 F4 3D
JP $1F4F ; 006B C3 4F 1F
As first I replace one instruction at address #6B
New routine is here:
1F4F: LD A, $FE
1F51: IN A, ($FE)
1F53: BIT 0, A
1F55: JR Z, $1F5F
1F57: POP AF
1F58: PUSH AF
1F59: LD HL, ($3DF9)
1F5C: JP $006E
1F5F: POP AF
1F60: PUSH AF
1F61: LD HL, $0067
1F64: PUSH HL
1F65: LD HL, ($3DF4)
1F68: JP $1FFA
press NMI+SHIFT = return to ZX rom to address #67
without SHIFT continue as original
this new code also cause incorrect value in R register and may need small fix... (add small DJNZ loop which add small delay and fix R)
This is usable in emulators, but on real ZX it need delay before last JP $1FFA. Ideally any loop 0.5 sec...
LD A, $FE
IN A, ($FE)
BIT 0, A
JR Z, $1F5F
POP AF
PUSH AF
LD HL, ($3DF9)
JP $006E
POP AF
PUSH AF
LD HL, $0067
PUSH HL
LD HL,XXXX ;delay value
LOOP: DEC HL
NOP
NOP
LD A,H
OR L
JR NZ,LOOP
LD HL, ($3DF4)
JP $1FFA
This option is possible, the only problem is that the address where the overlay is loaded and the internal functions may vary from one version to another of NMI.sys. It would be necessary to reassemble the module to work on the new version.
Well, if you define how a "custom module" should be then it may work for different versions:
- Max xxxx bytes
- Relocatable (no absolute jumps/calls, no absolute address reads/writes within the code)
Also, maybe you can set HL to base load address so the code in the module, if really to use absolute jumps/reads can automodify its code before running it.
Yes, all that is complicated, but opens a door for new developments for every user (think on debuggers, patchers, etc.)
esxDOS BBS → Development → New NMI handler / .commands
Powered by PunBB, supported by Informer Technologies, Inc.