[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] libgem16: vs_color
Am 19.01.2010, 09:30 Uhr, schrieb Johan Klockars <johan@klockars.net>:
As Henk said, you should never get an odd stack without there having
I like odd stacks!
I do simplify a couple of things here and there by setting the low bit
of pointers to signify special conditions. In the case of the driver
function that sets palette values, an odd address is used to select a
different way to specify colour values (that is, not using the normal
0-1000 -> 0-max conversion).
Nice ;)
As it happens, I don't think the functionality using the odd address
for the palette is used by the current fVDI. But at least it had a
useful purpose in uncovering what appears to be a MiNT kernel bug.
;-)
Couldn't have been easier to detect :)
So now we finally know why older MiNT kernels had the XaAES pixel
format detect routine working. But how on earth does the kernel end up
giving a process an odd stack?
We'll find this too.
I would not consider allowing for odd stack addresses a fix. If
anything, such should cause a crash early and hard.
Why do 020+ allow them then at all? The people of motorola seem to have
different views.
BTW: Is there any vdi-call that requires the phys-handle except v_clswk
(is this meanwhile fixed)?
--
Helmut Karlowski