3

Basically, I have to "paint" a simple picture of a house in my DOS Box using assembly code. Part of this picture involves a sky in the background and a green patch of grass underneath. I was told I can accomplish this by any method I wanted, but I was never taught much about x86 graphics mode. So, I decided to accomplish the goal in mode 3 (80x25 text mode). Basically, I am using loop structures to print empty spaces with highlights.

I've managed to paint the sky (along with several unintentional randomly assorted letters on the screen). However, my next instruction is to move the cursor to a certain position to the screen and then print the grass portion, but this does not happen. I'm not sure if NASM is simply ignoring the instruction, if it has no way to get to it, or if my code is wrong. Any insight would be appreciated.

Here is my code: 

org 100h

section .text

mov ah, 0       ;change to 80x25 color text mode
mov al, 3
int 10h

drawSky:

mov ax, 0b800h  ;color activate display page
mov ds, ax
mov cx, 2000    ;80x25 = 2000 words
mov di, 0
mov ax, 3320h   ;blank spaces with blue background
call    fillbuf

drawGrass:

mov ah, 2       ;move cursor
xor bh, bh      ;page number 0
mov dh, 14h     ;move to row 20
mov dl, 0h      ;move to column 0
int 10h

mov ax, 0b800h  ;color activate display page
mov ds, ax
mov cx, 1000
mov di, 0
mov ax, 2220h   ;blank spaces with blue background
call    fillbuf

fillbuf:

mov [di], ax    ;character in al, attribute in ah
add di, 2       ;go to next word
loop    fillbuf
rkhb
  • 14,159
  • 7
  • 32
  • 60
Brandon Copeland
  • 125
  • 1
  • 2
  • 9

1 Answers1

2

fillbuf needs to end with a ret instruction.

What is happening now is that you are invoking fillbuf, it displays the first text, and then it proceeds to execute random bytes past the end of your program, which is basically a crash. It never returns, so nothing else is printed.

The random bytes are interpreted as instructions, and since ds: already points to the video ram, the video ram receives some random garbage, thus the cute "unintentional randomly assorted letters" that you see. Just keep in mind for the future, that when you see those, you have a crash.

Also, since your program crashes, you are most probably receiving some kind of error, which you have not told us anything about. When asking questions on stackoverflow, please make it a point to mention any error messages that you might be seeing, they tend to be a bit pertinent.

Also, since you are directly accessing the video ram, you have no use for the cursor. You would have needed to place the cursor at a certain position if you were to use some other interrupt which emits text at the cursor location. But you are not doing that, so the cursor is of no use to you. If your instructor requires you to use the cursor, then he is also expecting you to use some interrupt instead of directly accessing the video ram.

Mike Nakis
  • 56,297
  • 11
  • 110
  • 142
  • 3
    Something you might want to point out is that even if you add `ret` in _fillbuff_, you still have to exit your program before _fillbuf_ so that you don't execute into _fillbuf_. Since this is a COM program I'd make sure they put a `ret` just before _fillbuf_ to ensure the main part of the program exits when it should. – Michael Petch Dec 09 '15 at 21:57
  • @MichaelPetch (sssh! let him get to the next error and post another stackoverflow question!) C-:= – Mike Nakis Dec 09 '15 at 21:58
  • Same type of problem, just a different place. I think fixing them both here is a good idea. – Michael Petch Dec 09 '15 at 21:59
  • @MichaelPetch yes, it is. I am just joking. – Mike Nakis Dec 09 '15 at 22:00
  • Technically the cursor wouldn't have moved in the OPs case because it never executed that code since it ran off the edge of the _fillbuff_ routine ;). Your comment about the need for the cursor is correct, but let us say they did want a flashing cursor somewhere on the screen (hypothetically) then there is yet another issue not mentioned, and that is the foreground and background colors are set the same thus rendering an invisible cursor. They use both attribute 0x22 and 0x33 when painting the screen. Both are forgeround=background – Michael Petch Dec 09 '15 at 22:17
  • There is no error, neither in the assembler nor in DOS Box. Yes there is a crash, but there is no error code or exception that was ever thrown at me. – Brandon Copeland Dec 09 '15 at 22:38
  • Okay, that's possible. (I think it is rare, but it is possible.) – Mike Nakis Dec 09 '15 at 22:42
  • @MikeNakis Also, the return statement fixed the problem. Thank you. However, we're not quite on the same page regarding the cursor. Unless I'm misunderstanding, you say I'm not trying to print text out to the screen, but that technically _is_ what I'm doing. I wanted to move the cursor to column 0 (and some arbitrary row near the bottom) to print the grass after I've printed the sky. – Brandon Copeland Dec 09 '15 at 22:47
  • Let me put it this way: by directly accessing the video ram, you are able to print text anywhere you want on the screen, regardless of where the cursor is located. So, why do you think you need it? Also, once you are done printing, the cursor is still in the same position, so the cursor knows nothing about what you are doing. So, your stuff and the cursor are completely unrelated. – Mike Nakis Dec 09 '15 at 23:10
  • Also, please do not forget to "upvote" & "accept" the answer. – Mike Nakis Dec 09 '15 at 23:12
  • Okay, I see now. Also, after fiddling with it some more, I found out that I control where it's printed by moving a certain hex value into ds (through ax) where I have the comment "color activate display page." That is actually a snippet of code my instructor had written out, but I'm not sure what each nybble represents. All I know now is that it is responsible for putting the text in a certain location. Could you maybe explain that part? My instructor doesn't seem to have any notes on it. – Brandon Copeland Dec 09 '15 at 23:14
  • Look here: http://stackoverflow.com/questions/32972051/in-c-how-do-i-write-to-a-particular-memory-location-e-g-video-memory-b800-in – Mike Nakis Dec 09 '15 at 23:22