Assembly code to display string

Question

I have this piece of assembly code to accept a string and display the string back.

My problem is I'm not able to figure out how exactly the name is getting stored in name1 as we are using buff to store the input from the user.

I know that

buff label byte
maxchar db 50
readchar db 0
name1 db 48 dup(0)

is got something to do with this. But I'm not able to understand the working.

.model small
.stack
.data
    buff label byte
    maxchar db 50
    readchar db 0
    name1 db 48 dup(0)
    m1 db 10,13,"enter name: $"
    m2 db 10,13,"your name is: $"
.code
    mov ax, @data
    mov ds, ax
    lea dx, m1
    mov ah, 09
    int 21h
    lea dx, buff
    mov ah, 10
    int 21h


    mov ah,0
    mov al, readchar
    add ax, 2
    mov si, al
    mov buff[si],24H ;ascii code for $ to terminate string
    lea dx, m2
    mov ah, 9
    int 21h
    lea dx, name1
    mov ah, 09
    int 21h

    mov ah, 4ch
    int 21h
end

please help!

thank you.

Solution

The input is read using DOS function 0x0a (or decimal 10 in your code) which performs buffered input. The DS:DX parameter points to a buffer that has the following format, which is at the location labeled buff (or equivalently maxchar) in your program:

 offset    meaning
 ------  -------------
    0      Number of bytes available for the input data (starting at offset 2)
    1      A location for DOS to put the number of characters read into the buffer
    2      A buffer of bytes that can hold the number of characters specified in 
           offset 0

So in your code, DS:DX points to buff which indicates that up to 50 characters can be put into the buffer at name1. It looks like the code has a potential problem since there are only 48 bytes in the buffer, but the data structure indicates that there are 50 bytes. So it's possible that the input will overwrite the first two bytes of m1. Now, assembly programs - especially old ones - are known for performing all sorts of tricks to save space. m1 isn't used after the call to DOS function 0x0a, so this might have been intentional (but if so, I'm not sure why more of m1 wasn't made available). I'd guess that it's unintentional, and the bug just never manifested into anything noticeable.