🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22150

Re: Byte ordering

#22150
From: Frank Korzeniewski
Date: Sun, 04 Feb 1990 23:26
49 lines
3313 bytes
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)
Technical Details
Message-ID: <1117@mtxinu.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mtxinu!frk
References: <9656@spool.cs.wisc.edu> <1990Feb2.215421.24894@utzoo.uucp> <131201@sun.Eng.Sun.COM> <1116@mtxinu.UUCP> <131204@sun.Eng.Sun.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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