> > > You would need to get XFree86 working on
> > > SPARC.  Do you really want to mess with that can of worms?
> > 
> >         How much more of a can or worms is it going to be compared to
> >         macppc and alpha,

> Both already do and in thier native OSes. :o/ And in linux...

I've been following this recurring thread for a year or so.  I'm not a
good enough programmer to help, but I can efficiently sum up what others
have said.

The Atari Hades also has PCI, according to the web pages.  There may also
be some embedded boards in there that take mezzanine PCI cards.  PCI is
showing up all over---I think a good MI way to get X-on-PCI would be
great, even if it required you to buy one specific graphics card chipset.

Supporting _one_ board on all the ports first, perhaps not using exactly
the XFree86 framework if it's too difficult, would be both more useful and
more interesting than, say, getting half of the Xfree86 4.0 servers to
work on sparc64 only.

Indeed, that's just what Tru64 does---last I heard, it only supported
about three chipsets.  Linux/Alpha claims to support all the XFree86
drivers and uses a different approach from Tru64, but many of the XFree86
drivers just don't work under Linux/Alpha's PeeCee-I/O emulation, and the
Linux/Alpha work did not generalize to Linux/macppc at all.  I think
that's why Linux is now backing off that path and working on ____fb
drivers like matroxfb or machfb or whatever.

I think Tru64 (or ___fb) is a better goal-orienter for sparc64, because it
works consistently, and because supporting just one chipset would be
easier to generalize to alpha, atari, macppc, mvme-whatever than some
ambitious thunking-glue trying to make all the cards work at once.

One of the big problems is that PeeCee and Mac PCI cards expect to be
initialized by their proprietary firmware before they're used.  An ATI
card for the Mac will not work in a PeeCee, nor the other way around.  The
alpha platform attacks this issue by including an 8086 emulator in the SRM
console.  They run the PeeCee initialization ROM with binary emulation. 
You will have to deal with this issue to write generic PCI video support: 

  o use an x86 emulator and support PeeCee cards.  This is hard, because
    you need to emulate the whole PeeCee like xmame does for other arcade
    hardware.  You need to emulate whatever PeeCee BIOS hooks the card's
    ROM needs.  Also, the ROM won't know how to find the various PCI
    busses in real computers---you need to simulate a PeeCee-architecture 
    computer with just one PCI bus, one card in it.  

    My experience with the emulation code in SRM is that it's quite poor
    and nearly useless.  Because it's necessarily so, or becuase they did
    a bad job?  I'm not sure.

  o write a Forth interpreter and support Mac/Sun cards.  This sounds like
    a lot more work, since I think it becomes equivalent to rewriting a
    BSD-licensed OpenFirmware kit.  It might be interesting and
    otherwise-useful work.  It's arguably the ``right'' solution because it
    might make supporting other Mac/Sun PCI cards on PeeCee's and Ataris
    easier.  It might attract people like Brains, Inc., and the DNARD
    project to NetBSD, since they could use BSD-OF rather than paying for
    a FirmWorks license.  Or, the entire project might fail explosively
    due to vendor OF shoddyness. Mostly, people seem too anxious to have
    working code in their hands to recommend this approach.

    The ``right'' solution isn't automatically the one that's the most
    difficult and takes the longest to finish.

  o learn all about one particular chip, and write your own initialization
    code for it by hand.

I favour the last solution.  I think it's easiest, least likely to fail,
and best-suited to the blooming embedded-systems market.  However, it will
further constrain the list of supported cards.

I really don't think that's a problem, though.  The cards are inexpensive
so it's easy to buy the card you're told that you need, and notPeeCee's
tend to keep the same onboard graphics chips for a long time. 

-- 
Miles Nordin / +1 720 841-8308