Hi Michael,
(replying in plain text mode ;-)
On Sun, Feb 13, 2022 at 9:29 PM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
On 13/02/22 03:59, Geert Uytterhoeven wrote:
While working on an Atari DRM driver for Linux, I discovered a problem
with video modes using 2 bitplanes: the display only shows tints of
blue. 1, 4, and 8 bitplanes work fine.
With debug code added to ARAnyM, it turns out the bad behavior
happens when ARAnyM uses the STe palette registers instead of the
Falcon palette registers. And apparently the issue can also be
reproduced with atafb, and with other color depths:
1. Boot Linux (I'm using video=atafb:tthigh)
Everything looks good:
refreshPalette:319: st_shift = 0
refreshPalette:354: Fal color 0 = 0x00000000 => 00/00/00
refreshPalette:354: Fal color 1 = 0x000000a8 => 00/00/aa
refreshPalette:354: Fal color 2 = 0x00a80000 => 00/aa/00
refreshPalette:354: Fal color 3 = 0x00a800a8 => 00/aa/aa
2. Change the color depth a few times:
$ fbset -depth 1
$ fbset -depth 2
Depth 2 forces STe palette mode (in decode_var; activated in the Videl in the vbl switcher).
$ fbset -depth 4
...
If good: console is white(grey) on black
refreshPalette:319: st_shift = 0
refreshPalette:354: Fal color 0 = 0x00000000 => 00/00/00
refreshPalette:354: Fal color 1 = 0xa8a800a8 => aa/aa/aa
refreshPalette:354: Fal color 2 = 0x54540054 => 55/55/55
refreshPalette:354: Fal color 3 = 0xfcfc00fc => ff/ff/ff
If bad: console is blue on black
refreshPalette:319: st_shift = 256
That's still depth 2.
refreshPalette:335: STe color 0 = 0x0000 => 00/00/00
refreshPalette:335: STe color 1 = 0x0117 => 22/22/ee
refreshPalette:335: STe color 2 = 0x0000 => 00/00/00
refreshPalette:335: STe color 3 = 0x0000 => 00/00/00
As a workaround, I fixed ARAnyM to force numColors to 256, so
it will always use the Falcon palette.
https://github.com/aranym/aranym/blob/master/src/videl.cpp#L319
Is this a bug in ARAnyM, or a bug in atafb?
It _looks_ as though changes to f_shift and st_shift are not pushed to hardware in the VBL interrupt. Does ARAnyM run the VBL interrupt regularly?
Yes it does.
But maybe the kernel and ARAnyM disagree because useStPalette() has this:
int hreg = handleReadW(HW + 0x82); // Too lame!
// Better way how to make out ST LOW mode wanted
if (hreg == 0x10 || hreg == 0x17 || hreg == 0x3e) {
useStPal = true;
}
for st_shift == 0
Linux' falcon_setcolreg() writes to both the Falcon palette registers
and shifter_tt.color_reg[], so shouldn't the STE color palette contain
the correct colors, too?
As the problem is not 100% reproducible, it looks like a race condition
in ARAnyM, or a wrong initialization order in atafb.
I'd have to test this on hardware but haven't got fbset on the Falcon. I'll try to locate a binary.
Sorry, you do not need fbset to reproduce this:
echo N > /sys/class/graphics/fb0/bits_per_pixel
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
