VT8605 (ProSavage PM133) ignoring VGA DAC color-map registers

J

Jordan Hazen

I'm having a problem with the integrated S3 ProSavage video chipset
(VT8605) on an older Socket 370 motherboard. Any attempt to change the
standard VGA palette (DAC color map) is silently ignored. I tried
Linux's virtual-console escape sequence:

(ESC) ] P c rr gg bb

e.g. (ESC)]P7F0F0F0

and also writing directly to the standard VGA DAC registers at 0x3c8,
0x3c9 using the code included below. Neither will work on this
particular board. Graphical framebuffer console behave the same as
text-mode.

Booting off a DOS floppy and running shareware tools like "palpal.exe"
also yield no change to the color table. With every other board, all
these methods work fine.

EGA Palette registers at 3c0, 3c1 do function correctly for remapping
the 16 "CGA" colors to 64 standard EGA colors, but with only three
luminance levels available, this doesn't help much in setting up
grayscale palettes for a monochrome monitor.

Does the VT8605 have a a special "lock" register I need to clear before
the VGA DAC palettes can be changed? Perhaps the DAC tables are mapped
differently on this chip than on every other VGA card?

Any insight would be appreciated...


/* vga-pset.c */
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/io.h>

void
ioport(int port) {

if (ioperm(port,2,1) == -1) {
fprintf(stderr,"Unable to set up i/o permissions, exiting.\n");
exit(1);
}
if (i386_set_ioperm(iomap) == -1)
errx(1, "Couldn't set I/O permissions.");
}

int
main(int argc, char **argv) {

int preg,r,g,b;

if (argc != 5) {
fprintf(stderr,"Need four arguments: preg [0-63], R, G, B values [all 0-63].\n");
exit(1);
}

preg=atoi(argv[1]);
r=atoi(argv[2]);
g=atoi(argv[3]);
b=atoi(argv[4]);

if (preg < 0 || preg > 63 || r < 0 || r > 63 || g < 0 || g > 63 || b < 0 || b > 63 ) {
fprintf(stderr,"Arguments out of range (preg [0-63], RGB colorvalues [0-63]).\n");
exit(1);
}

setuid(0);

ioport(0x3C6);
ioport(0x3C8);
ioport(0x3C9);

outb(0xFF,0x3C6);

outb(preg,0x3C8);
outb(r,0x3C9);
outb(g,0x3C9);
outb(b,0x3C9);

printf("set palette DAC reg %d to %d %d %d\n",preg,r,g,b);

return 0;
}
 
D

DOS Guy

[ * Replying from comp.os.msdos.programmer * ]


I'm having a problem with the integrated S3 ProSavage video chipset
(VT8605) on an older Socket 370 motherboard. Any attempt to change the
standard VGA palette (DAC color map) is silently ignored. I tried
Linux's virtual-console escape sequence:

(ESC) ] P c rr gg bb

e.g. (ESC)]P7F0F0F0

and also writing directly to the standard VGA DAC registers at 0x3c8,
0x3c9 using the code included below. Neither will work on this
particular board. Graphical framebuffer console behave the same as
text-mode.

Booting off a DOS floppy and running shareware tools like "palpal.exe"
also yield no change to the color table. With every other board, all
these methods work fine.

EGA Palette registers at 3c0, 3c1 do function correctly for remapping
the 16 "CGA" colors to 64 standard EGA colors, but with only three
luminance levels available, this doesn't help much in setting up
grayscale palettes for a monochrome monitor.

Does the VT8605 have a special "lock" register I need to clear before
the VGA DAC palettes can be changed? Perhaps the DAC tables are mapped
differently on this chip than on every other VGA card?

Any insight would be appreciated...

[ ... code snip ... ]


While I'm not familiar with this particular chipset, there are
certain universal true-isms that should apply to *all* VGA video.

Since some of these true-ism don't seem to apply to yours, here
are a few random thoughts:

1. The chipset or associated circuit components might be "broken."

2. It's remotely possible that the chipset simply doesn't support
changing the DAC color map. Some of those older "integrated"
video systems were pretty funky.

3. The chipset could be wildly proprietary, and originally have
required a memory-resident software "driver." Though rare,
this wasn't entirely unheard-of with older video hardware.

4. Have you tested to make absolutely certain that the video is
actually VGA? Under DOS, you can use INT 10h, Function 01Ah,
Sub-Function 0 (see Ralf Brown's Interrupt List, or any good
tech ref).

5. Have you tested to determine if the video system is VESA-
compatible? Under DOS, you can use INT 10h, Function 04Fh,
Sub-Function 0 (see Ralf Brown's Interrupt List, or any good
tech ref).

And if the system is VESA-compatible, have you tried using
VESA commands (INT 10h, Function 04Fh, various sub-functions),
rather than directly accessing the hardware?

6. If your ultimate goal is merely to make the display look good
with a monochrome VGA monitor, have you tried enabling
grayscale summing? This, alone, is often sufficient -- without
the need to futz with the DAC color map:

; Enable grayscale summing
mov ax,1200h
mov bl,33h
int 10h

; Disable grayscale summing
mov ax,1201h
mov bl,33h
int 10h

Good luck!
 
J

Jason Burgon

Jordan Hazen said:
I'm having a problem with the integrated S3 ProSavage video chipset
(VT8605) on an older Socket 370 motherboard. Any attempt to change the
standard VGA palette (DAC color map) is silently ignored.
Booting off a DOS floppy and running shareware tools like "palpal.exe"
also yield no change to the color table. With every other board, all
these methods work fine.

EGA Palette registers at 3c0, 3c1 do function correctly for remapping
the 16 "CGA" colors to 64 standard EGA colors, but with only three
luminance levels available, this doesn't help much in setting up
grayscale palettes for a monochrome monitor.

Does the VT8605 have a a special "lock" register I need to clear before
the VGA DAC palettes can be changed? Perhaps the DAC tables are mapped
differently on this chip than on every other VGA card?

Any insight would be appreciated...

It may well be that the VT8605 is not VGA register compatible in certain
video modes. Try running my GVFM.EXE DOS application (available from my
website - see my sig) and getting it to display one or more .JPG files in a
256 colour video mode. If GVFM displays these correctly then the chances are
it is using the VESA VBE API to change the hardware palette and NOT writing
to the VGA palette registers directly. It does this when the VBE reports the
video mode to be VGA [register] incompatible.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top