Am I using the Graphics Buffer correctly?

[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: [Select]

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

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]

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

according to that, mode 06h is 640x200 monochrome

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

[Johnpaul Humphrey]

I see what interlacing is. that would explain why my pixels were rectangular. They were double stacked. That means the behavior I observed was normal.
Eventually, I want to map a font on the screen. interlaced means more code, I think.
If I had a sprite stored at say 0xA000 That was 8 rows tall the fastest way I could think of mapping it would be, (assuming a BIT a character and an 8x8)

Code: [Select]

mov ebx, 0b8000h ;RBIL says B800, but B8000 seems to be correct.
mov si, 0xA000
mov cx, 4
halfA:
lodsb
mov byte [ebx], al
lodsb   ;skip row for interlacing
add ebx, 1
loop halfA
mov si, 0xA001
mov ebx, 0bcb00h ;half way if my calcs are correct.

halfB:
lodsb
mov byte [ebx], al
lodsb   ;skip row for interlacing
add ebx, 1
loop halfB

mode 13h comes recommended. If I just want/need monochrome, does a monochrome mode have any advantages, or are they primarily historical?

[ShaiHulud]

mode 13h comes recommended. If I just want/need monochrome, does a monochrome mode have any advantages, or are they primarily historical?

the first machine I played with was an IBM model PS2 (think Macintosh, monitor/motherboard/drives molded into one case, but with an 8086 and a hard drive, definitely not as pretty ) which came with MCGA, that supported the monochrome and CGA modes (320x200 4 color), and the 320x200 256 color mode. Most other video chips of the time were EGA, which also supported the mono, cga and 16 color hires modes, but not the 256 color modes. Soon vga chips came after supporting the 256 color modes, then VESA kicked in and supervga cards started appearing. A lot of the machines of the time used the hires monochrome modes for word processing (google WordPerfect), CAD, paint software. It was rare for games to use the monochrome modes. I can think of only one I ever played that used it, the first SimCity. When 286 started hitting the market, a version of Geos (like the commodore 64 one!) was made, and truly used the protected mode on that chip, almost a proper multitasking system (i say almost...its hard to multitask anything decently at 25mhz). It ran in hires monochrome as well, and did a windowed gui much like macintosh or c64 geos. I only remember it because it had one of the best printing apps of the time, it made spectacular printouts with just a dot matrix printer

A common trick that was used a lot for video routines: lookup tables. make an array of offsets into video memory, one entry per scanline for each row. Use the lookup to speed things up some in your loop, and you wont have to split your code up for the interlacing. if you're clever enough, you could make a macro that preinitializes it for you at compile time. And if i remember correctly, at 640x200, thats only 16k of memory...you should have enough video ram to do page flipping, aka double buffers. If you can manage to tweak the video regs, you could do some realtime stuff

[Johnpaul Humphrey]

Thanks for the help so far!
I will try to implement that, and if I come up with some cool macro, I will post it.
I think this solves my problem.
I

[Johnpaul Humphrey]

I think I am going to switch to mode 11h. It does not appear to be interlaced and appears to be a conventional size of 640x480.
640x200 seems a bit odd.

My question has been answered. The behavior I was experiencing was a mixture of the wrong size and interlacing.

I am marking the thread as solved.
EDIT:
There does not appear to be a way to mark a thread as solved. If I can't figure out how maybe I shouldn't be programming.