Hi Geert,
Am 15.02.2022 um 21:11 schrieb Geert Uytterhoeven:
Only the blue bits ever entirely seem to end up where they ought to.
Testing this hypothesis on ARAnyM (without getting it to boot all the
way, for some odd reason likely to do with my current .config) shows
that the current code results in the shifter_tt.color_reg entries either
5 or 0x17, 0x113 or 0x117. Adding the missing parentheses results in
what I'd expect to see.
Oops.
This bug has been present since at least 2.4.30. I do recall seeing this
odd blue console before on the Falcon, so it's been a real bug for ages.
I recall seeing an odd blue console before, too.
I always dismissed it as some artefact of redrawing the screen in
a different color mode, like we used to have when switching from a
16-color to a monochrome text console (remember the underlined text?).
Did/do you see it on the real Falcon, too?
I do see the blue text colour bug, but not the random behaviour in
switching to 2 bpp, on the actual hardware. So there appear to be two
distinct bugs - the STe colour map entries tend towards the blue, and
switching to that palette does not always happen when it should.
Still no idea what causes ARAnyM to miss palette updates or use the
wrong palette at times ...
I can confirm that the bug is gone with additional parentheses to apply
the shifts (<<8 for red, <<4 for green) to the result of the bit-wise
or, not just the right-hand portion of it.
Do you want me to prepare a patch, or would you prefer to do it yourself?
Feel free to send a patch.
Done (now that I've tested on hardware).
Cheers,
Michael
If you don't get to it, I'll make one, eventually.
Thanks!
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
