[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Supexec taking one VBL?



Hi Frank,

at first, topic-unrelated question: is there any problem with the patches I sent here some days ago? (-lsocket fix and hypview compilation).

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.
Well, from my experience, there's no need to gain access for everything. The most visible stuff is timer / interrupt handlers (this is really no way without flags -S) and then some Videl setting (changing video ram, correct store/restore of videl regs, fast palette setting). For example, controlling DMA sound is quite nicely done, IIRC I didn't use one single hardware access for sound in both Quake and Duke3D. Another story is DSP access, for 030-based demos this is real must to access it directly. But my goal was more oriented to 060 / Aranym applications.

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].
This is good note, for example the stuff related to double buffering etc is done by OpenGL drivers, i.e. in hardware. But since we have to care about it in software, it's quite a problem because everybody wants to use his solution, there's no need to adapt to one single API etc.

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 ;-) ]
Oh yes, I'm aware of that. I'd like to find some compromis -- it should be something very easy to implement and what's even more important, totally hidden for programmer who wants to run his app also under TOS. Probably some mintlib call wrapper could do this but question still is what to do with that handlers... For example, on Amiga is quite nicely done -- the OS supports exactly this, you define your function, the parameter it should take when the function is called (the most usable is some pointer), call something like registerMyVblHandlerDefinedByThisStructure() and here we go. It's managed by OS but user can define what he wants.

--
MiKRO / Mystic Bytes
http://mikro.atari.org