Hello,

First my apologies for bugging those of you with no interest in recent
LCG developments :-)

With huge effort of Michael Hitch Vaxstations with LCG should support
full wscons operation (font changing, color setting), automagically
detect all currently known )= reported to me) LCG types (and few that
have not been reported) and be able to run X server operating as dumb
framebuffer by the time 2.0 comes out.

The next logical step would be hardware acceleration of 2D functions but
documentation unfortunately doesn't exist. However, yesterday i finally
managed to complete diagrams of functions fiddling with LCG command FIFO
(the HW acceleration part of the LCG), from top to bottom level. The
goal is to rewrite all LCG accelerator test fucntions and see what kind
of results are expected by test routines and based on that figure out
what kind of command packets need to be sent to FIFO for certain HWE
accelerated operation to take place. This work is not anywhere close to
being done but i came across an interesting function yesterday and
another interesting function today.

1: The function i found yesterday apparently does block moves - for
testing purposes it writes some data to source lcoation, clears
destination lcoation, issues 8 command packets and checks destination
lcoation; unless it matches data at source lcoation it exits with what
appears to be an error message.

2: The function i found today takes two source parameters and a function
parameter, does some magic and compares the result of doing something to
the two source with third parameter. Here's the table of what it does
during testing in form of f(p1, p2, func) ? p3:

f(0xff, 0xff, 0) ? 0
f(0xf0, 0x55, 1) ? 0x50
f(0xf0, 0x55, 2) ? 0x05
f(0xff, 0x22, 3) ? 0x22
f(0xff, 0x55, 4) ? 0xaa
f(0xaa, 0x55, 5) ? 0xaa
f(0xff, 0x55, 6) ? 0xaa
f(0xf0, 0x55, 7) ? 0xf5
f(0xaa, 0x55, 8) ? 0
f(0xff, 0x55, 9) ? 0x55
f(0x55, 0x55, 11) ? 0xff
f(0xff, 0x55, 12) ? 0xaa
f(0x55, 0x55, 13) ? 0xff
f(0xaa, 0x55, 14) ? 0xff
f(0, 0, 15) ? 0xff

These look awfully like X server boolean operations. As a matter of fact
p3 is X server boolean function func's anticipated result if p1 =
source2 and p2 = source1 for the operation, fitting the description in
ALL 15 cases (operation $10, dest = NOT source2 is missing in tests, not
sure why). By the way, the operation is performed on an array of 0x30
sequental bytes, not a single byte and so is the check of results.

It is reasonable to assume we now know which command packet sequences
perform the most crucial console and X server operations, meaning some
LCG HW acceleration is quite possible eventually. There are few more
things that need to be sorted out (all operations in testing are
performed on single-line source, no source i've come across so far is
bigger than 256 bytes, not rectangles so i',m not yet sure how to
describe a rectangle in source or destination command packet).

There are other functions which i have already rewritten down to command
packet sequences but i fail to see the relation between source and
anticipated destination data so i don't have a slightest idea as to what
those functions do. I'll post results (all test functions rewritten in
pseudo code for easier understanding) when i'm finished ... this will
probably take a while ... a long while. I'm not sure whether i should
focus on getting some basic acceleration working first or deciphering
all command packet types and operations instead :-/

Blaz Antonic