The truecolor logic handles all of the VESA-standard truecolor modes: 
Sierra-style (5-5-5), XGA-style (5-6-5), 24-bit (8-8-8) and 32-bit 
(8-8-8 with another 8 for stuff we ignore). To define true-color modes 
I added them to the FRACTINT.CFG file specifying mode 28 and 256 colors:

 ,VESA 5-5-5 ,4f02, 110, 0, 0, 28, 640, 480, 256, True-color
 ,VESA 5-6-5 ,4f02, 111, 0, 0, 28, 640, 480, 256, True-color
 ,VESA 8-8-8 ,4f02, 112, 0, 0, 28, 640, 480, 256, True-color
 ,VESA 5-5-5 ,4f02, 113, 0, 0, 28, 800, 600, 256, True-color
 ,VESA 5-6-5 ,4f02, 114, 0, 0, 28, 800, 600, 256, True-color
 ,VESA 8-8-8 ,4f02, 115, 0, 0, 28, 800, 600, 256, True-color
 ,VESA 5-5-5 ,4f02, 116, 0, 0, 28,1024, 768, 256, True-color
 ,VESA 5-6-5 ,4f02, 117, 0, 0, 28,1024, 768, 256, True-color
 ,VESA 8-8-8 ,4f02, 118, 0, 0, 28,1024, 768, 256, True-color
 ,VESA 5-5-5 ,4f02, 119, 0, 0, 28,1280,1024, 256, True-color
 ,VESA 5-6-5 ,4f02, 11a, 0, 0, 28,1280,1024, 256, True-color
 ,VESA 8-8-8 ,4f02, 11b, 0, 0, 28,1280,1024, 256, True-color

The standard getcolor/putcolor routines all work. They just put whatever 
byte value you specify into the first byte of the true-color pixel - the 
image tends to look blue or blue-green depending on the true-color mode 
involved. Try the plasma cloud fractal for good examples. Fractint 
*thinks* that color-cycling works, but there are no visible signs of it 
as the true-color modes (at least the ones on the adapter I'm testing 
them on) ignore the color DAC completely.

There's a new global integer value accessable by the C modules, 
'istruecolor', which is true if you're in a true-color mode and 
false otherwise. There are also two new access routines, 
'puttruecolor(xdot, ydot, red, green, blue)' and 
'gettruecolor(xdot, ydot, &red, &green, &blue). These two "true color"
routines work in either true-color mode or 256-color mode.
In true-color mode, they work by invoking the true-color getcolor/putcolor 
routines as many times as necessary, incrementing an internal byte-counter 
telling them to access other than the first byte in a pixel. In
256-color mode, 'puttruecolor()' (slowly!) finds the closest color in 
the DAC and calls the normal 'putcolor()' routine to set the 
corresponding palette value. In 256-color mode, 'gettruecolor()' calls 
the normal 'getcolor()' routine and then returns the equivalent DAC value.
Note that in 256-color mode 'puttruecolor()' has to perform 768
multiplies and adds and 256 compares just to find the closest DAC
value for each pixel!!!

I've modified the 'test' fractal so that if DEBUG=500 *and* you're in 
a 256-color or true-color mode of 640x480 resolution or better it 
displays a test pattern on the screen using 'puttruecolor()' and 
'gettruecolor()', waits for you to press a key, and then clears 
those test patterns before proceeding with its standard Mandelbrot image.
This was invaluable for me while I was testing the code and also 
serves as a pretty good demo in terms of displaying how to invoke 
the appropriate routines. Fair warning: This test pattern is *godawful*
slow in 256-color mode, and it looks awful, too <g>!