Hi Geert,
On 15/02/22 09:50, Michael Schmitz wrote:
Either way, I think we've got operator precedence wrong here. Shift
takes precedence over bitwise and / or? With that precedence, what we
have in summary is
shifter_tt.color_reg[regno] =
(((red & 0xe000) >> 13) | ((red & 0x1000) >>
4)) |
(((green & 0xe000) >> 13) | ((green & 0x1000)
>> 8)) |
((blue & 0xe000) >> 13) | ((blue & 0x1000) >>
12);
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.
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?
Cheers,
Michael
