Theory time! Lets assume that you can a basic OS entry point and that z80 means ez80 or z80. Your entry point just jumps into a C void main(){...} function and ISR(s) use a lookup table placed at RAM block* 1 to see where they jump to.
Lets say that you have a Lua bytecode interpreter in C capable of running Lua 5.3 bytecode. Just the interpreter and some C interface to it, no compiler or such. Lets also supposed you have basic modules in C for Lua. Some of the built-in Lua modules and also a low-level library that allows port access and also access to CPU-specific features (shadow registers, stack, direct memory access, port access).
At the same time, you have a memory allocator that divides memory pages into blocks of a certain size (maybe 256 bytes) with the start of the memory (block 0) containing a map of allocation ID to block ID as well as a bitmap for block locks and counters for lock frequency. You can allocate block(s) of memory, they'll get placed on some memory page. When you want to access allocated memory, you lock the ID, get a fixed pointer, manipulate the memory, then unlock the ID. Behind the scenes, locking finds the page that the memory is on. If the page isn't swapped in, it swaps the page in. The memory block is moved to a page that isn't getting swapped out routinely (there will be one bank where locks are disallowed). The blocks are marked as locked and a pointer is returned. So long that the lock is held, that memory will always be there**. Unlocking removes the lock. More fun things happen, like swapping out infrequently used memory blocks to other pages when not enough memory is available and such.
The Lua core can run bytecode, has a memory allocator, has low-level modules and some common ones. Still hopefully on the first flash sector, there will be a root FS (read-only) (maybe multiple!) that stores the kernel and other Lua/data files. The kernel sets up ISRs and starts loading kernel modules. Filesystem early on is loaded by the kernel, rootfs is mounted, and modules start to get loaded from the FS. When enough modules are loaded, the rest of the flash gets mounted. From there, some init system starts running as the first process and starts launching lua code to start up the calc.
With Lua, you'll have a tree of Lua states, stemming from the kernel down through child processes/threads. Lua kernel will multitask these states based on interrupts or blocking kernel calls.
Good thing about this is that with only the low-levels needing to be in assembly, the kernel can get ported to different platforms.
As you can probably see, ISRs need to get handled. And, well, nearly everything is in Lua. An IRQ kernel module would contain the platform-specifc blob to handle passing the event to the module and interrupting the kernel to run the required handler(s).
Just a thought
Lets say that you have a Lua bytecode interpreter in C capable of running Lua 5.3 bytecode. Just the interpreter and some C interface to it, no compiler or such. Lets also supposed you have basic modules in C for Lua. Some of the built-in Lua modules and also a low-level library that allows port access and also access to CPU-specific features (shadow registers, stack, direct memory access, port access).
At the same time, you have a memory allocator that divides memory pages into blocks of a certain size (maybe 256 bytes) with the start of the memory (block 0) containing a map of allocation ID to block ID as well as a bitmap for block locks and counters for lock frequency. You can allocate block(s) of memory, they'll get placed on some memory page. When you want to access allocated memory, you lock the ID, get a fixed pointer, manipulate the memory, then unlock the ID. Behind the scenes, locking finds the page that the memory is on. If the page isn't swapped in, it swaps the page in. The memory block is moved to a page that isn't getting swapped out routinely (there will be one bank where locks are disallowed). The blocks are marked as locked and a pointer is returned. So long that the lock is held, that memory will always be there**. Unlocking removes the lock. More fun things happen, like swapping out infrequently used memory blocks to other pages when not enough memory is available and such.
The Lua core can run bytecode, has a memory allocator, has low-level modules and some common ones. Still hopefully on the first flash sector, there will be a root FS (read-only) (maybe multiple!) that stores the kernel and other Lua/data files. The kernel sets up ISRs and starts loading kernel modules. Filesystem early on is loaded by the kernel, rootfs is mounted, and modules start to get loaded from the FS. When enough modules are loaded, the rest of the flash gets mounted. From there, some init system starts running as the first process and starts launching lua code to start up the calc.
With Lua, you'll have a tree of Lua states, stemming from the kernel down through child processes/threads. Lua kernel will multitask these states based on interrupts or blocking kernel calls.
Good thing about this is that with only the low-levels needing to be in assembly, the kernel can get ported to different platforms.
As you can probably see, ISRs need to get handled. And, well, nearly everything is in Lua. An IRQ kernel module would contain the platform-specifc blob to handle passing the event to the module and interrupting the kernel to run the required handler(s).
Just a thought