Bochs VGA bug? :^(

[m]

Hi all.

I find my VGA initialization code doesn't work properly on Bochs.

It works unexpectedly on Bochs(but doesn't crash it). On a real machine it just works the way I expect.

After hours of debugging and commenting I finally lock the point that goes wrong. I write a model for the "wrong" point as a boot sector program (see the code below), so that you can easily try it to see what it does to your Bochs.

Code: Select all

org 0x07C00 

;general initilization

cli
mov ax,cs
mov ds,ax
mov fs,ax
mov gs,ax
sti

;clear the screen(I assume it's 80*25 text mode)

mov ax,0xb800
mov es,ax
xor di,di
xor al,al
mov cx,(2*80*25)    ;go through Page 0
rep stosb    ;char=NUL,foreground=0,background=0

;program the palette,RGB=(14,20,44)

mov dx,0x3c8
xor al,al    ;index=0,which is the background color
out dx,al

mov dx,0x3c9
mov al,14
out dx,al
mov al,20
out dx,al
mov al,44
out dx,al

jmp $ 

times 510-($-$$) db 0 
dw 0xaa55 

The screen SHOULD be totally blue because it's filled with background whose index equals 0. But on Bochs for Linux or Win32 only a few cells become blue, at least it happened to me.

I'm just wondering how it works on your Bochs. Would anyone bother trying this? Thanks in advance.

[urxae]

With the following bochsrc:

Code: Select all

floppya: 1_44=bootsect.bin, status=inserted

cpu: count=1, ips=12000000
vga_update_interval: 300000

(and your source compiled by nasm to bootsect.bin) it seems to work as you say it should (entire screen a blueish color). However, if I change or remove those last two lines it doesn't (only 2 character blocks are blue). So perhaps it's something timing-related?

[Kevin McGuire]

http://www.geocities.com/SiliconValley/ ... smstos.htm

I modified it for protected mode and using thirty-two bit registers since I really did not want to take a whole bunch of time but maybe this helps.

Code: Select all

; Setup my segment in protected mode.
mov ax, 0x10
mov es, ax
; Setup the copy destination ES:EDI
mov edi, 0xb8000
; Clear the copy source EAX.
xor eax, eax
; Loop this many times.
mov ecx,(80*25*2)    ;go through Page 0
; Copy from AL to (byte [ES:EDI])
rep stosb    ;char=NUL,foreground=0,background=0

;(This is not programming the palette...---> ) program the palette,RGB=(14,20,44)

; WRITE TO THE DAC ONE COLOR VALUE AT INDEX 0
mov dx,0x3c8
xor al,al    ;index=0,which is the background color
out dx,al
mov dx,0x3c9
mov al,0
out dx,al
mov al,63
out dx,al
mov al,
out dx,al

It clears the screen and changes the color in the DAC which also shows changed on the screen.

Are you using AL to hold the address instead of the value?
AL - source
ES:EDI - destination (incremented each literation)

[Combuster]

i get the same results using the sample. However, i can get the correct output by adding a delay in the code or writing something else than 0x00 to memory, which probably means the bug is some race condition in the video optimizer.

Although adjusting the DAC in text mode isn't really considered standard practice, you may want to file a bug report for this one...

[~]

How is it possible that such small snippets make Bochs malfunction and other OS'es like Menuet seem to work just as they sould?

[Combuster]

the thing is, when you wait a while and then do more graphical stuff, the graphics will work... At least thats what we all figured to fix the bug.
Normal OSes don't keep the screen in one and the same state - they update it regularly, which would cause bochs to force refreshes making everything show up correctly.

At least, that's my theory.