I wrote

> Is there anyone out there who knows how the SUNW,leo ("zx")
> framebuffer works [...]?  The hardware I have doesn't seem to be
> behaving in accordance with the docs I have....

This was neither the doc's fault nor, in most respects, the hardware's.
It seems the gcc version I was using for this takes

	struct foo { ... } __attribute__((__packed__));

to imply also __aligned__(1) - or at least it does four one-byte
loads/stores rather one four-byte load/store to access a four-byte
field.  (I finally got desperate enough to look at the assembly code.)

The leo does not like this.

Once I persuaded it to generate a single st/ld instead of four
stbs/ldubs, everything started working a whole lot better.

There are still a few problems remaining, but the only one that could
get in the way of the original goal is that something is flaky with the
RAM holding blue channel data; it looks as though the low bits of the
blue channel flake out in thin vertical stripes (about every eighth, or
maybe tenth, pixel - perhaps one of the chips has something akin to a
stuck-at-0 fault).  (The other problems are mostly lack of
documentation; while I haven't gone through the doc I have with a
fine-tooth comb looking for it, I've yet to find a description of how
provide the data for lighting calculations and suchlike.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B