#9 GXE64 support

#9 GXE64 support

[jmk]

i've lowered the threshold at which the att21x498 ramdac decides to use 2x8-bit mode
which should fix the problem. there's a new aux/vga and vgadb available in the pcdist
directory for pick-up by ftp. use at your own risk (i'd keep a copy of the old one
around...).

there are some other changes in the new version:
	support for #9GXE64pro;
	add trivial ctlr entry for att20c490 ramdac and tweak 
	  ramdac 'magic access' code;
	lower threshold at which att21c498 will use 2x8-bit mode to > 80MHz;
	add "-e" and "-k tables for the Chrontel CH9294 clock generator and
	  look for clock-divisors on the CH9294 and ICS2494 if asked for (ET4000);
	change BIOS id string for the Hercules Dynamite Power PCI and add ctlr entry
	  for the ISA version.

#9 GXE64 support

[Jeremy]

jmk@plan9.att.com:
> my suspicion is that aux/vga is not switching over to 2x8-bit mode for the
> higher clock rates when it can, we've never played with any resolution
> requiring a clock between 80MHz and 135MHz.
> 
> please post your parameters.

This is how XFree86 detects my card:
# XF86_S3 -probeonly
(**) stands for supplied, (--) stands for probed/default values
(**) Mouse: type: MouseSystems, device: /dev/mouse, baudrate: 1200
(**) S3: Graphics device ID: "#9GXE64"
(**) S3: Monitor ID: "MX17FG"
(**) FontPath set to "/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/"
(**) S3: Option "number_nine"
(--) S3: card type: PCI
(--) S3: chipset:   864 rev. 0
(**) S3: chipset driver: mmio_928
(**) S3: videoram:  2048k
(--) S3: Detected an ATT 20C498/21C498 RAMDAC
(--) S3: Ramdac type: att20c498
(**) S3: Ramdac speed: 135
(**) S3: Using ICD2061A programmable clock
(--) S3: Maximum allowed dot-clock: 135.000 MHz
(**) S3: Mode "1184x888@100": mode clock = 100.000
(**) S3: Mode "1152x864@90": mode clock =  90.000
(**) S3: Mode "1024x768": mode clock =  75.000
(**) S3: Mode "800x600": mode clock =  50.000
(**) S3: Mode "640x480": mode clock =  25.000
(--) S3: Using 8 bits per RGB value
(--) S3: Virtual resolution set to 1184x888

Here's the relevent details from /lib/vgadb:

ctlr
	0xC0094="#9-864"					# #9GXE64
	0xC0044="Phoenix S3 Vision864 (16Bit DAC)"		# GIS Globalyst 550
	link=vga
	hwgc=s3hwgc
	ctlr=vision864 link=ibm8514
	ramdac=att21c498-135
	clock=icd2061a link=s3clock

# From XFree86 config file:
#    ModeLine "1184x888"	100 1184 1216 1576 1608 888 891 903 928
include = 1184x888@67Hz
	clock=100
	shb=1216 ehb=1576 ht=1608
	vrs=891 vre=903 vt=928

#
# MAG MX17FG
# Horizontal timing:
#	Allowable frequency range: 30-64KHz
# Vertical timing:
#	Allowable frequency range: 50-120Hz
# Video bandwidth:
#	120MHz monitor
mag17fg = 1184x888x8
	include=1184x888@67Hz
mag17fg = 1184x888x4
	include=1184x888@67Hz
mag17fg = 1184x888x1
	include=1184x888@67Hz
#  ModeLine "1152x864@90"   90 1152 1184 1496 1528  864  867  876  900
#mag17fg = 1152x864x1
#	clock=90
#	shb=1184 ehb=1496 ht=1528
#	vrs=867 vre=876 vt=900

#  ModeLine "1152x864@80"   80 1152 1160 1384 1480  864  867  876  900
mag17fg = 1152x864x1
	clock=80
	shb=1160 ehb=1384 ht=1480
	vrs=867 vre=876 vt=900
mag17fg
	alias=multisync75

#9 GXE64 support

[jmk]

the ATT21C498 is the production version of the ATT20C498 according to the
datasheet.

my suspicion is that aux/vga is not switching over to 2x8-bit mode for the
higher clock rates when it can, we've never played with any resolution
requiring a clock between 80MHz and 135MHz.

please post your parameters.

------ original message follows ------

>From cse.psu.edu!9fans-outgoing-owner Mon Aug  7 06:46:32 EDT 1995
Received: by psuvax1.cse.psu.edu id <33963>; Mon, 7 Aug 1995 06:11:43 -0400
Received: from staff.cs.su.OZ.AU ([129.78.8.1]) by psuvax1.cse.psu.edu with SMTP id <33958>; Mon, 7 Aug 1995 06:07:16 -0400
Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for
	9fans@cse.psu.edu)
	with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Mon, 07 Aug 1995 20:05:30 +1000
Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP
	id AA29506; Mon, 7 Aug 95 20:05:11 EST (4.1/Unixware)
	(from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu)
Received: by sour.sw.oz.au
	id AA29618; Mon, 7 Aug 1995 20:05:10 +1000 (5.65c/1.34)
	(from jeremy@sour.sw.oz.au for 9fans@cse.psu.edu)
From:	jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <199508071005.AA29618@sour.sw.oz.au>
Subject: #9 GXE64 support
To:	9fans@cse.psu.edu (Graverobbers from Outer Space!)
Date:	Mon, 7 Aug 1995 06:05:09 -0400
Organization: Softway Pty Ltd
X-Face: 
	 '6U=%Tv\k1<Ek%ql%PN^v`Db4bakr[v~y]\u7"GbO#I=]N{l1=#P,glz$9q>l-:?\$C[D@G
	 7(vl~w8&y}!f\bh#w<Y*S~bEBTI:s&.QR>L#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb
	 l[EC}c=;uc%x'}uh3E91p&oE<q$w1r&U0yw.Sb3V&uw
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1262      
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans@cse.psu.edu

Hi all,

I've been successfully using the PC demo disks on my system with
a #9 GXE64 card in 1024x768x8 mode.  I calculated some new parameters
for use with X under Linux which make better use of my hardware,
and came up with a 1184x888@67Hz mode (100MHz dot clock), and a
1152x864 mode (at both 80MHz and 90MHz dot clocks).

These all worked well under XFree86, producing solid clear images.
I tried using the same parameters in /lib/vgadb, but only the
1152x864 w/ 80MHz dot clock worked properly.  The others had flickery
pixels, with 1 pixel-wide vertical lines disappearing altogether;
in other words it looked like something was being overclocked, and
it appears to happen at dot clocks somewhere between 80 and 90 MHz

vgadb's entry for the GXE64 lists the RAMDAC as being an att21x498-135.
However, my card has a att20c498-135 RAMDAC and aux/vga doesn't
seem to explicitly support this chip (isn't accepted in vgadb,
and strings doesn't show any mention in aux/vga itself).

I assume they are quite similar, but is there some slight difference
between them which needs to be handled differently with dot clocks
over, say, 80MHz? The 1152x864 w/ 80MHz dot clock is OK, but only
refreshes at 57Hz, so it's a bit too flickery for long-term use.

Thanks,
	J

#9 GXE64 support

[Jeremy]

Hi all,

I've been successfully using the PC demo disks on my system with
a #9 GXE64 card in 1024x768x8 mode.  I calculated some new parameters
for use with X under Linux which make better use of my hardware,
and came up with a 1184x888@67Hz mode (100MHz dot clock), and a
1152x864 mode (at both 80MHz and 90MHz dot clocks).

These all worked well under XFree86, producing solid clear images.
I tried using the same parameters in /lib/vgadb, but only the
1152x864 w/ 80MHz dot clock worked properly.  The others had flickery
pixels, with 1 pixel-wide vertical lines disappearing altogether;
in other words it looked like something was being overclocked, and
it appears to happen at dot clocks somewhere between 80 and 90 MHz

vgadb's entry for the GXE64 lists the RAMDAC as being an att21x498-135.
However, my card has a att20c498-135 RAMDAC and aux/vga doesn't
seem to explicitly support this chip (isn't accepted in vgadb,
and strings doesn't show any mention in aux/vga itself).

I assume they are quite similar, but is there some slight difference
between them which needs to be handled differently with dot clocks
over, say, 80MHz? The 1152x864 w/ 80MHz dot clock is OK, but only
refreshes at 57Hz, so it's a bit too flickery for long-term use.

Thanks,
	J