nanogui: Strange bug in ELKS and MicroWindows
Subject:
Strange bug in ELKS and MicroWindows
From:
Greg Haerr ####@####.####
Date:
28 Jul 1999 16:59:36 -0000
Message-Id: <01BED8E8.8A755470.greg@censoft.com>
I've been listening to the (sparse) comments about the need
for a faster VGA driver and am now responding with another
MicroWindows driver written in asm for ELKS. This one
operates faster, although the 8086 still doesn't exactly
blaze when it comes to graphics.
However, I've encountered a _strange_ bug that I can't quite
seem to get my hands around.... The microwindows
driver uses the VGA read-modify-write that sets the
VGA latches to draw a pixel. Assume that DS:BX is
the byte in screen ram, there's two ways to do this,
depending out OUTs that setup the VGA:
1) ...setup mask register with bit to write
or [bx],al ; rmw the vga
or 2)
mov al,[bx] ; read
mov al,[bp+8] ; modify
mov [bx],al ; write
If option two is used, which was my first version, then the mouse
leaves little "droppings" on the screen when it's being moved, every
once in a while.
If I recode (2) with cli/sti around it, it works.
If I recode (2) as follows, (assume now ES:BX is screen byte)
mov al,es:[bx]
mov al,[bp+8]
mov es:[bx],al
It seems as though ELKS is trashing user DS during mouse movement!!!
However, if I use option (1), it works, although the screen is only accessed
with a single DS move.
So, I can't imagine that ELKS is trashing DS, or other programs
would crash. The only other possibility is that the VGA hardware is being
accessed during interrupt time in ELKS, inbetween instructions in option (2).
Anyone quite familiar with ELKS interrupt internals is welcome
to comment on this... I do seem to remember some code where the VGA
text mode location was accessed during interrupt time to indicate activity,
but it seems to be commented out. The three move instructions need to be
sequential, or it won't work.
Greg
