> It definitely uses DMA; the buffer must be located within the
> first 8 MB of physical space, probably due to addressing limitations
> of the stic.
It also has to be aligned on a 32kB boundary, and you have to start
writing 12 bytes in to allow for microcode generated by the card. This
is all handled for now in px_attach().

I have just about all of the major bits of code written. The OSF code
that you provided me with was *greatly* helpful. It also shows that 
if we support the PMAG-CA, supporting the other cards (PMAG-D, etc.)
is a trivial affair. X server support should be a matter of a few
weeks programming/testing (hacking of the X sources) now that I understand
the cards. If we really wanted to, we could emulate the ioctls and get the
Ultrix Xtm2d server running. My px_packet_intr() routing handles all the
needed bits for X server support.

The major problem I'm facing at the moment is this. I can construct 
a valid packet (to draw a rectangle, scroll or whatever), then hit
the STIC until it's ready to accept the packet. Then I check the STIC poll
register for the buffer that I'm using, and everything's fine there (it
never pukes). The thing I don't understand, and can't see in either the
OSF code or the dissasembly of the kernel on my Ultrix-4.2 box is how the
hell we point the STIC at our ring buffer. Basically it's not DMAing. It
doesn't know where to DMA from.

I'm assuming this is somewhere like ga_data.c or ioconf.c? It's not in
the sources that I have anyway. This is the *only* blocking factor. If
we get this out of the way, then the cards are supported.

Interestingly enough, the test code I hacked up in px.c calls
px_draw_rect() and then px_scoll() which in turn calls px_draw_rect()
again. This generates three packets, howerver px_intr() only gets called
for the third one.

Jonathan, Matthias, any ideas?

Regards,
Andy.