Hello Mark
- Don't you like green ?
It looks fine for me : http://temlib.org/pub/boot_netbsd6.jpg
- "checkpatch.pl" did not find anything wrong with this patch. I will adjust
style and spacings anyway.
- AFAIU, it is impossible to implement exactly this video board on QEMU with
reasonable performance.
The S24/TCX has a 1Meg * 26 bits framebuffer.
For each pixel, two bits are used for selecting between 256 indexed and 24bits
truecolor.
The RAMDAC/palette handles this selection, as well as an overlay plane for the
cursor
(with 4 additional colours).
This enable handling different "visuals" for each X11 window. Text mode is also
8bits indexed
even on 24bits mode.
The memory is simultaneously accessible at several addresses, with different
alignment :
RDFB32: Each pixel occupies 32bits. D[31:26]=0000_00, D[25:24]=MODE,
D[23:0]=Colour
DFB24 : Each pixel occupies 32bits. D[31:24]=0000_0000, D[23:0]=Colour
DFB8 : Each pixel occupies 8bits, mapped to D[7:0] of the framebuffer.
MODE=D[25:24] (-> datasheet ATT20C567)
00 : 256 colours "pseudocolor" : R=pal_r(D[ 7: 0]) G=pal_g(D[ 7:0])
B=pal_b(D[ 7:0])
01 : 16M colours "directcolor" : R=pal_r(D[ 7: 0]) G=pal_g(D[15:8])
B=pal_b(D[23:16])
10 : 16M colours "truecolor" gamma : R=gamma(D[ 7: 0]) G=gamma(D[15:8])
B=gamma(D[23:16])
11 : 16M colours "truecolor" raw : R= D[ 7: 0] G= D[15:8]
B= D[23:16]
QEMU cannot directly imitate this behavior, so :
- The RDFB32 area is only used for the MODE bits
- 8 colours applications are expected to write only in the DFB8 area
- 24 colours applications are expected to write only in the DFB24 area
- the blitter and stippler accelerators update all areas simultaneously in
24bits mode
- As the 24bits mode is simultaneously both a 8bits and 24bits mode, dirtying
the (smaller) 8bits area
is sufficient.
Olivier
qemu-tcx-accel-rebase.patch