Topic: Custom ROM and NMI reentry on space address.

The ROM does not have basic in. Assuming an NMI fails as I can't even trace where the "pop af" happens in the spaghetti. I think the "rst 38" and "rst 10" is sorted. If using assembly calls to the routines.

I'm kind of assuming the NMI does not do a return to $67 to exit, and uses some BASIC routines. I think switching to the ROM after boot, does allow a "jp $000a" at $0008, for "rst 10" access to raw assembler esxDOS calls.


Re: Custom ROM and NMI reentry on space address.

So I'm assuming the characters at end of ROM need to be there.

The calls all go through a ram springboard so paging the 48 ROM back in is a last resort before calling (with some clobbered variable space in ram).

It really doesn't solve knowing which basic routines and sys vars are the minimum set for functioning NMI.


Re: Custom ROM and NMI reentry on space address.

Very specifically NMI z80 load/save snapshots.

The boot 128 likely goes fine (48 ROM) then a development z80 loads.
This will bank to the other ROM (128 editor replacement), and clobber quite a few things.
EsxDos calls can be handled ok.
An NMI will bank, and apart from conservation of push and a pop af at the 67 location the goal is to do what I need while supporting the space exit and snapshots for a form of load save.
I could make the NMI be a crash unlucky but it would be easier to preserve a little of the ROM intent to clean accept an NMI.

Things I know the NMI must do:
Print characters. (A JP vector).
Get keyboard (a JP vector).

While the z80 development is loaded dot commands are not of interest.
As stable button save is the goal. With load ok too.

Ok so the fact the port (128 edit ROM) banking is not readable ... Might limit snap saves, although that's one clobber address where basic stores it.



Re: Custom ROM and NMI reentry on space address.

Writing a custom ROM that works with esxDOS is seriously non-trivial. I've done it. You're welcome to examine the source (https://github.com/source-solutions/sebasic4). You can't store code in the area normally occupied by the character set because calling it will invoke the hardware TR-DOS traps.