Re: [MiNT] libgem16: vs_color

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

Am 18.01.2010, 22:47 Uhr, schrieb Roger Burrows <rfburrows@ymail.com>:

(redirecting to mintlist)

> It looks as though, when vs_color() gets control, the stack pointer is  
> odd.
> This makes all the pointers in VDIPB odd, since they point to areas  
> within the
> stack.  Probably only fVDI (of the various VDIs) checks for this, so is  
> the
> only one to behave oddly.  Having an odd stack pointer is strange  
> behaviour,
> given the 68K architecture.  Perhaps the code calling vs_color() has

That is what I also think meanwhile.

> somehow
> managed to arrange that, or perhaps it's something in Aranym.  Is this

It's all simple c-coding:


void
set_syspalette(short vdih, struct rgb_1000 *palette)
{
  short i, pens, rgb[3];
  //if( C.fvdi_version == 0 ) return; /* as long as this doesn't work  
reliable */

  if (screen.planes > 8)
    pens = 256;
  else
    pens = 1 << screen.planes;

//  display("set syspal - %d pens", pens);
  BLOG((0,"set_syspalette:vdih=%d", vdih));
  for (i = 0; i < pens; i++)
  {
    rgb[0] = palette[i].red, rgb[1] = palette[i].green, rgb[2] =  
palette[i].blue;
    //vs_color(vdih, i, (short *)&(palette[i]));
    vs_color(vdih, i, rgb );
  }
}

See I also changed the rgb-arg, no change. It is also called from a  
different place with the same behaviour.

> with the
> basic Aranym, or JIT?

All platforms, even TT with crazy-dots+nvdi-et4000, but nvdi seems to be  
able to handle odd pointers ...

I can't find it, so I leave the static-version in for now.

--
Helmut Karlowski