Click above to get retro games delivered to your door ever month!

  If you are in a position to choose between the keyboard services of your
  programming language or the ROM BIOS keyboard services, you could safely
  and wisely use either one. Although in some cases there are arguments
  against using the ROM BIOS services directly, as with the diskette
  services, those arguments do not apply as strongly to the keyboard
  services. However, as always, you should fully examine the potential of
  the DOS services before resorting to the ROM BIOS services; you may find
  all you need there, and the DOS services are more long-lived in the
  ever-changing environments of personal computers.

  Most programming languages depend on the DOS services for their keyboard
  operations, a factor that has some distinct advantages. One advantage is
  that the DOS services allow the use of the standard DOS editing operations
  on string input (input that is not acted on until the Enter key is
  pressed). Provided that you do not need input control of your own, it can
  save you a great deal of programming effort (and user education) to let
  DOS handle the string input, either directly through the DOS services or
  indirectly through your language's services. But if you need full control
  of keyboard input, you'll probably end up using the ROM BIOS routines in
  the long run. Either way, the choice is yours.

  Another advantage to using the DOS keyboard services is that the DOS
  services can redirect keyboard input so that characters are read from a
  file instead of the keyboard. If you rely on the ROM BIOS keyboard
  services, you can't redirect keyboard input. (Chapters 16 and 17 contain
  information on input/output redirection.)

  For our assembly-language example of the use of keyboard services, we'll
  get a little fancier than we have in previous examples and show you a
  complete buffer flusher. This routine will perform the action outlined
  under keyboard service 01H, the report-whether-character-ready service.

  _TEXT           SEGMENT byte public 'CODE'
                  ASSUME  cs:_TEXT

                  PUBLIC  _kbclear
  _kbclear        PROC    near

                  push    bp
                  mov     bp,sp

  L01:            mov     ah,1            ; test whether buffer is empty
                  int     16h
                  jz      L02             ; if so, exit

                  mov     ah,0
                  int     16h             ; otherwise, discard data
                  jmp     L01             ; .. and loop

  L02:            pop     bp
                  ret

  _kbclear        ENDP

  _TEXT           ENDS

  The routine works by using interrupt 16H, service 01H to check whether the
  keyboard buffer is empty. If no characters exist in the buffer, service
  01H sets the zero flag, and executing the instruction JZ L02 causes the
  routine to exit by branching to the instruction labeled L02. If the buffer
  still contains characters, however, service 01H clears the zero flag, and
  the JZ L02 instruction doesn't jump. In this case the routine continues to
  the instructions that call service 00H to read a character from the
  buffer. Then the process repeats because the instruction JMP L01 transfers
  control back to label L01. Sooner or later, of course, the repeated calls
  to service 00H empty the buffer, service 01H sets the zero flag, and the
  routine terminates.

  Among the new things this buffer-flusher routine illustrates is the use of
  labels and branching. When we discussed the generalities of
  assembly-language interface routines in Chapter 8, we mentioned that an
  ASSUME CS statement is necessary in some circumstances, and you see one in
  action here.

  The ASSUME directive in this example tells the assembler that the labels
  in the code segment (that is, labels that would normally be addressed
  using the CS register) do indeed lie in the segment whose name is _TEXT.
  This may seem obvious, since no other segments appear in this routine.

  Nevertheless, it is possible to write assembly-language routines in which
  labels in one segment are addressed relative to some other segment; in
  such a case, the ASSUME directive would not necessarily reference the
  segment within which the labels appear. In later chapters you'll see
  examples of this technique, but here the only segment to worry about is
  the _TEXT segment, and the ASSUME directive makes this fact explicit.