Re: [MiNT] libgem16: vs_color

[Johan Klockars <johan@klockars.net>]

>> A odd stack always is the result of a corruption.
>
> There's nothing corrupted. Odd stack-values seem ok, but not for at least

As Henk said, you should never get an odd stack without there having
been some kind of corruption. And as has also been pointed out, an odd
stack would cause an immediate crash on a 68000 (where word and long
word accesses must always be aligned or you'll get an address error on
use).

> fvdi, because it does something like:

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).

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.
;-)

>> And a corrupted stack causes massive mayham very quick.
>
> Everything is working except the one (f)vdi-call.

Everything will be running at a performance penalty. And on a 68000 not at all.

> It gets the stack from the kernel. I changed to the trunk-MiNT (ozk-MiNT
> does also) and everything is even. The ozk-XaAES now detects pixel-format

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?

> also. So it's all up to using the right kernel (or a fixed fvdi).

I would not consider allowing for odd stack addresses a fix. If
anything, such should cause a crash early and hard.

/Johan