The screen only scrolls when procedures are in a curtain order

[youngstorm]

I'll show the code 2 different ways. The screen SHOULD scroll in both cases. Any ideas on whats going on here?
Mike

In this case the program works great. The start procedure is on top.

[BITS 16]
[ORG 0x0100]

[SECTION .text]

Start:
    mov al, 3
    call scrollXLines
    mov ax, 4c00h
    int 21h
    
scrollXLines:
    mov CX, 0
    mov DX, 7924
    mov bh, 7h
    mov ah, 6h
    int 10h
    ret

In this case start is at the bottom and it just clears the screen.

[BITS 16]
[ORG 0x0100]

[SECTION .text]


scrollXLines:
    mov CX, 0
    mov DX, 7924
    mov bh, 7h
    mov ah, 6h
    int 10h
    ret

Start:
    mov al, 3
    call scrollXLines
    mov ax, 4c00h
    int 21h

[Tight_Coder_Ex]

Unlike executables that have a lot more information for startup and memory allocation, your binary file always starts at the origin. So in case #2 you have to put a jump instruction ahead of scrollXLines so it will actual start where you expect

[Tight_Coder_Ex]

The reason the screen clears is because AL is probably a value greater than the number of lines your displaying so it is actually scrolling that number of lines (value of AL).

[youngstorm]

So execution does not nessesaily begin with "start:"? If this is true al would be some random value.

[Tight_Coder_Ex]

Only when object files are linked to create an executable EXE, then the PE header has lots of information in it of where to start, memory allocation etc. An example would be link /entry:start /stack:0x8000 /heap:0x8000 ?.obj. In your case you didn't have to link because you've only got one file and that image is ready to go at 100H

All registers are of random values in any program on startup unless you've taken steps in preamble to set to know values before entering the main body of program

[youngstorm]

kool! thanks bro