Subject: Re: PX/PXG and Neon project (beating the dead horse again)
To: None <port-pmax@netbsd.org>
From: Andy Doran <ad@fionn.sports.gov.uk>
List: port-pmax
Date: 04/17/2000 13:24:43
Toru Nishimura <nisimura@itc.aist-nara.ac.jp> wrote:

> PXG i860 is driven by passing 'command packet' in reserved RAM area in
> which both CPU and i860 share.

Sort of. The PXG also has a PixelStamp. It's possible to drive that directly
(stamp command packets located in the SRAM), or let the i860 manage it. The
code that runs on the i860 is loaded by the Xserver at start-up. Otherwise,
it's inactive. Ultrix makes [part of] the Xserver's address space available
to the i860 (it's paged in and out of the SRAM).

The two cards could share an Xserver that ignores the i860. The main
obstacles that I found are:

- The packet-done interrupts don't get through reliably enough, and on the
  PXG, they don't seem to come through at all (STIC interrupts are routed
  through the co-processor on the PXG). Polling on completion *sucks*
  performance wise.

- I don't understand the format of the two clipping retangles passed in the
  packet. I've tried all sorts of combinations. So, hardware clipping is out
  of the question.

I have the beginnings of a from-scratch Xserver. I also have a port of
Xpxpmax. The latter is buggy, and performance *really sucks* (most
everything is done with a hacked cfb layer and the STAMP_PUTSPANS
primative).

I am willing to release the source to both if someone wants it.