Hello,

Status report on SPXg driver: I have collected all the information
needed to implement accelerated hardware scrolling (block set & block
copy) so all I have to do now is to actually sit down and write the code
:-) I suppose I'll be doing that next week when I finally put this board
into my development machine (and when weather cools down a bit during
some storm or something). Performance of SPXg is likely to be similar or
slower than LCSPX and SPXgt is likely to be roughly three times slower
than SPXg.

SPXg is functionally similar to (LC)SPX but not quite the same (LCSPX
and SPX are identical from software's point of view). This means I'll be
making a separate driver for SPXg (and hopefully SPXgt eventually, if I
get ahold of it) that will be sharing most of the code with LCSPX driver
- but then again code is duplicated among all Vaxstation 4000
framebuffer drivers. This should allow for additional hardware support
for SPXg/gt should we ever come across some useful docs.

In the meanwhile I could use some feedback from people who either have
VS 4000/60 with SPXg/SPXgt framebuffer or those with VS 4000/9x (any
framebuffer):

>>> e 25800000 (for VS 4000/9x)

or

>>> e 20020000 (for VS 4000/60)

will return a value that I'm interested in. Please remember to note the
position of S3 switch (serial or glass console) AND also include the
output of 

>>> show config

pertaining to framebuffer (that would be SP3D or LCSPX). Please send
this info to me directly.

This should help me with proper hardware detection - something that
LCSPX driver lacks at the moment, currently it just assumes that VS
4000/9x equals "LCSPX inside", this is one of the few things that still
needed fixing before I submit the driver to be included into the main
tree. Michael Hitch: when/if you get around to completing LCG driver
make sure you add a similar check, it's also missing there AFAIK.

SPX support, while apparently working when S3 switch is set to glass
console mode and causing stray interrupts when it's not, will only be
supported through a small&quick do-it-yourself hack as far as I'm
concerned - this is because I don't have a VS 3100 machine with SPX;
others are welcome to add proper hardware detection later as needed,
I'll provide all the clues and pointers necessary, it should be less
than hour of work. (LC)SPX driver will still be named lcspx.c but that
doesn't mean that this same code (with few additional machine type and
framebuffer type checks, obviously) wouldn't work on 'plain' SPX
hardware. Consequently there probably won't be any "spx.c" file or
"spx0" option in NetBSD kernel configuration file, don't let that
confuse you into thinking that VS3100 SPX board is not supported. It is,
if you only move your butt a little :-)

Blaz Antonic
-- 
Hi! I'm a signature virus!
Copy me into your signature to help me spread!