Z80 in Protected Mode

[jopil]

Hello. Recently I became aware of the following video where the Andy Hu guy presents a clean n' neat  method for achieving full protected-mode operation on a Z80 build. It would  be helpful to many if the builders of this forum make their comments and  suggestions on this approach/technique. Thanks, John

https://www.youtube.com/watch?v=DLSUAVPKeYk

[Tadeusz Pycio]

Creative use of the NMI signal to achieve protected mode. I think a better solution to this problem is to use the Z280 which has a built-in user and system mode, and an MMU tracking access. The very idea of using a Z80 for this task is interesting in concept.

[Douglas Miller]

Interesting, but I'm not sure how new the idea is or how practical. You can't base your OS on CP/M because the NMI vector at 0066H is in the middle of memory defined for use by the OS and user programs. Or else you need more sophisticated circuitry to such that the NMI is able to save the PC in the user memory stack and then switch to kernel memory to execute the code at 0066H. Then there's the problem of the IORQ signal also being active during interrupt acknowledge and how that might impact handling of it for trapping user program I/O.

I also believe this has been done before, but I can't point to a specific example off hand. It's probably forgotten to time because the effort was not practical or marketable. The basic idea of using NMI to "virtualize" I/O is not new. Heath used it on their H89 computer to "simulate" certain hardware that only existed on the H8 computers (access to certain I/O ports caused an NMI, the ROM code then analyzed and performed the equivalent operation). This feature, of course, had to be abandoned for CP/M since 0066H is in an area reserved by CP/M.

[Mark T]

The youtube video seems to be a lot longer than it needed to be for the information provided which makes it awkward to revisit the points raised. A project posted on hackaday or github would be better, but I guess doesn’t provide for any possible revenue. I only watched it once so may have missed something.

As Douglas already mentioned, timing of memory bank switching so the return address is saved to user stack and retrieved from user stack seems to be missing. It should probably also block some instructions to prevent user programs changing interupt status or mode or from manupulating the stack. Fetching interupt vector from system memory before saving pc to user stack would be complicated. It might be possible to capture the interupt vector from the hardware and then have system software determine the target address, but that might be a bit slow.

[Alan Cox]

There are a bunch of cheats for some of it. Eg If you reimplement
interrupts using the NMI line and an interrupt controller you don't
have to worry about DI/EI (or you have an NMI watchdog - either
works). You pin some bytes of memory as ROM so that you cannot fill
all 64K with a prefix and hang the CPU. You can not rely on the DRAM
refresh to avoid LD R, attacks.

It's also not actually essential to handle SP on the NMI switch
because you can check if the SP is nonsense in the handler and kill
the offending task, providing you don't let it scribble into protected
space initially. IoW the timing of the switch cycle during the
exception is critical.

The 65C816 one I did is a bit simpler because the processor provides
some small helpers. It's a flip/flop for user/kernel mode. The
kernel->user direction is done by an I/O, and the user->kernel
direction is handled by the vector pull line (on Z80 you'd have to
spot an ifetch from 66h and a syscall of some kind). When in user mode
IORQ is simply not generated so I/O ops just do nothing. The MMU
mapping is also reset by the VP so the kernel mode gets a possibly
invalid SP but a known good mapping. NMI is driven by a watchdog that
counts cycles whilst the CPU is in user mode and NMIs if it stays
there too long (meaning it's blocked interrupts, etc) so that the task
switcher can recover.

For a Z80 it's not in theory much more complicated other than the 66h
ifetch and timing stuff. We don't use memory refresh in RC2014 so
continually loading R won't crash the system which was one of the
other corner cases for old setups.

Alan

[jopil]

Tadeusz, Dag, Mark & Alan, thank you very much for your assessments on this issue. Andy seems to be new in the making of tech-videos but this video's information content I thing makes it  worth viewing, apart from the fact, that Z80 issues been considered today by ages like that of Andy's, maybe signs a Z80's "eternal life". 
All the best, John