INT 21h AH=0Bh answers one question: is input waiting at standard input? It returns AL = FFh if a key is there and 00h if not, without waiting and without taking the key. A following read then returns at once.

prints: 00 FF x
MOV     AH, 0Bh       ; DOS: is a key waiting?
INT     21h           ; AL = 00h: the buffer is empty
CALL    HEX2
MOV     CX, 2D78h     ; "x": scan code 2Dh, ASCII 78h
MOV     AH, 05h       ; BIOS: store a keystroke in the keyboard buffer
INT     16h
MOV     DL, " "
MOV     AH, 02h       ; DOS: print the character in DL
INT     21h
MOV     AH, 0Bh
INT     21h           ; AL = FFh: now there is one
CALL    HEX2
MOV     DL, " "
MOV     AH, 02h       ; DOS: print the character in DL
INT     21h
MOV     AH, 07h       ; 0Bh left the key there: take it out
INT     21h
MOV     DL, AL
MOV     AH, 02h       ; DOS: print the character in DL
INT     21h
 
HEX2    PROC    NEAR  ; print AL as two hex digits
PUSH    AX
MOV     CL, 4
SHR     AL, CL        ; the high digit first
CALL    NIB1
POP     AX
AND     AL, 0Fh       ; then the low one
CALL    NIB1
RET
HEX2    ENDP
NIB1    PROC    NEAR  ; print AL (0-15) as one hex digit
ADD     AL, "0"
CMP     AL, "9"
JBE     NIB2
ADD     AL, 7         ; 10-15 become "A"-"F"
NIB2:
MOV     DL, AL
MOV     AH, 02h
INT     21h
RET
NIB1    ENDP

The example asks twice, before and after putting an "x" into the BIOS keyboard buffer with INT 16h AH=05h, then reads the key to show it was still there. The usual use is a loop that works until a key is pressed:

WORK1:
; ... one step of the work ...
MOV     AH, 0Bh  ; DOS: is a key waiting?
INT     21h
TEST    AL, AL
JZ      WORK1    ; 00h: no, go on working
MOV     AH, 07h  ; take the key out of the buffer
INT     21h

Take the key out when the loop ends. Left in the buffer it is read by whatever reads next, often COMMAND.COM, which then shows it at the prompt.

Pitfalls

MS-DOS checks for Ctrl+C here as in the other console services: a waiting Ctrl+C makes 0Bh print ^C and end the program. That is a feature in a work loop, where Ctrl+C stops it, and a surprise in a program that wanted to read Ctrl+C itself; INT 21h AH=06h with DL = FFh asks the same question without the check, taking the key at the same time. With input redirected from a file, 0Bh reports FFh until the file ends. The BIOS has the same test one level down, INT 16h AH=01h, which also tells which key is waiting. DOSBox-X slows each 0Bh call down a little, as a real DOS would be, because some old games depend on that.