If I remember correctly, Supexec() sends a signal to the caller. This signal is later detected by the kernel and turned into a call in supervisor mode. But - correct me someone if I am wrong - this needs the entire scheduler turn to send and receive a signal, so this is probably the cause of your problem.
Thanks for the explanation. I've seen something like that in source code comments but your explanation has made it clear. All at all, it doesn't make my life easier ;-)
I was thinking about implementing some new functions into mintlib, just for working with VIDEL -- for example correct Vsetmode(), something more flexible than Vsetscreen(), user vbl handler and so on... it's not that hard (for freemint we can do it using that Ssystem()? call and for singletos we can use standard asm routines for this purpose which are well tested and widely used).
What do you people think? For example, it would be really cool to have it implemented in such way that program using that vbl handler wouldn't need to be executed as supervisor protected (you know, flags -S program_name), it would improve stability a lot. But I'm not sure how it could work, as far as I know, such user vbl has to be in supervisor memory and something like allocSuperMemory(), copyHandlerCodeHere(), executeHere() isn't probably the best way :) (isn't this functionality more or less what linux's mmap() does ?)