1
.Model small

.stack 64

.data

mesg db "What is your name? ",'$'

.code 

Main PROC far 

mov ax,@data

mov ds,ax        


; clear the screen 

mov ax,0600h

mov cx,0

mov dx,184FH

int 10h

; change to text mode 

mov ax,3

int 10h

; place cursor on row=15 col=20

mov ah,2

mov dx,1521

int 10h

; Prompt Mesg into the screen 

mov ah,09

mov dx,offset mesg

int 21h 



Main ENDP

end Main

an image of the error that happened to me

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Michael Aziz
  • 13
  • 2
  • 2
    `mov dx,1521` is a decimal number, not hex. Was that supposed to be `mov dx,1521h` to have DH=0x15 and DL=0x21? Or `mov dx,0F15h` to have DH=15 and DL=21 (decimal)? IDK if that fully accounts for the weirdness you're seeing, maybe I was hasty closing it as a duplicate. – Peter Cordes Dec 12 '20 at 13:23
  • If fixing that doesn't fix the problem, we can reopen. But for now there's no need to have more people spend time looking at it in this state, I think. – Peter Cordes Dec 12 '20 at 13:28
  • i know the problem....iam doing that on purpose, i just couldn't understand why it overflow 'me?' up not down like the rest of the line.....because mov dx,1521 means row 5 and 241 col which means 5*80+241=641, so, that should mean row=641/80=8 and col=641%80=1 and thats right for most of the message but not right for the last 3-chars "me?" – Michael Aziz Dec 13 '20 at 02:49
  • The comments in your code say "row=15 col=20", so either the code or the comment is a bug. Apparently it's the comment that's the bug; I guess you removed the `h` from `1521h` or something and forgot to update the comment. But yes, `1521` is `0x05f1`. I'd recommend writing your constant in a way that doesn't make it look like a bug, and updating the comment to match. – Peter Cordes Dec 13 '20 at 06:54

1 Answers1

2

Your code is invoking what C users would call "undefined behaviour". It seems like you accidentally forgot the h in your constant and now you are curious why your program behaves the way it does. As you calculated yourself in the comments, you told the BIOS to put the cursor into column 241. With the video BIOS in your PC (emulator), this works as expected until column 255, that is for 15 characters. When the BIOS increments the cursor column from 255 to 0, it notices the carry and applies an emergency fixup: it injects a newline (as it also would have injected a newline when it increments the cursor column from 79 to 80 in 80 character modes). This makes the cursor jump from row 5, column 256 to row 6, column zero.

You should be aware that printing a string using the DOS function invokes the console output driver (INT 29) for every single character, and the console output driver forwards each character individually to the BIOS "print TTY character" service (INT 10, AH=0E). Each character printing needs to load the current cursor position, print a single character and update the cursor position. The cursor position is the only state held between the printing the characters. That's why the string is not just printed character by character to the screen position indicated by your invalid cursor position, but it jumps to a completely different (but now validly described) position after printing a couple of characters.

Michael Karcher
  • 3,803
  • 1
  • 14
  • 25