Re: [9fans] any vga driver gurus about?

Re: [9fans] any vga driver gurus about?

[Russ Cox]

IBM wasn't thinking much about the future when
they set up the VGA registers.  What goes into things
like vga->crt[0x13] and vga->crt[0x16] are the 
lower eight bits of those values.  In modes higher
than standard VGA can handle, various overflow
bits are scattered elsewhere.  Exactly where is card
dependent; that's what you're seeing.


	in my cl-gd52x manual

Surely there's a digit missing here?

Russ

Re: [9fans] any vga driver gurus about?

[Matt]

> Exactly where is card
> dependent; that's what you're seeing.

It's beginning to sink in.

> in my cl-gd52x manual

> Surely there's a digit missing here?

yup, it's a 4. 
Where to put it I'll leave as an exercise for the reader.

Re: [9fans] any vga driver gurus about?

[nigel]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

Well, the best book has not been written, since one that says "well hey,
this is how the whole mess developed" doesn't seem to be out there, but

1. IBM PS/2 hardware technical reference manual is quite definitive on VGAs
    but hard to come by!

2. Programmers Guide to PC & PS/2 Video Systems, R. Wilton, Microsoft Press
    is pretty good, if a bit "BIOS"y, but is certainly pure VGA

3. Programmers Guide to the EGA, VGA and Super VGA Cards, Ferraro, Adison Wesley
    was quite good on first generation SVGAs, and has some history

4. The Indispensible PC Hardware Book, Messmer, Adison Wesley, is always useful


[-- Attachment #2: Type: message/rfc822, Size: 2000 bytes --]

From: FODEMESI Gergely <fgergo@eik.bme.hu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] any vga driver gurus about?
Date: Tue, 26 Sep 2000 00:24:12 +0200 (MET DST)
Message-ID: <Pine.GSO.4.21.0009260017500.9791-100000@goliat>


ngr wrote:
> You should also read a
> good book on the history of the vga to understand the
> full horror.

Which book would you recommend?

 thanks: gergo

Re: [9fans] any vga driver gurus about?

[nigel]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

I remember the strap line for the original ads. for AIX. It was
something like "we've added a 1000000 lines of code to make
Unix better".

Clearly a misunderstanding of what fat farms are for.


[-- Attachment #2: Type: message/rfc822, Size: 2368 bytes --]

From: "Boyd Roberts" <boyd@planete.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] any vga driver gurus about?
Date: Mon, 25 Sep 2000 23:10:38 +0200
Message-ID: <00d501c02735$0de5fc60$89c584c3@cybercable.fr>

this is a bit off topic, but i ran into these two IBM suit wearing type in a
paris
the other night in a bar called 'barfly' (av george v, just off the champs
elysees).
somehow, during the second whisky sour, i got talking to them.  unix was
mentioned
and one of them claimed that it was written by IBM.  needless to say, they
didn't
live very long :-)

Re: [9fans] any vga driver gurus about?

[FODEMESI Gergely]

ngr wrote:
> You should also read a
> good book on the history of the vga to understand the
> full horror.

Which book would you recommend?

 thanks: gergo

Re: [9fans] any vga driver gurus about?

[Matt]

<snip> thanks

> Which chip is it that is not supported? I would have thought
> all the Cirrus CL-GD chips were supported.

it's a cl-gd7543

it's got an entry on vgadb which directs to the clgd542x.c driver

ctlr
    0xC0039="CL-GD7543"    # notebook
    link=vga
    ctlr=clgd542x
    hwgc=clgd542xhwgc

but from aux/vga I get a response of
clgd542x: unknown chip id - 0x30

looking in clgd542x.c I see that 0x30 is not part of the static :

static Gd542x family[] = {
          { 0x88,  75000000, },           /* CL-GD5420 */
          { 0x8C,  80000000, },           /* CL-GD5422 */
          { 0x94,  80000000, },           /* CL-GD5424 */
          { 0x90,  80000000, },           /* CL-GD5426 */
          { 0x98,  80000000, },           /* CL-GD5428 */
          { 0x9C,  86000000, },           /* CL-GD5429 */
          { 0xA0,  86000000, },           /* CL-GD5430 */
          { 0xA8, 90000000, },            /* CL-GD5434 */
          { 0xAC, 135000000, },           /* CL-GD5436 */
          { 0xB8, 135000000, },           /* CL-GD5446 */
          { 0x00, },
  };

which makes identify() barf.

Looking through the cl-gd7543 manual the stuff is mostly the same
I think the general difference is that it has ntsc/pal output

I was hoping that just putting an entry in the Gd542x family[] would work.

Matt

Re: [9fans] any vga driver gurus about?

[Boyd Roberts]

this is a bit off topic, but i ran into these two IBM suit wearing type in a
paris
the other night in a bar called 'barfly' (av george v, just off the champs
elysees).
somehow, during the second whisky sour, i got talking to them.  unix was
mentioned
and one of them claimed that it was written by IBM.  needless to say, they
didn't
live very long :-)

Re: [9fans] any vga driver gurus about?

[nigel]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

The in memory version is maintained as 16 bits to allow
some overflow in calculations, such as horizontal counts.

The original 6845 core was extended in the design of the
vga to allow the generation of wider displays. The original
width register was too small, so bits in other registers were
borrowed to extend the basic register.

By using a 16 bit in-memory register, the standard
calculation could be done, and then the overflow bits
copied to the right place.

This explains what you are seeing.

If you have not done this before, I strongly recommend
getting a working system you can play with. This is not
known as vga Hell for nothing. You should also read a
good book on the history of the vga to understand the
full horror.

Which chip is it that is not supported? I would have thought
all the Cirrus CL-GD chips were supported.


[-- Attachment #2: Type: message/rfc822, Size: 3038 bytes --]

From: "Matt" <matt@proweb.co.uk>
To: "9fans" <9fans@cse.psu.edu>
Subject: [9fans] any vga driver gurus about?
Date: Mon, 25 Sep 2000 21:45:18 +0100
Message-ID: <003b01c02731$8823c420$0301a8c0@freeze>

Hi,

Okay I've ended up having to try and write a vga driver for my laptop
a challenge to which I have never risen before
It's partiularly intriguing as I've not even got a running plan9 to compile
it with

I'm reading through stuff and I've come across something I don't understand

in http://offworld.fac.cs.cmu.edu/plan9/source/src/cmd/aux/vga/vga.h

the crt registers are defined as ushorts

125 typedef struct Vga {
129         ushort  crt[256];

in my cl-gd52x manual

the CRT registers are 8 bits

in http://offworld.fac.cs.cmu.edu/plan9/source/src/cmd/aux/vga/clgd542x.c
which is the driver file I'm studying

there is some stuff like this :

248         if(vga->crt[0x16] & 0x100)
249                 vga->crt[0x1A] |= 0x40;
250         if(vga->crt[0x16] & 0x200)
251                 vga->crt[0x1A] |= 0x80;
these set the vertical blank end overflows (whatever they are :)


253         if(vga->crt[0x13] & 0x100)
254                 vga->crt[0x1B] |= 0x10;
this sets the blanking control to 1 which enables the blanking set in CR1A

so what use is & ing an 8bit value with a 16bit value?

Matt

[9fans] any vga driver gurus about?

[Matt]

Hi,

Okay I've ended up having to try and write a vga driver for my laptop
a challenge to which I have never risen before
It's partiularly intriguing as I've not even got a running plan9 to compile
it with

I'm reading through stuff and I've come across something I don't understand

in http://offworld.fac.cs.cmu.edu/plan9/source/src/cmd/aux/vga/vga.h

the crt registers are defined as ushorts

125 typedef struct Vga {
129         ushort  crt[256];

in my cl-gd52x manual

the CRT registers are 8 bits

in http://offworld.fac.cs.cmu.edu/plan9/source/src/cmd/aux/vga/clgd542x.c
which is the driver file I'm studying

there is some stuff like this :

248         if(vga->crt[0x16] & 0x100)
249                 vga->crt[0x1A] |= 0x40;
250         if(vga->crt[0x16] & 0x200)
251                 vga->crt[0x1A] |= 0x80;
these set the vertical blank end overflows (whatever they are :)


253         if(vga->crt[0x13] & 0x100)
254                 vga->crt[0x1B] |= 0x10;
this sets the blanking control to 1 which enables the blanking set in CR1A

so what use is & ing an 8bit value with a 16bit value?

Matt