Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mtxinu!frk
From: frk@mtxinu.COM (Frank Korzeniewski)
Newsgroups: comp.arch
Subject: Re: Byte ordering
Message-ID: <1117@mtxinu.UUCP>
Date: 4 Feb 90 23:26:31 GMT
References: <9656@spool.cs.wisc.edu> <1990Feb2.215421.24894@utzoo.uucp> <131201@sun.Eng.Sun.COM> <1116@mtxinu.UUCP> <131204@sun.Eng.Sun.COM>
Reply-To: frk@mtxinu.UUCP (Frank Korzeniewski)
Organization: mt Xinu, Berkeley
Lines: 49

In article <131204@sun.Eng.Sun.COM> david@sun.com (POP-TARTS CONTAIN SLACK!!) writes:
#In article <1116@mtxinu.UUCP> frk@mtxinu.UUCP (Frank Korzeniewski) writes:
#>I have written bitblt and graphics routines for an EGA on an 80386, and I
#>consider this in"consistency" to be a serious mistake.  You cannot take
#>advantage of 32 bit shifts when the bits are laced back and forth thru
#>the 32 bit word.
#
#I'm not familiar with EGA, but it sounds like the problem is something
#beyond inconsistent pixel and byte order.  Certainly the bits that make up
#each pixel should be contiguous, but once you've managed that, the order
#of the pixels within the word is not critical.

Okay, the following is a map of the coorespondence between the cpu
(register or memory) and the video memory.  Video memory is numbered
with the bit order that will show up on the screen. I.e., v0 is the
leftmost pixel, v1 is to its right, v7 is followed on its right by
v8, and so on.  The cpu bit numbering is based on which bits move
into which other bits when a shift operation is performed.  B0 moves
into b1's position, ... b7 moves into b8's position, and so on,
when a single bit left shift is done.

        |---------------------------------------------------|
        |       order of bits in a word in cpu memory       |
        |   byte 3   |   byte 2   |   byte 1   |   byte 0   |
        | b31 .. b24 | b23 .. b16 | b15 ..  b8 | b7  ..  b0 |
        |---------------------------------------------------|
        | v24 .. v31 | v16 .. v23 | v8  .. v15 | v0  ..  v7 |
        |   byte 3   |   byte 2   |   byte 1   |   byte 0   |
        |           order of bits in video memory           |
        |---------------------------------------------------|

The important thing to note is that is you do a 16 bit rotate right on
the half-word containing v8..v15,v0..v7, then v7 will move into the
position occupied by v8.  The converse is true for left rotates.  This is
very important in bitblt for aligning bitfields prior to writing them into
memory.  This works very well when you are dealing with the data on the
basis of 16 bit words.  This same procedure falls apart when you try to do
it on a 32 bit word scale.  There is no shift instruction on the 386 that
will move v7 into v8, and also move v15 into v16, and also move v23 into v24.
As a consequence you can at most use 16 bit quantities when dealing with
video memory data.

This is an example of single bit pixels.  For multi-bit pixels, you would
have to bank switch in the other bits.  The EGA only allows aggregate pixel
access, one bit plane at a time.  You can access a 4 bit pixel as a single
quantity, but only ONE of these at a time.  EGA was not your basic high
proformance graphic design.

Frank Korzeniewski     (frk@mtxinu.com)