Subject: Re: Any experince with this alpha?
To: Matt Thomas <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-alpha
Date: 08/26/1996 19:12:31
In message <>Matt Thomas writes
>> 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.

It's ... nice... that the accelearated ddx layer is available.
I'd kind of hoped to aim for an Xws-like user/kernel interface (as X11R6
and I think R5 used on Ultrix) on NetBSD/pmax and NetBSD/vax.  That may
not be compatible with whatever user/kernel interface XFree86 has.

It also doesn't help with the turbochannel PixelStamp/ i860 2-d and
3-d framebuffers (PMAG-C, -D, -E, iirc), which also aren't yet
supported by netbsd on any platform.

>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). 

I thought the TGA functionality was a strict superset of the sfb?

> [Of course,
>this begs the question of why we TGA console but no SFB console under

No lk-201-to-ASCII translation (and no mechanism to redirect
scc input streams to such translation) in the Alpha kernel.

The SFB  is a supported console on TC pmaxes.  Pmaxes use the
rcons "machine-independent"   glass-tty-on-framebuffer interface.
Alphas use wscons, which is richer and can handle (S)VGA text modes
as well as raw pixels.  If I had any spare time, NetBSD/vax would get
rcons-based fb support for the pmax-like 3100 framebuffer, qvss, and
qdss.  If anyone _really_ wants to kill off qvss-style in-kernel
pointer-tracing and cursor-sprite movement and shared-memory
input-event ring-buffer, now is the time to speak. I'm afraid it
may still make sense on microvax-IIs, for performance reasons.
(anyone  really want vaxstation-100 support? I hope not..)