Re: modex/rage128

Search this archive.

From: Ryan Rubley (rubleyr@csis.gvsu.edu)
Date: Tue 30 Jan 2001 - 01:17:40 IST


On Mon, 29 Jan 2001, Matan Ziv-Av wrote:

>
> > Hello, I am Ryan "Ark" Rubley, I wrote the trident 94xx/96xx extensions
> > back a long time ago, and now I am interested in writing svgalib drivers
> > from scratch for the ATI Rage128/Rage128pro chipset cards (these cards
> > exist in 30+ machines at my university, and are limited to 320x240 for
> > console applications .. yeah quake2 ;)
>
> Doesn't XFree86 4 with hardware accelerated glx on rage 128 work with
> quake2?

The machines are still running 3.3.6, and Quake2+GLX, in my experience, is
laggy and slow at best.  Mouse support is useless without hacks I cant run
(no root there) and the frame rate is very low.
In fact, the Rage128 X server messes up text and grfx in regular windows
like even an X term. rather annoying.  4.0.1 on my personal machine seems
to work better, but I have not tried Quake under DRI yet.
I prefer the console either way..



> > I just now put together a quicky 400x300x256 mode-X driver that works
> > great with Quake2, and would like to submit this to svgalib, however it
> > would require two tiny changes to each existing driver (where they check
> > for <640x480x256||hercules mode to pass thru to the vga driver)
>
> It is a problem to integrate such a mode. How does Quake2 recognize
> it? Maybe it is best to have a config file option to let this mode take
> over an old mode (G640x200x16 for example)?
> A different solution is for the vga driver to support mode 55
> (G400x300x256), and so if a native chipset driver is running the modeX
> 400x300 won't be available, but a linear 400x300 might be. This means
> the application needs to check if the mode is modeX. Does quake2 do
> that?

Well the entry in the modeinfo table needs {400, 300, 256, 100, 0},
instead of {400, 300, 256, 400, 1}, to work properly, so what I did was
add a new mode:
#define G400x300x256X 145
and in vgadrv.c:

/* non-BIOS mode - 400x300x256 - added by Ark 28-JAN-2001 */
static const unsigned char g400x300x256X_regs[60] =
{
  0x71, 0x63, 0x64, 0x92, 0x65, 0x82, 0x46, 0x1F, 0x00, 0x40, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x31, 0x80, 0x2B, 0x32, 0x00, 0x2F, 0x44, 0xE3,
  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B,
    0x0C, 0x0D, 0x0E, 0x0F, 0x41, 0x00, 0x0F, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0F, 0xFF,
    0x03, 0x01, 0x0F, 0x00, 0x06,
    0xA7
};

plus:

    OneModeEntry(400x300x256X), /* added by Ark 28-JAN-2001 */

and a few "case G400x300x256X:"  (four I think)
in various files..

Then in the driver files XXX_modeavailable() function, I changed the if:

if ((mode < G640x480x256 )
        || mode == G720x348x2
        || mode == G400x300x256X )

and in XXX_setmode()

    if ((mode < G640x480x256)||(mode==G720x348x2)||(mode==G400x300x256X))


Tested it and it works great. Quake probably probes for all available 256
color modes (it lists all it finds on startup)
400x300 is a big improvement over 320x240 for anybody who doesnt have any
other driver to fall back to, and who cant use the VESA driver...

we tried the VESA driver and it locks up randomly during and after usage
on both types of systems in our lab:
Rage128(not pro) Dual P3-650 (VIA chipset, PC133 ram)
Matrox G200 w/ Celeron 400 on Intel BX boards



> > I have begun work on a Rage128 driver and would like to know if anybody
> > else is working on this chipset, or if anybody else is interested in
> > working with me on this project?
>
> I am working on this driver. I actually finished writing it. All that
> is left is to put the card in the computer and see why it does not
> work :-).
> I just finished debugging the G450 driver, so the R128 is the next thing
> tomorrow morning.

hey, well does the G450 support G200/G400 too? that would be great.
And I can help you test the Rage driver on my Rage128pro and our lab of
Rage128's


Hope you can manage to include that 400x300 into the next svgalib, since
we all know how important good quaking is ;)



------------------------------------------------------------------
Unsubscribe:  To:   listbot@svgalib.org
              Body: unsubscribe linux-svgalib


This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:23 IST