Greetings !

> First: I'm on vacation for the next 2 weeks. So don't expect any answer
> soon - not that I would write anything that deserves an answer anyhow...
And it seems that I need it... :-(

> > > > Other bit-depths work analogously.  If you're going to fix the rasops code, though, the first
> > > > thing that needs doing is to make it properly endianness-independent.
> > > Sounds awful but needs to be done.
> > Yep.  And you need to allow for the CPU and the framebuffer being
> > different endiannesses, and there being multiple framebuffers of different
> > endiannesses installed at once and so on.  All good fun.
> So what - we need to know what endianness the framebuffer expects and
> code the rest in C-macros like hton and so on... would be bitchy to
> debug but sounds rather straight forward... btw. I never saw a
> framebuffer that disagreed with it's host CPU regarding endianness...
> not that this would mean anything.
I shouldn't write after midnight, sorry. Have to correct myself: I
remember lots of "big endian" framebuffers, ( left bit -> left pixel ).
Most took a whole byte for a pixel even with only one plane though ( HP
Catseye ).

bye
Michael