[9fans] NeoMagic MagicGraph 128 (NM2070, 10c8/0001)

[9fans] NeoMagic MagicGraph 128 (NM2070, 10c8/0001)

[Dave Eckhardt]

vgadb and aux/vga explicitly rejects this chip as unsupported.

Sure enough, if add the "appropriate" case statements there and
in the kernel I get a screen full of hash.

Any hints on what's wrong?  Does whoever declared the chip
unsupported remember whether there was a known problem which
was the obstacle, or just a lack of debugging cycles?

Dave Eckhardt

Re: [9fans] NeoMagic MagicGraph 128 (NM2070, 10c8/0001)

[jmk]

Looking at the XFree86 code (which is is the only documentation
available, I believe), you see the 2070 is the odd man out, requiring
extra fiddling. I suspect that whoever did the original code thought
it wasn't worth the effort for what looks like the oldest chip
especially if there was no hardware on hand to test it on.

It's probably not hard to add, start with
.../xc/programs/Xserver/hw/xfree86/drivers/neomagic/neo_driver.c
and just step through it looking for the string "2070" and comparing
what's there to what's in /sys/src/cmd/aux/vga/neomagic.c and
/sys/src/9/pc/vganeomagic.c. It looks like you may have to alter
the latter of those for acceleration.

--jim

On Sat Jan  8 17:57:01 EST 2005, davide+p9@cs.cmu.edu wrote:
> vgadb and aux/vga explicitly rejects this chip as unsupported.
> 
> Sure enough, if add the "appropriate" case statements there and
> in the kernel I get a screen full of hash.
> 
> Any hints on what's wrong?  Does whoever declared the chip
> unsupported remember whether there was a known problem which
> was the obstacle, or just a lack of debugging cycles?
> 
> Dave Eckhardt

Re: [9fans] NeoMagic MagicGraph 128 (NM2070, 10c8/0001)

[Dave Eckhardt]

Based on Jim's advice, I've been working on extending the neomagic
driver to support the primeval NM2070.  I've made a bunch of progress
but would appreciate some informed advice.

The good news so far is:
* kernel code restructured to deal with 2070's single PCI memory region
* timing problems specific to 2070 fixed by ramming undocumented constants
  into "shadow registers" the way XF86 does
* existing cursor code correctly draws and positions
* rio paints grey desktop background
* the BIOS battery-status icon paints & unpaints when requested

For the moment I disabled acceleration (by not filling in scr->fill or
scr->scroll) since the 2070 doesn't do that the same way as later chips.

Current bad news:
* there is a band of bad pixels near the bottom of the screen which looks
  sort of like a random-dot stereogram
* when I right-button to bring up the rio menu, parts of it appear scattered
  to the right and below the correct place (30-ish little scraps, each fairly
  recognizable).  When the menu pops down, the scattered parts are un-drawn
  and the desktop is gray again.

Does the latter look like any standard mistake to anybody, e.g., "you're
not really in linear mode", "there is a scanline padding problem", etc.?

Is it possible that the memory layout is weird in some way which requires
acceleration for the chip to work?  If that seems likely I can push on that
for a while.

Dave Eckhardt