[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GEMDOS from VBL
First a rather fundamental question:
Do you really need the VBL at all for Clocky under MiNT?
>From what I could see in the documentation for Clocky (I don't use it
myself), all you need is a way to periodically write things to the screen.
For that you could use the MiNT timer calls (whatever they are called) and
then your problems would disappear (since you could have Clocky running as
a normal process).
> a little update of my previous message: calling Malloc(-1L) from VBL
I haven't looked that much into the MiNT code, but it is by no means
obvious that all parts of GEMDOS should be reentrant. After all, MiNT
doesn't multitask once supervisor mode is entered and the original OS
code is still used for some things.
I'd imagine quite a few semaphore locks would be needed to make sure all
data structures stay consistent. To protect against a normal interrupt
handler (which MiNT doesn't know anything about), MiNT would even have
to disable all interrupts, which definitely isn't something you want with
ordinary memory allocators for example.
A quick look at the 1.12.4 sources didn't show any protection around
the memory allocation code, but I might have missed something.
Still, Malloc(-1) could probably be used without fear, since it shouldn't
update anything.
> obviously works, but returns 0 (which is probably correct for TSR after
> it terminated). The trick Julian has suggested with DSetpath("U:\PROC")
If you really are using the VBL, I don't see how MiNT could know what
program the code was originally part of so, if anything, the Malloc(-1)
should be treated as if it came from the application that was running
when the interrupt occured.
As was said before, OS calls from interrupts are often a very bad idea.
> and Dfree('U') behaves very strangely, though: it returns numbers from
What should that call return anyway? The same thing as Malloc(-1) or the
total amount of free memory (such as you can get by looking through the
allocation list)?
--
Chalmers University | Why are these | e-mail: rand@cd.chalmers.se
of Technology | .signatures | johan@rand.thn.htu.se
| so hard to do | WWW/ftp: rand.thn.htu.se
Gothenburg, Sweden | well? | (MGIFv5, QLem, BAD MOOD)