Re: [9fans] More Mach64 Problems

Re: [9fans] More Mach64 Problems

[Richard Miller]

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

> It will help a lot if you have graphics working on this system in
> some other operating system that lets you poke at the VGA card,
> to read out a working register dump.  Such systems include Windows 9x,
> Linux, and FreeBSD but not Windows NT or 2000.

Are there ready-made tools which will give you a register dump or do
you have to write something specific for each card?  I have access to
a machine with a #9 Imagine 2 which I would quite like to use as a
plan 9 terminal.  The t2r4 driver looks like it should work with a
bit of tweaking.

-- Richard


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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] More Mach64 Problems
Date: Mon, 19 Nov 2001 12:15:11 -0500
Message-ID: <20011119171514.3FF3D1998A@mail.cse.psu.edu>

The problem is in fact the memory timings, but it's ever so difficult
to figure out the exact bits without sitting there at the machine.
(It's basically trial and error, which is much harder when it takes a
day or two to do a round trip.)

There's some code in /sys/src/cmd/aux/vga/mach64xx.c that handles
sniffing the card and trying to get the timings set right, but it
appears to fail on some cards, including apparently yours.
If you're game, I can tell you how to tweak the registers and
you can sit there poking bits until it works, but it's really an
open-ended process: sometimes you get it, sometimes you don't.
It will help a lot if you have graphics working on this system in
some other operating system that lets you poke at the VGA card,
to read out a working register dump.  Such systems include Windows 9x,
Linux, and FreeBSD but not Windows NT or 2000.

I tried to help someone via email with this Mach 64 problem a month
ago and it just didn't work, even with working register dumps to
compare against.

In the case of the person with the similar S3 problem, that was more
easily fixed because the S3 chipset handles most of those calculations
for you.  We just had to add the card type to the driver.

Russ

Re: [9fans] More Mach64 Problems

[Russ Cox]

> Not on the distribution, I think.

Indeed.  Sorry about that.  I put the directory
in a file called vga.tgz on the updates page.

Russ

Re: [9fans] More Mach64 Problems

[Richard Miller]

> ... /sys/src/cmd/aux/vga/win
> is a portable copy of vga that can be run to dump registers
> on a variety of systems.

Not on the distribution, I think.

-- Richard

Re: [9fans] More Mach64 Problems

[Russ Cox]

No, there aren't ready made tools.  /sys/src/cmd/aux/vga/win
is a portable copy of vga that can be run to dump registers
on a variety of systems.  It is always out of date, but it's
not hard to update the driver you're interested in.

Russ

Re: [9fans] More Mach64 Problems

[Cameron Morland]

La 2001-11-19, Russ Cox skribis:

> There's some code in /sys/src/cmd/aux/vga/mach64xx.c that handles
> sniffing the card and trying to get the timings set right, but it
> appears to fail on some cards, including apparently yours.
> If you're game, I can tell you how to tweak the registers and
> you can sit there poking bits until it works, but it's really an
> open-ended process: sometimes you get it, sometimes you don't.
> It will help a lot if you have graphics working on this system in
> some other operating system that lets you poke at the VGA card,
> to read out a working register dump.  Such systems include Windows 9x,
> Linux, and FreeBSD but not Windows NT or 2000.

I have Debian installed on the box. Just tell me what to do and I'll do
it. This box is completely junk, so it doesn't matter if it's out of
service for a long time.

+----------------------------------------------------------
| PGP http://www.eng.uwaterloo.ca/student/cjmorlan/pgp.txt
| cjmorland@uwaterloo.ca
|
| Necessity is the plea for every infringement of human freedom.
| It is the argument of tyrants; it is the creed of slaves.
|     --William Pitt
+----------------------------------------------------------

Re: [9fans] More Mach64 Problems

[Russ Cox]

The problem is in fact the memory timings, but it's ever so difficult
to figure out the exact bits without sitting there at the machine.
(It's basically trial and error, which is much harder when it takes a
day or two to do a round trip.)

There's some code in /sys/src/cmd/aux/vga/mach64xx.c that handles
sniffing the card and trying to get the timings set right, but it
appears to fail on some cards, including apparently yours.
If you're game, I can tell you how to tweak the registers and
you can sit there poking bits until it works, but it's really an
open-ended process: sometimes you get it, sometimes you don't.
It will help a lot if you have graphics working on this system in
some other operating system that lets you poke at the VGA card,
to read out a working register dump.  Such systems include Windows 9x,
Linux, and FreeBSD but not Windows NT or 2000.

I tried to help someone via email with this Mach 64 problem a month
ago and it just didn't work, even with working register dumps to
compare against.

In the case of the person with the similar S3 problem, that was more
easily fixed because the S3 chipset handles most of those calculations
for you.  We just had to add the card type to the driver.

Russ

Re: [9fans] More Mach64 Problems

[bcrawford]

I have /exactly/ the same issue here with another mach64.  Its not
exactly the same card, but it has the same issue.  One of the things I
intend to try is running though the vagdb and hacking the id strings so
as to fake the card type till i find one that works.  (that part assumes
that the id strings there do something aside from merely identifying the
driver to use as 'yet another mach64', someone please let us know if
this is/is-not the case).
Several months ago, somone posted these symptoms with an (s3? (I found
it on groups.google.com, but cant find it since)) card.  The fix
desribed a small hack to the drivers to zero the timings somehow. (this
is hard to do without a workign display from which to modify the drivers
& recompile... is there a howto on recompiling your kernel from a
foriegn system?)
Anyways, the short story is that this symptom has been seen and dealt
with in the past by someone, so /someone/ has some idea how to deal with
it.. if that someone is still out there, we would appreciate hearing
from you.


Cameron Morland wrote:

> Hello,
>
> I managed to acquire a Mach64 Rage II PCI card, which appears to be
> supported. Using a new download, I get
>
> aux/vga: controller not in /lib/vgadb
> 0xC0000 55 AA 40 EB 7B D9 5A 00 00 00 00 00 00 00 00 00  U.@.{.Z.........
> 0xC0010 00 00 00 00 00 00 00 00 58 01 00 00 00 00 49 42  ........X.....IB
> 0xC0020 4D 00 37 7C 01 65 5A 08 00 00 00 00 00 00 00 00  M.7|.eZ.........
> 0xC0030 20 37 36 31 32 39 35 35 32 30 00 00 9A 7B 57 D5   761295520...{W.
> 0xC0040 33 3F 00 3C 00 00 00 00 0A 01 00 00 00 00 00 00  3?.<............
> 0xC0050 31 39 39 36 2F 31 32 2F 30 34 20 31 35 3A 34 39  1996/12/04 15:49
> 0xC0060 00 00 00 00 E9 42 51 00 E9 37 51 00 E9 DF 12 00  .....BQ..7Q.....
> 0xC0070 00 00 00 00 00 00 00 00 00 00 00 00 9A 7B 57 D5  .............{W.
> 0xC0080 E9 ED 00 0D 0A 41 54 49 20 4D 41 43 48 36 34 20  .....ATI MACH64
> 0xC0090 47 54 42 20 42 49 4F 53 20 50 2F 4E 20 31 31 33  GTB BIOS P/N 113
> 0xC00A0 2D 33 38 32 30 34 2D 31 30 32 20 0D 0A 00 28 43  -38204-102 ...(C
> 0xC00B0 29 20 31 39 38 38 2D 39 36 2C 20 41 54 49 20 54  ) 1988-96, ATI T
> 0xC00C0 65 63 68 6E 6F 6C 6F 67 69 65 73 20 49 6E 63 2E  echnologies Inc.
> 0xC00D0 42 4B 33 2E 38 2E 31 2F 33 2E 30 33 33 20 67 74  BK3.8.1/3.033 gt
> 0xC00E0 67 70 31 6A 2E 61 73 20 36 20 4D 41 43 48 36 34  gp1j.as 6 MACH64
> 0xC00F0 47 54 50 43 49 55 59 4D 55 32 34 31 30 30 2D 34  GTPCIUYMU24100-4
>
> Searching in vgadb, I find
>
>         0xC00E1="MACH64GTPCIUYMU"                       # ATI Rage II PCI
>
> Which has the wrong offset, but the right string. So I replaced the
> 0xC00E1 with 0xC00EA. Now I get a video signal, but instead of being
> the entire screen it is the first 1/3 of the screen, repeated 3
> times. The mouse moves over the whole screen (due to the hardware
> cursor). I've tried some adjustment to the monitor size and type, but
> no changes were apparent. (I'm running at 640x480x8 right now.)
>
> Actually it's not exactly the first 1/3. More precise would be:
>
> 0123 4567 89AB CDEF
>
> turns into
>
> 0123 4012 3451 2345
>
> ie the three bands are slightly different.
>
> Suggestions?
>
> +----------------------------------------------------------
> | PGP http://www.eng.uwaterloo.ca/student/cjmorlan/pgp.txt
> | cjmorland@uwaterloo.ca
> |
> | The easiest way to get shot is to carry a gun.
> |     --Atticus Finch
> +----------------------------------------------------------

Re: [9fans] More Mach64 Problems

[Matt Senecal]

Have you tried adding the offset and string for the ATI MACH64 GTB BIOS? Not
sure it will work, but just a thought...

Re: [9fans] More Mach64 Problems

[Dan Cross]

In article <Pine.LNX.4.33.0111151304410.10844-100000@burns> you write:
>Actually it's not exactly the first 1/3. More precise would be:
>
>0123 4567 89AB CDEF
>
>turns into
>
>0123 4012 3451 2345
>
>ie the three bands are slightly different.
>
>Suggestions?

Sounds like it might be a clock miscalculation, but I'm not sure.  I'll
let the real experts say more.

	- Dan C.

[9fans] More Mach64 Problems

[Cameron Morland]

Hello,

I managed to acquire a Mach64 Rage II PCI card, which appears to be
supported. Using a new download, I get

aux/vga: controller not in /lib/vgadb
0xC0000 55 AA 40 EB 7B D9 5A 00 00 00 00 00 00 00 00 00  U.@.{.Z.........
0xC0010 00 00 00 00 00 00 00 00 58 01 00 00 00 00 49 42  ........X.....IB
0xC0020 4D 00 37 7C 01 65 5A 08 00 00 00 00 00 00 00 00  M.7|.eZ.........
0xC0030 20 37 36 31 32 39 35 35 32 30 00 00 9A 7B 57 D5   761295520...{W.
0xC0040 33 3F 00 3C 00 00 00 00 0A 01 00 00 00 00 00 00  3?.<............
0xC0050 31 39 39 36 2F 31 32 2F 30 34 20 31 35 3A 34 39  1996/12/04 15:49
0xC0060 00 00 00 00 E9 42 51 00 E9 37 51 00 E9 DF 12 00  .....BQ..7Q.....
0xC0070 00 00 00 00 00 00 00 00 00 00 00 00 9A 7B 57 D5  .............{W.
0xC0080 E9 ED 00 0D 0A 41 54 49 20 4D 41 43 48 36 34 20  .....ATI MACH64
0xC0090 47 54 42 20 42 49 4F 53 20 50 2F 4E 20 31 31 33  GTB BIOS P/N 113
0xC00A0 2D 33 38 32 30 34 2D 31 30 32 20 0D 0A 00 28 43  -38204-102 ...(C
0xC00B0 29 20 31 39 38 38 2D 39 36 2C 20 41 54 49 20 54  ) 1988-96, ATI T
0xC00C0 65 63 68 6E 6F 6C 6F 67 69 65 73 20 49 6E 63 2E  echnologies Inc.
0xC00D0 42 4B 33 2E 38 2E 31 2F 33 2E 30 33 33 20 67 74  BK3.8.1/3.033 gt
0xC00E0 67 70 31 6A 2E 61 73 20 36 20 4D 41 43 48 36 34  gp1j.as 6 MACH64
0xC00F0 47 54 50 43 49 55 59 4D 55 32 34 31 30 30 2D 34  GTPCIUYMU24100-4

Searching in vgadb, I find

        0xC00E1="MACH64GTPCIUYMU"                       # ATI Rage II PCI

Which has the wrong offset, but the right string. So I replaced the
0xC00E1 with 0xC00EA. Now I get a video signal, but instead of being
the entire screen it is the first 1/3 of the screen, repeated 3
times. The mouse moves over the whole screen (due to the hardware
cursor). I've tried some adjustment to the monitor size and type, but
no changes were apparent. (I'm running at 640x480x8 right now.)

Actually it's not exactly the first 1/3. More precise would be:

0123 4567 89AB CDEF

turns into

0123 4012 3451 2345

ie the three bands are slightly different.

Suggestions?

+----------------------------------------------------------
| PGP http://www.eng.uwaterloo.ca/student/cjmorlan/pgp.txt
| cjmorland@uwaterloo.ca
|
| The easiest way to get shot is to carry a gun.
|     --Atticus Finch
+----------------------------------------------------------