Hello,

I still haven't received a single ID report of SPXg/gt on VS 4000/60. 

Update regarding SPXg support ... it's more along the lines of good 'n'
bad jokes but anyhow:

The good:
- console text renders nicely
- framebuffer window switching finally works as expected without my
oversights crashing the kernel
- accelerated functions (block copy & block set) work
- I managed to track down a HW problem with "grainy" display
(framebuffer can't keep up with the CPU)
- as with (LC)SPX I set up nice HW cursor instead of SW-emulated one

The bad:
- accel functions break just about everything once they're done
executing; window switching no longer works, framebuffer memory layout
organization apparently changes somehow (?), framebuffer memory becomes
read-only
- this braindead hardware needs delays in order not to lose data sent by
the CPU

Possible solution #1: pre-render font glyphs in all variants
(underlined, etc.) in off-screen memory and copy them instead of
attempting to render them after hell breaks loose (i.e. first time one
of accel functions is called). This would actually speed up rendering
which takes ungodly amount of CPU cycles and writes across that slow
LCG_emulating bus attachment and wouldn't manifest "grainy" display at
all. The downside is that no color changing in framebuffer would be
possible so the only way to alter text colors would be through RAMDAC
colormap entires *or* by using accelerated masked copy operation.
Compared to #2 its performance will increase with the size of the font
glyph.

Possible solution #2: abandon HW acceleration and go for dumb FB
operation only. Before anybody suggests this let me illustrate this with
an example: *_show_screen() function (which spends 99.99% of time
plotting all pixels that fit into virtual character cell matrix in
framebuffer memory) takes literally seconds to complete. Yes, that means
~5 seconds for console switch on Vaxstation 4000/96, the epytome of
tabletop Vaxen-speed. This is 160x68 character cells so you can figure
out the time necessary for 1 screen scroll (cat
text_file_with_68_lines_and_160_chars_per_line > /dev/ttyw0) - 67 * ~5
seconds (~5 minutes). Few minutes for simple ls- al on a small directory
anyone ? The performance of this alternative doesn't change with the
size of the glyph as every single fuggin pixel needs to be painted
manually, while waiting for card to catch up with the CPU without
getting a heart attack. Alternative #1 should be blazing fast compared
to this (few seconds for same operation at most) but it has its
drawbacks (as mentioned above).

Either way it's a lose-lose situation. SPXgt should be pretty much the
same, except that it is likely to be 3-4 times slower than SPXg. Unless
I find a way around this obstacle I will complete the driver to support
one of these alternatives so that SPXg will be usable at the very least.

Conclusion: it really isn't worth installing SPXg/gt in your Vaxstation.
if you have 4000/60 then you're much better off with LCG, which is
simply amazing (in its more common 8 plane incarnation; less common 4
plane ones are quite unappealing because of workarounds that must be
taken in order to get them to work well) and can be supported very
efficiently in NetBSD (Michael Hitch has my old driver which is somewhat
incomplete - all it needs it adding HW cursor support which is rather
trivial + few bugfixes; I can provide all the information needed to fix
that driver properly).

If you have 4000/9x you're still better off with the default LCSPX; it
consumes less power and it is faster (as in: few times faster, not just
few percent faster) than SPXg, plus all the acceleration features needed
for console but HW font rendering work are supported without any fuss.
This driver will support it and will be faster and more
"inquisitive-user-friendly" than the old lcspx.c which some of you got
from me was (it was extremely cryptic and full of debugging code which I
plan to trim away now so that somebody might actually benefit by looking
at the code). As an added bonus this driver will work on Vaxstation
3100's and VXT2000's SPX framebuffer if somebody can be bothered to add
the proper framebuffer identification code for this hardware (I don't
have it so I have no idea how to detect it; if you *know* your box has
SPX inside you could just compile the driver into your kernel withut any
of that detection mumbo-jumbo and it should work regardless). 

If you're literally stuck with SPXg/gt and cannot afford a spare
alternative from eBay (they're going cheap when they show up) or one of
your fellow Vaxenthusiasts  then by all means do yourself a favor and
use VMS instead :-)

Opinions ?

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