NASM Forum > Other Discussion

Am I using the Graphics Buffer correctly?

(1/2) > >>

Johnpaul Humphrey:
Hi all,
I recently got into assembly again.
I started out using Linux system calls, but I felt distanced from the actual computer, so I decided to get into bare metal. I want to write programs for computers instead of operating systems.
I started out with text mode, and that went fairly smoothly. (smoothly means I was able to correct the errors in my code)
I have been writing my code in a text editor (vi)
Then assembling them with the following command
nasm -f bin boot.asm
Then running them on QEMU
qemu-system-i386 boot

So I decided to get into graphics.
My goal is very simple: create a checkerboard of black and white pixels.
Graphics Mode 6h seemed to suit my purpose. 320x200x2
I wrote the following code:

--- Code: ---bits 16
org 0x7c00
init:
        mov ah, 00h ;change graphics mode
        mov al, 06h ;320x200x2
        int 10h ;bios graphics service

        mov ebx, 0xb8000 ;start of video
        mov cl, 0 ;row counter
rows:
        cmp cl, 200
        je end
        add cl, 1 ; should this be 2 to compensate for two rows? I see no difference when running it at 2 or 1.
        mov ch, 0 ;colum counter
        .colsa: ;row one
        cmp ch, 80 ; 320 / 4 = 80
        je .colsb
        add ch, 1
        mov word [ebx], 0xaaaa
        add ebx, 1
        jmp .colsa
        .colsb: ;staggered row
        cmp ch, 160
        je rows
        add ch, 1
        mov word [ebx], 0x5555
        add ebx, 1
        jmp .colsb
end: jmp $ ;does this infinite loop run the risk of screen burn? sonce it is a virtual machine, I do not really care.
times 510-($-$$) db 0
dw 0xAA55 ;boot signature

--- End code ---

When I run it in QEMU on Linux, I notice something interesting happens.
It does every other line, then comes back and fills in.
I was able to observe this by lowering the compare values.
I have observed the same behavior in Mode 4h.

Is this how the video buffer actually works, or is this a faulty implementation, or better yet, a programming oversight? (My programming is 90% oversight  :) )
Also, how is my coding style?
Is there a better platform to test on than QEMU?
If I should focus on one question per thread, it would be my first one.

I know this is not directly related to NASM. Is there a better forum to post this on?
I know that there is a lot of knowledge on this forum about things related to assembly, so I thought I would post.

Thanks in advance for any help,
Johnpaul

ShaiHulud:
http://www.columbia.edu/~em36/wpdos/videomodes.txt

according to that, mode 06h is 640x200 monochrome

debs3759:

--- Quote from: ShaiHulud on July 07, 2020, 01:02:50 PM ---http://www.columbia.edu/~em36/wpdos/videomodes.txt

according to that, mode 06h is 640x200 monochrome

--- End quote ---

That is right, it's the same mode table Ralf Brown's Interrupt List has. I can't see a 320x200x2 anywhere. I would opt for 640x480 mono (mode 11h) for what the OP is trying to do, as it is more useful for VGA and later. Personally, for simple graphics, I would start with 640x480x16, as that uses a nibble for the colours (ie 0Fh for white, 0 for black). The link above will show you all the options, if you want EGA or something older :)

debs3759:
Also, the described behaviour indicates that it is an interlaced mode.

Johnpaul Humphrey:
I did want monochrome, but I think I will go with a colored mode, for a byte per pixel.
My mistake appears to be two-fold.
1. I got the wrong screen size.
2. it is an interlaced mode. (I will have to research that)
I will look at the provided links.
I am comfortable with mode 3h, but I want to get into graphics mode.

Thanks for all your replies.
Johnpaul Humphrey

Navigation

[0] Message Index

[#] Next page