16bpp graphics modes on old iMac, what is the MSB function?

[l***@larwe.com]

Is there some special function assigned to the MSB of video memory in a
Mac running at "thousands" of colors, specifically a 16bpp mode on the
kernel framebuffer device?

I'm experimenting with an old iMac running Linux. According to
everything the fbdev ioctls show me, the video mapping is 5:6:5
big-endian. So I'd expect filling video RAM with 0xF800 to give me a
bright red floodfill. In fact after much experiment I've discovered
that the real assignment is as below.

15 - "magic"
14 - R3
13 - R2
12 - R1

11 - R0
10 - G5
09 - G4
08 - G3

07 - G2
06 - G1
05 - G0 (maybe no function, it's invisible)
04 - B4

03 - B3
02 - B2
01 - B1
00 - B0

If the "magic" bit is set, the pixel appears black. So it is really a
4:6:5 video mode?! I can't find any documentation on this special bit;
can someone point me to anything appropriate? It's apparently an
Apple-specific thing, since the same behavior doesn't appear on a
Mach64 in a PC.

[Tom Stiller]

Post by l***@larwe.com
Is there some special function assigned to the MSB of video memory in a
Mac running at "thousands" of colors, specifically a 16bpp mode on the
kernel framebuffer device?
I'm experimenting with an old iMac running Linux. According to
everything the fbdev ioctls show me, the video mapping is 5:6:5
big-endian. So I'd expect filling video RAM with 0xF800 to give me a
bright red floodfill. In fact after much experiment I've discovered
that the real assignment is as below.
15 - "magic"
14 - R3
13 - R2
12 - R1
11 - R0
10 - G5
09 - G4
08 - G3
07 - G2
06 - G1
05 - G0 (maybe no function, it's invisible)
04 - B4
03 - B3
02 - B2
01 - B1
00 - B0
If the "magic" bit is set, the pixel appears black. So it is really a
4:6:5 video mode?! I can't find any documentation on this special bit;
can someone point me to anything appropriate? It's apparently an
Apple-specific thing, since the same behavior doesn't appear on a
Mach64 in a PC.

IIRC, the 2^15 bit was an alpha plane overlay bit. I think there's
something wrong with your mapping. It makes no sense to have more bits
representing blue than representing red.

[l***@larwe.com]

Hi Tom,

Post by Tom Stiller

Post by l***@larwe.com
Is there some special function assigned to the MSB of video memory in a
Mac running at "thousands" of colors, specifically a 16bpp mode on the
kernel framebuffer device?

IIRC, the 2^15 bit was an alpha plane overlay bit. I think there's
something wrong with your mapping. It makes no sense to have more bits
representing blue than representing red.

I did post a reply saying I agree it makes no sense, but I'd verified
it experimentally. Well, that turns out to be a lie. In fact the mode
that the normal console runs in is utterly beyond weird. The color
components are in basically the right positions, but it's as if the DAC
is still in a palettized mode.

If I execute X & sleep 10 ; ./myapp then the graphics appear totally
normal.

It's really, really bizarre. Any thoughts?

[Tom Stiller]

Post by l***@larwe.com
Hi Tom,

Post by Tom Stiller

Post by l***@larwe.com
Is there some special function assigned to the MSB of video memory in a
Mac running at "thousands" of colors, specifically a 16bpp mode on the
kernel framebuffer device?

IIRC, the 2^15 bit was an alpha plane overlay bit. I think there's
something wrong with your mapping. It makes no sense to have more bits
representing blue than representing red.

I did post a reply saying I agree it makes no sense, but I'd verified
it experimentally. Well, that turns out to be a lie. In fact the mode
that the normal console runs in is utterly beyond weird. The color
components are in basically the right positions, but it's as if the DAC
is still in a palettized mode.
If I execute X & sleep 10 ; ./myapp then the graphics appear totally
normal.
It's really, really bizarre. Any thoughts?

It's been too long since I worked at that level of graphic hardware and
my brain's fuzzy.