Re: [MiNT] Supexec taking one VBL?

["Miro Kropacek" <miro.kropacek@gmail.com>]

> First, XBIOS must be fixed. Miro kind of volunteered to write that and
> implement it in the MiNTlib. It obviously belongs to FreeMiNT directly.
More precisely, I was thinking about mintlib (or libSDL, this doesn't
matter now) wrapper which will branch according to FreeMiNT's presence
-- i.e. call kernel API for FreeMiNT and fall back to Super() /
Supexec() for the rest.

> With fixed XBIOS there is no need to access the hardware registers
> directly, not even from a VBL-like interrupt (of course the fixed XBIOS
> or new YBIOS or however you name it would be fully re-entrant and would
> work from interrupts, if needed, though might not be needed at all, see
> below).
This is very good note (about the re-entrance), I spent week in
hunting what's wrong with my routines and then I realized it's the
XBIOS call called in the "improper" place.

>
> Second, Miro wanted to change certain things (like background color) at
> the moment when the ray running in the cathode is turned off and slowly
> moving from bottom right corner to the upper left (try to imagine it on
> your new LCD :-). This is traditionally called a VBL, Vertical BLank.
> But please note Miro's backcolor changing routine does not need to be
> called from within the very hardware interrupt - it would be enough if
> the FreeMiNT sent an awake signal to his routine when the VBL occurs,
> and sort of guaranteed that context switch occurs quickly enough so that
> the routine waiting for the signal is executed at the right time (while
> the screen is in the blank).
>
> Does it make sense?
Actually, non-hardware VBL (exception / interrupt handlers in general)
is quite cool idea! After reviewing all my VBL and timer handlers I
couldn't find reason why this couldn't work (setting the palette,
resolution, video ram, swapping replay buffers, ...) except one
exception: HBL interrupt. This happens on every scanline (in the worst
case) and there's no way we could use any system-related routine
(because every cycle counts). Question is if this is really such bad
since we're talking mainly about 060 targeted stuff. Personally, I
never needed anything in HBL to be done.

So, is this Petr's idea technically realizable? I mean, there must be
very short time between the state "XX int signaled" and "XX user
handler entered". For VBL maybe isn't such complicated but events like
TimerD (300 Hz for example) certainly conflicts with regular task
preemption...

Btw I'm really happy we're moving somewhere :)

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