Re: [MiNT] libgem16: vs_color

["Helmut Karlowski" <helmut.karlowski@ish.de>]

Am 19.01.2010, 01:22 Uhr, schrieb Henk Robbers <h.robbers@chello.nl>:

> A odd stack always is the result of a corruption.

There's nothing corrupted. Odd stack-values seem ok, but not for at least  
fvdi, because it does something like:

f(short *x)
{
if( x & 1 ){
	x &= ~1;
	do this
}
else{
	do that
}
]

> And a corrupted stack causes massive mayham very quick.

Everything is working except the one (f)vdi-call.

> To find the place where the corruption occurs you must
> look at many more places.
>
> Move addresses of local variable to a static array and look at these at
> a later convenient point. At some point you can dump the array to disc.
>
> Use dumparray[n] = &var where n is a constant unique for each move.
> Make sure that the assignment is as simple as possible
> e.g. lea An,d(sp)  move.l An,dumparray+(n*4)
>
> The stack will NOT get odd by pushing a byte by -(sp)
> on normal 68K.
>
> Only a direct move or a add/subtract of a odd number can do that.

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  
also. So it's all up to using the right kernel (or a fixed fvdi).

Maybe that it's not intentionally set to an even value, if so someone will  
have to force it to be so.

But surprisingly it worked well with the odd stack.

> PS
> In the 20+ years of atari computing I never encountered a odd
> stack without very quick crashing after rts.
> Always more corruption then only becoming odd.

Never saw any crash - XaAES running all day here.


--
Helmut Karlowski