nanogui: Microwindows for Hercules
Subject:
Re: Microwindows for Hercules
From:
Ben Pfaff ####@####.####
Date:
16 Jul 1999 22:25:54 -0000
Message-Id: <87yaggi69b.fsf@pfaffben.user.msu.edu>
Chipzz ####@####.#### writes:
> A good idea, almost. The BOGL library performs this for the packed pixel
> modes, but the VGA requires OUT instructions inbetween memory accesses,
> so it can't run on a generalized bit-depth algorithm in planes mode. (The VGA
> design has to be seen/studied to be believed, I've never seen such a complicated
> piece of hardware for something kinda-conceptually simple)
Hmm then that's something that could be checked for in between STOSB
instructions (or the like). We could for example use something like this
(just an idea), where ? is a flag that isn't used (maybe the carry flag?):
PUSH flags register
CLI
...
{If out needed} ST?
...
{Bresenham}
...
STOSB {or something like that, like OR}
LOOPN?
JN? :End
...
{Perform OUT}
...
LOOP
...
:End
...
POP flags register
We could of course also use something else than a flag, like a register,
if Bresenham doesn't already use all of them...
Just an idea, I never did VGA 4 bit programming, I always used mode 13h.
Hmm, it's a good idea. Unfortunately, I don't think that it will work
out. The OUTs that need to be performed are not the same for each
pixel; rather, they are dependent on what needs to be written. At any
rate, adding those jumps will kill your performance on 8086-class
processors, since it increases code size (read Abrash's _Zen of
Assembly Language Programming_).
Most VGA16 code ends up looking something like this:
Set up lots of internal VGA registers with OUT operations.
Read a byte from the memory byte that contains the pixel(s) of
interest to load the internal VGA latches.
Write an arbitrary byte whose value doesn't matter to the same
memory byte.
Start over.
Which may be more of a problem is if we would use res > 320x200x256. These
don't fit in one page, and we would have to do page swapping. (Except if
we got a linear framebuffer). But there won't be many 8088-80286 that sup-
port those res anyway..
Actually there's semi-standard 800x600x16 support that works on most
SVGA controllers using the same VGA16 code; that requires 800 * 600 /
2 = 240,000 bytes memory, but it's mapped into 800 * 600 / 8 = 60,000
bytes memory at one bit per pixel with the VGA16 code.
