Subject: Re: Any experince with this alpha?
To: Matt Thomas <email@example.com>
From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
Date: 08/26/1996 23:50:22
> > As a small data point, here are some numbers for a TurboChannel sfb
> > (which uses an earlier generation of the chip that the multia uses)
> > running on a DECstation 5000/260 (R4400). With an XFree86/X11R6 X
> > server (which treats the sfb as a dumb framebuffer) I get around 20k
> > xstones. With the DEC supplied X server, this jumps to over 120k
> > xstones.
> Digital has supplied to the XFree86 folks the accelerated ddx layer for
> the TGA X server (primarily for Linux). If anyone is really interested
> in a fast X server, I suggest you talk to them.
(1) as of the last public source release, i couldn't find
any TGA sources in the XF86 public distribution.
(2) i'm on their beta list, and i've yet to see TGA support
listed among their patches.
(3) with respect to how they're planning to do server support
for the Alpha in general, i've sent several pieces of
mail inquiring, and never received a response from anyone
other than users, who pretty much said "works great on
linux." It was suggested at one point that there should
be an XFreeAXP server, which i agree with, given my desire
to support 'wacked out' frame buffers (i.e. various TC
stuf), that makes little sense in the 'normal' XFree86
tree, and also given my desire to support LK-series
keyboards on TC machines (which makes absolutely no sense
in the context of XFree86). As far as I can tell, the
"strategy" is to hack XFree86 linux sources until they
work on the Alpha. That doesn't make any sense for
NetBSD/Alpha, since the i386 and Alpha console code
is so different, and given my previously stated desires.
(4) many of the hacks mentioned in (3) were, as of the last
time i looked at the source code (~3.1.2E) of the form
that they would not be portable to different machines in
the Alpha family that NetBSD/Alpha currently supports.
In particular, they were hard-coding address ranges
for PCI dense memory, and the values that they were using
worked on the 2106x, but would not work on the 21164.
In other words:
As of the last time I looked, XFree86 supports various PCI VGA boards
on the Alpha, but does not support TGA, and the means used to support
those VGA boards were both inadqeuate for the purposes of
NetBSD/Alpha, and ill-thought-out.
(If somebody from the XF86 group takes issue with this
characterization, uh, well, you can start your reply by responding to the
questions and points that i raised in my message to axp@Xfree86.org,
dated June 26, 1996, message ID <firstname.lastname@example.org>,
and resent, dated July 4, 1996, message ID
<email@example.com>. Yes, i am a bit annoyed about
being blown off, especially since i went out of my way to provide
early copies of my hacked TGA server to XF86 people who wanted them.)
To those who have been asking about PCI VGA server support under
NetBSD/Alpha: no, there is currently nothing being done, and the
problems listed above, along with my lack of time, are largely the
reason. Sorry to have taken so long to reply to your queries.
> This also means with little effort you can have a fast X server for SFB
> based systems (Flamingo/Sandpiper or DECstations 5000) since the TGA and
> SFB chipsets are very similar (mostly just different buses). [Of course,
> this begs the question of why we TGA console but no SFB console under
Because a console needs input.
There is currently no support in NetBSD/Alpha for LK-series keyboard
input, or for mouse input. I've been hoping that a pmax person would
convert the z8530 driver to use the (relatively new)
machine-independent 8530 code, and produce something that works on
both that pmax and on the alpha. Unfortunately, that's not happened
yet, but i can't harp on people for not having enough free time to
work on projects for me. 8-)
There currently _does_ exist a working SFB driver for NetBSD/Alpha...
However, because there's no LK keyboard support, console is
effectively output only. "not bloody useful." Once the keyboard
support is there, it wouldn't be hard to hook the keyboard/SFB up as
the "real" console, but until the keyboard works, i'd say that that
is counter-productive, if not dangerous. (Actually, i'm not entirely
telling the truth -- the NetBSD/Alpha SFB driver works, but doesn't
include any real support for the RAMDACs found on the SFB. but that
code already exists for the TGA, and could be copied, or, better,
shared. Still, that's a SMOP, whereas making the keyboard driver go
is a fair bit harder, since the z8530 driver currently used by
NetBSD/Alpha should be taken out and burned.)