nanogui: Thread: Strange bug in ELKS and MicroWindows

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

Greg Haerr ####@####.#### writes:

   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

There's no need to actually modify the byte: mov al,[bx]; mov [bx],
al; should work just as well.

   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.

Sure, it's possible that your code is being called reentrantly or some
other routine is reading or writing the screen.

Is there a reason you don't want to use version 1?

	   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.

That's truly bizarre, and I can't comment on why that would help.