I sent a corrected piece of code using two 16 bit 64k lookup tables
as follows.
a0 points to RG table and a1 to B.It sounds very likely that the W bit is G2.
m33RGB move.w (a4)+,d2 get B0
move.w (a4)+,d3 get RG
move.w (a0,d3.w),d3 use lookup table to sort RG
move.w (a1,d2.w),d2 also sort B
or.w d2,d3 combine RGB
m33done move.w d3,d6 left pixel done, now do right
swap d6
... inline repeat of above for right pixel
move.l d6,(a3)+ two pixels to window save area
BORG in BBBBBBBBOOOOOOOO RRRRRRRRGGGGGGGG
76543210 7654321076543210
After Lookup 0000000000BBBBB0 GGGGGRRRRR00000G
76543 7654376543 2
After OR GGGGGRRRRRBBBBBG
7654376543765432
Cheers
Malcolm
Dave Westbury wrote:
009b01c0a26d$8cfe87c0$964e073e@default">Malcolm Lear wrote:Just a thought on speeding things up.
How about using a 16 bit lookup table to rearrange the red and green bits some
like this:
m33RGB move.w (a4)+,d2 get B0
move.w (a4)+,d3 get RG
move.w (a0,d3.w),d3 use lookup table to sort RG
andi.w #$f800,d2 mask out B
or.w d2,d3 combine RGB
m33done move.w d3,d6 left pixel done, now do right
swap d6
... inline repeat of above for right pixel
move.l d6,(a3)+ two pixels to window save area
The W bit would be created by the lookup table and depend on RG levels. Not a
perfect solution but maybe acceptable.
But this not only ignores B2 but puts the RGB bits in the wrong order for the
Q40 display (if RG table returned 00000WGG GGGRRRRR then you would still need to
do a rotate after the OR.W). The criteria was if two or three bits in G2/R2/B2
are set then set RGB0 bit.
The most correct way I guess would be to add R2-0 + G2-0 + B0-2 and set RGB0 if
the result is greater than half maximum value (ugh!). I still think I prefer
just using G2 since I feel RGB0 is effectively a luminance bit
Regards,
Dave.
