Hello!
Yes, writing driver is easy but imagine the instruction for running the demo -- before you run my demo, please copy this xdd to freemint's sysdir, reboot, run my demo and pray it doesn't kill your system. If so, I'm sorry for next reboot :)
Even if we builtin something into the kernel, your instruction is: if you don't have FreeMiNT version XXX running, please install it first before running this application.
Maybe this isn't such bad idea in general but I can't imagine how this could work for custom handlers, i.e. every demo/game coder would want to use his own specific code in VBL. And even when we find a way how to do it, we're back in the beginning -- such coder could write bad (leading to crash) code which will take whole kernel down and this is the current situation with Super()-ised democode.
The problem is that you don't have an application, you write a demo and you need full control over some parts of the hardware system.
The hardware system is normally managed by the operating system, and, ideally, the user space applications don't have any access to the hardware [and, much much better, the applications are protected against each other through the MMU]).
This means that only the the parts of the operating system have access to the hardware [for example, the hard disc driver is also part of the operating system].
That means there is no 'clean' way to access the hardware, except the one over the operating system.
It's nice that you like to write clean and FreeMiNT friendly demo applications. I really appreciate this and like to help as I can. For lot of things this is easily possible without lot of work or overhead.
But running a part of your userspace application inside the operating system violates the rules. Even if we design a new system call we will end up with something like Super/Supexec or whatever (maybe with some more protection and checks, but if your handler crash you crash the system).
[ Btw. Super/Supexec and friends are from the (modern) operating system design absolutely bad things, they allow user space application to enter privileged mode and getting full control over the system. This is ok for TOS (designed 30 years ago). For FreeMiNT it makes the life much harder. Imagine what a stable system you get if you a) forbid Super/Supexec and so on and b) always run with memory protection enabled :-) You only loose some compatibility to lot of existing applications ;-) ]
Regards, Frank -- ATARI FALCON 060 // MILAN 060 ----------------------------- http://sparemint.org/ e-Mail: fnaumann@boerde.de