[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Supexec taking one VBL?
The Amiga OS most probably does not *prevent* it (if I understand your
explanation above correctly) but makes it *unnecessary* and the Amiga
programmers are so smart/lazy/disciplined that are not trying to work
with the hardware directly.
Yes, you got it right ;) Generally, Amiga programmers were encouraged to
cleanly program since 1985 -- just because their apps/games/demos then
could work in (multitasking) Amiga OS correctly. Compare to situation
with TOS :)
everything (demo/game) programmers usually need. When this becomes part
of FreeMiNT then programmers might start using it and slowly start
rewriting old and creating new games and demos for FreeMiNT.
You know, problem is the most people don't want to use FreeMiNT as
platform for their demo/game programming -- they can write code as clean
as possible, yes, but you can't force people to write for FreeMiNT
*only*. In such case all the effort would be wasted, there's a very few
guys like me who like to program both demos and applications... most of
them is good with old-fashioned TOS and that's it. We can't just assume
these people switch to FreeMiNT for their democoding. Specially, keep in
mind there's a lot of 030 Falcons, its owners certainly don't want to
install FreeMiNT just to watch a demo...
Another obvious thing (if we want to stay in this sci-fi land for
another paragraph) is that the API must be accessible in other major
systems used on our hardware (TOS, MagiC) so there should probably be a
library that the game/demo programmers ("coders" :) could link or
distribute with their 'products'.
Exactly. And as you suggest, it's very unlikely if not impossible. So
what are the options?
- force demo/game programmers to write two versions of their stuff (no
way, everybody will ignore it)
- make FreeMiNT somehow compatible with current state and just offer, as
bonus, some library with some nice functions. These functions will be
implemented in both ways, for TOS and FreeMiNT. Of course it doesn't
guarantee someone will use it but it's much easier to tell "hey guys,
here's nice lib with this and this functionality, your code will be
compatible with both TOS and FreeMiNT, just include this file and this
binary to your project in Devpac." The problem is how this lib would be
implemented on that FreeMiNT side, see below.
Well, I'd suggest to check the libSDL (www.libsdl.org) - maybe it's
close to what they need. If not then I am afraid it's about 22 years
late for inventing a better XBIOS...
libSDL is already ported and even when we forget TOS compatibility
(which is now 99% I believe) it fights with the same problem -- the
software which uses it must be 'flags -S'-ed just because libSDL needs
to hook on VBL, TimerA, ...
So you say, we will make it compatible with FreeMiNT using that signals
& stuff. But libSDL needs exactly what I needed -- control over
hardware, immediate responses (imagine there's an interrupt for sample
replay and this information will arrive to application using the library
in random intervals, depending on how fast kernel sends / receives
messages).
I've got one idea but you will not like me because it's against
everything what you OS guys like :) Now we have kernel and user space to
guarantee some stability you say. But how looks this stability in
practice? I run some "dirty" program which wants to hook on VBL. I run
it, Memory violation, system halted, fatal error, see ya and reboot your
machine. WTF?! This is that stability?
When you think about it, everything is caused by that separation of
kernel/user space. I was just thinking -- do we (Atari users) really
need it? Yes, it's basic principle of every modern OS etc etc but in
practice? Does it make our life nicer, easier? On the example above I'd
say exactly the opposite. What about just killing this assumption? We
could still keep memory protection (its basic functionality is to report
illegal memory accesses and this works nice now, without full-featured
VM, and it will work with one code space, too). I think AmigaOS works on
the similar basis, just don't care if VBL is system or user, it's just
VBL and period.
P.S. This idea isn't identical to "Let's run everything in supervisor" :)
--
MiKRO / Mystic Bytes
http://mikro.atari.org