PCjs Machines

Home of the original IBM PC emulator for browsers.

Logo

The New Peter Norton Programmer's Guide to the IBM PC and PS/2

The following document is from the Microsoft Programmer’s Library 1.3 CD-ROM.

The New Peter Norton Programmer's Guide to the IBM(R) PC and PS/2(R)


════════════════════════════════════════════════════════════════════════════

The New Peter Norton Programmer's Guide to the IBM(R) PC and PS/2(R)

By Peter Norton and Richard Wilton

════════════════════════════════════════════════════════════════════════════

PUBLISHED BY
Microsoft Press
A Division of Microsoft Corporation
16011 NE 36th Way, Box 97017, Redmond, Washington 98073-9717

First edition copyright (C) 1985 by Peter Norton
Second edition revisions copyright (C) 1988 by Microsoft Press
All rights reserved. No part of the contents of this book may be reproduced
or transmitted in any form or by any means without the written permission of
the publisher.

Library of Congress Cataloging in Publication Data

Norton, Peter, 1943- .
The new Peter Norton programmer's guide to the IBM PC and PS/2 :
the ultimate reference guide to the entire family of IBM Personal
Computers / Peter Norton and Richard Wilton.

        p.        cm.

Includes index.

1. IBM microcomputers--Programming.  2. IBM Personal Computer.
3. IBM Personal System/2 (Computer system)  I. Wilton, Richard, 1953- .
II. Title.  III. Title: Programmer's guide to the IBM Personal Computers.
QA76.8.I1015N67    1988    88-21104
005.265--dc19                CIP
ISBN 1-55615-131-4

Printed and bound in the United States of America.

1 2 3 4 5 6 7 8 9  FGFG  3 2 1 0 9 8

Distributed to the book trade in the United States by Harper & Row.

Distributed to the book trade in Canada by General Publishing Company, Ltd.

Distributed to the book trade outside the United States and Canada by
Penguin Books Ltd.

Penguin Books Ltd., Harmondsworth, Middlesex, England
Penguin Books Australia Ltd., Ringwood, Victoria, Australia
Penguin Books N.Z. Ltd., 182-190 Wairau Road, Auckland 10, New Zealand

British Cataloging in Publication Data available

Microsoft(R), Flight Simulator(R), and GW-BASIC(R) are registered trademarks
of Microsoft Corporation.

IBM(R), PC/AT(R), Personal System/2(R), and PS/2(R) are registered
trademarks, and Micro Channel(TM), PCjr(TM), and PC/XT(TM) are trademarks of
International Business Machines Corporation.

Norton Utilities(TM) is a trademark of Peter Norton.

────────────────────────────────────────────────────────────────────────────
Project Editor: Megan E. Sheppard
Technical Editors: Bob Combs and Jim Johnson
────────────────────────────────────────────────────────────────────────────



────────────────────────────────────────────────────────────────────────────
Contents

    Introduction

    1       Anatomy of the PCs and PS/2s
    2       The Ins and Outs
    3       The ROM Software
    4       Video Basics
    5       Disk Basics
    6       Keyboard Basics
    7       Clocks, Timers, and Sound Generation
    8       ROM BIOS Basics
    9       ROM BIOS Video Services
    10       ROM BIOS Disk Services
    11       ROM BIOS Keyboard Services
    12       Miscellaneous Services
    13       ROM BIOS Services Summary
    14       DOS Basics
    15       DOS Interrupts
    16       DOS Functions: Version 1
    17       DOS Functions: Versions 2.0 and Later
    18       DOS Functions Summary
    19       Program Building
    20       Programming Languages

    Appendix A: Installable Device Drivers
    Appendix B: Hexadecimal Arithmetic
    Appendix C: About Characters
    Appendix D: DOS Version 4

    Index



────────────────────────────────────────────────────────────────────────────
Introduction

    The world of personal computers has come a long way in the few years since
    the original edition of this book appeared, yet the goal of this book
    remains a simple but ambitious one: to help you master the principles of
    programming the IBM personal computer family. From the time that the first
    IBM Personal Computer (known simply as "the PC") was introduced in the
    fall of 1981, it was clear that it was going to be a very important
    computer. Later, as PC sales zoomed beyond the expectations of everyone
    (IBM included) and as the original model was joined by a sibling or two,
    the PC became recognized as the standard for serious desktop computers.
    From the original PC, a whole family of computers──a family with many
    branches──has evolved. And at the same time the importance of the PC
    family has also grown.

    The success and significance of the PC family has made the development of
    programs for it very important. However, the fact that each member of the
    family differs in details and characteristics from its relatives has also
    made the development of programs for the family increasingly complex.

    This book is about the knowledge, skills, and concepts that are needed to
    create programs for the PC family──not only for one member of the family
    (though you might perhaps cater to the peculiarities and quirks of one
    member) but for the family as a whole──in a way that is universal enough
    that your programs should work not only on all the present family members,
    but on future members as well.

    This book is for anyone involved in the development of programs for the PC
    family. It is for programmers, but not only for programmers. It is for
    anyone who is involved in or needs to understand the technical details and
    working ideas that are the basis for PC program development, including
    anyone who manages programmers, anyone who plans or designs PC programs,
    and anyone who uses PC programs and wants to understand the details behind
    them.


Some Comments on Philosophy

    One of the most important elements of this book is the discussion of
    programming philosophy. You will find throughout this book explanations of
    the ideas underlying IBM's design of the PC family and of the principles
    of sound PC programming, viewed from experience.

    If this book were to provide you with only facts──tabulations of technical
    information──it would not serve you well. That's why we've interwoven with
    the technical discussion an explanation of what the PC family is all
    about, of the principles that tie the various family members together, and
    of the techniques and methods that can help you produce programs that will
    endure and prosper along with the PC family.


How to Use This Book

    This book is both a reading book and a reference book, and you can
    approach it in at least two ways. You may want to read it as you would any
    other book, from front to back, digging in where the discussion is useful
    to you and quickly glancing through the material you don't yet need. This
    approach provides a grand overview of the workings (and the ideas behind
    the workings) of PC programs. You can also use this book as a pure
    reference, and dip into specific chapters for specific information. We've
    provided a detailed table of contents at the beginning of each chapter and
    an extensive index to help you find what you need.

    When you use this book as a random-access reference to the details of PC
    programming, you'll find that much of the material is intricately
    interrelated. To help you understand the interrelationships, we have
    repeated some details when it was practical to do so and have referred you
    to other sections when such repetition was less practical.

What's New in This Edition

    As you might guess, this edition of the Programmer's Guide has been
    brought up to date for the new generation of IBM personal computers: the
    Personal System/2 computers, or PS/2s.

    In some ways this book is more complex and more detailed than the
    original. There's a good reason for this: The newer members of the PC and
    PS/2 family are more complicated computers, and the later versions of DOS
    are more complicated and have more features than their predecessors. It
    was inevitable that this revised version of the Programmer's Guide would
    reflect this greater complexity in the hardware, the ROM BIOS, and DOS.

    Still, you'll find that a few members of the extended PC family aren't
    covered in this book. The PCjr, the XT/286, and the PC Convertible are
    used relatively infrequently, and the PS/2 Model 70 was released too
    recently to be included. Nevertheless, each of these machines is similar
    to one of the PCs or PS/2s whose innards we will examine in detail, so
    this book should be a useful guide even if you are programming a Model 70
    or one of the less widely used PCs.

    Here are some of the changes you'll find in this new edition:

    New video subsystems. Since the original edition appeared, IBM's Enhanced
    Graphics Adapter (EGA) became a de facto hardware standard for PC
    programmers and users. Then the PS/2s introduced two new video subsystems,
    the Multi-Color Graphics Array (MCGA) and the Video Graphics Array (VGA).
    These new video subsystems receive extensive coverage in Chapters 4 and
    9.

    New keyboards. IBM supports a new, extended keyboard with later versions
    of the PC/AT and with all PS/2s. Chapters 6 and 11 have been expanded to
    cover the new hardware.

    A new focus on C programming. For better or worse, the most recent
    versions of DOS have been strongly influenced by the C programming
    language. This influence is even more apparent in such operating
    environments as Microsoft Windows, UNIX, and OS/2──all of which were
    designed by C programmers. For this reason you'll find new examples of C
    programming in several different chapters. Of course, we haven't abandoned
    Pascal and BASIC──in fact, Chapter 20 examines each of these programming
    languages.

    A new perspective on DOS. DOS has evolved into a mature operating system
    whose design can now be viewed with the clarity of hindsight. The past
    several years of working with DOS have helped us view this immensely
    popular operating system with a practical perspective born of experience.
    Our discussions of DOS emphasize which of its features are obsolescent and
    which are pointers to the future.

    Despite these changes, the direction and philosophy of this book remain
    the same. When you write a program for a PC or PS/2, you can actually
    program for an entire family of computers. Each member of the family──the
    PC, the PC/XT, the PC/AT, and all PS/2s──has hardware and software
    components that are identical or similar to those in other members of the
    family. When you keep this big picture in mind, you'll be able to write
    programs that take advantage of the capabilities of the different PC and
    PS/2 models without sacrificing portability.


Other Resources

    One book, of course, can't provide you with all the knowledge that you
    might possibly need. We've made this book as rich and complete as we
    reasonably can, but there will always be a need for other kinds of
    information. Here are some of the places you might look for material to
    supplement what you find here.

    For detailed technical information about the PC family, the ultimate
    source is IBM's series of technical reference manuals. Specific technical
    reference manuals exist for the original PC, for the XT, for the AT, and
    for PS/2 models 30, 50, 60, and 80. In addition, the detailed IBM BIOS
    Interface Technical Reference Manual summarizes the capabilities of the
    Basic Input/Output System in all members of the extended PC family. You
    should know a few things about using these model-specific manuals:

    ■  Information specific to one model is not differentiated from general
        information for the whole PC family. To be sure of the differences, you
        should use common sense, compare the different manuals, and consult
        this book.

    ■  Remember that each new model in the PC family adds new features. If you
        turn to the manual for a later model, you will find information on a
        wide variety of features; if you turn to the manual for an earlier
        model, you'll avoid being distracted by features that do not apply to
        all models in the family.

    There is also an IBM Options and Adapters Technical Reference Manual for
    the various options and adapters used by the PC family, such as different
    disk drives or display screens. Technical information about this kind of
    equipment is gathered into this manual, which is updated periodically.
    (The updates are available by subscription.) Little of the information in
    this technical reference manual is of use to programmers, but you might
    find some parts of interest.

    IBM also publishes technical reference manuals for special extensions to
    the PC, such as PC Network.

    Perhaps the most important of the IBM technical reference manuals is the
    series for DOS. These manuals contain a wealth of detailed technical
    information which we have summarized in this book.

    A number of other sources can provide information to supplement the IBM
    manuals:

    ■  For a somewhat broader perspective on the IBM Personal Computer──one
        that is not focused on programming──see Peter Norton's Inside the IBM
        Personal Computer, published by Robert J. Brady Company.

    ■  For a broader perspective on DOS, see the third edition of Van
        Wolverton's Running MS-DOS, and The MS-DOS Encyclopedia, both published
        by Microsoft Press.

    Because this book covers the subject of PC programming in a broad fashion,
    it can provide you with only a few key details about individual
    programming languages. For details on particular programming languages and
    the many specific compilers for those languages, you will need more books
    than we could begin to list or recommend.

    With these introductory remarks completed, it's time to plunge into the
    task of mastering the principles of programming the PC family!



────────────────────────────────────────────────────────────────────────────
Chapter 1  Anatomy of the PCs and PS/2s

    The Microprocessor
    The 8088 Microprocessor
    The 8086 Microprocessor
    The 80286 Microprocessor
    The 80386 Microprocessor
    The Math Coprocessor

    The Support Chips
    The Programmable Interrupt Controller
    The DMA Controller
    The Clock Generator
    The Programmable Interval Timer
    Video Controllers
    Input/Output Controllers

    Linking the Parts: The Bus
    The Address Bus
    The Data Bus
    Micro Channel Architecture

    Memory
    CPU Address Space
    The System Memory Map

    Design Philosophy

    From the programmer's point of view, all members of the PC family consist
    of a processor, memory chips, and several smart, or programmable, circuit
    chips. All the main circuit components that make the computer work are
    located on the system board; other important parts are located on
    expansion boards, which can be plugged into the system board.

    The system board (Figures 1-1 through 1-3) contains the microprocessor,
    which is tied to at least 64 KB of memory; some built-in ROM programs,
    such as BASIC and the ROM BIOS; and several very important support chips.
    Some of these chips control external devices, such as the disk drive or
    the display screen, and others help the microprocessor perform its tasks.

    In this section, we discuss each major chip and give a few important
    technical specifications. These chips are frequently known by more than
    one name. For example, some peripheral input/output hardware is supervised
    by a chip known as the 8255. This chip is also referred to as the 8255A
    and the 8255A-5. The suffixes A and 5 refer to revision numbers and to
    parts rated for operation at different speeds. For programming purposes,
    any Intel chip part number that starts with 8255 is identical to any other
    chip whose part number starts with 8255, regardless of the suffix.
    However, when you replace one of these chips on a circuit board, note the
    suffix. If the suffixes are different, the part may not operate at the
    proper speed.


The Microprocessor

    In all PCs, the microprocessor is the chip that runs programs. The
    microprocessor, or central processing unit (CPU), carries out a variety of
    computations, numeric comparisons, and data transfers in response to
    programs stored in memory.

    The CPU controls the computer's basic operation by sending and receiving
    control signals, memory addresses, and data from one part of the computer
    to another along a group of interconnecting electronic pathways called a
    bus. Located along the bus are input and output (I/O) ports that connect
    the various memory and support chips to the bus. Data passes through these
    I/O ports while it travels to and from the CPU and the other parts of the
    computer.

    In the IBM PCs and PS/2s, the CPU always belongs to the Intel 8086 family
    of microprocessors. (See Figure 1-4.) We'll point out the similarities
    and differences between the different microprocessors as we describe them.

    ┌────────────────────────────────────────────────────────────────────────┐
    │ Figure 1-1 can be found on p.3 of the printed version of the book.     │
    └────────────────────────────────────────────────────────────────────────┘

    Figure 1-1.  The IBM PC system board.

    ┌────────────────────────────────────────────────────────────────────────┐
    │ Figure 1-2 can be found on p.4 of the printed version of the book.     │
    └────────────────────────────────────────────────────────────────────────┘

    Figure 1-2.  The PC/AT system board.

    ┌────────────────────────────────────────────────────────────────────────┐
    │ Figure 1-3 can be found on p.5 of the printed version of the book.     │
    └────────────────────────────────────────────────────────────────────────┘

    Figure 1-3.  The PS/2 Model 60 system board.

    Model                                Microprocessor
    ──────────────────────────────────────────────────────────────────────────
    PC                                   8088
    PC/XT                                8088
    PC/AT                                80286
    PS/2 Models 25, 30                   8086
    PS/2 Models 50, 60                   80286
    PS/2 Model 80                        80386
    ──────────────────────────────────────────────────────────────────────────

    Figure 1-4.  Microprocessors used in IBM PCs and PS/2s.

The 8088 Microprocessor

    The 8088 is the 16-bit microprocessor that controls the standard IBM
    personal computers, including the original PC, the PC/XT, the Portable PC,
    and the PCjr. Almost every bit of data that enters or leaves the computer
    passes through the CPU to be processed.

    Inside the 8088, 14 registers provide a working area for data transfer and
    processing. These internal registers, forming an area 28 bytes in size,
    are able to temporarily store data, memory addresses, instruction
    pointers, and status and control flags. Through these registers, the 8088
    can access 1 MB (megabyte), or more than one million bytes, of memory.

The 8086 Microprocessor

    The 8086 is used in the PS/2 models 25 and 30 (and also in many IBM PC
    clones). The 8086 differs from the 8088 in only one minor respect: It uses
    a full 16-bit data bus instead of the 8-bit bus that the 8088 uses. (The
    difference between 8-bit and 16-bit buses is discussed on page 12.)
    Virtually anything that you read about the 8086 also applies to the 8088;
    for programming purposes, consider them identical.

The 80286 Microprocessor

    The 80286 is used in the PC/AT and in the PS/2 models 50 and 60. Although
    fully compatible with the 8086, the 80286 supports extra programming
    features that let it execute programs much more quickly than the 8086.
    Perhaps the most important enhancement to the 80286 is its support for
    multitasking.

    Multitasking is the ability of a CPU to perform several tasks at a time──
    such as printing a document and calculating a spreadsheet──by quickly
    switching its attention among the controlling programs.

    The 8088 used in a PC or PC/XT can support multitasking with the help of
    sophisticated control software. However, an 80286 can do a much better job
    of multitasking because it executes programs more quickly and addresses
    much more memory than the 8088. Moreover, the 80286 was designed to
    prevent tasks from interfering with each other.

    The 80286 can run in either of two operating modes: real mode or protected
    mode. In real mode, the 80286 is programmed exactly like an 8086. It can
    access the same 1 MB range of memory addresses as the 8086. In protected
    mode, however, the 80286 reserves a predetermined amount of memory for an
    executing program, preventing that memory from being used by any other
    program. This means that several programs can execute concurrently without
    the risk of one program accidentally changing the contents of another
    program's memory area. An operating system using 80286 protected mode can
    allocate memory among several different tasks much more effectively than
    can an 8086-based operating system.

The 80386 Microprocessor

    The PS/2 Model 80 uses the 80386, a faster, more powerful microprocessor
    than the 80286. The 80386 supports the same basic functions as the 8086
    and offers the same protected-mode memory management as the 80286.
    However, the 80386 offers two important advantages over its predecessors:

    ■  The 80386 is a 32-bit microprocessor with 32-bit registers. It can
        perform computations and address memory 32 bits at a time instead of 16
        bits at a time.

    ■  The 80386 offers more flexible memory management than the 80286 and
        8086.

    We'll say more about the 80386 in Chapter 2.

The Math Coprocessor

    The 8086, 80286, and 80386 can work only with integers. To perform
    floating-point computations on an 8086-family microprocessor, you must
    represent floating-point values in memory and manipulate them using only
    integer operations. During compilation, the language translator represents
    each floating-point computation as a long, slow series of integer
    operations. Thus, "number-crunching" programs can run very slowly──a
    problem if you have a large number of calculations to perform.

    A good solution to this problem is to use a separate math coprocessor that
    performs floating-point calculations. Each of the 8086-family
    microprocessors has an accompanying math coprocessor: The 8087 math
    coprocessor is used with an 8086 or 8088; the 80287 math coprocessor is
    used with an 80286; and the 80387 math coprocessor is used with an 80386.
    (See Figure 1-5.) Each PC and PS/2 is built with an empty socket on its
    motherboard into which you can plug a math coprocessor chip.

    From a programmer's point of view, the 8087, 80287, and 80387 math
    coprocessors are fundamentally the same: They all perform arithmetic with
    a higher degree of precision and with much greater speed than is usually
    achieved with integer software emulation. In particular, programs that use
    math coprocessors to perform trigonometric and logarithmic operations can
    run up to 10 times faster than their counterparts that use integer
    emulation.

    Programming these math coprocessors in assembly language can be an
    exacting process. Most programmers rely on high-level language translators
    or commercial subroutine libraries when they write programs to run with
    the math coprocessors. The techniques of programming the math coprocessors
    directly are too specialized to cover in this book.

╓┌─┌────────────────────┌────────────────────┌────────────────────┌─────────┌►
                            Approximate Range                                Si
    Data Type            (from)               (to)                 Bits      (d
    ───────────────────────────────────────────────────────────────────────────
    Word integer         -32,768              +32,767              16
    Short integer        -2 x 10E9            +2 x 10E9            32
    Long integer         -9 x 10E18           +9 x 10E18           64
    Packed decimal       -99...99             +99...99             80
    Short real           8.43 x 10E-37        3.37 x 10E38         32
    Long real            4.19 x 10E-307       1.67 x 10E308        64        15
    Temporary real       3.4 x 10E-4932       1.2 x 10E4932        80
    ───────────────────────────────────────────────────────────────────────────


    Figure 1-5.  The range of numeric data types supported by the 8087,
    80287, and 80387 math coprocessors.


The Support Chips

    The microprocessor cannot control the entire computer without some
    help──nor should it. By delegating certain control functions to other
    chips, the CPU is free to attend to its own work. These support chips
    can be responsible for such processes as controlling the flow of
    information throughout the internal circuitry (as the interrupt
    controller and the DMA controller are) and controlling the flow of
    information to or from a particular device (such as a video display or
    disk drive) attached to the computer. These so-called device controllers
    are often mounted on a separate board that plugs into one of the PC's
    expansion slots.

    Many support chips in the PCs and PS/2s are programmable, which means
    they can be manipulated to perform specialized tasks. Although direct
    programming of these chips is generally not a good idea, the following
    descriptions will point out which chips are safe to program directly and
    which aren't. Because this book does not cover direct hardware control,
    you should look in the IBM technical manuals as well as in the chip
    manufacturers' technical literature for details about programming
    individual chips.

The Programmable Interrupt Controller

    In a PC or PS/2, one of the CPU's essential tasks is to respond to
    hardware interrupts. A hardware interrupt is a signal generated by a
    component of the computer, indicating that component's need for CPU
    attention. For example, the system timer, the keyboard, and the disk
    drive controllers all generate hardware interrupts at various times. The
    CPU responds to each interrupt by carrying out an appropriate
    hardware-specific activity, such as incrementing a time-of-day counter
    or processing a keystroke.

    Each PC and PS/2 has a programmable interrupt controller (PIC) circuit
    that monitors interrupts and presents them one at a time to the CPU. The
    CPU responds to these interrupts by executing a special software routine
    called an interrupt handler. Because each hardware interrupt has its own
    interrupt handler in the ROM BIOS or in DOS, the CPU can recognize and
    respond specifically to the hardware that generates each interrupt. In
    the PC, PC/XT, and PS/2 models 25 and 30, the PIC can handle 8 different
    hardware interrupts. In the PC/AT and PS/2 models 50, 60, and 80, two
    PICs are chained together to allow a total of 15 different hardware
    interrupts to be processed.

    Although the programmable interrupt controller is indeed programmable,
    hardware interrupt management is not a concern in most programs. The ROM
    BIOS and DOS provide nearly all of the services you'll need for managing
    hardware interrupts. If you do plan to work directly with the PIC, we
    suggest you examine the ROM BIOS listings in the IBM technical reference
    manuals for samples of actual PIC programming.

The DMA Controller

    Some parts of the computer are able to transfer data to and from the
    computer's memory without passing through the CPU. This operation is
    called direct memory access, or DMA, and it is handled by a chip known
    as the DMA controller. The main purpose of the DMA controller is to
    allow disk drives to read or write data without involving the
    microprocessor. Because disk I/O is relatively slow compared to CPU
    speeds, DMA speeds up the computer's overall performance quite a bit.

The Clock Generator

    The clock generator supplies the multiphase clock signals that
    coordinate the microprocessor and the peripherals. The clock generator
    produces a high-frequency oscillating signal. For example, in the
    original IBM PC, this frequency was 14.31818 megahertz (MHz, or million
    cycles per second); in the newer machines, the frequency is higher.
    Other chips that require a regular timing signal obtain it from the
    system clock generator by dividing the base frequency by a constant to
    obtain the frequency they need to accomplish their tasks. For example,
    the IBM PC's 8088 is driven at 4.77 MHz, one-third of the base
    frequency. The PC's internal bus and the programmable interval timer
    (discussed shortly) use a frequency of 1.193 MHz, running at a quarter
    of the 8088 rate and one-twelfth of the base rate.

The Programmable Interval Timer

    The programmable interval timer generates timing signals at regular
    intervals controlled by software. The chip can generate timing signals
    on three different channels at once (four channels in the PS/2 models
    50, 60, and 80).

    The timer's signals are used for various system tasks. One essential
    timer function is to generate a clock-tick signal that keeps track of
    the current time of day. Another of the timer's output signals can be
    used to control the frequency of tones produced with the computer's
    speaker. See Chapter 7 for more information about programming the
    system timer.

Video Controllers

    The many video subsystems available with the PCs and PS/2s present a
    variety of programmable control interfaces to the video hardware. For
    example, all PC and PS/2 video subsystems have a cathode ray tube (CRT)
    controller circuit to coordinate the timing signals that control the
    video display.

    Although the video control circuits can be programmed in application
    software, all video subsystems have different programming interfaces.
    Fortunately, all PCs and PS/2s are equipped with basic video control
    routines in the ROM BIOS. We'll describe these routines in Chapter 9.

Input/Output Controllers

    PCs and PS/2s have several input/output subsystems with specialized
    control circuitry that provides an interface between the CPU and the
    actual I/O hardware. For example, the keyboard has a dedicated
    controller chip that transforms the electrical signals generated by
    keystrokes into 8-bit codes that represent the individual keys. All disk
    drives have separate controller circuitry that directly controls the
    drive; the CPU communicates with the controller through a consistent
    interface. The serial and parallel communications ports also have
    dedicated input/output controllers.

    You rarely need to worry about programming these hardware controllers
    directly because the ROM BIOS and DOS provide services that take care of
    these low-level functions. If you need to know the details of the
    interface between the CPU and a hardware I/O controller, see the IBM
    technical reference manuals and examine the ROM BIOS listings in the PC
    and PC/AT manuals.


Linking the Parts: The Bus

    As we mentioned, the PC family of computers links all internal control
    circuitry by means of a circuit design known as a bus. A bus is simply a
    shared path on the main circuit board to which all the controlling parts
    of the computer are attached. When data is passed from one component to
    another, it travels along this common path to reach its destination.
    Every microprocessor, every control chip, and every byte of memory in
    the computer is connected directly or indirectly to the bus. When a new
    adapter is plugged into one of the expansion slots, it is actually
    plugged directly into the bus, making it an equal partner in the
    operation of the entire unit.

    Any information that enters or leaves a computer system is temporarily
    stored in at least one of several locations along the bus. Data is
    usually placed in main memory, which in the PC family consists of
    thousands or millions of 8-bit memory cells (bytes). But some data may
    end up in a port or register for a short time while it waits for the CPU
    to send it to its proper location. Generally, ports and registers hold
    only 1 or 2 bytes of information at a time and are usually used as
    stopover sites for data being sent from one place to another. (Ports and
    registers are described in Chapter 2.)

    Whenever a memory cell or port is used as a storage site, its location
    is known by an address that uniquely identifies it. When data is ready
    to be transferred, its destination address is first transmitted along
    the address bus; the data follows along behind on the data bus. So the
    bus carries more than data: It carries power and control information,
    such as timing signals (from the system clock) and interrupt signals, as
    well as the addresses of the thousands or millions of memory cells and
    the many devices attached to the bus. To accommodate these four
    different functions, the bus is divided into four parts: the power
    lines, the control bus, the address bus, and the data bus. We're going
    to discuss the subjects of address and data buses in greater detail
    because they move information in a way that helps to explain some of the
    unique properties of the PC family.

The Address Bus

    The address bus in the PC, PC/XT, and PS/2 models 25 and 30 uses 20
    signal lines to transmit the addresses of the memory cells and devices
    attached to the bus. (Memory addressing is discussed more fully on page
    13 and in Chapter 3.) Because two possible values (either 1 or 0) can
    travel along each of the 20 address lines, these computers can specify
    2^20 addresses──the limit of the addressing capability of the 8088 and
    8086 microprocessors. This amounts to more than a million possible
    addresses.

    The 80286 used in the PC/AT can address 2^24 bytes of memory, so the AT
    has a 24-line address bus. The bus in the 80286-based PS/2 models 50 and
    60 also supports 24-bit memory addressing; in the 80386-based PS/2 Model
    80, the bus has 32-bit addressing capability.

The Data Bus

    The data bus works with the address bus to carry data throughout the
    computer. The PC's 8088-based system uses a data bus that has 8 signal
    lines, each of which carries a single binary digit (bit); data is
    transmitted across this 8-line bus in 8-bit (1-byte) units. The 80286
    microprocessor of the AT uses a 16-bit data bus and therefore passes
    data in 16-bit (1-word) units.

    The 8088, being a 16-bit microprocessor, can work with 16 bits of data
    at a time, exactly like its relative the 80286. Although the 8088 can
    work with 16-bit numbers internally, the size of its data bus allows the
    8088 to pass data only 8 bits at a time. This has led some people to
    comment that the 8088 is not a true 16-bit microprocessor. Rest assured
    that it is, even though it is less powerful than the 80286. The 16-bit
    data bus of the 80286 does help it move data around more efficiently
    than the 8088, but the real difference in speed between the 8088 and the
    AT comes from the AT's faster clock rate and its more powerful internal
    organization.

    There is an important practical reason why so many computers, including
    the older members of the PC family, use the 8088 with its 8-bit data
    bus, rather than the 8086 with its 16-bit bus. The reason is simple
    economics. A variety of 8-bit circuitry elements are available in large
    quantities at low prices. When the PC was being designed, 16-bit
    circuitry was more expensive and was less readily available. The use of
    the 8088, rather than the 8086, was important not only to hold down the
    cost of the PC, but also to avoid a shortage of parts. The price of
    16-bit circuitry elements has decreased significantly since then,
    however, and it has become economically feasible to use the more
    efficient 80286 with its 16-bit bus. Furthermore, the 80286 is able to
    use a mixture of 8-bit parts and 16-bit parts, thereby maintaining
    compatibility within the PC family.

Micro Channel Architecture

    The PS/2 models 50, 60, and 80 introduced a new bus hardware design that
    IBM calls Micro Channel architecture. Both the Micro Channel bus in the
    PS/2s and the earlier PC and PC/AT bus accomplish the same task of
    communicating addresses and data to plug-in adapters. The Micro Channel
    bus hardware is designed to run at higher speeds than its predecessors
    as well as to allow for more flexible adapter hardware designs. The
    Micro Channel differs from the PC and PC/AT bus design both in its
    physical layout and in its signal specifications, so an adapter that can
    be used with one bus is incompatible with the other.

    The differences between the original PC bus, the PC/AT bus, and the
    Micro Channel bus are important in operating system software but not in
    applications programs. Although all programs rely implicitly on the
    proper functioning of the address and data buses, very few programs are
    actually concerned with programming the bus directly. We'll come back to
    the Micro Channel architecture only when we describe PS/2 ROM BIOS
    services that work specifically with it.


Memory

    So far, we've discussed the CPU, the support chips, and the bus, but
    we've only touched on memory. We've saved our discussion of memory for
    the end of this chapter because memory chips, unlike the other chips
    we've discussed, don't control or direct the flow of information through
    a computer system; they merely store information until it is needed.

    The number and storage capacity of memory chips that exist inside the
    computer determine the amount of memory we can use for programs and
    data. Although this may vary from one computer to another, all PCs and
    PS/2s come with at least 40 KB of read-only memory (ROM)──with space for
    more──and between 64 KB and 2 MB of random-access memory (RAM). Both ROM
    and RAM capacities can be augmented by installing additional memory
    chips in empty sockets on the motherboard as well as by installing a
    memory adapter in one of the system expansion slots. But this is only
    the physical view of memory. A program sees memory not as a set of
    individual chips, but as a set of thousands or millions of 8-bit
    (1-byte) storage cells, each with a unique address.

    Programmers must also think of memory in this way──not in terms of how
    much physical memory there is, but in terms of how much addressable
    memory there is. The 8088 and 8086 can address up to 1 MB (1024 KB, or
    exactly 1,048,576 bytes) of memory. In other words, that's the maximum
    number of addresses, and therefore the maximum number of individual
    bytes of information, the processors can refer to. Memory addressing is
    discussed in more detail in Chapter 2.

CPU Address Space

    Each byte is referred to by a 20-bit numeric address. In the 8086 memory
    scheme, the addresses are 20 bits "wide" because they must travel along
    the 20-bit address bus. This gives the 8086 an address space with
    address values that range from 00000H through FFFFFH (0 through
    1,048,576 in decimal notation). If you have trouble understanding hex
    notation, you might want to take a quick look at Appendix B.

    Similarly, the 80286's 24-bit addressing scheme lets it use extended
    address values in the range 000000H through FFFFFFH, or 16 MB. The 80386
    can use extended 32-bit addresses, so its maximum address value is
    FFFFFFFFH; that is, the 80386 can directly address up to 4,294,967,296
    bytes, or four gigabytes (GB), of memory. This is enough memory for most
    practical purposes, even for the most prolific programmer.

    Although the 80286 and 80386 can address more than 1 MB of memory, any
    program compatible with the 8086 and with DOS must limit itself to
    addresses that lie in the 1 MB range available to the 8086. When the IBM
    PC first appeared in 1981, 1 MB seemed like a lot of memory, but large
    business-applications programs, memory-resident utility programs, and
    system software required for communications and networking can easily
    fill up the entire 8086 address space.

    One way to work around the 1 MB limit is with the LIM
    (Lotus-Intel-Microsoft) Expanded Memory Specification (EMS). The EMS is
    based on special hardware and software that map additional RAM into the
    8086 address space in 16 KB blocks. The EMS hardware can map a number of
    different 16 KB blocks into the same 16 KB range of 8086 addresses.
    Although the blocks must be accessed separately, the EMS lets up to 2048
    different 16 KB blocks map to the same range of 8086 addresses. That's
    up to 32 MB of expanded memory.

    ────────────────────────────────────────────────────────────────────────
    NOTE:
    Don't confuse EMS "expanded" memory with the "extended" memory located
    above the first megabyte of 80286 or 80386 memory. Although many
    memory expansion adapters can be configured to serve as either
    expanded or extended memory (or both), these two memory configurations
    are very different from both a hardware and software point of view.
    ────────────────────────────────────────────────────────────────────────

The System Memory Map

    On the original IBM PC, the 1 MB address space of the 8088 was split
    into several functional areas. (See Figure 1-6.) This memory map has
    been carried forward for compatibility in all subsequent PC and PS/2
    models.

                ┌────────────────────────────────────┐
                │   PC/AT and PS/2 extended memory   │
                └────────────────────────────────────┘
    100000H ────►┌────────────────────────────────────┐
                │      Reserved for ROM BIOS         │
    E0000H ────►├────────────────────────────────────┤
                │    Reserved for installable ROM    │
    C0000H ────►├────────────────────────────────────┤
                │           Video buffers            │
    A0000H ────►└────────────────────────────────────┘
                ┌────────────────────────────────────┐──┐
                │      Transient portion of DOS      │  │
                ├────────────────────────────────────┤  │
                │                                    │  │
                │       Transient Program Area       │  │
                │      (user programs and data)      │  │
                ├────────────────────────────────────┤  │
                │       Resident portion of DOS      │  ├── System
                ├────────────────────────────────────┤  │   RAM
                │  Data area for ROM BIOS and BASIC  │  │
    00500H ────►├────────────────────────────────────┤  │
                │       Data area for ROM BIOS       │  │
    00400H ────►├────────────────────────────────────┤  │
                │          Interrupt vectors         │  │
    00000H ────►└────────────────────────────────────┘──┘

    Figure 1-6.  An outline of memory usage in PCs and PS/2s.

    Some of the layout of the PC and PS/2 memory map is a consequence of the
    design of the 8086 microprocessor. For example, the 8086 always maintains
    a list of interrupt vectors (addresses of interrupt handling routines) in
    the first 1024 bytes of RAM. Similarly, all 8086-based microcomputers have
    ROM memory at the high end of the 1 MB address space, because the 8086,
    when first powered up, executes the program that starts at address FFFF0H.

    The rest of the memory map follows this general division between RAM at
    the bottom of the address space and ROM at the top. A maximum of 640 KB of
    RAM can exist between addresses 00000H and 9FFFFH. (This is the memory
    area described by the DOS CHKDSK program.) Subsequent memory blocks are
    reserved for video RAM (A0000H through BFFFFH), installable ROM modules
    (C0000H through DFFFFH), and permanent ROM (E0000H through FFFFFH). We'll
    explore each of these memory areas in greater detail in the chapters that
    follow.


Design Philosophy

    Before leaping into the following chapters, we should discuss the design
    philosophy behind the PC family. This will help you understand what is
    (and what isn't) important or useful to you.

    Part of the design philosophy of the IBM personal computer family centers
    around a set of ROM BIOS service routines (see Chapters 8 through 13)
    that provide essentially all the control functions and operations that IBM
    considers necessary. The basic philosophy of the PC family is: Let the ROM
    BIOS do it; don't mess with direct control. In our judgment, this is a
    sound idea that has several beneficial results. Using the ROM BIOS
    routines encourages good programming practices, and it avoids some of the
    kludgy tricks that have been the curse of many other computers. It also
    increases the chances of your programs working on every member of the PC
    family. In addition, it gives IBM more flexibility in making improvements
    and additions to the line of PC computers. However, it would be naive for
    us to simply say to you, "Don't mess with direct control of the hardware."
    For good reasons or bad, you may want or may need to have your programs
    work as directly with the computer hardware as possible, doing what is
    colorfully called "programming down to the bare metal."

    Still, as the PC family has evolved, programmers have had the opportunity
    to work with increasingly powerful hardware and system software. The newer
    members of the PC family provide faster hardware and better system
    software, so direct programming of the hardware does not necessarily
    result in significantly faster programs. For example, with an IBM PC
    running DOS, the fastest way to display text on the video display is to
    use assembly-language routines that bypass DOS and directly program the
    video hardware. Video screen output is many times slower if you route it
    through DOS. Contrast this with a PC/AT or PS/2 running OS/2, where the
    best way to put text on the screen is to use the operating system output
    functions. The faster hardware and the efficient video output services in
    OS/2 make direct programming unnecessary.

    As you read the programming details we present in this book, keep in mind
    that you can often obtain a result or accomplish a programming task
    through several means, including direct hardware programming, calling the
    ROM BIOS, or using a DOS service. You must always balance portability,
    convenience, and performance as you weigh the alternatives. The more you
    know about what the hardware, the ROM BIOS, and the operating system can
    do, the better your programs can use them.



────────────────────────────────────────────────────────────────────────────
Chapter 2  The Ins and Outs

    How the 8086 Communicates
    The 8086 Data Formats

    How the 8086 Addresses Memory
    Segmented Addresses
    80286 and 80386 Protected-Mode Addresses
    Address Compatibility

    The 8086 Registers
    The Scratch-Pad Registers
    The Segment Registers
    The Offset Registers
    The Flags Register
    Addressing Memory Through Registers
    Rules for Using Registers

    How the 8086 Uses I/O Ports

    How the 8086 Uses Interrupts
    Software Interrupts
    Hardware Interrupts

    Generally speaking, the more you know about how your computer works, the
    more effective you'll be at writing programs for it. High-level
    programming languages, such as BASIC and C, are not designed to include
    every possible function that you might need while programming──though
    admittedly, some are better than others. At some point, you will want to
    go deeper into your system and use some of the routines the languages
    themselves use, or perhaps go even deeper and program at the hardware
    level.

    Although some languages provide limited means to talk directly to memory
    (as with PEEK and POKE in BASIC) or even to some of the chips (as with
    BASIC's INP and OUT statements), most programmers eventually resort to
    assembly language, the basic language from which all other languages and
    operating systems are built. The 8086 assembly language, like all other
    assembly languages, is composed of a set of symbolic instructions, as
    shown in Figure 2-1. An assembler translates these instructions and the
    data associated with them into a binary form, called machine language,
    that can reside in memory and be processed by the 8086 to accomplish
    specific tasks.

╓┌─┌──────────────────┌──────────────────────────────────────────────────────╖
    Mnemonic           Full Name
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    Instructions recognized by all 8086-family microprocessors
    AAA                ASCII Adjust After Addition
    AAD                ASCII Adjust After Division
    AAM                ASCII Adjust After Multiplication
    AAS                ASCII Adjust After Subtraction
    ADC                ADd with Carry
    ADD                ADD
    AND                AND
    CALL               CALL
    CBW                Convert Byte to Word
    CLC                CLear Carry flag
    CLD                CLear Direction flag
    CLI                CLear Interrupt flag
    CMC                CoMplement Carry flag
    CMP                CoMPare
    CMPS               CoMPare String
    CMPSB              CoMPare String (Bytes)
    CMPSW              CoMPare String (Words)
    CWD                Convert Word to Doubleword
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    CWD                Convert Word to Doubleword
    DAA                Decimal Adjust After Addition
    DAS                Decimal Adjust After Subtraction
    DEC                DECrement
    DIV                Unsigned DIVide
    ESC                ESCape
    HLT                HaLT
    IDIV               Integer DIVide
    IMUL               Integer MULtiply
    IN                 INput from I/O port
    INC                INCrement
    INT                INTerrupt
    INTO               INTerrupt on Overflow
    IRET               Interrupt RETurn
    JA                 Jump if Above
    JAE                Jump if Above or Equal
    JB                 Jump if Below
    JBE                Jump if Below or Equal
    JC                 Jump if Carry
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    JC                 Jump if Carry
    JCXZ               Jump if CX Zero
    JE                 Jump if Equal
    JG                 Jump if Greater than
    JGE                Jump if Greater than or Equal
    JL                 Jump if Less than
    JLE                Jump if Less than or Equal
    JMP                JuMP
    JNA                Jump if Not Above
    JNAE               Jump if Not Above or Equal
    JNB                Jump if Not Below
    JNBE               Jump if Not Below or Equal
    JNC                Jump if No Carry
    JNE                Jump if Not Equal
    JNG                Jump if Not Greater than
    JNGE               Jump if Not Greater than or Equal
    JNL                Jump if Not Less than
    JNLE               Jump if Not Less than or Equal
    JNO                Jump if Not Overflow
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    JNO                Jump if Not Overflow
    JNP                Jump if Not Parity
    JNS                Jump if Not Sign
    JNZ                Jump if Not Zero
    JO                 Jump if Overflow
    JP                 Jump if Parity
    JPE                Jump if Parity Even
    JPO                Jump if Parity Odd
    JS                 Jump if Sign
    JZ                 Jump if Zero
    LAHF               Load AH with Flags
    LDS                Load pointer using DS
    LEA                Load Effective Address
    LES                Load pointer using ES
    LOCK               LOCK bus
    LODS               LOaD String
    LODSB              LOaD String (Bytes)
    LODSW              LOaD String (Words)
    LOOP               LOOP
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    LOOP               LOOP
    LOOPE              LOOP while Equal
    LOOPNE             LOOP while Not Equal
    LOOPNZ             LOOP while Not Zero
    LOOPZ              LOOP while Zero
    MOV                MOVe data
    MOVS               MOVe String
    MOVSB              MOVe String (Bytes)
    MOVSW              MOVe String (Words)
    MUL                MULtiply
    NEG                NEGate
    NOP                No OPeration
    NOT                NOT
    OR                 OR
    OUT                OUTput to I/O port
    POP                POP
    POPF               POP Flags
    PUSH               PUSH
    PUSHF              PUSH Flags
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    PUSHF              PUSH Flags
    RCL                Rotate through Carry Left
    RCR                Rotate through Carry Right
    REP                REPeat
    REPE               REPeat while Equal
    REPNE              REPeat while Not Equal
    REPNZ              REPeat while Not Zero
    REPZ               REPeat while Zero
    RET                RETurn
    ROL                ROtate Left
    ROR                ROtate Right
    SAHF               Store AH into Flags
    SAL                Shift Arithmetic Left
    SAR                Shift Arithmetic Right
    SBB                SuBtract with Borrow
    SCAS               SCAn String
    SCASB              SCAn String (Bytes)
    SCASW              SCAn String (Words)
    SHL                SHift Left
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    SHL                SHift Left
    SHR                SHift Right
    STC                SeT Carry flag
    STD                SeT Direction flag
    STI                SeT Interrupt flag
    STOS               STOre String
    STOSB              STOre String (Bytes)
    STOSW              STOre String (Words)
    SUB                SUBtract
    TEST               TEST
    WAIT               WAIT
    XCHG               eXCHanGe
    XLAT               transLATe
    XOR                eXclusive OR

    Instructions recognized by the 80286 and 80386 only:
    ARPL               Adjust RPL field of selector
    BOUND              Check array index against BOUNDs
    CLTS               CLear Task-Switched flag
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    CLTS               CLear Task-Switched flag
    ENTER              Establish stack frame
    INS                INput String from I/O port
    LAR                Load Access Rights
    LEAVE              Discard stack frame
    LGDT               Load Global Descriptor Table register
    LIDT               Load Interrupt Descriptor Table register
    LLDT               Load Local Descriptor Table register
    LMSW               Load Machine Status Word
    LSL                Load Segment Limit
    LTR                Load Task Register
    OUTS               OUTput String to I/O port
    POPA               POP All general registers
    PUSHA              PUSH All general registers
    SGDT               Store Global Descriptor Table register
    SIDT               Store Interrupt Descriptor Table register
    SLDT               Store Local Descriptor Table register
    SMSW               Store Machine Status Word
    STR                Store Task Register
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    STR                Store Task Register
    VERR               VERify a segment selector for Reading
    VERW               VERify a segment selector for Writing

    Instructions recognized by the 80386 only:
    BSF                Bit Scan Forward
    BSR                Bit Scan Reverse
    BT                 Bit Test
    BTC                Bit Test and Complement
    BTR                Bit Test and Reset
    BTS                Bit Test and Set
    CDQ                Convert Doubleword to Quadword
    CMPSD              CoMPare String (Doublewords)
    CWDE               Convert Word to Doubleword in EAX
    LFS                Load pointer using FS
    LGS                Load pointer using GS
    LSS                Load pointer using SS
    LODSD              LOaD String (Doublewords)
    MOVSD              MOVe String (Doublewords)
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    MOVSD              MOVe String (Doublewords)
    MOVSX              MOVe with Sign-eXtend
    MOVZX              MOVe with Zero-eXtend
    SCASD              SCAn String (Doublewords)
    SETA               SET byte if Above
    SETAE              SET byte if Above or Equal
    SETB               SET byte if Below
    SETBE              SET byte if Below or Equal
    SETC               SET byte if Carry
    SETE               SET byte if Equal
    SETG               SET byte if Greater
    SETGE              SET byte if Greater or Equal
    SETL               SET byte if Less
    SETLE              SET byte if Less or Equal
    SETNA              SET byte if Not Above
    SETNAE             SET byte if Not Above or Equal
    SETNB              SET byte if Not Below
    SETNBE             SET byte if Not Below or Equal
    SETNC              SET byte if No Carry
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    SETNC              SET byte if No Carry
    SETNE              SET byte if Not Equal
    SETNG              SET byte if Not Greater
    SETNGE             SET byte if Not Greater or Equal
    SETNL              SET byte if Not Less
    SETNLE             SET byte if Not Less or Equal
    SETNO              SET byte if Not Overflow
    SETNP              SET byte if Not Parity
    SETNS              SET byte if Not Sign
    SETNZ              SET byte if Not Zero
    SETO               SET byte if Overflow
    SETP               SET byte if Parity
    SETPE              SET byte if Parity Even
    SETPO              SET byte if Parity Odd
    SETS               SET byte if Sign
    SETZ               SET byte if Zero
    SHLD               SHift Left (Doubleword)
    SHRD               SHift Right (Doubleword)
    STOSD              STOre String (Doublewords)
    Mnemonic           Full Name
    ──────────────────────────────────────────────────────────────────────────
    STOSD              STOre String (Doublewords)
    ──────────────────────────────────────────────────────────────────────────


    Figure 2-1.  The instruction set used with the 8086, 80286, and 80386.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Although this chapter discusses the details of 8086 programming,
    remember that we're implicitly talking about the 8088, 80286, and 80386
    as well. Information pertaining exclusively to the 80286 or 80386 will
    be noted.
    ──────────────────────────────────────────────────────────────────────────

    The operations that the 8086 instructions can perform break down into only
    a few categories. They can do simple, four-function integer arithmetic.
    They can move data around. They can, using only slightly clumsy methods,
    manipulate individual bits. They can test values and take logical action
    based on the results. And last but not least, they can interact with the
    circuitry around them. The size of each instruction varies, but generally
    the most basic and often-used instructions are the shortest.

    Assembly-language programming can be carried out on one of two levels: to
    create interface routines that will tie high-level programs to the
    lower-level DOS and ROM-BIOS routines; or to create full-fledged
    assembly-language programs that are faster and smaller than equivalent
    high-level programs, or that perform exotic tasks at the hardware level,
    perhaps accomplishing a feat that is accomplished nowhere else. Either
    way, to understand how to use assembly language, you must understand how
    8086-family microprocessors process information and how they work with the
    rest of the computer. The rest of this chapter describes how the
    microprocessor and the computer's other parts communicate.


How the 8086 Communicates

    The 8086, 80286, and 80386 interact with the circuitry around them in
    three ways: through direct and indirect memory access, through
    input/output (I/O) ports, and with signals called interrupts.

    The microprocessor uses memory by reading or writing values at memory
    locations that are identified with numeric addresses. The memory locations
    can be accessed in two ways: through the direct memory access (DMA)
    controller or through the microprocessor's internal registers. The disk
    drives and the serial communications ports can directly access memory
    through the DMA controller. All other devices transfer data to and from
    memory by way of the microprocessor's registers.

    Input/Output ports are the microprocessor's general means of communicating
    with any computer circuitry other than memory. Like memory locations, I/O
    ports are identified by number, and data can be read from or written to
    any port. I/O port assignment is unique to the design of any particular
    computer. Generally, all members of the IBM PC family use the same port
    specifications, with just a few variations among the different models.
    (See page 37.)

    Interrupts are the means by which the circuitry outside the microprocessor
    reports that something (such as a keystroke) has happened and requests
    that some action be taken. Although interrupts are essential to the
    microprocessor's interaction with the hardware around it, the concept of
    an interrupt is useful for other purposes as well. For example, a program
    can use the INT instruction to generate a software interrupt that requests
    a service from DOS or from the system ROM BIOS. Interrupts are quite
    important when programming the PC family, so we'll devote a special
    section to them at the end of this chapter.

The 8086 Data Formats

    Numeric data. The 8086 and 80386 are able to work with only four simple
    numeric data formats, all of which are integer values. The formats are
    founded on two building blocks: the 8-bit byte and the 16-bit (2-byte)
    word. Both of these basic units are related to the 16-bit processing
    capacity of the 8086. The byte is the more fundamental unit; and when the
    8086 and 80286 address memory, bytes are the basic unit addressed. In a
    single byte, these microprocessors can work with unsigned positive numbers
    ranging in value from 0 through 255 (that is, 2^8 possibilities). If the
    number is a signed value, one of the 8 bits represents the sign, so only 7
    bits represent the value. Thus a signed byte can represent values ranging
    from -128 through +127. (See Figure 2-2.)

    The 8086 and 80286 can also operate on 16-bit signed and unsigned values,
    or words. Words are stored in memory in two adjacent bytes, with the low-
    order byte preceding the high-order byte. (See the discussion of
    "back-words storage" on page 24.)

                                    Range
    Size        Signed?      Dec                     Hex
    ──────────────────────────────────────────────────────────────────────────
    8          No           0 through 255           00H through FFH

    8          Yes          -128 through 0 through  80H through 00H through
                            +127                    7FH

    16          No           0 through 65,535        0000H through FFFFH

    16          Yes          -32,768 through 0       8000H through 0000H
                            through +32,767         through 7FFFH

    32          No           0 through 4,294,967,295 00000000H through
                                                    FFFFFFFFH

    32          Yes          -2,147,483,648 through  00000000H through
                            +2,147,483,647          00000000H through
                                                    7FFFFFFFH
    ──────────────────────────────────────────────────────────────────────────

    Figure 2-2.  The six data formats used in the 8086 family. (Only the 80386
    supports 32-bit formats.)

    A word interpreted as an unsigned, positive number can have 2^16 different
    values ranging from 0 through 65,535. As a signed number, the value can
    range from -32,768 through +32,767.

    The 80386 differs from its predecessors in that it can also work with
    32-bit integer values, or doublewords. A doubleword represents a signed or
    unsigned 4-byte integer with any of 2^32 (or 4,294,967,295) different
    values.

    Character data. Character data is stored in the standard ASCII format,
    with each character occupying 1 byte. The 8086 family knows nothing about
    ASCII characters and treats them as arbitrary bytes, with one exception:
    The instruction set accommodates decimal addition and subtraction
    performed on binary coded decimal (BCD) characters. The actual arithmetic
    is done in binary, but the combination of the AF flag (see page 33) and a
    few special instructions makes it practical to work on decimal characters
    and get decimal results, which can easily be converted to ASCII.

    ──────────────────────────────────────────────────────────────────────────
    Back-Words Storage
    While the PC's memory is addressed in units of individual 8-bit bytes,
    many operations involve 16-bit words. In memory, a 16-bit word is stored
    in any two adjacent 8-bit bytes. The least-significant byte of the word
    is stored in the lower memory location, and the most significant byte is
    stored in the higher memory location. From some points of view, storing
    a word this way is the opposite of what you might expect. Due to the
    backward appearance of this storage scheme, it is sometimes whimsically
    called "back-words" storage.

    ─── Higher addresses ───────►
    ┌───────┬───────┐
    │  9C   │  E6   │                   Value of word is E69CH
    └───────┴───────┘

    ─── Higher addresses ───────►
    ┌───────┬───────┬───────┬───────┐
    │  4A   │  5B   │  00   │  12   │   Value of doubleword is 12005B4AH
    └───────┴───────┴───────┴───────┘

    If you are working with bytes and words in memory, you should take care
    not to be confused by back-words storage. The source of the confusion
    has mostly to do with how you write data. For example, if you are
    writing a word value in hex, you write it like this: ABCD. The order of
    significance is the same as if you are writing a decimal number: The
    most significant digit is written first. But a word is stored in memory
    with the lowest address location first. So, in memory, the number ABCD
    appears as CDAB, with the bytes switched.
    ──────────────────────────────────────────────────────────────────────────

    See Appendix C for more information on ASCII and the PC family's extended
    ASCII character set.


How the 8086 Addresses Memory

    The 8086 is a 16-bit microprocessor and cannot therefore work directly
    with numbers larger than 16 bits. Theoretically, this means that the 8086
    should be able to access only 64 KB of memory. But, as we noted in the
    previous chapter, it can in fact access much more than that──1024 KB to be
    exact. This is possible because of the 20-bit addressing scheme used with
    the 8086, which expands the full range of memory locations that the 8086
    can work with from 2^16 (65,536) to 2^20 (1,048,576). But the 8086 is
    still limited by its 16-bit processing capacity. To access the 20-bit
    addresses, it must use an addressing method that fits into the 16-bit
    format.

Segmented Addresses

    The 8086 divides the addressable memory space into segments, each of which
    contains 64 KB of memory. Each segment begins at a paragraph address──that
    is, a byte location that is evenly divisible by 16. To access individual
    bytes or words, you use an offset that points to an exact byte location
    within a particular segment. Because offsets are always measured relative
    to the beginning of a segment, they are also called relative addresses or
    relative offsets.

    Together, a segment and an offset form a segmented address that can
    designate any byte in the 8086's 1 MB address space. The 8086 converts a
    given 32-bit segmented address into a 20-bit physical address by using the
    segment value as a paragraph number and adding the offset value to it. In
    effect, the 8086 shifts the segment value left by 4 bits and then adds the
    offset value to create a 20-bit address.

    Figure 2-3 shows how this is done for a segment value of 1234H and an
    offset of 4321H. The segmented address is written as 1234:4321, with
    4-digit hexadecimal values and with a colon separating the segment and
    offset.

        1234:4321
    shift│    │
    left│    │
        │    │
        ▼    │
    12340   │
    +4321◄──┘
    ─────
    16661

    Figure 2-3.  Decoding an 8086 segmented address. The segment value 1234H
    is shifted left 4 bits (one hex digit) and added to the offset 4321H to
    give the 20-bit physical address 16661H.

    On the 8086, there's obviously a great deal of overlap in the range of
    values that can be expressed as segmented addresses. Any given physical
    address can be represented by up to 2^12 different segmented addresses.
    For example, the physical address 16661H could be represented not only as
    1234:4321, but also as 1666:0001, 1665:0011, 1664:0021, and so on.

80286 and 80386 Protected-Mode Addresses

    The 80286 also uses segmented addresses, but when the 80286 runs in
    protected mode, the addresses are decoded differently than on an 8086 or
    in 80286 real mode. The 80286 decodes protected-mode segmented addresses
    through a table of segment descriptors. The "segment" part of a segmented
    address is not a paragraph value, but a "selector" that represents an
    index into a segment descriptor table (Figure 2-4). Each descriptor in
    the table contains a 24-bit base address that indicates the actual start
    of a segment in memory. The resulting address is the sum of the 24-bit
    base address and the 16-bit offset specified in the segmented address.
    Thus, in protected mode the 80286 can access up to 2^24 bytes of memory;
    that is, physical addresses are 24 bits in size.

    This table-driven addressing scheme gives the 80286 a great deal of
    control over memory usage. In addition to a 24-bit base address, each
    segment descriptor specifies a segment's attributes (executable code,
    program data, read-only, and so on), as well as a privilege level that
    lets an operating system restrict access to the segment. This ability to
    specify segment attributes and access privileges is of great use to a
    multitasking operating system like OS/2.

    The 80386 supports both 8086 and 80286 protected-mode addressing. The
    80386 enhances the protected-mode addressing scheme by allowing 32-bit
    segment base addresses and 32-bit offsets. Thus a single segmented
    address, consisting of a 16-bit selector and a 32-bit offset, can specify
    any of 2^32 different physical addresses.

                            0038:4321
                            │    │
    │            │         │    │
    ├────────────┤         │    │
    │            │ 28      │    │
    ├────────────┤         │    │
    │            │ 30      │    │
    ├────────────┤         │    │
    ┌─┤   012340   │ 38 ◄────┘    │
    │ ├────────────┤              │
    │ │            │ 40           │
    │ ├────────────┤              │
    │ │            │              │
    │                             │
    └──────────────────► 012340   │
                        + 4321 ◄─┘
                        ──────
                        016661

    Figure 2-4.  Decoding an 80286 protected-mode segmented address. The
    segment selector 38H indicates an entry in a segment descriptor table. The
    segment descriptor contains a 24-bit segment base address which is added
    to the offset 4321H to give the 24-bit physical address 016661H.

    The 80386 also provides a "virtual 8086" addressing mode, in which
    addressing is the same as the usual 8086 16-bit addressing, but with the
    physical addresses corresponding to the 1 MB 8086 address space mapped
    anywhere in the 4 gigabyte (GB) 80386 address space. This lets an
    operating system execute several different 8086 programs, each in its own
    1 MB, 8086-compatible address space.

Address Compatibility

    The different addressing schemes used by the 80286 and 80386 are generally
    compatible (except, of course, for 32-bit addressing on the 80386).
    However, if you are writing an 8086 program that you intend to convert for
    use in protected mode, be careful to use segments in an orderly fashion.
    Although it's possible to specify a physical 8086 address with many
    different segment-offset combinations, you will find it easier to convert
    8086 programs to 80286 protected-mode addressing if you keep your segment
    values as constant as possible.

    For example, imagine that your program needs to access an array of
    160-byte strings of characters, starting at physical address B8000H. A
    poor way to access each string would be to exploit the fact that the
    strings are each 10 paragraphs long by using a different segment value to
    locate the start of each string:

    B800:0000H (physical address B8000H)
    B80A:0000H (physical address B80A0H)
    B814:0000H (physical address B8140H)
    B81E:0000H (physical address B81E0H)

    A better way to accomplish the same addressing would be to keep a constant
    segment value and change the offset value:

    B800:0000H (physical address B8000H)
    B800:00A0H (physical address B80A0H)
    B800:0140H (physical address B8140H)
    B800:01E0H (physical address B81E0H)

    Although the result is the same on an 8086 and in real mode on an 80286,
    you'll find that the second method is much better suited to 80286
    protected mode, where each different segment selector designates a
    different segment descriptor.


The 8086 Registers

    The 8086 was designed to execute instructions and perform arithmetic and
    logical operations as well as receive instructions and pass data to and
    from memory. To do this, it uses a variety of 16-bit registers.

    There are fourteen registers in all, each with a special use. Four
    scratch-pad registers are used by programs to temporarily hold the
    intermediate results and operands of arithmetic and logical operations.
    Four segment registers hold segment values. Five pointer and index
    registers hold the offsets that are used with the values in the segment
    registers to locate data in memory. Finally, one flags register contains
    nine 1-bit flags that are used to record 8086 status information and
    control 8086 operations. (See Figure 2-5.)

                                        Scratch-pad registers

                            7                      0 7                      0
                            ╓──┬──┬──┬──┬──┬──┬──┬──╥──┬──┬──┬──┬──┬──┬──┬──╖
    AX (accumulator)        ║          AH           ║          AL           ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──╫──┼──┼──┼──┼──┼──┼──┼──╢
    BX (base)               ║          BH           ║          BL           ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──╫──┼──┼──┼──┼──┼──┼──┼──╢
    CX (count)              ║          CH           ║          CL           ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──╫──┼──┼──┼──┼──┼──┼──┼──╢
    DX (data)               ║          DH           ║          DL           ║
                            ╙──┴──┴──┴──┴──┴──┴──┴──╨──┴──┴──┴──┴──┴──┴──┴──╜

                                            Segment registers

                            15                                              0
                            ╓──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──╖
    CS (code segment)       ║                                               ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──╢
    DS (data segment)       ║                                               ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──╢
    SS (stack segment)      ║                                               ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──╢
    ES (extra segment)      ║                                               ║
                            ╙──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──╜

                                            Offset registers

                            15                                              0
                            ╓──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──╖
    IP (instruction pointer)║                                               ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──╢
    SP (stack pointer)      ║                                               ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──╢
    BP (base pointer)       ║                                               ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──╢
    SI (source index)       ║                                               ║
                            ╟──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──╢
    DI (destination index)  ║                                               ║
                            ╙──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──╜

                                            Flags register

                            15                                              0
                            ╓──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──╖
                    Flags  ║           │OF│DF│IF│TF│SF│ZF│  │AF│  │PF│  │CF║
                            ╙──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──╜

    Figure 2-5.  The 8086 registers and flags.

The Scratch-Pad Registers

    When a computer is processing data, a great deal of the microprocessor's
    time is spent transferring data to and from memory. This access time can
    be greatly reduced by keeping frequently used operands and results inside
    the 8086. Four 16-bit registers, usually called the scratch-pad or data
    registers, are designed for this purpose.

    The scratch-pad registers are known as AX, BX, CX, and DX. Each of them
    can also be subdivided and separately used as two 8-bit registers. The
    high-order 8-bit registers are known as AH, BH, CH, and DH, and the low-
    order 8-bit registers are known as AL, BL, CL, and DL.

    The scratch-pad registers are used mostly as convenient temporary working
    areas, particularly for arithmetic operations. Addition and subtraction
    can be done in memory without using the registers, but the registers are
    faster.

    Although these registers are available for any kind of scratch-pad work,
    each also has some special uses:

    ■  The AX (accumulator) register is the main register used to perform
        arithmetic operations. (Although addition and subtraction can be
        performed in any of the scratch-pad or offset registers, multiplication
        and division must be done in AX or AL.)

    ■  The BX (base) register can be used to point to the beginning of a
        translation table in memory. It can also be used to hold the offset
        part of a segmented address.

    ■  The CX (count) register is used as a repetition counter for loop
        control and repeated data moves. For example, the LOOP instruction in
        assembly language uses CX to count the number of loop iterations.

    ■  The DX register is used to store data for general purposes, although
        it, too, has certain specialized functions. For example, DX contains
        the remainder of division operations performed in AX.

The Segment Registers

    As we discussed earlier, the complete address of a memory location
    consists of a 16-bit segment value and a 16-bit offset within the segment.
    Four registers, called CS, DS, ES, and SS, are used to identify four
    specific segments of memory. Five offset registers, which we'll discuss
    shortly, can be used to store the relative offsets of the data within each
    of the four segments.

    Each segment register is used for a specific type of addressing:

    ■  The CS register identifies the code segment, which contains the program
        that is being executed.

    ■  The DS and ES registers identify data segments where data used in a
        program is stored.

    ■  The SS register identifies the stack segment. (See page 32 for more
        information about stacks.)

    Programs rarely use four separate segments to address four different 64 KB
    areas of memory. Instead, the four segments specified in CS, DS, ES, and
    SS usually refer to overlapping or identical areas in memory. In effect,
    the different segment registers identify areas of memory used for
    different purposes.

    For example, Figure 2-6 shows how the values in the segment registers
    correspond to the memory used in a hypothetical DOS program. The values in
    the segment registers are chosen to correspond to the start of each
    logically different area of memory, even though the 64 KB areas of memory
    identified by each segment overlap each other. (See Chapter 20 for more
    about segments and the memory layout of DOS programs.)

    All 8086 instructions that use memory have an implied use of a particular
    segment register for the operation being performed. For example, the MOV
    instruction, because it acts on data, uses the DS register. The JMP
    instruction, which affects the flow of a program, automatically uses the
    CS register.

    This means that you can address any 64 KB segment in memory by placing its
    paragraph address in the appropriate segment register. For example, to
    access data in the video buffer used by IBM's Color Graphics Adapter, you
    place the paragraph address of the start of the buffer in a segment
    register and then use the MOV instruction to transfer data to or from the
    buffer.

                ┌─────────────────────┐        ◄───┐
        SS=2919H │       Stack         │ 29190H     ├─ 2 KB
                ├─────────────────────┤        ◄───┤
                │                     │            │
        DS=2419H │    Program data     │            ├─ 20KB
                │                     │ 24190H     │
                ├─────────────────────┤        ◄───┤
                │                     │            │
        CS=2019H │   Executable code   │            ├─ 16 KB
                │                     │ 20190H     │
                └─────────────────────┘        ◄───┘
    Segment registers              Physical addresses

    Figure 2-6.  Segment usage in a typical DOS program. Each segment register
    contains the starting paragraph of a different area of memory.

    mov ax,0B800h                   ; move the segment value into DS
    mov ds,ax
    mov al,[0000]                   ; copy the byte at B800:0000
                                    ; into AL

    In interpreted BASIC you can use this method with the DEF SEG statement:

    DEF SEG = &HB800                ' move the segment value into DS
    X = PEEK(0000)                  ' copy the byte at B800:0000 into X

The Offset Registers

    Five offset registers are used with the segment registers to contain
    segmented addresses. One register, called the instruction pointer (IP),
    contains the offset of the current instruction in the code segment; two
    registers, called the stack registers, are intimately tied to the stack;
    and the remaining two registers, called the index registers, are used to
    address strings of data.

    The instruction pointer (IP), also called the program counter (PC),
    contains the offset within the code segment where the current program is
    executing. It is used with the CS register to track the location of the
    next instruction to be executed.

    Programs do not have direct access to the IP register, but a number of
    instructions, such as JMP and CALL, change the IP value implicitly.

    The stack registers, called the stack pointer (SP) and the base pointer
    (BP), provide offsets into the stack segment. SP gives the location of the
    current top of the stack. Programs rarely change the value in SP directly.
    Instead, they rely on PUSH and POP instructions to update SP implicitly.
    BP is the register generally used to access the stack segment directly.
    You'll see BP used quite often in the assembly-language examples that
    appear in Chapters 8 through 20.

    The index registers, called the source index (SI) and the destination
    index (DI), can be used for general-purpose addressing of data. Also, all
    string move and comparison instructions use SI and DI to address data
    strings.

The Flags Register

    The fourteenth and last register, called the flags register, is really a
    collection of individual status and control bits called flags. The flags
    are maintained in a register, so they can be either saved and restored as
    a coordinated set or inspected as ordinary data. Normally, however, the
    flags are set and tested as independent items──not as a set.

    There are nine 1-bit flags in the 8086's 16-bit flags register, leaving 7
    bits unused. (The 80286 and 80386 use some of the unused flags to support
    protected-mode operation.) The flags can be logically divided into two
    groups: six status flags, which record processor status information
    (usually indicating what happened with a comparison or arithmetic
    operation), and three control flags, which direct some of the 8086
    instructions. Be prepared to see a variety of notations for the flags,
    including distinct names for whether they are set (1) or clear (0). The
    terms used in Figures 2-7 and 2-8 are the most common.

    ──────────────────────────────────────────────────────────────────────────
    The Stack
    The stack is a built-in feature of the 8086. It provides programs with a
    place to store and keep track of work in progress. The most important
    use of the stack is to keep a record of where subroutines were invoked
    from and what parameters were passed to them. The stack can also be used
    for temporary working storage, although this is less fundamental and
    less common.

    The stack gets its name from an analogy to a spring-loaded stack of
    plates in a cafeteria: New data is "pushed" onto the top of the stack
    and old data is "popped" off. A stack always operates in
    last-in-first-out (LIFO) order. This means that when the stack is used
    to keep track of where to return to a program, the most recent calling
    program is returned to first. This way, a stack maintains the orderly
    workings of programs, subroutines, and interrupt handlers, no matter how
    complex their operation.

    A stack is used from the bottom (highest address) to the top (lowest
    address) so that when data is pushed onto the top of the stack, it is
    stored at the memory addresses just below the current top of the stack.
    The stack grows downward so that as data is added, the location of the
    top of the stack moves to lower and lower addresses, decreasing the
    value of SP each time. You need to keep this in mind when you access the
    stack, which you are likely to do in assembly-language interface
    routines.

    Any part of any program can create a new stack space at any time, but
    this is not usually done. Normally, when a program is run, a single
    stack is created for it and used throughout the operation of the
    program.

    There is no simple way to estimate the size of stack that a program
    might need, and the 8086's design does not provide any automatic way of
    detecting when stack space is in short supply or exhausted. This can
    make programmers nervous about the amount of space that should be set
    aside for a stack. A conservative estimate of how much stack space to
    maintain is about 2 KB (2048 bytes), the default amount allocated by
    many high-level language compilers.

                                                ┌──────┐◄─── Bottom of stack
                                        :1008 │ 5E00 │
            ┌──────┐◄─── Bottom of stack       ├──────┤
    :1008 │ 5E00 │                     :1006 │ 4D00 │
            ├──────┤                           ├──────┤
    :1006 │ 4D00 │                     :1004 │ 3C00 │◄─── Old top of stack
            ├──────┤                           ├──────┤
    :1004 │ 3C00 │◄─── Top of stack    :1002 │ 2B00 │◄─── Top of stack
            ├──────┤     (SP=1004)             ├──────┤     (SP=1002)
    :1002 │      │                     :1000 │      │
            ├──────┤                           └────┘
    :1000 │      │                             ║  ║
            └──────┘                             PUSH
    a. Stack before a PUSH             b. Stack after a PUSH
    ──────────────────────             ─────────────────────

                                ┌──────┐◄─── Bottom of stack
                        :1008 │ 5E00 │
                                ├──────┤
                        :1006 │ 4D00 │
                                ├──────┤
                        :1004 │ 3C00 │◄─── Top of stack
                                ├──────┤     (SP=1004)
                        :1002 │      │
                                ├──────┤
                        :1000 │      │
                                └─║──║─┘
                                ▼  ▼
                                POP
                        c. Stack after a POP
                        ────────────────────

    ──────────────────────────────────────────────────────────────────────────

    Code        Name                     Use
    ──────────────────────────────────────────────────────────────────────────
    CF          Carry flag               Indicates an arithmetic carry
    OF          Overflow flag            Indicates signed arithmetic overflow
    ZF          Zero flag                Indicates zero result, or equal
                                        comparison
    SF          Sign flag                Indicates negative result/comparison
    PF          Parity flag              Indicates even number of 1 bits
    AF          Auxiliary carry flag     Indicates adjustment needed in
                                        binary-coded decimal (BCD) arithmetic
                                        operations
    ──────────────────────────────────────────────────────────────────────────

    Figure 2-7.  The six status flags in the 8086's flags register.

    Code        Name                     Use
    ──────────────────────────────────────────────────────────────────────────
    DF          Direction flag           Controls increment direction in
                                        string operations (CMPS, LODS, MOVS,
                                        SCAS, STOS)
    IF          Interrupt flag           Controls whether interrupts are
                                        enabled
    TF          Trap flag                Controls single-step operation (used
                                        by DEBUG) by generating an interrupt
                                        at the end of every instruction
    ──────────────────────────────────────────────────────────────────────────

    Figure 2-8.  The three control flags in the 8086's flags register.

Addressing Memory Through Registers

    We've seen that memory is always addressed by a combination of a segment
    value and a relative offset. The segment value always comes from one of
    the four segment registers.

    In contrast, the relative offset can be specified in many different ways.
    (See Figure 2-9.) For each machine instruction that accesses memory, the
    8086 computes an effective address by combining one, two, or three of the
    following:

    ■  The value in BX or BP

    ■  The value in SI or DI

    ■  A relative-offset value, called a displacement, that is part of the
        instruction itself

╓┌─┌──────────────────┌───────────────────────────┌──────────────────┌───────►
    Name               Effective Address           Example            Comments
    ───────────────────────────────────────────────────────────────────────────
    Immediate          Value "addressed" is part   mov ax,1234h       Stores 12
                        of the 8086 instruction

    Direct             Specified as part of the    mov ax,[1234h]     Copies th
                        8086 instruction                               into AX.
                                                                    register

    Register indirect  Contained in BX, SI, DI, or mov ax,[bx]        Copies th
                        BP                                             offset co
                                                                    AX. The d
                                                                    register
    Name               Effective Address           Example            Comments
    ───────────────────────────────────────────────────────────────────────────
                                                                    register
                                                                    [DI] is D
                                                                    default i

    Based              The sum of a displacement   mov ax,[bx+2]      Copies th
                        (part of the instruction)   or mov ax,2[bx]    past the
                        and the value in BX or BP                      BX into A
                                                                    segment r
                                                                    DS; for [
                                                                    SS.

    Indexed            The sum of a displacement   mov ax,[si+2]      Copies th
                        and the value in SI or DI   or mov ax,2[si]    past the
                                                                    SI into A
                                                                    segment r
    Based indexed      The sum of a displacement,  mov ax,[bp+si+2]   The offse
                        the value in SI or DI, and  or mov ax,2[bp+si] values in
                        the value in BX or BP       or                 When BX i
                                                    mov ax,2[bp][si]   segment r
    Name               Effective Address           Example            Comments
    ───────────────────────────────────────────────────────────────────────────
                                                    mov ax,2[bp][si]   segment r
                                                                    BP is use
                                                                    SS.

    String addressing  Source string: register     movsb              Copies th
                        indirect using SI                              memory at
                        Destination string:                            ES:[DI].
                        register indirect using DI
    ───────────────────────────────────────────────────────────────────────────


    Figure 2-9.  8086 Addressing Modes. In assembly language, some
    instructions can be specified in several different ways.

    Each of the various ways of forming an effective address has its uses. You
    can use the Immediate and Direct methods when you know the offset of a
    particular memory location in advance. You must use one of the remaining
    methods when you can't tell what an address will be until your program
    executes. In the chapters ahead, you'll see examples of most of the
    different 8086 addressing modes.

    The notation used in specifying 8086 addresses is straightforward.
    Brackets, [ ], are used to indicate that the enclosed item specifies a
    relative offset. This is a key element of memory addressing: Without
    brackets, the actual value stored in the register is used in whatever
    operation is specified.

Rules for Using Registers

    It is important to know that various rules apply to the use of registers,
    and it is essential to be aware of these rules when writing assembly-
    language interface routines. Because the rules and conventions of usage
    vary by circumstance and by programming language, exact guidelines are not
    always available, but the general rules that follow will apply in most
    cases. (You will find additional guidance, and working models to copy, in
    the examples in Chapters 8 through 20.) Keep in mind, though, that the
    following rules are general, not absolute.

    Probably the most useful rule for using the registers is simply to use
    them for what they are designed for. The idea that each of the 8086
    registers has certain special uses may seem somewhat quirky, particularly
    to a programmer who is accustomed to working with a CPU that has a less
    specialized set of registers (such as the 68000, for example). On the
    8086, using the registers for their natural functions leads to cleaner,
    more efficient source code and ultimately to more reliable programs.

    For example, the segment registers are designed to contain segment values,
    so don't use them for anything else. (In 80286 protected mode you can't
    use them for anything else anyway without generating an error condition.)
    The BP register is intended for stack addressing; if you use it for
    anything else, you'll have to do some fancy footwork when you need to
    address values in the stack segment.

    Particular rules apply to the four segment registers (CS, DS, ES, and SS).
    The CS register should be changed only through intersegment jumps and
    subroutine calls.

    Most programmers use the DS register to point to a default data segment
    that contains the data most frequently used in a program. This means that
    the value in the DS register is usually initialized at the beginning of a
    program and then left alone. Should it be necessary to use DS to address a
    different segment, its original value is saved, the new segment is
    accessed, and then the original value is restored. In contrast, most
    people use the ES register as needed to access arbitrary segments in
    memory.

    The stack segment (SS) and stack pointer (SP) registers should usually be
    updated implicitly, either by PUSH and POP instructions or by CALL and RET
    instructions that save subroutine return addresses on the stack. When DOS
    loads a program into memory to be executed, it initializes SS and SP to
    usable values. In .COM programs, SS:SP points to the end of the program's
    default segment; in .EXE programs, SS:SP is determined explicitly by the
    size and location of the program's stack segment. In either case, it's
    rare that you need to change SS or SP explicitly.

    If you need to discard a number of values from the stack or reserve
    temporary storage space on top of the stack, you can increment or
    decrement SP directly:

    add sp,8                        ; discard four words (8 bytes)
                                    ; from stack
    sub sp,6                        ; add three empty words (6 bytes)
                                    ; to top of stack

    If you need to move the stack to a different location in memory, you must
    generally update both SS and SP at the same time:

    cli                             ; disable interrupts
    mov ss,NewStackSeg              ; update SS from a memory variable
    mov sp,NewStackPtr              ; update SP from a memory variable
    sti                             ; re-enable interrupts

    Be careful when you change SS and SP explicitly. If you modify SS but fail
    to update SP, SS will be specifying a new stack segment while SP will be
    pointing somewhere inside another stack segment──and that's asking for
    trouble the next time you use the stack.

    It's hard to be explicit about the use of the other registers. In general,
    most programmers try to minimize memory accesses by keeping the
    intermediate results of lengthy computations in registers. This is because
    it takes longer to perform a computation on a value stored in memory than
    on a value stored in a register. Of course, the 8086 has only so many
    registers to work with, so you may find yourself running out of registers
    before you run out of variables.


How the 8086 Uses I/O Ports

    The 8086-family microprocessors communicate with and control many parts of
    the computer through the use of input and output (I/O) ports. The I/O
    ports are doorways through which information passes as it travels to or
    from an I/O device, such as a keyboard or a printer. Most of the support
    chips we described in Chapter 1 are accessed through I/O ports; in fact,
    each chip may use several port addresses for different purposes.

    Each port is identified by a 16-bit port number, which can range from 00H
    through FFFFH (65,535). The CPU identifies a particular port by the port's
    number.

    As it does when accessing memory, the CPU uses the data and address buses
    as conduits for communication with the ports. To access a port, the CPU
    first sends a signal on the system bus to notify all I/O devices that the
    address on the bus is that of a port. The CPU then sends the port address.
    The device with the matching port address responds.

    The port number addresses a memory location that is associated with an I/O
    device but is not part of main memory. In other words, an I/O port number
    is not the same as a memory address. For example, I/O port 3D8H has
    nothing to do with memory address 003D8H. To access an I/O port, you don't
    use data-transfer instructions like MOV and STOS. Instead, you use the
    instructions IN and OUT, which are reserved for I/O port access.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Many high-level programming languages provide functions that access I/O
    ports. The BASIC functions INP and OUT, and the C functions inp and
    outp, are typical examples.
    ──────────────────────────────────────────────────────────────────────────

    The uses of specific I/O ports are determined by the hardware designers.
    Programs that make use of I/O ports need to be aware of the port numbers,
    as well as their use and meaning. Port number assignments differ slightly
    among the PC family members, but, in general, IBM has reserved the same
    ranges of I/O port numbers for the same input/output devices in all PCs
    and PS/2s. (See Figure 2-10.) For details on how each I/O port is used,
    see the descriptions of the various input/output devices in the IBM
    technical reference manuals.

╓┌─┌──────────────────────────────────────────────┌───────────────┌──────────►
    Description                                    I/O Port        Comment
                                                    Numbers
    ───────────────────────────────────────────────────────────────────────────
    Programmable Interrupt Controller (master)     20H─3FH

    System timer                                   40H─5FH

    Keyboard controller                            60H─6FH         On PS/2 Mode
                                                                    are reserved
                                                                    control and

    System control port B                          61H             PS/2 models

    Real-time clock, NMI mask                      70H─7FH         On PC, PC/XT
                                                                    30, NMI mask

    System control port A                          92H             PS/2 models
    Description                                    I/O Port        Comment
                                                    Numbers
    ───────────────────────────────────────────────────────────────────────────
    System control port A                          92H             PS/2 models

    Programmable Interrupt Controller (slave)      A0H─BFH         On PS/2 Mode

    Real-time clock                                B0H─BFH,        PS/2 Model 3
                                                    E0H─EFH

    Clear math coprocessor busy                    F0H

    Reset math coprocessor                         F1H

    Math coprocessor                               F8H─FFH

    Fixed-disk controller                          1F0H─1F8H

    Game control adapter                           200H─207H

    Parallel printer 3                             278H─27BH
    Description                                    I/O Port        Comment
                                                    Numbers
    ───────────────────────────────────────────────────────────────────────────
    Parallel printer 3                             278H─27BH

    Serial communications 2                        2F8H─2FFH

    Fixed-disk controller                          320H─32FH       PC/XT and PS

    PC network                                     360H─363H,
                                                    368H─36BH

    Parallel printer 2                             378H─37BH

    Monochrome Display Adapter                     3B0H─3BBH       Also used by
                                                                    monochrome v

    Parallel printer 1                             3BCH─3BFH

    Enhanced Graphics Adapter (EGA),               3C0H─3CFH
    Video Graphics Array (VGA)
    Description                                    I/O Port        Comment
                                                    Numbers
    ───────────────────────────────────────────────────────────────────────────
    Video Graphics Array (VGA)

    Color Graphics Adapter (CGA),                  3D0H─3DFH       Also used by
    Multi-Color Graphics Array (MCGA)                              color video

    Diskette controller                            3F0H─3F7H

    Serial communications 1                        3F8H─3FFH
    ───────────────────────────────────────────────────────────────────────────


    Figure 2-10.  PC and PS/2 input/output port assignments. This table lists
    the most frequently used I/O ports. For a complete list, see the IBM
    Technical Reference manuals.


How the 8086 Uses Interrupts

    An interrupt is an indication to the microprocessor that its immediate
    attention is needed. The 8086-family microprocessors can respond to
    interrupts from either hardware or software. A hardware device can
    generate an interrupt signal that is processed by the programmable
    interrupt controller (PIC) and passed to the microprocessor; in software,
    the INT instruction generates an interrupt. In both cases, the
    microprocessor stops processing and executes a memory-resident subroutine
    called an interrupt handler. After the interrupt handler has performed its
    task, the microprocessor resumes processing at the point the interrupt
    occurred.

    The 8086 supports 256 different interrupts, each identified by a number
    between 00H and FFH (decimal 255). The segmented addresses of the 256
    interrupt handlers are stored in an interrupt vector table that starts at
    0000:0000H (that is, at the very beginning of available memory). Each
    interrupt vector is 4 bytes in size, so you can locate the address of any
    interrupt handler by multiplying the interrupt number by 4. You can also
    replace an existing interrupt handler with a new one by storing the new
    handler's segmented address in the appropriate interrupt vector.

Software Interrupts

    Probably the most familiar type of interrupts are generated by the INT
    instruction. Consider what happens when the CPU executes the following
    instruction:

    INT 12H

    The CPU pushes the current contents of the flags register, the CS (code
    segment) register, and the IP (instruction pointer) register onto the
    stack. Then it transfers control to the interrupt handler corresponding to
    interrupt number 12H, using the segmented address stored at 0000:0048H.
    The CPU then executes the interrupt 12H handler, which responds
    appropriately to interrupt 12H. The interrupt handler terminates with an
    IRET instruction that pops CS:IP and the flags back into the registers,
    thus transferring control back to the interrupted program.

Hardware Interrupts

    The microprocessor responds to a hardware interrupt in much the same way
    it responds to a software interrupt: by transferring control to an
    interrupt handler. The important difference lies in the way the interrupt
    is signalled.

    Devices such as the system timer, the hard disk, the keyboard, and the
    serial communications ports can generate interrupt signals on a set of
    reserved interrupt request (IRQ) lines. These lines are monitored by the
    PIC circuit, which assigns interrupt numbers to them. When a particular
    hardware interrupt occurs, the PIC places the corresponding interrupt
    number on the system data bus where the microprocessor can find it.

    The PIC also assigns priorities to the various interrupt requests. For
    example, the highest-priority PIC interrupt in all PCs and PS/2s is the
    timer-tick interrupt, which is signalled on interrupt request line 0
    (IRQ0) and is assigned interrupt 08H by the PIC. When a system timer
    generates a timer- tick interrupt, it does so by signalling on IRQ0; the
    PIC responds by signalling the CPU to execute interrupt 08H. If a
    lower-priority hardware interrupt request occurs while the timer-tick
    interrupt is being processed, the PIC delays the lower-priority interrupt
    until the timer interrupt handler signals that it has finished its
    processing.

    When you coldboot the computer, the system start-up routines assign
    interrupt numbers and priorities to the hardware interrupts by
    initializing the PIC. In 8088- and 8086-based machines (PCs, PC/XTs, PS/2
    models 25 and 30), interrupt numbers 08H through 0FH are assigned to
    interrupt request levels 0 through 7 (IRQ0 through IRQ7). In PC/ATs and
    PS/2 models 50, 60, and 80, an additional eight interrupt lines (IRQ8
    through IRQ15) are assigned interrupt numbers 70H through 77H.

    One hardware interrupt bypasses the PIC altogether. This is the
    non-maskable interrupt (NMI), which is assigned interrupt number 02H in
    the 8086 family. The NMI is used by devices that require absolute,
    "now-or-never" priority over all other CPU functions. In particular, when
    a hardware memory error occurs, the computer's RAM subsystem generates an
    NMI. This causes the CPU to pass control to an interrupt 02H handler; the
    default handler in the PC family resides in ROM and issues the "PARITY
    CHECK" message you see when a memory error occurs.

    When you debug a program on any member of the PC family, remember that
    hardware interrupts are occurring all the time. For example, the system
    timer-tick interrupt (interrupt 08H) occurs roughly 18.2 times per second.
    The keyboard and disk-drive controllers also generate interrupts. Each
    time these hardware interrupts occur, the 8086 uses the current stack to
    save CS:IP and the flags register. If your stack is too small, or if you
    are manipulating SS and SP when a hardware interrupt occurs, the 8086 may
    damage valuable data when it saves CS:IP and the flags.

    If you look back at our example of updating SS and SP on page 36, you'll
    see that we explicitly disable hardware interrupts by executing the CLI
    instruction prior to updating SS. This prevents a hardware interrupt from
    occurring between the two MOV instructions while SS:SP is pointing
    nowhere. (Actually, this is a problem only in very early releases of the
    8088; the chip was later redesigned to prevent this problem by disabling
    interrupts during the instruction that follows a data move into SS.)

    We'll talk in more detail about how PCs and PS/2s use interrupts in
    Chapters 3 and 8.



────────────────────────────────────────────────────────────────────────────
Chapter 3  The ROM Software

    The Start-Up ROM

    The ROM BIOS
    Interrupt Vectors
    Key Low-Memory Addresses
    The ROM Version and Machine-ID Markers

    The ROM BASIC

    The ROM Extensions

    Comments

    It takes software to make a computer go. And getting a computer going and
    keeping it going is much easier if some of that software is permanently
    built into the computer. That's what the ROM programs are all about. ROM
    stands for read-only memory──memory permanently recorded in the circuitry
    of the computer's ROM chips, that can't be changed, erased, or lost.

    PCs and PS/2s come with a substantial amount of ROM that contains the
    programs and data needed to start and operate the computer and its
    peripheral devices. The advantage of having a computer's fundamental
    programs stored in ROM is that they are right there──built into the
    computer──and there is no need to load them into memory from disk the way
    that DOS must be loaded. Because they are permanent, the ROM programs are
    very often the foundation upon which other programs (including DOS) are
    built.

    There are four elements to the ROM in IBM's PC family: the start-up
    routines, which do the work of getting the computer started; the ROM
    BIOS──an acronym for Basic Input/Output System──which is a collection of
    machine-language routines that provide support services for the continuing
    operation of the computer; the ROM BASIC, which provides the core of the
    BASIC programming language; and the ROM extensions, which are programs
    that are added to the main ROM when certain optional equipment is added to
    the computer. We'll be examining each of these four major elements
    throughout the rest of this chapter.

    The ROM programs occupy addresses F000:0000H through F000:FFFFH in the
    PC/XT/AT family and the PS/2 models 25 and 30, and E000:0000H through
    F000:FFFFH in the other PS/2s. However, the routines themselves are not
    located at any specific addresses in ROM as they are in other computers.
    The address of a particular ROM routine varies among the different members
    of the PC/XT/AT and PS/2 families.

    Although the exact addresses of the ROM routines can vary, IBM provides a
    consistent interface to the ROM software by using interrupts. Later in
    this book we'll show you exactly how to use interrupts to execute the ROM
    routines.


The Start-Up ROM

    The first job the ROM programs have is to supervise the start-up of the
    computer. Unlike other aspects of the ROM, the start-up routines have
    little to do with programming the PC family──but it is still worthwhile to
    understand what they do.

    The start-up routines perform several tasks:

    ■  They run a quick reliability test of the computer (and the ROM
        programs) to ensure everything is in working order.

    ■  They initialize the chips and the standard equipment attached to the
        computer.

    ■  They set up the interrupt-vector table.

    ■  They check to see what optional equipment is attached.

    ■  They load the operating system from disk.

    The following paragraphs discuss these tasks in greater detail.

    The reliability test, part of a process known as the Power On Self Test
    (POST), is an important first step in making sure the computer is ready.
    All POST routines are quite brief except for the memory tests, which can
    be annoyingly lengthy in computers that contain a large amount of memory.

    The initialization process is slightly more complex. One routine sets the
    default values for interrupt vectors. These default values either point to
    the standard interrupt handlers located inside the ROM BIOS, or they point
    to do-nothing routines in the ROM BIOS that may later be superseded by the
    operating system or by your own interrupt handlers. Another initialization
    routine determines what equipment is attached to the computer and then
    places a record of it at standard locations in low memory. (We'll be
    discussing this equipment list in more detail later in the chapter.) How
    this information is acquired varies from model to model──for example, in
    the PC it is taken mostly from the settings of two banks of switches
    located on the computer's system board; in the PC/AT and the PS/2s, the
    ROM BIOS reads configuration information from a special nonvolatile memory
    area whose contents are initialized by special setup programs supplied by
    IBM. The POST routines learn about the computer's hardware by a logical
    inspection and test. In effect, the initialization program shouts to each
    possible option, "Are you there?", and listens for a response.

    No matter how it is acquired, the status information is recorded and
    stored in the same way for every model so that your programs can examine
    it. The initialization routines also check for new equipment and
    extensions to ROM. If they find any, they momentarily turn control over to
    the ROM extensions so that they can initialize themselves. The
    initialization routines then continue executing the remaining start-up
    routines (more on this later in the chapter).

    The final part of the start-up procedure, after the POST tests, the
    initialization process, and the incorporation of ROM extensions, is called
    the bootstrap loader. It's a short routine that loads a program from disk.
    In essence, the ROM bootstrap loader attempts to read a disk boot program
    from a disk. If the boot program is successfully read into memory, the ROM
    loader passes control of the computer to it. The disk boot program is
    responsible for loading another, larger disk program, which is usually a
    disk operating system such as DOS, but can be a self-contained and
    self-loading program, such as Microsoft Flight Simulator. If the ROM
    bootstrap loader cannot read a disk's boot program, it either activates
    the built-in ROM BASIC or displays an error message if the disk boot
    program contains an error. As soon as either of these two events occurs,
    the system start-up procedure is finished and the other programs take
    over.


The ROM BIOS

    The ROM BIOS is the part of ROM that is in active use whenever the
    computer is at work. The role of the ROM BIOS is to provide the
    fundamental services that are needed for the operation of the computer.
    For the most part, the ROM BIOS controls the computer's peripheral
    devices, such as the display screen, keyboard, and disk drives. When we
    use the term BIOS in its narrowest sense, we are referring to the device
    control programs──the programs that translate a simple command, such as
    read-something-from-the-disk, into all the steps needed to actually
    perform the command, including error detection and correction. In the
    broadest sense, the BIOS includes not only routines needed to control the
    PC's devices, but also routines that contain information or perform tasks
    that are fundamental to other aspects of the computer's operation, such as
    keeping track of the time of day.

    Conceptually, the ROM BIOS programs lie between programs that are
    executing in RAM (including DOS) and the hardware. In effect, this means
    that the BIOS works in two directions in a two-sided process. One side
    receives requests from programs to perform the standard ROM BIOS
    input/output services. A program invokes these services with a combination
    of an interrupt number (which indicates the subject of the service
    request, such as printer services) and a service number (which indicates
    the specific service to be performed). The other side of the ROM BIOS
    communicates with the computer's hardware devices (display screen, disk
    drives, and so on), using whatever detailed command codes each device
    requires. This side of the ROM BIOS also handles any hardware interrupts
    that a device generates to get attention. For example, whenever you press
    a key, the keyboard generates an interrupt to let the ROM BIOS know.

    Of all the ROM software, the BIOS services are probably the most
    interesting and useful to programmers──as a matter of fact, we have
    devoted six chapters to the BIOS services in Chapters 8 through 13. Since
    we deal with them so thoroughly later on, we'll skip any specific
    discussion of what the BIOS services do and instead focus on how the BIOS
    as a whole keeps track of the computer's input and output processes.

Interrupt Vectors

    The IBM PC family, like all computers based on the Intel 8086 family of
    microprocessors, is controlled largely through the use of interrupts,
    which can be generated by hardware or software. The BIOS service routines
    are no exception; each is assigned an interrupt number that you must call
    when you want to use the service.

    When an interrupt occurs, control of the computer is turned over to an
    interrupt-handling subroutine that is often stored in the system's ROM (a
    BIOS service routine is nothing more than an interrupt handler). The
    interrupt handler is called by loading its segment and offset addresses
    into registers that control program flow: the CS (code segment) register
    and the IP (instruction pointer) register──together known as the CS:IP
    register pair. Segment addresses that locate interrupt handlers are called
    interrupt vectors.

    During the system start-up process, the BIOS sets the interrupt vectors to
    point to the interrupt handlers in ROM. The interrupt vector table starts
    at the beginning of RAM, at address 0000:0000H. (See Chapter 2 for more
    about interrupts and interrupt vectors.) Each entry in the table is stored
    as a pair of words, with the offset portion first and the segment portion
    second. The interrupt vectors can be changed to point to a new interrupt
    handler simply by locating the vector and changing its value.

    As a general rule, PC-family interrupts can be divided into six
    categories: microprocessor, hardware, software, DOS, BASIC, and general
    use.

    Microprocessor interrupts, often called logical interrupts, are designed
    into the microprocessor. Four of them (interrupts 00H, 01H, 03H, and 04H)
    are generated by the microprocessor itself, and another (interrupt 02H,
    the nonmaskable interrupt) is activated by a signal generated by certain
    hardware devices, such as the 8087 math coprocessor.

    Hardware interrupts are built into the PC hardware. In PCs, XTs, and PS/2
    models 25 and 30, interrupt numbers 08H through 0FH are used for hardware
    interrupts; in ATs and PS/2 models 50, 60, and 80, interrupt numbers 08H
    through 0FH and 70H through 77H are reserved for hardware interrupts. (See
    Chapter 2 for more about hardware interrupts.)

    ──────────────────────────────────────────────────────────────────────────
    The Part DOS Plays
    The ROM bootstrap loader's only function is to read a bootstrap program
    from a disk and transfer control to it. On a bootable DOS disk, the disk
    bootstrap program verifies that DOS is stored on the disk by looking for
    two hidden files named IBMBIO.COM and IBMDOS.COM. If it finds them, it
    loads them into memory along with the DOS command interpreter,
    COMMAND.COM. During this loading process, optional parts of DOS, such as
    installable device drivers, may also be loaded.

    The IBMBIO.COM file contains extensions to the ROM BIOS. These
    extensions can be changes or additions to the basic I/O operations and
    often include corrections to the existing ROM BIOS, new routines for new
    equipment, or customized changes to the standard ROM BIOS routines.
    Because they are part of disk software, the IBMBIO.COM routines provide
    a convenient way to modify the ROM BIOS. All that is necessary, besides
    the new routine, is that the interrupt vectors for the previous ROM BIOS
    routines be changed to point to the location in memory where the new
    disk BIOS routines are placed. Whenever new devices are added to the
    computer, their support programs can be included in the IBMBIO.COM file
    or as installable device drivers, eliminating the need to replace ROM
    chips. See Appendix A for more on device drivers.

    You can think of the ROM BIOS routines as the lowest-level system
    software available, performing the most fundamental and primitive I/O
    operations. The IBMBIO.COM routines, being extensions of the ROM BIOS,
    are essentially on the same low level, also providing basic functions.
    By comparison, the IBMDOS.COM routines are more sophisticated; think of
    them as occupying the next level up, with applications programs on top.

    The IBMDOS.COM file contains the DOS service routines. The DOS services,
    like the BIOS services, can be called by programs through a set of
    interrupts whose vectors are placed in the interrupt-vector table in low
    memory. One of the DOS interrupts, interrupt 21H (decimal 33), is
    particularly important because when invoked, it gives you access to a
    rather large group of DOS functions. The DOS functions provide more
    sophisticated and efficient control over the I/O operations than the
    BIOS routines do, especially with regard to disk file operations. All
    standard disk processes──formatting diskettes; reading and writing data;
    opening, closing, and deleting files; performing directory searches──are
    included in the DOS functions and provide the foundation for many
    higher-level DOS programs, such as FORMAT, COPY, and DIR. Your programs
    can use the DOS services when they need more control of I/O operations
    than programming languages allow, and when you are reluctant to dig all
    the way down to the BIOS level. The DOS services are a very important
    part of this book, and we have devoted five chapters to them. (See
    Chapters 14 through 18.)

    The COMMAND.COM file is the third and most important part of DOS, at
    least from a utilitarian standpoint. This file contains the routines
    that interpret the commands you type in through the keyboard in the DOS
    command mode. By comparing your input to a table of command names, the
    COMMAND.COM program can differentiate between internal commands that are
    part of the COMMAND.COM file, such as RENAME or ERASE, and external
    commands, such as the DOS utility programs (like DEBUG) or one of your
    own programs. The command interpreter acts by executing the required
    routines for internal commands or by searching for the requested
    programs on disk and loading them into memory. The whole subject of the
    COMMAND.COM file and how it works is intriguing and well worth
    investigating──as are the other DOS programs. We recommend you read the
    DOS Technical Reference Manual or Inside the IBM PC for additional
    information.
    ──────────────────────────────────────────────────────────────────────────

    Software interrupts incorporated into the PC design are part of the ROM
    BIOS programs. ROM BIOS routines invoked by these interrupts cannot be
    changed, but the vectors that point to them can be changed to point to
    different routines. Reserved interrupt numbers are 10H through 1FH
    (decimal 16 through 31) and 40H through 5FH (decimal 64 through 95).

    DOS interrupts are always available when DOS is in use. Many programs and
    programming languages use the services provided by DOS through the DOS
    interrupts to handle basic operations, especially disk I/O. DOS interrupt
    numbers are 20H through 3FH (decimal 32 through 63).

    BASIC interrupts are assigned by BASIC itself and are always available
    when BASIC is in use. The reserved interrupt numbers are 80H through F0H
    (decimal 128 through 240).

    General-use interrupts are available for temporary use in your programs.
    The reserved interrupt numbers are 60H through 66H (decimal 96 through
    102).

    Most of the interrupt vectors used by the ROM BIOS, DOS, and BASIC contain
    the addresses of interrupt handlers. A few interrupt vectors, however,
    point to tables of useful information. For example, interrupt 1EH contains
    the address of a table of diskette drive initialization parameters; the
    interrupt 1FH vector points to a table of bit patterns used by the ROM
    BIOS to display text characters; and interrupts 41H and 46H point to
    tables of fixed-disk parameters. These interrupt vectors are used for
    convenience, not for interrupts. If you tried to execute interrupt 1EH,
    for instance, you'd probably crash the system because the interrupt 1EH
    vector points to data, not to executable code.

    The interrupt vectors are stored at the lowest memory locations; the very
    first location in memory contains the vector for interrupt number 00H, and
    so on. Because each vector is two words in length, you can find a
    particular interrupt's location in memory by multiplying its interrupt
    number by 4. For example, the vector for interrupt 05H, the print-screen
    service interrupt, would be at byte offset 20 (5 x 4 = 20); that is, at
    address 0000:0014H. You can examine the interrupt vectors by using DEBUG.
    For example, you could examine the interrupt 05H vector with DEBUG in the
    following way:

    DEBUG
    D 0000:0014 L 4

    DEBUG will show 4 bytes, in hex, like this:

    54 FF 00 F0

    Converted to a segment and offset address and allowing for "back-words"
    storage, the interrupt vector for the entry point in ROM of the
    print-screen service routine (interrupt 05H) is F000:FF54H. (Of course,
    this address may be different in different members of the PC and PS/2
    families.) The same DEBUG instruction finds any other interrupt vector
    just as easily.

    Figure 3-1 lists the main interrupts and their vector locations. These
    are the interrupts that programmers will probably find most useful.
    Details are available for most of these interrupts in Chapters 8 through
    18. Interrupts that are not mentioned in this list are, for the most part,
    reserved for future development by IBM.

╓┌─┌───────────┌────────────┌────────────────────────────────────────────────╖
    Interrupt   Offset in    Use
    Hex   Dec   Segment
                0000
    ──────────────────────────────────────────────────────────────────────────
    00H   0     0000         Generated by CPU when division by zero is
                            attempted
    01H   1     0004         Used to single-step through programs (as with
                            DEBUG)
    02H   2     0008         Nonmaskable interrupt (NMI)
    03H   3     000C         Used to set break-points in programs (as with
                            DEBUG)
    04H   4     0010         Generated when arithmetic result overflows
    05H   5     0014         Invokes print-screen service routine in ROM BIOS
    08H   8     0020         Generated by hardware clock tick
    Interrupt   Offset in    Use
    Hex   Dec   Segment
                0000
    ──────────────────────────────────────────────────────────────────────────
    08H   8     0020         Generated by hardware clock tick
    09H   9     0024         Generated by keyboard action
    0EH   14    0038         Signals diskette attention (e.g. to signal
                            completion)
    0FH   15    003C         Used in printer control
    10H   16    0040         Invokes video display services in ROM BIOS
    11H   17    0044         Invokes equipment-list service in ROM BIOS
    12H   18    0048         Invokes memory-size service in ROM BIOS
    13H   19    004C         Invokes disk services in ROM BIOS
    14H   20    0050         Invokes communications services in ROM BIOS
    15H   21    0054         Invokes system services in ROM BIOS
    16H   22    0058         Invokes standard keyboard services in ROM BIOS
    17H   23    005C         Invokes printer services in ROM BIOS
    18H   24    0060         Activates ROM BASIC language
    19H   25    0064         Invokes bootstrap start-up routine in ROM BIOS
    1AH   26    0068         Invokes time and date services in ROM BIOS
    1BH   27    006C         Interrupt by ROM BIOS for Ctrl-Break
    Interrupt   Offset in    Use
    Hex   Dec   Segment
                0000
    ──────────────────────────────────────────────────────────────────────────
    1BH   27    006C         Interrupt by ROM BIOS for Ctrl-Break
    1CH   28    0070         Interrupt generated at each clock tick
    1DH   29    0074         Points to table of video control parameters
    1EH   30    0078         Points to diskette drive parameter table
    1FH   31    007C         Points to CGA video graphics characters
    20H   32    0080         Invokes program-terminate service in DOS
    21H   33    0084         Invokes all function-call services in DOS
    22H   34    0088         Address of DOS program-terminate routine
    23H   35    008C         Address of DOS keyboard-break handler
    24H   36    0090         Address of DOS critical-error handler
    25H   37    0094         Invokes absolute disk-read service in DOS
    26H   38    0098         Invokes absolute disk-write service in DOS
    27H   39    009C         Ends program, but keeps it in memory under DOS
    2FH   47    00BC         DOS Multiplex interrupt
    41H   65    0104         Points to fixed-disk drive parameter table
    43H   67    010C         Points to video graphics characters (EGA, PS/2s)
    67H   103   019CH        Invokes LIM Expanded Memory Manager
    Interrupt   Offset in    Use
    Hex   Dec   Segment
                0000
    ──────────────────────────────────────────────────────────────────────────
    67H   103   019CH        Invokes LIM Expanded Memory Manager
    ──────────────────────────────────────────────────────────────────────────


    Figure 3-1.  Important interrupts used in the IBM personal computer
    family.

    Changing Interrupt Vectors

    The main programming interest in interrupt vectors is not to read them but
    to change them to point to a new interrupt-handling routine. To do this,
    you must write a routine that performs a different function than the
    standard ROM BIOS or DOS interrupt handlers perform, store the routine in
    RAM, and then assign the routine's address to an existing interrupt in the
    table.

    A vector can be changed byte by byte on an assembly-language level, or by
    using a programming-language instruction like the POKE statement in BASIC.
    In some cases, there may be a danger of an interrupt occurring in the
    middle of a change to the vector. If you are not concerned about this, go
    ahead and use the POKE method. Otherwise, there are two ways to change
    a vector while minimizing the likelihood of interrupts: by suspending
    interrupts during the process, or by using a DOS interrupt specially
    designed to change vectors.

    The first method requires that you use assembly language to suspend
    interrupts while you change the interrupt vector. You can use the clear
    interrupts instruction (CLI), which suspends all interrupts until a
    subsequent STI (set interrupts) instruction is executed. By temporarily
    disabling interrupts with CLI you ensure that no interrupts can occur
    while you update an interrupt vector.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    CLI does not disable the nonmaskable interrupt (NMI). If your
    application is one of the rare ones that needs to supply its own NMI
    handler, the program should temporarily disable the NMI while changing
    the NMI interrupt vector. (See PC or PS/2 technical reference manuals
    for details.)
    ──────────────────────────────────────────────────────────────────────────

    The following example demonstrates how to update an interrupt vector with
    interrupts temporarily disabled. This example uses two MOV instructions to
    copy the segment and offset address of an interrupt handler from DS:DX
    into interrupt vector 60H:

    xor     ax,ax                   ; zero segment register ES
    mov     es,ax
    cli                             ; disable interrupts
    mov     word ptr es:[180h],dx   ; update vector offset
    mov     word ptr es:[182h],ds   ; update vector segment
    sti                             ; enable interrupts

    The second method of updating an interrupt vector is to let DOS do it for
    you using DOS interrupt 21H, service 25H (decimal 37), which was designed
    for this purpose. There are two very important advantages to letting DOS
    set interrupts for you. One advantage is that DOS takes on the task of
    putting the vector into place in the safest possible way. The other
    advantage is more far-reaching. When you use DOS service 25H to change an
    interrupt vector, you allow DOS to track changes to any interrupt vectors
    it may itself be using. This is particularly important for programs that
    might run in the DOS "compatibility box" in OS/2. Using a DOS service to
    set an interrupt vector instead of setting it yourself is only one of many
    ways that you can reduce the risk that a program will be incompatible with
    new machines or new operating-system environments.

    The following example demonstrates how to use interrupt 21H, service 25H
    to update the vector for interrupt 60H from values stored in a memory
    variable:

    mov     dx,seg Int60Handler     ; copy new segment to DS
    mov     ds,dx
    mov     dx,offset Int60Handler  ; store offset address in DX
    mov     al,60h                  ; interrupt number
    mov     ah,25h                  ; DOS set-interrupt function number
    int     21h                     ; DOS function-call interrupt

    This example shows, in the simplest possible way, how to use the DOS
    service. However, it glosses over an important and subtle difficulty: You
    have to load one of the addresses that you're passing to DOS into the DS
    (data segment) register──which effectively blocks normal access to data
    through the DS register. Getting around that problem requires you to
    preserve the contents of the DS register. Here is one way this can be
    done. In this example, taken from the Norton Utilities programs, the
    interrupt 09H vector is updated with the address of a special interrupt
    handler:

    push    ds                      ; save current data segment
    mov     dx,offset PGROUP:XXX    ; store handler's offset in DX
    push    cs                      ; move handler's code segment...
    pop     ds                      ; ...into DS
    mov     ah,25h                  ; request set-interrupt function
    mov     al,9                    ; change interrupt number 9
    int     21h                     ; DOS function-call interrupt
    pop     ds                      ; restore original data segment

Key Low-Memory Addresses

    Much of the operation of the PCs and PS/2s is controlled by data stored in
    low-memory locations, particularly in the two adjacent 256-byte areas
    beginning at segments 40H and 50H (addresses 0040:0000H and 0050:0000H).
    The ROM BIOS uses the 256 bytes from 0040:0000H through 0040:00FFH as a
    data area for its keyboard, video, disk, printer, and communications
    routines. The 256 bytes between 0050:0000H and 0050:00FFH are used
    primarily by BASIC, although a few ROM BIOS status variables are located
    there as well.

    Data is loaded into these areas by the BIOS during the start-up process.
    Although the control data is supposed to be the private reserve of the
    BIOS, DOS, and BASIC, your programs are allowed to inspect or even change
    it. Even if you do not intend to use the information in these control
    areas, it is worth studying because it reveals a great deal about what
    makes the PC family tick.

    The ROM BIOS Data Area

    Some memory locations in the BIOS data area are particularly interesting.
    Most of them contain data vital to the operation of various ROM BIOS and
    DOS service routines. In many instances, your programs can obtain
    information stored in these locations by invoking a ROM BIOS interrupt; in
    all cases, they can access the information directly. You can easily check
    out the values at these locations on your own computer, using either DEBUG
    or BASIC. To use DEBUG, type a command of this form:

    DEBUG
    D XXXX:YYYY L 1

    XXXX represents the segment part of address you want to examine. (This
    would be either 0040H or 0050H, depending on the data area that interests
    you.) YYYY represents the offset part of the address. The L 1 tells DEBUG
    to display one byte. To see two or more bytes, type the number of bytes
    (in hex) you want to see after the L instruction. For example, the BIOS
    keeps track of the current video mode number in the byte at 0040:0049H. To
    inspect this byte with DEBUG, you would type

    DEBUG
    D 0040:0049 L 1

    To display the data with BASIC, use a program of the following form,
    making the necessary substitutions for segment (&H0040 or &H0050),
    number.of.bytes, and offset (the offset part of the address you want to
    inspect):

    10 DEF SEG = segment
    20 FOR I = 0 TO number.of.bytes - 1
    30   VALUE = PEEK(offset + I)
    40   IF VALUE < 16 THEN PRINT "0";    ' needed for leading zero
    50   PRINT HEX$ (VALUE);" ";
    60 NEXT I

    The following pages describe useful low-memory addresses.

    0040:0010H (a 2-byte word). This word holds the equipment-list data that
    is reported by the equipment-list service, interrupt 11H (decimal 17). The
    format of this word, shown in Figure 3-2, was established for the PC and
    XT; certain parts may appear in a different format in later models.

    0040:0013H (a 2-byte word). This word contains the usable memory size in
    KB. BIOS interrupt service 12H (decimal 18) is responsible for reporting
    the value in this word.

    0040:0017H (2 bytes of keyboard status bits). These bytes are actively
    used to control the interpretation of keyboard actions by the ROM BIOS
    routines. Changing these bytes actually changes the meaning of keystrokes.
    You can freely change the first byte, at address 0040:0017H, but it is not
    a good idea to change the second byte. See pages 137 and 138 for the bit
    settings of these 2 bytes.

╓┌─┌──────────────────┌─────────────────┌────────────────────────────────────╖
                    Bit
    F E D C B A 9 8    7 6 5 4 3 2 1 0   Meaning
    ──────────────────────────────────────────────────────────────────────────
    X X . . . . . .    . . . . . . . .   Number of printers installed
    . . X . . . . .    . . . . . . . .   (Reserved)
    . . . X . . . .    . . . . . . . .   1 if game adapter installed
    . . . . X X X .    . . . . . . . .   Number of RS-232 serial ports
    . . . . . . . X    . . . . . . . .   (Reserved)
    . . . . . . . .    X X . . . . . .   +1 = number of diskette drives:
                                            00 = 1 drive; 01 = 2 drives;
                                            10 = 3 drives;
                                            11 = 4 drives (see bit 0)
    . . . . . . . .    . . X X . . . .   Initial video mode:
                                            01 = 40-column color;
                                            10 = 80-column color,
                                            11 = 80-column monochrome;
                    Bit
    F E D C B A 9 8    7 6 5 4 3 2 1 0   Meaning
    ──────────────────────────────────────────────────────────────────────────
                                            11 = 80-column monochrome;
                                            00 = none of the above
    . . . . . . . .    . . . . X X . .   For PC with 64 KB motherboard:
                                            Amount of system board RAM
                                            (11 = 64 KB, 10 = 48 KB,
                                            01 = 32 KB, 00 = 16 KB)
                                        For PC/AT: Not used
                                        For PS/2s: Bit 3: Not used;
                                            Bit 2: 1 = pointing device
                                        installed
    . . . . . . . .    . . . . . . X .   1 if math coprocessor installed
    . . . . . . . .    . . . . . . . X   1 if any diskette drives present (if
                                        so, see bits 7 and 6)
    ──────────────────────────────────────────────────────────────────────────


    Figure 3-2.  The coding of the equipment-list word at address 0040:0010H.

    0040:001AH (a 2-byte word). This word points to the current head of the
    BIOS keyboard buffer at 0040:001EH, where keystrokes are stored until they
    are used.

    0040:001CH (a 2-byte word). This word points to the current tail of the
    BIOS keyboard buffer.

    0040:001EH (32 bytes, used as sixteen 2-byte entries). This keyboard
    buffer holds up to 16 keystrokes until they are read via the BIOS services
    through interrupt 16H (decimal 22). As this is a circular queue buffer,
    two pointers indicate the head and tail. It is not wise to manipulate this
    data.

    0040:003EH (1 byte). This byte indicates if a diskette drive needs to be
    recalibrated before seeking to a track. Bits 0 through 3 correspond to
    drives 0 through 3. If a bit is clear, recalibration is needed. Generally,
    you will find that a bit is clear if there was any problem with the most
    recent use of a drive. For example, the recalibration bit will be clear if
    you try to request a directory (DIR) on a drive with no diskette, and then
    type A in response to the following display:

    Not ready reading drive A
    Abort, Retry, Fail?

    0040:003FH (1 byte). This byte returns the diskette motor status. Bits 0
    through 3 correspond to drives 0 through 3. If the bit is set, the
    diskette motor is running.

    0040:0040H (1 byte). This byte is used by the ROM BIOS to ensure that the
    diskette drive motor is turned off. The value in this byte is decremented
    with every tick of the system clock (that is, about 18.2 times per
    second). When the value reaches 0, the BIOS turns off the drive motor.

    0040:0041H (1 byte). This byte contains the status code reported by the
    ROM BIOS after the most recent diskette operation. (See Figure 3-3.)

    0040:0042H (7 bytes). These 7 bytes hold diskette controller status
    information.

    Beginning at 0040:0049H is a 30-byte area used for video control. This is
    the first of two areas in segment 40H that the ROM BIOS uses to track
    critical video information.

    Value              Meaning
    ──────────────────────────────────────────────────────────────────────────
    00H                No error
    01H                Invalid diskette command requested
    02H                Address mark on diskette not found
    03H                Write-protect error
    04H                Sector not found; diskette damaged or not formatted
    06H                Diskette change line active
    08H                DMA diskette error
    09H                Attempt to DMA across 64 KB boundary
    0CH                Media type not found
    10H                Cyclical redundancy check (CRC) error in data
    20H                Diskette controller failed
    40H                Seek operation failed
    80H                Diskette timed out (drive not ready)
    ──────────────────────────────────────────────────────────────────────────

    Figure 3-3.  Diskette status codes in the ROM BIOS data area at
    0040:0041H.

    Although programs can safely inspect any of this data, you should modify
    the data only when you bypass the ROM BIOS video services and program the
    video hardware directly. In such cases, you should update the video
    control data to reflect the true status of the video hardware.

    0040:0049H (1 byte). The value in this byte specifies the current video
    mode. (See Figure 3-4.) This is the same video-mode number used in the
    ROM BIOS video services. (See Chapter 9 for more on these services and
    page 72 for general information concerning video modes.)

    We've already shown how to use DEBUG to determine the current video mode
    by inspecting the byte at 0040:0049H. BASIC programs can use the following
    instructions to read this byte and determine the video mode:

    DEF SEG = &H40                  ' set BASIC data segment to 40H
    VIDEO.MODE = PEEK(&H49)         ' look at location 0040:0049H

    0040:004AH (a 2-byte word). This word indicates the number of characters
    that can be displayed in each row of text on the screen.

    0040:004CH (a 2-byte word). This word indicates the number of bytes
    required to represent one screenful of video data.

    Number             Description
    ──────────────────────────────────────────────────────────────────────────
    00H                40 x 25 16-color text
                        (CGA composite color burst disabled)
    01H                40 x 25 16-color text
    02H                80 x 25 16-color text
                        (CGA composite color burst disabled)
    03H                80 x 25 16-color text
    04H                320 x 200 4-color graphics
    05H                320 x 200 4-color graphics
                        (CGA composite color burst disabled)
    06H                640 x 200 2-color graphics
    07H                80 x 25 monochrome text
    0DH                320 x 200 16-color graphics
    0EH                640 x 200 16-color graphics
    0FH                640 x 350 monochrome graphics
    10H                640 x 350 16-color graphics
    11H                640 x 480 2-color graphics
    12H                640 x 480 16-color graphics
    13H                320 x 200 256-color graphics
    ──────────────────────────────────────────────────────────────────────────

    Figure 3-4.  BIOS video mode numbers stored at address 0040:0049H.

    0040:004EH (a 2-byte word). This word contains the starting byte offset
    into video display memory of the current display page. In effect, this
    address indicates which page is in use by giving the offset to that page.

    0040:0050H (eight 2-byte words). These words give the cursor locations for
    eight separate display pages, beginning with page 0. The first byte of
    each word gives the character column and the second byte gives the row.

    0040:0060H (a 2-byte word). These 2 bytes indicate the size of the cursor,
    based on the range of cursor scan lines. The first byte gives the ending
    scan line, the second byte the starting scan line.

    0040:0062H (1 byte). This byte holds the current display page number.

    0040:0063H (a 2-byte word). This word stores the port address of the
    hardware CRT controller chip.

    0040:0065H (1 byte). This byte contains the current setting of the CRT
    mode register on the Monochrome Display Adapter and the Color Graphics
    Adapter.

    0040:0066H (1 byte). This byte contains the current setting of the Color
    Graphics Adapter's CRT color register. This byte ends the first block of
    ROM BIOS video control data.

    0040:0067H (5 bytes). The original IBM PC BIOS used the 5 bytes starting
    at 0040:0067H for cassette tape control. In PS/2 models 50, 60, and 80,
    which don't support a cassette interface, the 4 bytes at 0040:0067H can
    contain the address of a system reset routine that overrides the usual
    BIOS startup code. (See the BIOS technical reference manual for details.)

    0040:006CH (4 bytes stored as one 4-byte number). This area is used as a
    master clock count, which is incremented once for each timer tick. It is
    treated as if it began counting from 0 at midnight. When the count reaches
    the equivalent of 24 hours, the ROM BIOS resets the count to 0 and sets
    the byte at 0040:0070H to 1. DOS or BASIC calculates the current time from
    this value and sets the time by putting the appropriate count in this
    field.

    0040:0070H (1 byte). This byte indicates that a clock rollover has
    occurred. When the clock count passes midnight (and is reset to 0), the
    ROM BIOS sets this byte to 1, which means that the date should be
    incremented.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    This byte is set to 1 at midnight and is not incremented. There is no
    indication if two midnights pass before the clock is read.
    ──────────────────────────────────────────────────────────────────────────

    0040:0071H (1 byte). The ROM BIOS sets bit 7 of this byte to indicate that
    the Ctrl-Break key combination was pressed.

    0040:0072H (a 2-byte word). This word is set to 1234H after the initial
    power-up memory check. When a warm boot is instigated from the keyboard
    (via Ctrl-Alt-Del), the memory check will be skipped if this location is
    already set to 1234H.

    0040:0074H (4 bytes). These 4 bytes are used by various members of the PC
    family for diskette and fixed-disk drive control. See the IBM BIOS
    Interface Technical Reference Manual for details.

    0040:0078H (4 bytes). These bytes control time-out values for the parallel
    printers. (In the PS/2, only the first 3 bytes are used for this purpose.)

    0040:007CH (4 bytes). These bytes contain time-out values for up to four
    RS-232 serial ports.

    0040:0080H (a 2-byte word). This word points to the start of the keyboard
    buffer area.

    0040:0082H (a 2-byte word). This word points to the end of the keyboard
    buffer area.

    The next 7 bytes are used by the ROM BIOS in the EGA and PS/2s for video
    control:

    0040:0084H (1 byte). The value of this byte is one less than the number of
    character rows displayed on the screen. The BIOS can refer to this value
    to determine how many character rows of data to erase when the screen is
    cleared or how many rows to print when Shift-PrtSc is pressed.

    0040:0085H (2 bytes). This word indicates the height, in scan lines, of
    characters on the screen.

    0040:0087H (4 bytes). These 4 bytes are used by the BIOS video support
    routines to indicate the amount of video RAM available, the initial
    settings of the EGA configuration switches, and other miscellaneous video
    status information.

    0040:008BH (11 bytes). The ROM BIOS uses this data area for control and
    status information regarding the diskette and fixed-disk drives.

    0040:0098H (9 bytes). This data area is used by the PC/AT and PS/2 BIOS to
    control certain functions of the real-time clock.

    0040:00A8H (4 bytes). In the EGA and PS/2 BIOS, these bytes contain the
    segmented address of a table of video parameters and overrides for default
    ROM BIOS video configuration values. The actual contents of the table
    vary, depending on which video hardware you are using. The IBM ROM BIOS
    Interface Technical Reference Manual describes this table in detail.

    0050:0000H (1 byte). This byte is used by the ROM BIOS to indicate the
    status of a print-screen operation. Three possible hex values are stored
    in this location:

    ──────────────────────────────────────────────────────────────────────────
    00H            Indicates OK status
    01H            Indicates a print-screen operation is currently in progress
    FFH            Indicates an error occurred during a print-screen operation
    ──────────────────────────────────────────────────────────────────────────

    0050:0004H (1 byte). This byte is used by DOS when a single-diskette
    system mimics a two-diskette system. The value indicates whether the one
    physical drive is acting as drive A or drive B. These values are used:

    ──────────────────────────────────────────────────────────────────────────
    00H            Acting as drive A
    01H            Acting as drive B
    ──────────────────────────────────────────────────────────────────────────

    0050:0010H (a 2-byte word). This area is used by ROM BASIC to hold its
    default data segment (DS) value.

    BASIC lets you set your own data segment value with the DEF SEG = value
    statement. (The offset into the segment is specified by the PEEK or POKE
    function.) You can also reset the data segment to its default setting by
    using the DEF SEG statement without a value. Although BASIC does not give
    you a simple way to find the default value stored in this location, you
    can get it by using this little routine:

    DEF SEG = &H50
    DATA.SEGMENT = PEEK(&H11) * 256 + PEEK(&H10)

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    BASIC administers its own internal data based on the default data
    segment value. Attempting to change this value is likely to sabotage
    BASIC's operation.
    ──────────────────────────────────────────────────────────────────────────

    0050:0012H (4 bytes). In some versions of ROM BASIC, these 4 bytes contain
    the segment and offset address of BASIC's clock-tick interrupt handler.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    In order to perform better, BASIC runs the system clock at four times
    the standard rate, so BASIC must replace the ROM BIOS clock interrupt
    routine with its own. The standard BIOS interrupt routine is invoked by
    BASIC at the normal rate; that is, once for every four fast ticks.
    There's more about this on page 146.
    ──────────────────────────────────────────────────────────────────────────

    0050:0016H (4 bytes). This area contains the address of ROM BASIC's
    break-key handling routine.

    0050:001AH (4 bytes). This area contains the address of ROM BASIC's
    diskette error-handling routine.

    The Intra-Application Communications Area

    In the PC/XT/AT family, the 16 bytes starting at 0040:00F0H are reserved
    as an intra-application communication area (ICA). This data area provides
    an area of RAM at a known address that an application can use for sharing
    data among separate program modules. In the PS/2 BIOS, however, the ICA is
    no longer documented.

    Few applications actually use the ICA because the amount of RAM is so
    small and because the data within the ICA can be unexpectedly modified
    when more than one program uses it. If you do write a program that uses
    the ICA, we recommend that you include a checksum and also a signature so
    that you can ensure that the data in the ICA is yours and that it has not
    been changed by another program.

    ──────────────────────────────────────────────────────────────────────────
    WARNING:
    The ICA is definitely located in the 16 bytes from 0040:00F0H through
    0040:00FFH. A typographic error in some editions of the IBM PC Technical
    Reference Manual places it at 0050:0000H through 0050:00FFH. This is
    incorrect.
    ──────────────────────────────────────────────────────────────────────────

    The BIOS Extended Data Area

    The PS/2 ROM BIOS start-up routines allocate an additional area of RAM for
    their own use. The BIOS routines use this extended data area for transient
    data storage. For example, the BIOS routines that support the
    pointing-device (mouse) controller hardware use part of the extended data
    area for temporary storage.

    You can determine the starting address of the extended data area by using
    a system service available through ROM BIOS interrupt 15H. (See Chapter
    12.) The first byte in the extended data area contains the size of the
    data area in KB.

The ROM Version and Machine-ID Markers

    Because the BIOS programs are fixed in memory, they can't be easily
    changed when additions or corrections are needed. This means that ROM
    programs must be tested very carefully before they are frozen onto memory
    chips. Although there is a good chance for serious errors to exist in a
    system's ROM programs, IBM has a fine track record; so far, only small and
    relatively unimportant errors have been found in the PC family's ROM
    programs, and IBM has done well to correct errors by revising the BIOS.

    The different versions of ROM software could present a small challenge to
    programmers who discover that the differences affect the operating
    characteristics of their programs. But an even greater challenge for
    programmers is that the PC, XT, AT, and PS/2s each have a slightly
    different set of ROM BIOS routines.

    To ensure that programs can work with the appropriate ROM programs and the
    right computer, IBM has supplied two identifying markers that are
    permanently available at the end of memory in the system ROM. One marker
    identifies the ROM release date, which can be used to identify the BIOS
    version, and the other gives the machine model. These markers are always
    present in IBM's own machines and you'll also find them supplied by the
    manufacturers of a few PC compatibles. The following paragraphs describe
    these markers in detail.

    The ROM release date can be found in an 8-byte storage area from
    F000:FFF5H to F000:FFFCH (2 bytes before the machine ID byte). It consists
    of ASCII characters in the common American date format; for example,
    06/01/83 stands for June 1, 1983. This release marker is a common feature
    of the IBM personal computers, but is present in only a few IBM
    compatibles. For example, the Compaq Portable I does not have it, but the
    Panasonic Senior Partner does.

    You can look at the release date with DEBUG by using the following
    command:

    DEBUG
    D F000:FFF5 L 8

    Or you can let your program look at the bytes using this technique:

    10 DEF SEG = &HF000
    20 FOR I = 0 TO 7
    30   PRINT CHR$(PEEK(&HFFF5 + I));
    40 NEXT
    50 END

    The model ID is a byte located at F000:FFFEH. This byte identifies which
    model of PC or PS/2 you are using. (See Figure 3-5.) In addition, a ROM
    BIOS service in the PC/AT and PS/2s returns more detailed identification
    information, including the submodel byte listed in the figure. (See
    Chapter 12.)

╓┌─┌──────────────────┌────────┌────────┌────────┌─────────┌─────────────────╖
    Machine            Date     Model    Submodel BIOS      Revision Notes
    ──────────────────────────────────────────────────────────────────────────
    PC                 04/24/81 FFH      ☼        00
                        10/19/81 FFH      ☼        01        Some BIOS bugs
                                                            fixed
                        10/27/82 FFH      ☼        02        Upgrade of PC BIOS
                                                            to XT level
    PC/XT              11/08/82 FEH      ☼        00
                        01/10/86 FBH      00       01        256/640 KB system
                                                            board
                        05/09/86 FBH      00       02
    PC/AT              01/10/84 FCH      ☼        00        6 MHz 80286
                        06/10/85 FCH      00       01
                        11/15/85 FCH      01       00        8 MHz 80286
    PS/2 Model 25      06/26/87 FAH      01       00
    PS/2 Model 30      09/02/86 FAH      00       00
                        12/12/86 FAH      00       01
    PS/2 Model 50      02/13/87 FCH      04       00
    PS/2 Model 60      02/13/87 FCH      05       00
    Machine            Date     Model    Submodel BIOS      Revision Notes
    ──────────────────────────────────────────────────────────────────────────
    PS/2 Model 60      02/13/87 FCH      05       00
    PS/2 Model 80      03/30/87 F8H      00       00        16 MHz 80386
    PS/2 Model 80      10/07/87 F8H      01       00        20 MHz 80386
    PCjr               06/01/83 FDH      ☼        00
    PC Convertible     09/13/85 F9H      00       00
    PC/XT Model        04/21/86 FCH      02       00
    286
    ──────────────────────────────────────────────────────────────────────────


    Figure 3-5.  Machine and ROM BIOS version identification.

    It is possible that IBM-compatible computers can be identified in the same
    way, but we do not know of any reliable published information. You may
    need to rely on improvised methods to identify non-IBM compatibles.

    You can examine the machine ID byte with DEBUG by using the following
    command:

    DEBUG
    D F000:FFFE L 1

    A BASIC program can inspect this byte using techniques such as this:

    10 DEF SEG = &HF000
    20 MODEL = PEEK(&HFFFE)
    30 IF MODEL < &HF8 THEN PRINT "I'm not an IBM computer" : STOP
    40 ON (MODEL - &HF7) GOTO 100,110,120,130,140,150,160,170
    100 PRINT "I'm a PS/2 Model 80" : STOP
    110 PRINT "I'm a PC convertible" : STOP
    120 PRINT "I'm a PS/2 Model 30" : STOP
    130 PRINT "I'm a PC/XT" : STOP
    140 PRINT "I'm an 80286-based machine (PC/AT, PS/2 Model 50 or 60)" :
                STOP
    150 PRINT "I'm a PCjr" : STOP
    160 PRINT "I'm a PC/XT" : STOP
    170 PRINT "I'm a PC" : STOP


The ROM BASIC

    Now we move on to the third element of ROM: the ROM BASIC. The ROM BASIC
    acts in two ways. First, it provides the core of the BASIC language, which
    includes most of the commands and the underlying foundation──such as
    memory management──that BASIC uses. The disk versions of interpreted
    BASIC, which are found in the program files BASIC.COM and BASICA.COM, are
    essentially supplements to ROM BASIC, and they rely on ROM BASIC to get
    much of their work done. The second role of ROM BASIC is to provide what
    IBM calls "cassette" BASIC──the BASIC that is activated when you start up
    your computer without a disk.

    Whenever you use any of the interpreted, disk-based BASICs, the ROM BASIC
    programs are also used──although there's nothing to make you aware of it.
    On the other hand, compiled BASIC programs don't make use of the ROM
    BASIC.


The ROM Extensions

    The fourth element of the ROM has more to do with the PC's design than
    with the actual contents of its memory. The PC was designed to allow for
    installable extensions to the built-in software in ROM. The additional ROM
    is usually located on a plug-in adapter such as the Enhanced Graphics
    Adapter or a fixed-disk controller card. Computers in the PC/XT/AT family
    also have empty sockets on their system boards to accommodate additional
    ROM chips. Because the original ROM BIOS could not include support
    programs for future hardware, ROM extensions are obviously a necessary and
    helpful addition.

    Several memory areas are reserved for ROM extensions. Addresses C000:0000H
    through C000:7FFFH are reserved for video adapter ROM. The area between
    C800:0000H and D000:FFFFH can be used by nonvideo adapters. (For example,
    the IBM XT fixed-disk adapter occupies addresses starting at C800:0000H.)
    Finally, ROM extensions on chips placed onto the system board of a PC, XT,
    or AT occupy the address range E000:0000H through E000:FFFFH. In the PS/2
    models 50, 60, and 80, you cannot add ROM chips to the system board. The
    system ROM in these computers occupies the entire address range between
    E000:0000H and F000:FFFFH.


Comments

    As the PC family has evolved, the amount and complexity of the ROM
    software has increased to accommodate the greater sophistication of the
    computer hardware. The source code listings in the PC, XT, and AT
    technical reference manuals consist of tens of thousands of
    assembly-language instructions. Despite the size of the ROM BIOS, a browse
    through the source code can be fun and enlightening.

    We have made every effort in this book to point out when and how to use
    the ROM BIOS routines. We recommend that you read Chapters 8 through 13
    before you begin your own exploration of the ROM BIOS.



────────────────────────────────────────────────────────────────────────────
Chapter 4  Video Basics

    The Video Subsystems
    Memory and the Video Subsystems
    Creating the Screen Image

    The Video Display Modes
    Video Mode Control
    Display Resolution

    The Use of Color
    Color-Suppressed Modes
    Color in Text and Graphics Modes

    Inside the Display Memory
    Display Pages in Text Modes
    Display Pages in Graphics Modes
    Displaying Characters in Text and Graphics Modes

    Controlling the Video Display
    Direct Hardware Control

    Compatibility Considerations

    To many people, the video display is the computer. Programs are often
    judged by their display quality and visual design alone. In this chapter,
    you'll see what kinds of video display output the IBM PC family can
    produce. More importantly, we'll describe how to manipulate the video
    displays to get the effects you want.


The Video Subsystems

    Every PC and PS/2 has a video subsystem responsible for producing the
    image that appears on the screen. At the heart of the video subsystem is
    the special-purpose circuitry that must be programmed to generate the
    electrical signals that control the video display. Most members of the
    PC/XT/AT family require you to install a display adapter, a special video
    circuit board that plugs into one of the computer's expansion slots. On
    the other hand, all PS/2s are equipped with built-in video circuitry and,
    therefore, require no display adapter.

    The video circuitry consists of a group of interrelated components that
    control signal timing, colors, and the generation of text characters. All
    IBM video subsystems have a video buffer, a block of dedicated memory that
    holds the text or graphics information displayed on the screen. The video
    subsystem performs the unique task of translating the raw data in the
    video buffer into the signals that drive the video display.

    The various video subsystems used in PCs and PS/2s all evolved from the
    two video adapters originally released by IBM for the PC: the Monochrome
    Display Adapter (MDA) and the Color Graphics Adapter (CGA). IBM later
    released its Enhanced Graphics Adapter (EGA), a more powerful successor to
    the MDA and CGA.

    When the PS/2s appeared, IBM introduced two more video subsystems: the
    Multi-Color Graphics Array (MCGA), built into the PS/2 models 25 and 30,
    and the Video Graphics Array (VGA), built into the PS/2 models 50, 60, and
    80. At the same time the PS/2s appeared, IBM introduced a VGA adapter that
    can be used in the PC/XT/AT family as well as in the PS/2 Model 30.

    We'll be discussing all five of these IBM subsystems──MDA, CGA, EGA, MCGA,
    and VGA──in this chapter. Although clear differences in hardware design
    exist between the various video subsystems, their strong family
    resemblance should encourage you to consider what they have in common
    before worrying about the differences between them.

    Most of the five video subsystems can be programmed into two fundamentally
    different modes, called text mode and graphics mode by IBM. (The lone
    exception is the MDA, which operates only in text mode.) In text mode you
    can display only text characters, though many of these characters are
    suitable for producing simple line drawings. (See Appendix C for more on
    characters.) Graphics mode is mainly used for complex drawings but you can
    also use it to draw text characters in a variety of shapes and sizes.

    The CGA can operate in both text and graphics modes to produce drawings
    and characters in several formats and colors. By contrast, the MDA can
    operate only in text mode, using a stored set of ASCII alphanumeric and
    graphics characters and displaying them in only one color. The MDA works
    only with the IBM Monochrome Monitor (or its equivalent) while the CGA
    must be connected to either a direct-drive or a composite color monitor.
    (See page 74 for more on monitors.) Many business and professional users
    prefer a monochrome display to a color display because a monochrome screen
    is easier on the eyes and less expensive than an equivalent color display.
    But in choosing monochrome, they sacrifice color, a valuable asset for any
    computer display.

    The MDA's most obvious drawback is its inability to display images in
    graphics mode. For this reason, PC/XT/AT users who prefer a monochrome
    display, yet need to view graphics, must turn to an EGA or to a non-IBM
    adapter like the Hercules Graphics Card, which emulates the MDA's text
    mode but supports a monochrome graphics mode as well.

    Roughly two-thirds of all PCs are equipped with the standard MDA and
    therefore have no graphics or color capability. While there are real
    advantages to using color and graphics, most PCs get along nicely without
    either. Although the clear trend is toward higher-performance video
    subsystems that can display graphics as well as text, keep in mind as you
    plan computer applications that many PCs display text only.

    The best way to understand the video capabilities of the PCs and PS/2s is
    to cover the features that their various video subsystems have in common.
    As we go along, we'll point out the differences and improvements that
    distinguish the newer and more complicated subsystems (EGA, MCGA, and VGA)
    from their predecessors (MDA and CGA).

Memory and the Video Subsystems

    The video buffer memory is connected directly to the display circuitry so
    that the data in the video buffer can be repeatedly read out of the buffer
    and displayed. However, the video buffer is also logically (to the CPU) a
    part of the computer's main memory address space. A full 128 KB of the
    memory address space is set aside for use as video buffers, at addresses
    A000:0000H through B000:FFFFH, but the two original display adapters use
    only two small parts of this memory area. The Monochrome Display Adapter
    (MDA) provides 4 KB of display memory located at segment B000H. The
    original CGA provides 16 KB of display memory located at segment B800H.

    With the other IBM video subsystems, the address at which video memory is
    located isn't fixed──it depends on how the subsystem is configured. For
    example, when an EGA is used with a monochrome display, its text-mode
    video buffer is placed at B000H, just as with an MDA. When an EGA is
    attached to a color display, its video buffer can be addressed at B800H.
    And when you use an EGA in non-CGA graphics modes, the starting buffer
    address is A000H. Like the EGA, the MCGA and the VGA also support this
    chameleon-like method of buffer addressing.

Creating the Screen Image

    You can describe the screen display created by IBM video subsystems as a
    memory-mapped display, because each address in the display memory
    corresponds to a specific location on the screen. (See Figure 4-1.) The
    display circuitry repeatedly reads information from memory and places it
    on the screen. The information can be changed as quickly as the computer
    can write new information from your programs into memory. The display
    circuitry translates the stream of bits it receives from memory into
    bursts of light at particular locations on the screen.

                    ┌─────────────────────────────────────────┐
                    │ ┌─────────────────────────────────────┐ │
                    │ │ •• •••  • •••• •••• ••• Pixels or   │ │
                    │ │                         characters  │ │
                    │ │                         on screen   │ │
                    │ │                                     │ │
                    │ │                                     │ │
                    │ │                                     │ │
                    │ │                                     │ │
                    │ │                                     │ │
                    │ │                                     │ │
                    │ └─────────────────────────────────────┘ │
                    └─────────────────────────────────────────┘
                                        
                                        ║  ║
    ┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬
    │▓│▓│ │▓│▓│▓│ │ │▓│ │▓│▓│▓│▓│ │▓│▓│▓│▓│ │▓│▓│▓│ │ │ │ │ │ │ │ │ │ │ │ │ │ │
    └─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴
                            Successive locations in RAM

    Figure 4-1.  The memory-mapped display.

    These dots of light are called pixels and are produced by an electron beam
    striking the phosphorescent surface of the CRT. The electron beam is
    produced by an electron gun that scans the screen line by line. As the gun
    moves across and down the screen in a fixed path called a raster scan, the
    video subsystem generates video control signals that turn the beam on and
    off, matching the pattern of the bits in memory.

    The video circuitry refreshes the screen between 50 and 70 times a second
    (depending on the video mode), making the changing images appear clear and
    steady. At the end of each screen-refresh cycle, the electron beam must
    move from the bottom right corner to the top left corner of the screen to
    begin a new cycle. This movement is called the vertical retrace. During
    the retrace, the beam is blanked and no pixels are written to the screen.

    The vertical retrace period (about 1.25 milliseconds) is important to
    programmers for one main reason, which requires some explanation. The
    special dual-ported design of the video memory gives the CPU and the
    display-refresh circuitry equal access to the display memory. This allows
    the CPU and the display circuitry to access video memory at the same time.

    This causes a problem on the Color Graphics Adapter (CGA). If the CPU
    happens to read or write to the video buffer at the same time the display
    circuitry is copying data out of the buffer to display onscreen, a "snow"
    effect may briefly appear on the screen. However, if you instruct the CPU
    to access memory only during vertical retrace, when the display circuitry
    is not accessing the video buffer, then snow can be eliminated. A program
    running on a CGA can test the value of bit 3 in the adapter's I/O port at
    3DAH. This bit is set on at the beginning of vertical retrace and then set
    off at the end. During this 1.25-millisecond pause, you can have your
    programs write as much data as possible to the video display memory. At
    the end of the retrace, the display circuitry can write this data to the
    screen without snow.

    This technique is useful for any application that directly accesses data
    in the video buffer in text mode on a CGA. Fortunately, the hardware
    design of all other IBM video subsystems avoids this access conflict and
    makes this specialized programming technique unnecessary.


The Video Display Modes

    Originally, there were eight video modes defined for the IBM personal
    computers: seven on the CGA and one on the MDA. The more sophisticated
    EGA, MCGA, and VGA introduced several new modes plus variations on the
    original eight. As a result, among the five IBM video subsystems are 12
    text and graphics modes and, depending how you count them, seven or eight
    variations──and that's not counting the extra modes available with non-IBM
    video hardware and with defunct IBM systems like the PCjr. There's plenty
    of variety when you're working with IBM video subsystems.

    Despite the perplexing proliferation of video modes, what is striking
    about the different modes is not their differences but their similarities
    (Figure 4-2): All video modes are related in resolution and in video
    buffer organization to the original MDA and CGA modes.

    The MDA's 80-column, 25-row monochrome text mode is supported on the EGA
    and VGA. Similarly, the CGA's two text modes (40 x 25 and 80 x 25 16-color
    modes) are also supported on the EGA, MCGA, and VGA. Don't let the
    redundant mode numbers in Figure 4-2 confuse you: The difference between
    mode 0 and mode 1, for example, is that the composite color signal on the
    CGA is modified for composite monochrome monitors in mode 0. (See page
    74 for more on monitors.) With all other monitors and in all other video
    subsystems, modes 0 and 1 are the same, as are modes 2 and 3 and modes 4
    and 5.

╓┌─┌────────────┌─────────────┌────────────┌─────────────┌────────────┌──────►
    BIOS Mode Number
    Hex          Dec           Type         Resolution    Colors       Video Su
    ───────────────────────────────────────────────────────────────────────────
    00H,01H      0, 1          Text         40 x 25       16           CGA, EGA
    02H,03H      2, 3          Text         80 x 25       16           CGA, EGA
    04H,05H      4, 5          Graphics     320 x 200     4            CGA, EGA
    06H          6             Graphics     640 x 200     2            CGA, EGA
    07H          7             Text         80 x 25       Mono         MDA, EGA
    08H,09H,0AH  8, 9, 10                                              (PCjr on
    0BH,0CH      11, 12                                                (Used in
                                                                        BIOS)
    0DH          13            Graphics     320 x 200     16           EGA,VGA
    BIOS Mode Number
    Hex          Dec           Type         Resolution    Colors       Video Su
    ───────────────────────────────────────────────────────────────────────────
    0DH          13            Graphics     320 x 200     16           EGA,VGA
    0EH          14            Graphics     640 x 200     16           EGA,VGA
    0FH          15            Graphics     640 x 350     Mono         EGA,VGA
    10H          16            Graphics     640 x 350     16           EGA,VGA
    11H          17            Graphics     640 x 480     2            MCGA,VGA
    12H          18            Graphics     640 x 480     16           VGA
    13H          19            Graphics     320 x 200     256          MCGA,VGA
    ───────────────────────────────────────────────────────────────────────────


    Figure 4-2.  Video modes available on IBM video subsystems.

    The evolutionary pattern is the same for graphics modes. The CGA supports
    two graphics modes, a 320 x 200 pixel, 4-color mode and a 640 x 200,
    2-color mode. These same two modes are supported on the EGA, MCGA, and
    VGA. The EGA introduced three new graphics modes with more colors and
    better resolution than the original CGA graphics modes: the 320 x 200,
    16-color; 640 x 200, 16-color; and 640 x 350, 16-color modes. The EGA also
    introduced a 640 x 350 monochrome graphics mode that could be used only
    with an MDA-compatible monochrome display.

    When the PS/2s appeared, their video subsystems supported the same modes
    as did the MDA, CGA, and EGA──but again, a few new graphics modes were
    introduced. The MCGA in the PS/2 models 25 and 30 followed the CGA
    tradition: It supported all CGA modes, plus new 640 x 480, 2-color and 320
    x 200, 256-color graphics modes. The VGA in the other PS/2 models strongly
    resembles the EGA. It provides all the EGA's text and graphics modes, the
    two new MCGA graphics modes, and one more graphics mode not supported by
    the other subsystems──a 640 x 480, 16-color mode.

    How do you know which mode to use in a program? Clearly, if broad
    compatibility is a concern, the MDA and CGA modes are the least common
    denominator. If you need more colors or better graphics resolution than
    the CGA modes provide, you can turn to one of the EGA, MCGA, or VGA
    graphics modes. Of course, if your program requires an EGA or a VGA to
    run, users who have only a CGA will be out of luck.

    Many commercial software vendors solve this problem by distributing
    installable video output routines along with their products. Before you
    can use a package like Microsoft Windows or Lotus 1-2-3, for example, you
    must run a special installation program that binds output routines for
    your particular video hardware to the software application. This approach
    is more work for both the people who write software and the people who use
    it, but it is a good way to make applications deliver the best possible
    video performance without stumbling over the diversity of video hardware
    and video modes.

Video Mode Control

    Before we get into the details about resolution and color in video modes,
    let's consider how you select which video mode to use. The most efficient
    way to set up a video mode is to use assembly language to call the ROM
    BIOS. ROM BIOS interrupt 10H (decimal 16), service 00H, provides a way to
    select a video mode using the mode numbers listed in Figure 4-2. (See
    Chapter 9 for more details on this.)

    ──────────────────────────────────────────────────────────────────────────
    Monitors
    The type of video display, or monitor, that might be used has an
    important effect on program design. Many monitors cannot produce color
    or graphics, and a few produce such a poor quality image that you can
    use only the 40-column text display format. The many kinds of monitors
    that can be used with the PC family of computers can be broken down into
    five basic types.

    Direct-drive monochrome monitors. These monitors are designed to work
    with the Monochrome Display Adapter (MDA), although you can also use
    them with an Enhanced Graphics Adapter (EGA). The green IBM Monochrome
    Display is reminiscent of IBM's 3270 series of mainframe computer
    terminals; it's no surprise that many business users are comfortable
    with the combination of an MDA and a green monochrome display.

    Composite monochrome monitors. These monitors are still among the most
    widely used and least expensive monitors available. They connect to the
    composite video output on the Color Graphics Adapter (CGA) and provide a
    fairly clear one-color image (usually green or amber). Don't confuse the
    composite monochrome monitor with the direct-drive monochrome monitor.
    The composite monochrome monitor can be attached only to the CGA,
    whereas the direct-drive monochrome monitor must be used with an MDA or
    EGA.

    Composite color monitors and TV sets. Composite color monitors use a
    single combined signal such as the composite video output of the CGA.
    The composite color monitor produces color and graphics but has
    limitations: An 80-column display is often unreadable; only certain
    color combinations work well; and graphics resolution is low in quality,
    so graphics must be kept simple by using low-resolution graphics modes.

    Although the standard television set (color or black-and-white) is
    technically a composite monitor, it usually produces an even
    lower-quality image than the dedicated composite monitor. Text displays
    must be in 40-column mode to ensure that the display is readable. TVs
    are connected to the composite video output of the CGA, but the
    composite signal must be converted by an RF adapter before going into
    the TV.

    RGB color monitors. The RGB monitors are considered the best of both
    worlds. They combine the high-quality text display of the monochrome
    monitors with high-resolution graphics and color. RGB stands for
    red-green-blue, and RGB monitors are so named because they use separate
    red, green, and blue color signals, unlike the composite monitors, which
    use only one composite signal. The image and color quality of an RGB
    monitor is much better than that available through any screen that
    connects to the composite video output.

    Variable-frequency monitors. One of the problems created by the
    proliferation of different video subsystems is that some subsystems
    produce color and timing signals with different frequencies or different
    encodings than other subsystems. For example, you cannot use a
    PS/2-compatible monitor with a CGA because the color information in the
    monitor drive signals is encoded differently by a CGA than it is by a
    PS/2 video subsystem (MCGA or VGA).

    Monitor manufacturers addressed this problem by designing
    variable-frequency RGB monitors that can be used with a wide range of
    signal frequencies and with more than one type of color signal encoding.
    For example, NEC's MultiSync monitors can adjust to the different signal
    frequencies generated by the CGA, the EGA, and the PS/2 video
    subsystems. These monitors also have a switch that lets you adapt them
    either to the digital color signal encoding used by the CGA and EGA or
    to the analog color signals used by the PS/2 subsystems.

    Many people use variable-frequency monitors because they anticipate the
    need to upgrade their video subsystems at some time in the future, and
    they don't want to be stuck with an incompatible monitor.
    ──────────────────────────────────────────────────────────────────────────

    Many programming languages also offer high-level commands that select
    video modes for you. For example, BASIC gives you control over the video
    modes through the SCREEN statement but refers to them in its own way,
    using different mode numbers than the ROM BIOS routines. You can also
    control some of the video modes through the DOS MODE command. (See Figure
    4-3.)

    BIOS Mode Number         BASIC Statement to      DOS Statement to
    Hex          Dec         Change Mode             Change Mode
    ──────────────────────────────────────────────────────────────────────────
    00H          0           SCREEN 0,0: WIDTH 40    MODE BW40
    01H          1           SCREEN 0,1:WIDTH 40     MODE CO40
    02H          2           SCREEN 0,0:WIDTH 80     MODE BW80
    03H          3           SCREEN 0,1:WIDTH 80     MODE CO80
    04H          4           SCREEN 1,0              n/a
    05H          5           SCREEN 1,1              n/a
    06H          6           SCREEN 2                n/a
    07H          7           n/a                     MODE MONO
    ──────────────────────────────────────────────────────────────────────────

    Figure 4-3.  The BASIC and DOS commands used to change video modes.

Display Resolution

    Video images consist of a large number of closely spaced pixels. The
    display resolution is defined by the number of pixel rows, or scan lines,
    from top to bottom and the number of pixels from left to right in each
    scan line. The horizontal and vertical resolution is limited by the
    capabilities of the video monitor as well as the display circuitry inside
    the computer. The video modes available on the different subsystems were
    carefully designed so that the horizontal and vertical resolution in each
    mode is within the limits imposed by the hardware.

    The MDA's single text mode has 720 x 350 pixel resolution; that is, the
    screen has 350 scan lines, each of which contains 720 pixels. Because 25
    rows of 80 characters of text are displayed in this mode, each character
    is 9 pixels wide (720 ÷ 80) and 14 pixels high (350 ÷ 25). The CGA's text
    modes are a bit lower resolution, because the CGA's pixel resolution is
    only 640 x 200. Thus the 25 rows of 80-character text on a CGA consist of
    characters that are only 8 pixels wide (640 ÷ 80) and 8 pixels high (200 ÷
    25). That's why text looks sharper on an MDA screen than on a CGA.

    The trend in the newer IBM video subsystems is to provide better vertical
    resolution. For example, the EGA's 80 x 25 text mode has 640 x 350 pixel
    resolution, so text characters are 8 x 14 pixels. On the MCGA, the default
    80 x 25 text mode has 640 x 400 resolution (8 x 16 characters), and on the
    VGA the same text mode has 720 x 400 resolution, so characters are each 9
    pixels wide and 16 pixels high. From a program's point of view, the 80 x
    25 text mode is the same on the CGA, the MCGA, and the VGA──it's display
    mode 3 in all cases──but a user sees much higher resolution when using a
    VGA or MCGA than when using one of the older subsystems.

    You see the same trend towards better resolution when you examine the
    graphics modes available with the newer video subsystems. The VGA's 640 x
    480, 16-color mode has more than twice as many pixels on the screen as the
    original CGA's 640 x 200 graphics mode. It's ironic that this CGA mode was
    known as a "high-resolution" mode when the CGA was new.


The Use of Color

    A variety of colors is available in every video mode except of course on a
    monochrome display. You may have noticed that among the various modes
    there are substantial differences in the number of colors available. In
    this section, we will describe the color options for the video modes.

    Colors for the video display screens are produced by combinations of four
    elements: three color components──red, green, and blue──plus an intensity,
    or brightness, component. Text and graphics modes use the same colors and
    intensity options, but they combine them in different ways to produce
    their colored displays. The text modes, whose basic unit is a character
    composed of several pixels, use an entire byte to set the color, the
    intensity, and the blinking characteristics of the character and its
    background. In graphics modes, each pixel is represented by a group of 1
    through 8 bits whose value determines the color and brightness of the
    displayed pixel.

    In 16-color text and graphics modes, the four basic color and brightness
    components can be combined in 16 ways. Colors are specified by a group of
    4 bits. Each bit designates whether a particular color component is on or
    off. The result is 16 color combinations that correspond to the 16 4-bit
    binary numbers. (See Figure 4-4.)

    In some video modes, the data in the video buffer consists of 4-bit
    attribute values that correspond exactly to the 16 possible color
    combinations on the screen. In other video modes, the attribute values do
    not directly specify colors. For example, on the EGA, each attribute value
    designates one of 16 palette registers, each of which contains a color
    value. (See Figure 4-5.) It is the palette color values that determine
    the color combinations displayed on the screen.

    Intensity Red       Green    Blue      Binary    Hex       Description
    ───────────────────────────────────────────────────────────────────────────
    0         0         0        0         0000B     00H       Black
    0         0         0        1         0001B     01H       Blue
    0         0         1        0         0010B     02H       Green
    0         0         1        1         0011B     03H       Cyan (blue-green
    0         1         0        0         0100B     04H       Red
    0         1         0        1         0101B     05H       Magenta
    0         1         1        0         0110B     06H       Brown (or dark
                                                                yellow)
    0         1         1        1         0111B     07H       Light gray (or
                                                                ordinary white)
    1         0         0        0         1000B     08H       Dark gray (black
                                                                many screens)
    1         0         0        1         1001B     09H       Light blue
    1         0         1        0         1010B     0AH       Light green
    1         0         1        1         1011B     0BH       Light cyan
    1         1         0        0         1100B     0CH       Light red
    1         1         0        1         1101B     0DH       Light magenta
    1         1         1        0         1110B     0EH       Yellow (or light
                                                                yellow)
    1         1         1        1         1111B     0FH       Bright white
    ───────────────────────────────────────────────────────────────────────────

    Figure 4-4.  Default colors available in 16-color text and graphics modes.

    ┌──────────────────────────────────── ┌─────────────┐
    │ 0110 1010 1010 0111 0101 0101 1101  │▒▒▒▒▒▒▒▒▒▒▒▒▒│
    │                └─┬┘                 ├─────────────┤
    │                  │                  │▒▒▒▒▒▒▒▒▒▒▒▒▒│
    │                  │                  ├─────────────┤
    │                  │                  │▒▒▒▒▒▒▒▒▒▒▒▒▒│
    │                  │                  ├─────────────┤
    │                  │                  │▒▒▒▒▒▒▒▒▒▒▒▒▒│
    │                  │                  ├─────────────┤    ┌──────────
    │                  └─────────────────►│ Color value ├───►│ ┌────────
    │                                     ├─────────────┤    │ │ ▒
    │                                     │▒▒▒▒▒▒▒▒▒▒▒▒▒│    │ │
    │                                     ├─────────────┤    │ │
    │                                     │▒▒▒▒▒▒▒▒▒▒▒▒▒│    │ │
                                        ├─────────────┤
                                        │▒▒▒▒▒▒▒▒▒▒▒▒▒│
                Attribute value in         └─────────────┘     Color on
                video buffer           Pallette registers    screen

    Figure 4-5.  How EGA colors are specified using palette registers. Each
    attribute value in the video buffer designates a palette register whose
    contents specify a color.

    The use of palettes makes it possible to specify one of a broad range of
    colors using relatively few bits of data in the video buffer. Each of the
    EGA's 16 palette registers, for example, can contain one of 64 different
    6-bit color values. In this way, any 2 of 64 different colors can be used
    in a 2-color EGA video mode, any 4 out of 64 can be used in a 4-color
    mode, and any 16 of 64 can be used in a 16-color mode.

    All IBM video subsystems except the MDA can use palettes to display
    colors. The CGA has three built-in, 4-color palettes for use in 320 x 200,
    4-color mode. The EGA, as we have seen, has a 16-color palette in which
    each color can be selected from a set of 64 colors. The MCGA and the VGA,
    which can display an even wider range of colors, use a separate
    palette-like component, the video digital to analog converter (video DAC),
    to send color signals to the screen.

    The video DAC contains 256 color registers, each of which contains 6-bit
    color values for red, green, and blue. Since there are 64 possible values
    for each of the RGB components, each video DAC color register can contain
    one of 64 x 64 x 64, or 262,144 different color values. That wide range of
    colors can help you display very subtle color shades and contours.

    With the MCGA, the video DAC color registers serve much the same purpose
    as the palette registers do with the EGA. Attribute values in the video
    buffer designate video DAC color registers whose contents specify the
    colors that appear on the screen. Unfortunately, only one MCGA video mode
    can take full advantage of the video DAC's capabilities: 320 x 200,
    256-color mode. Only this video mode uses 8-bit attribute values that can
    specify all 256 of the video DAC's color registers. All remaining video
    modes use attribute values that have no more than 4 bits, so only the
    first 16 video DAC color registers are used.

    The VGA gets around this limitation (and complicates matters somewhat) by
    using a set of 16 palette registers like the EGA's, as well as a set of
    256 video DAC color registers like the MCGA's. An attribute value in the
    video buffer selects one of the 16 palette registers, whose contents
    select one of the 256 video DAC color registers──whose contents "in turn"
    determine the color displayed on the screen. (See Figure 4-6.)

    Specifying colors on an EGA, MCGA, or VGA is clearly more complicated than
    it is on the CGA. To simplify this process, however, the ROM BIOS loads
    the palette registers (on the EGA and VGA) and the video DAC color
    registers (on the MCGA and VGA) with color values that exactly match those
    available on the CGA. If you use CGA-compatible text and graphics modes on
    the newer subsystems and ignore the palette and video DAC registers,
    you'll see the same colors you would on a CGA.

    ┌──────────────────────────────────────
    │ 0110 1010 1010 0111 0101 0101 1101
    │                └─┬┘                            •
    │                  │   ┌─────────────┐    │      •      │
    │                  │   │▒▒▒▒▒▒▒▒▒▒▒▒▒│    │      •      │
    │                  │   ├─────────────┤    ├─────────────┤
    │                  │   │▒▒▒▒▒▒▒▒▒▒▒▒▒│    │▒▒▒▒▒▒▒▒▒▒▒▒▒│
    │                  │   ├─────────────┤    ├─────────────┤
    │ Attribute value  │   │▒▒▒▒▒▒▒▒▒▒▒▒▒│    │▒▒▒▒▒▒▒▒▒▒▒▒▒│
    │ in video buffer  │   ├─────────────┤    ├─────────────┤
    │                  └──►│    Color    ├─┐  │▒▒▒▒▒▒▒▒▒▒▒▒▒│
    │                      │   register  │ │  ├─────────────┤   ┌─────────
    │                      ├─────────────┤ │  │  RGB color  ├──►│ ┌───────
    │                      │▒▒▒▒▒▒▒▒▒▒▒▒▒│ └─►│    value    │   │ │ ▒
    │                      ├─────────────┤    ├─────────────┤   │ │
                            │▒▒▒▒▒▒▒▒▒▒▒▒▒│    │▒▒▒▒▒▒▒▒▒▒▒▒▒│   │ │
                            ├─────────────┤    ├─────────────┤   │ │
                            │▒▒▒▒▒▒▒▒▒▒▒▒▒│    │▒▒▒▒▒▒▒▒▒▒▒▒▒│   │ │
                            └─────────────┘    ├─────────────┤
                            Palette registers  │▒▒▒▒▒▒▒▒▒▒▒▒▒│    Color on
                                            ├─────────────┤     screen
                                            │      •      │
                                            │      •      │
                                                    •
                                        Video DAC color registers

    Figure 4-6.  How VGA colors are specified using palette registers and the
    video DAC.

    For this reason it's usually best to ignore the palette and video DAC
    registers when you start developing an application. Once your application
    works properly with the CGA-compatible colors, you can add program code
    that changes the palette and/or the video DAC colors. The ROM BIOS
    provides a complete set of services that let you access the palette and
    video DAC registers. Chapter 9 covers these services in detail.

    In considering color, read each of the remaining sections, which discuss
    important color-related items.

Color-Suppressed Modes

    In an effort to make the graphics modes compatible with a wide range of
    monitors, both color and monochrome, IBM included a few modes on the Color
    Graphics Adapter that do not produce color: color-suppressed modes. There
    are three color-suppressed modes: modes 0, 2, and 5. In these modes,
    colors are converted into shades of gray, or whatever color the screen
    phosphor produces. There are four gray shades in mode 5, and a variety of
    shades in modes 0 and 2. CGA's color is suppressed in the composite output
    but not in its RGB output. This inconsistency is the result of an
    unavoidable technical limitation.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    For each color-suppressed mode, there is a corresponding color mode, so
    modes 0 and 1 correspond to 40-column text, modes 2 and 3 to 80-column
    text, and modes 4 and 5 to medium-resolution graphics. The fact that
    modes 4 and 5 reverse the pattern of modes 0 and 1 and modes 2 and 3,
    where the color-suppressed mode comes first, has led to a complication
    in BASIC. The burst parameter of the BASIC SCREEN statement controls
    color. The meaning of this parameter is reversed for modes 4 and 5 so
    that the statement SCREEN,1 activates color in the text modes (0, 1, 2,
    and 3) but suppresses color in the graphics modes (4 and 5). This
    inconsistency may have been a programming error at first, but it is now
    part of the official definition of the SCREEN statement.
    ──────────────────────────────────────────────────────────────────────────

Color in Text and Graphics Modes

    Text and graphics modes use the same color-decoding circuitry, but differ
    in the way they store the color attribute data in the video buffer. In
    text modes, no matter what video subsystem you use, the foreground and
    background colors of each character are specified by two 4-bit fields in a
    single attribute byte. (See Figure 4-7.) Together, the foreground and
    background attributes describe all of a character's pixels: All foreground
    pixels are displayed with the character's foreground attribute, and all
    background pixels assume the background attribute.

        Bit
    7 6 5 4 3 2 1 0          Use
    ──────────────────────────────────────────────────────────────────────────
    1 . . . . . . .          Blinking of foreground character or intensity
                            component of background color
    . 1 . . . . . .          Red component of background color
    . . 1 . . . . .          Green component of background color
    . . . 1 . . . .          Blue component of background color
    . . . . 1 . . .          Intensity component of foreground color
    . . . . . 1 . .          Red component of foreground color
    . . . . . . 1 .          Green component of foreground color
    . . . . . . . 1          Blue component of foreground color
    ──────────────────────────────────────────────────────────────────────────

    Figure 4-7.  The coding of the color attribute byte.

    In graphics modes, each pixel's attribute is determined by the contents of
    a bit field in the video buffer. The size and format of a pixel's bit
    field depend on the video mode: The smallest bit fields are only 1 bit
    wide (as in 640 x 200, 2-color mode), and the largest bit fields are 8
    bits wide (as in 320 x 200, 256-color mode).

    The reason for having both text and graphics modes becomes clear if you
    think about how much data it takes to describe the pixels on the screen.
    In graphics modes, you need between 1 and 8 bits of data in the video
    buffer for every pixel you display. In 640 x 350, 16-color mode, for
    instance, with 4 bits per pixel, you need 640 x 350 x 4 ÷ 8 (112,000)
    bytes to represent one screenful of video data. But if you display 25 rows
    of 80 characters in a text mode with the same resolution, you need only 80
    x 25 x 2, or 4000, bytes.

    The tradeoff is clear: Text modes consume less memory and require less
    data manipulation than do graphics modes──but you can manipulate each
    pixel independently in graphics modes, as opposed to manipulating entire
    characters in text modes.

    Setting color in text modes

    Let's take a closer look at how you control colors in text modes. (We'll
    get back to graphics modes later in this chapter.) In text modes, each
    character position on the display screen is controlled by a pair of
    adjacent bytes in the video buffer. The first byte contains the ASCII code
    for the character that will be displayed. (See Appendix C for a chart of
    characters.) The second byte is the character's attribute byte. It
    controls how the character will appear, that is, its colors, brightness
    (intensity), and blinking.

    We've already mentioned two attributes that affect a character's
    appearance: color and intensity (brightness). You can assign several other
    attributes to text characters, depending on which video subsystem you're
    using. With all IBM video subsystems, text characters can blink. On
    monochrome-capable subsystems (the MDA, EGA, and VGA), characters can also
    be underlined. Also, on some non-IBM subsystems like the Hercules Graphics
    Card Plus, characters can have attributes such as overstrike and boldface.

    In all cases, you assign these alternate attributes by using the same
    4-bit attributes that specify color. A case in point is the blinking
    attribute. Character blinking is controlled by setting a bit in a special
    register in the video subsystem. (On the CGA, for example, this
    enable-blink bit is bit 5 of the 8-bit register mapped at input/output
    port 3D8H.) When this bit is set to 1, the high-order bit of each
    character's attribute byte is not interpreted as part of the character's
    background color specification. Instead, this bit indicates whether the
    character should blink.

    If you have a CGA, watch what happens when you run the following BASIC
    program:

    10 DEF SEG = &HB800             ' point to start of video buffer
    20 POKE 0,ASC("A")              ' store the ASCII code for A in the buffer
    30 POKE 1,&H97                  ' foreground attribute = 7 (white)
                                    ' background attribute = 9 (intense blue)

    You'll see a blinking white letter A on a blue background. If you add the
    following statement to the program, you'll clear the enable-blink bit and
    cause the CGA to interpret the background attribute as intense blue:

    40 OUT &H3D8,&H09               ' clear the "enable-blink" bit

    The default attribute used by DOS and BASIC is 07H, normal white (7) on
    black (0), without blinking, but you can use any combination of 4-bit
    foreground and background attributes for each character displayed in a
    text mode. If you exchange a character's foreground and background
    attributes, the character is displayed in "reverse video." If the
    foreground and background attributes are the same, the character is
    "invisible."

    Setting attributes in the monochrome mode

    The monochrome mode (mode 7) used by the Monochrome Display Adapter has a
    limited selection of attributes that take the place of color. Like the
    CGA, the MDA uses 4-bit foreground and background attributes, but their
    values are interpreted differently by the MDA attribute decoding
    circuitry.

    Only certain combinations of foreground and background attributes are
    recognized by the MDA. (See Figure 4-8.) Other useful combinations, like
    "invisible" (white-on-white) or a reverse-video/underlined combination,
    aren't supported by the hardware.

    Like the CGA, the MDA has an enable-blink bit that determines whether the
    high-order bit of each character's attribute byte controls blinking or the
    intensity of the background attribute. On the MDA, the enable-blink bit is
    bit 5 of the register at port 3B8H. As on the CGA, the enable-blink bit is
    set by the ROM BIOS when it establishes monochrome text mode 7, so you
    must explicitly clear this bit if you want to disable blinking and display
    characters with intensified background.

    With the EGA, MCGA, and VGA, text-mode attributes work the same as with
    the MDA and CGA. Although the enable-blink bit is not in the same hardware
    register in the newer subsystems, the ROM BIOS offers a service through
    interrupt 10H that toggles the bit on an EGA, MCGA, or VGA. (See Chapter
    9, page 178 for more information about this service.)

╓┌─┌──────────┌──────────────────────────────────────────────────────────────╖
    Attribute  Description
    ──────────────────────────────────────────────────────────────────────────
    00H        Nondisplayed

    01H        Underlined

    07H        Normal (white on black)

    09H        High-intensity underlined

    0FH        High-intensity

    70H        White background, black foreground ("reverse video")

    87H☼       Blinking white on black (if blinking enabled)
                Dim background, normal foreground (if blinking
                disabled)
    Attribute  Description
    ──────────────────────────────────────────────────────────────────────────
                disabled)

    8FH☼       Blinking high-intensity (if blinking enabled)
                Dim background, high-intensity foreground (if blinking
                disabled)

    F0H        Blinking "reverse video" (if blinking enabled)
                High-intensity background, black foreground (if blinking
                disabled)
    ──────────────────────────────────────────────────────────────────────────


    Figure 4-8.  Monochrome text-mode attributes. The appearance of some
    attributes depends on the setting of the enable-blink bit at I/O port
    3B8H.

    Setting color in graphics modes

    So far, we've seen how to set color (and the monochrome equivalent of
    color) in text modes. Setting color in graphics modes is quite different.
    In graphics modes, each pixel is associated with a color. The color is set
    the same way attributes are set in text mode, but there are important
    differences. First, since each pixel is a discrete dot of color, there is
    no foreground and background──each pixel is simply one color or another.
    Second, pixel attributes are not always 4 bits in size──we've already
    mentioned that pixel attributes can range from 1 to 8 bits, depending on
    the video mode being used. These differences give graphics-mode programs a
    subtly different "feel" than they have in text modes, both to programmers
    and to users.

    The most important difference between text-mode and graphics-mode
    attributes, however, is this: In graphics modes you can control the color
    of each pixel. This lets you use colors much more effectively than you can
    in text modes. This isn't so obvious with the CGA and its limited color
    capabilities, but with an MCGA or VGA it's quite apparent.

    Let's start with the CGA. The CGA's two graphics modes are relatively
    limited in terms of color: In 320 x 200, 4-color mode, pixel attributes
    are only 2 bits wide, and you can display only four different colors at a
    time. In 640 x 200, 2-color mode, you have only 1 bit per pixel, so you
    can display only two different colors. Also, the range of colors you can
    display in CGA graphics modes is severely limited.

    In 320 x 200, 4-color mode, pixels can have value 0, 1, 2, or 3,
    corresponding to the 2-bit binary values 00B, 01B, 10B, and 11B. You can
    assign any one of the CGA's 16 color combinations to zero-value pixels,
    but colors for nonzero pixels are derived from one of three built-in
    palettes. (See Figure 4-9.) In 640 x 200, 2-color mode, nonzero pixels
    can be assigned any one of the 16 color combinations, but zero-value
    pixels are always black. In both modes, you can assign palette colors
    using ROM BIOS interrupt 10H services described in Chapter 9.

    The EGA, MCGA, and VGA are considerably more flexible in terms of color
    management, because you can assign any color combination to any palette or
    video DAC color register. Equally important is the fact that you have
    larger pixel values and therefore more colors to work with on the screen.
    The most frequently used graphics modes on the EGA and VGA are the
    16-color modes with pixels that require 4 bits to define the colors. In
    most applications, 16 colors are adequate, because you can select those 16
    colors from the entire range of color combinations the hardware can
    display (64 colors on the EGA and 262,144 colors on the MCGA and VGA).
    Again, the ROM BIOS provides services that let you assign arbitrary color
    combinations to the palette and video DAC color registers on the EGA,
    MCGA, and VGA. See Chapter 9 for details.

    Pixel Bits               Pixel Value             Pixel Color
    ──────────────────────────────────────────────────────────────────────────
    Mode 4, palette 0:
    0 1                      1                       Green
    1 0                      2                       Red
    1 1                      3                       Yellow or brown

    Mode 4, palette 1:
    0 1                      1                       Cyan
    1 0                      2                       Magenta
    1 1                      3                       White

    Mode 5:
    0 1                      1                       Cyan
    1 0                      2                       Red
    1 1                      3                       White
    ──────────────────────────────────────────────────────────────────────────

    Figure 4-9.  Palettes in CGA 320 x 200, 4-color graphics mode.


Inside the Display Memory

    Now we come to the inner workings of the video buffer map. In this
    section, we'll see how the information in the video memory is related to
    the display screen.

    Although the video buffer memory map varies according to the video mode
    you use, a clear family resemblance exists among the video modes. In text
    modes, the video buffer map in all IBM video subsystems is the same. In
    graphics modes, there are two general layouts, a linear map based on the
    map used with the original CGA graphics modes and a parallel map that was
    first used in EGA graphics modes.

    Video Mode     Starting       Memory Used   Subsystem
                    Paragraph      (bytes)
                    Address (hex)
    ──────────────────────────────────────────────────────────────────────────
    00H, 01H       B800H             2000       CGA, EGA, MCGA, VGA
    02H, 03H       B800H             4000       CGA, EGA, MCGA, VGA
    04H, 05H       B800H           16,000       CGA, EGA, MCGA, VGA
    06H            B800H           16,000       CGA, EGA, MCGA, VGA
    07H            B000H             4000       MDA, EGA, VGA
    0DH            A000H           32,000       EGA, VGA
    0EH            A000H           64,000       EGA, VGA
    0FH            A000H           56,000       EGA, VGA
    10H            A000H          112,000       EGA, VGA
    11H            A000H           38,400       MCGA, VGA
    12H            A000H          153,600       VGA
    13H            A000H           64,000       MCGA, VGA
    ──────────────────────────────────────────────────────────────────────────

    Figure 4-10.  Video buffer addresses in IBM video modes.

    Before we examine the actual map of the video buffer, let's look at the
    addresses where the video buffer is located. (See Figure 4-10.) The
    breakdown is straightforward: Color text modes start at paragraph address
    B800H, and monochrome text mode starts at B000H. CGA-compatible graphics
    modes start at B800H. All other graphics modes start at A000H. The amount
    of RAM required to hold a screenful of data varies according to the number
    of characters or pixels displayed, and, in the case of graphics modes,
    with the number of bits that represent a pixel.

Display Pages in Text Modes

    The amount of RAM physically installed in the various video subsystems is
    frequently more than enough to contain more than one screen's worth of
    video data. In video modes where this is true, all IBM video subsystems
    support multiple display pages. When you use display pages, the video
    buffer is mapped into two or more areas, and the video hardware is set up
    to selectively display any one of these areas in the map.

    Because only one page is displayed at any given time, you can write
    information into nondisplayed pages as well as directly to the displayed
    page. Using this technique you can build a screen on an invisible page
    while another page is being displayed and then switch to the new page when
    the appropriate time comes. Switching screen images this way makes screen
    updates seem instantaneous.

    The display pages are numbered 0 through 7, with page 0 starting at the
    beginning of the video buffer. Of course, the amount of available RAM may
    be insufficient to support eight full display pages; the actual number of
    pages you can use (see Figure 4-11) depends on how much video RAM is
    available and on how much memory is required for one screenful of data.
    Each page begins on an even kilobyte memory boundary. The display page
    offset addresses are shown in Figure 4-12.

    To select a display page, use ROM BIOS interrupt 10H, service 05H. To
    determine which page is actively displayed, use interrupt 10H, service
    0FH. (See Chapter 9 for information about these ROM BIOS services.)

    In any of these modes, if the pages are not actively used (actually
    displayed on the screen), then the unused part of the display memory can
    conceivably be used for data besides text or pixels, although this usage
    is neither normal nor advisable. Making any other use of this potentially
    free memory is asking for trouble in the future.

                                        Number of
    Video Mode  Subsystem                Pages       Notes
    ──────────────────────────────────────────────────────────────────────────
    00H, 01H    CGA, EGA, MCGA, VGA      8
    02H, 03H    CGA                      4
                EGA, MCGA, VGA           8
    04H, 05H    CGA, MCGA                1
                EGA, VGA                 2           Not fully supported by
                                                    ROM BIOS
    06H         CGA, EGA, MCGA, VGA      1
    07H         MDA                      1
                EGA, VGA                 8
    0DH         EGA, VGA                 8
    0EH         EGA, VGA                 4
    0FH         EGA, VGA                 2
    10H         EGA, VGA                 2
    11H         MCGA, VGA                1
    12H         VGA                      1
    13H         MCGA, VGA                1
    ──────────────────────────────────────────────────────────────────────────

    Figure 4-11.  Display pages available in IBM video subsystems.

    Page   40 x 25, 16-color      80 x 25, 16-color     80 x 25 Mono
    ──────────────────────────────────────────────────────────────────────────
    0      B800:0000H             B800:0000H            B000:0000H
    1      B800:0800H             B800:1000H            B000:1000H☼
    2      B800:1000H             B800:2000H            B000:2000H☼
    3      B800:1800H             B800:3000H            B000:3000H☼
    4      B800:2000H             B800:4000H☼           B000:4000H☼
    5      B800:2800H             B800:5000H☼           B000:5000H☼
    6      B800:3000H             B800:6000H☼           B000:6000H☼
    7      B800:3800H             B800:7000H☼           B000:7000H☼
    ──────────────────────────────────────────────────────────────────────────

    Figure 4-12.  Start addresses for text-mode display pages in IBM video
    subsystems.

Display Pages in Graphics Modes

    For the EGA, the MCGA, and the VGA, the page concept is as readily
    available in graphics modes as in text modes. Obviously there is no reason
    not to have graphics pages if the memory is there to support them.

    The main benefit of using multiple pages for either graphics or text is to
    be able to switch instantly from one display screen to another without
    taking the time to build the display information from scratch. In theory,
    multiple pages could be used in graphics mode to produce smooth and
    fine-grained animation effects, but there aren't enough display pages to
    take the animation very far.

Displaying Characters in Text and Graphics Modes

    As you have learned, in text modes no character images are stored in video
    memory. Instead, each character is represented in the video buffer by a
    pair of bytes containing the character's ASCII value and display
    attributes. The pixels that make up the character are drawn on the screen
    by a character generator that is part of the display circuitry. The Color
    Graphics Adapter has a character generator that produces characters in an
    8 x 8 pixel block format, while the Monochrome Display Adapter's character
    generator uses a 9 x 14 pixel block format. The larger format is one of
    the factors that makes the MDA's display output easier to read.

    The standard ASCII characters (01H through 7FH [decimal 1 through 127])
    represent only half of the ASCII characters available in the text modes.
    An additional 128 graphics characters (80H through FFH [decimal 128
    through 255]) are available through the same character generator. More
    than half of them can be used to make simple line drawings. A complete
    list of both the standard ASCII characters and the graphics characters
    provided by IBM is given in Appendix C.

    The graphics modes can also display characters, but they are produced
    quite differently. Graphics-mode characters are drawn, pixel by pixel, by
    a ROM BIOS software character generator, instead of by a hardware
    character generator. (ROM BIOS interrupt 10H provides this service; see
    Chapter 9.) The software character generator refers to a table of bit
    patterns to determine which pixels to draw for each character. The ROM of
    every PC and PS/2 contains a default table of character bit patterns, but
    you can also place a custom bit pattern table in RAM and instruct the BIOS
    to use it to display your own character set.

    In CGA-compatible graphics modes (640 x 200, 2-color and 320 x 200,
    4-color), the bit patterns for the second 128 ASCII characters are always
    found at the address stored in the interrupt 1FH vector at 0000:007CH. If
    you store a table of bit patterns in a buffer and then store the buffer's
    segment and offset at 0000:007CH, the ROM BIOS will use the bit patterns
    in the buffer for ASCII characters 80H through FFH (decimal 128 through
    255. In other graphics modes on the EGA, MCGA, and VGA, the ROM BIOS
    provides a service through interrupt 10H that lets you pass the address of
    a RAM-based table of character bit patterns for all 256 characters.

    Mapping characters in text modes

    In text modes, the memory map begins with the top left corner of the
    screen, using 2 bytes per screen position. The memory bytes for succeeding
    characters immediately follow in the order you would read them──from left
    to right and from top to bottom.

    Modes 0 and 1 are text modes with a screen format of 40 columns by 25
    rows. Each row occupies 40 x 2 = 80 bytes. A screen occupies only 2 KB in
    modes 0 and 1, which means the CGA's 16 KB memory can accommodate eight
    display pages. If the rows are numbered 0 through 24 and the columns
    numbered 0 through 39, then the offset to any screen character in the
    first display page is given by the following BASIC formula:

    CHARACTER.OFFSET = (ROW.NUMBER * 80) + (COLUMN.NUMBER * 2)

    Since the attribute byte for any character is in the memory location next
    to the ASCII character value, you can locate it by simply adding 1 to the
    character offset.

    Modes 2, 3, and 7 are also text modes, but with 80 columns in each row
    instead of 40. The byte layout is the same, but each row requires twice as
    many bytes, or 80 x 2 = 160 bytes. Consequently, the 80 x 25 screen format
    uses 4 KB, and the 16 KB memory can accommodate four display pages. The
    offset to any screen location in the first display page is given by the
    following BASIC formula:

    CHARACTER.OFFSET = (ROW.NUMBER * 160) + (COLUMN.NUMBER * 2)

    The beginning of each text display page traditionally starts at an even
    kilobyte boundary. Because each screen page in the text modes actually
    uses only 2000 or 4000 bytes, some unused bytes follow each page: either
    48 or 96 bytes, depending on the size of the page. So, to locate any
    screen position on any page in text mode, use the general formula shown on
    the next page.

    LOCATION = (SEGMENT.PARAGRAPH * 16)
                + (PAGE.NUMBER * PAGE.SIZE) + (ROW.NUMBER * ROW.WIDTH * 2)
                + (COLUMN.NUMBER * 2) + WHICH
    LOCATION  is the 20-bit address of the screen information.
    SEGMENT.PARAGRAPH  is the location of the video display memory
    (for example, B000H or B800H).
    PAGE.NUMBER  is in the range 0 through 3 or 0 through 7.
    PAGE.SIZE  is 2000 or 4000.
    ROW.NUMBER  is from 0 through 24.
    ROW.WIDTH  is 40 or 80.
    COLUMN.NUMBER  is from 0 through 39 or 0 through 79.
    WHICH  is 0 for the display character or 1 for the display attribute.

    Mapping pixels in graphics modes

    When you use a graphics mode, pixels are stored as a series of bit fields,
    with a one-to-one correlation between the bit fields in memory and the
    pixels on the screen. The actual mapping of bit fields in the video buffer
    depends on the video mode.

    In CGA-compatible graphics modes, the display is organized into 200 lines,
    numbered 0 through 199. Each line of pixels is represented in the video
    buffer in 80 bytes of data. In 640 x 200, 2-color mode, each bit
    represents one pixel on the screen, while in 320 x 200, 4-color mode, each
    pixel is represented by a pair of bits in the buffer. (See Figure 4-13.)
    Thus there are eight pixels to each byte in 640 x 200, 2-color mode, and
    80 x 8, or 640, pixels per row. Similarly, there are four pixels to each
    byte in 320 x 200, 4-color mode, and 80 x 4, or 320, pixels per row.

    The storage for the pixel rows is interleaved:

    ■  Pixels in even-numbered rows are stored in the first half of the video
        buffer, starting at B800:0000H.

    ■  Pixels in odd-numbered rows are stored starting at B800:2000H.

    For example, in 640 x 200, 2-color mode, the first pixel in the first row
    (in the upper-left corner of the screen) is represented by the leftmost
    bit (bit 7) in the byte at B800:0000H. The second pixel in the row is
    represented by bit 6 of the same byte. Because of the interleaved buffer
    map, however, the pixel immediately below the first pixel is represented
    in bit 7 of the byte at B800:2000H.

    640 x 200, 2-color mode            320 x 200, 4-color mode

            bit                                bit
        7 6 5 4 3 2 1 0                    7 6 5 4 3 2 1 0
    ┌───────────────────┐              ┌───────────────────┐
    │  1 0 0 0 1 1 1 1  │              │  1 1 0 0 0 1 0 1  │
    └──┼─┼─┼─┼─┼─┼─┼─┼──┘              └──┬─┬─┬─┬─┬─┬─┬─┬──┘
        │ │ │ │ │ │ │ │                    └┬┘ └┬┘ └┬┘ └┬┘
    ┌───│─│─│─│─│─│─│─│───────         ┌────│───│───│───│────────
    │┌──│─│─│─│─│─│─│─│───────         │┌───│───│───│───│────────
    ││  ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼                ││   ▼   ▼   ▼   ▼
    ││  ▓ • • • ▓ ▓ ▓ ▓                ││   ▒   •   ▓   ▓
    ││                                 ││
    ││                                 ││
    ││                                 ││

    Figure 4-13.  Pixel mapping in CGA-compatible graphics modes.

    In all other graphics modes, the buffer map is linear, as it is in text
    modes. Pixels are stored from left to right in each byte, and one row of
    pixels immediately follows another in the video buffer. On the MCGA and
    VGA, for example, the 1-bit pixels in 640 x 480, 2-color mode and the
    8-bit pixels in 320 x 200, 256-color mode are stored starting at
    A000:0000H and proceeding linearly through the buffer.

    The catch is that pixel bit fields are not always mapped linearly in all
    video modes. On the EGA and VGA, the video buffer in 16-color graphics
    modes is arranged as a set of four parallel memory maps. In effect, the
    video memory is configured to have four 64 KB memory maps spanning the
    same range of addresses starting at A000:0000H. The EGA and VGA have
    special circuitry that accesses all four memory maps in parallel. Thus in
    16-color EGA and VGA graphics modes, each 4-bit pixel is stored with 1 bit
    in each memory map. (See Figure 4-14.) Another way to visualize this is
    that a 4-bit pixel value is formed by concatenating corresponding bits
    from the same address in each memory map.

    There is a good reason why the EGA and VGA were designed to use parallel
    memory maps in graphics modes. Consider the situation in 640 x 350,
    16-color mode: With 4 bits per pixel, you need 640 x 350 x 4 (896,000)
    bits to store one screenful of pixels. That comes out to 112,000 bytes,
    which is bigger than the 64 KB maximum size of one 8086 segment. If you
    organize the pixel data in parallel, however, you only need 112,000 ÷ 4
    (28,000) bytes in each memory map.

    With this variety of memory maps and pixel sizes, it's fortunate that the
    ROM BIOS provides services that let you read and write individual pixels
    regardless of the video mode. (Chapter 9 describes these services.)
    Unfortunately, these ROM BIOS pixel-manipulation services are pretty slow.
    If you're working in graphics modes, you'll probably find that the
    graphics drawing functions provided in your programming language (such as
    the PSET, LINE, and CIRCLE functions in BASIC) are the best tools for
    creating graphics-mode screens.

                ┌───────────────────┐
    Parallel    │  1 0 1 1 0 1 0 1  │ Map 3
    memory      └──┬─┬─┬─┬─┬─┬─┬─┬──┘
    maps        ┌──┴─┴─┴─┴─┴─┴─┴─┴──┐
                │  1 0 0 0 0 0 0 0  │ Map 2
                └──┬─┬─┬─┬─┬─┬─┬─┬──┘
                ┌──┴─┴─┴─┴─┴─┴─┴─┴──┐
                │  1 0 1 1 0 1 1 1  │ Map 1
                └──┬─┬─┬─┬─┬─┬─┬─┬──┘
                ┌──┴─┴─┴─┴─┴─┴─┴─┴──┐
                │  1 0 1 1 0 0 0 1  │ Map 0
                └──┬─┬─┬─┬─┬─┬─┬─┬──┘
        ┌─────────┘ │ │┌┘ └┐│ │ └─────────┐
        │    ┌──────Pixel values─────┐    │
        │    │    ┌───┘│   │└───┐    │    │
        ┌─┴┐ ┌─┴┐ ┌─┴┐ ┌─┴┐ ┌┴─┐ ┌┴─┐ ┌┴─┐ ┌┴─┐
        1111 0000 1011 1011 0000 1010 0010 1011
        │    │    └───┐│   │┌───┘    │    │
        │    └──────┐ │└┐ ┌┘│ ┌──────┘    │
        └─────────┐ │ │ │ │ │ │ ┌─────────┘
                ┌───│─│─│─│─│─│─│─│───────
                │┌──│─│─│─│─│─│─│─│───────
                ││  ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
                ││  ▒ • ▓ ▓ • ▓ ▓ ▓
                ││

    Figure 4-14.  Pixel mapping in 16-color EGA and VGA graphics modes.


Controlling the Video Display

    In general, control of the display screen, like most other computer
    operations, can be done in four ways:

    ■  By using the programming-language services (for example, BASIC's SCREEN
        statement)

    ■  By using the DOS services (see Chapters 16 and 17)

    ■  By using the ROM BIOS video services (see Chapter 9)

    ■  By direct manipulation of the hardware via memory or I/O ports

    The video services available through programming languages, DOS, and the
    ROM BIOS automatically place screen output data in the video buffer, with
    each type of service offering varying levels of control. The ROM BIOS
    services are particularly powerful, providing nearly all the functions
    needed to generate display-screen output, control the cursor, and
    manipulate screen information. (All video services are fully described in
    Chapter 9.) For maximum control over the video display, you also have the
    option of bypassing the software services and placing data directly in the
    video buffer──when you feel you have good reason to.

    ──────────────────────────────────────────────────────────────────────────
    About the Cursor
    A blinking cursor is a feature of the text modes that is used to
    indicate the active location on the display screen. The cursor is
    actually a group of scan lines that fill the entire width of the
    character box. The size of the character-box varies with the video
    hardware and video mode: The Monochrome Display Adapter uses a
    9-pixels-wide-by-14-scan-lines-high format; the Color Graphics Adapter
    uses an 8-pixels-by-8-scan-lines format; the EGA's default text-mode
    character box is 8 pixels wide by 14 scan lines high; and the VGA's is 9
    by 16. The higher-resolution video subsystems use character boxes with
    more scan lines, so their text-mode characters appear sharper and more
    detailed, as you'll see in Appendix C.

    The default cursor format uses two scan lines near the bottom of the
    character box but may be changed to display any number of scan lines
    within the character box. Since the blinking cursor used in text modes
    is a hardware-created feature, software has only limited control over
    it.

    You can change the size of the cursor as well as its location on the
    screen using the services provided by the ROM BIOS. Interrupt 10H,
    service 01H lets you set the size of the cursor, whereas service 02H
    lets you move the cursor to any character position on the screen. The
    ROM BIOS also provides a service (interrupt 10H, service 03H) that
    reports the current size and location of the cursor.

    So far, we've been talking about the text-mode cursor. In graphics modes
    there is no hardware-generated cursor, but the ROM BIOS routines keep
    track of a logical cursor location that tells you the active screen
    location. As in text modes, you can use ROM BIOS services 02H and 03H to
    keep track of the graphics-mode cursor location.

    To create a cursor in graphics modes, many programs, including BASIC,
    simulate the block cursor by using a distinctive background color at the
    cursor location or by using the ASCII block characters.
    ──────────────────────────────────────────────────────────────────────────

    Before opting for direct video output, you should know that it does
    interfere with windowing systems and more advanced multitasking operating
    environments. All the same, many important programs for the PC family
    generate direct video output──so many, in fact, that this has become a
    standard and accepted way of creating output. So, even though in the long
    run it's probably not wise to place output directly in the video buffer,
    everyone seems to be doing it.

    Basically, you can't mix programs that write directly into the display
    memory and windowing systems because two programs would be fighting over
    the control of the same memory and messing up each other's data. But
    because so many programs now generate direct video output, multitasking
    operating systems like OS/2 go to great lengths to accommodate programs
    that write directly to the display memory. A system like OS/2 can make
    this accommodation simply by keeping a separate copy of the program's
    display memory; when the program is running, the copy is moved into the
    display buffer, and when the program is stopped, a fresh copy of the
    display buffer is made. This technique allows OS/2 to run programs that
    work directly with the display memory, but at a cost: First, computing and
    memory overhead go up; second, the program can't run in the background
    simultaneously with other programs; and third, the display information
    can't be "windowed"; that is, it can't be moved or adjusted in size.

    Programmers are faced with a conflict here: Direct output to the screen
    has the benefit of speed and power, but using ROM BIOS or higher-level
    services for screen output has the benefit of more flexibility for
    adapting to windowing systems, new video hardware, and so on. The best
    solution is to use both techniques, trading off portability whenever
    maximum performance is an absolute priority.

Direct Hardware Control

    Much of the information we've provided in this chapter, particularly
    information on internal mapping of display memory, is meant to help you
    write video information directly into the display memory. But remember
    that direct programming has inherent risks, and you'll find it both safer
    and easier to use the highest available means to control the video
    display. Lower-level means, particularly direct manipulation, can be very
    disruptive.

    More important, it's not always easy to write "well-behaved" programs that
    access video hardware directly. There are several reasons for this. One is
    simply that there is a lot of different video hardware to worry about.
    Apart from the five IBM video subsystems we've discussed here, many
    non-IBM video adapters and built-in video subsystems exist in non-IBM
    computers. If you write a program that programs a particular IBM video
    subsystem directly, the program probably won't be portable to a different
    IBM subsystem or to non-IBM hardware.

    We've already mentioned another reason to avoid direct video hardware
    programming: Multitasking or windowing operating systems must work
    overtime to accommodate programs that directly access video hardware. Of
    course, the designers of newer PC and PS/2 operating environments are well
    aware of the need for good video performance, so modern operating systems
    generally offer faster and more flexible video output services than do
    older systems, such as DOS. Direct hardware programming offers little
    advantage if the operating system's video I/O services are fast enough.

    Also, direct video hardware control can get you into trouble with the ROM
    BIOS if you aren't careful. The ROM BIOS keeps track of the video hardware
    status in a set of variables in the data area in segment 40H. (See Chapter
    3 for a list of ROM BIOS video status variables.) If you program the
    video hardware directly, you must be careful to update the ROM BIOS status
    variables accordingly.

    For example, the simple routine we presented earlier for resetting the CGA
    enable-blink bit bypasses a ROM BIOS status variable. To update the
    enable-blink bit without causing the ROM BIOS to lose track of the video
    hardware state, you would update the ROM BIOS status variable at
    0040:0065H:

    10 DEF SEG = &HB800             ' (same as before)
    20 POKE 0,ASC("A")
    30 POKE 1,&H97
    40 DEF SEG = &H0040             ' address the BIOS data area
    50 POKE &H0065,(PEEK(&H0065) AND NOT &H20) ' update BIOS status variable
    60 OUT &H3D8,PEEK(&H0065)       ' update hardware register

    If you program carefully, controlling the video hardware directly can be
    very rewarding. You can maximize the speed of your video output as well as
    take full advantage of hardware capabilities such as smooth,
    pixel-by-pixel panning or hardware-generated interrupts. But when you
    write such a program, keep the pitfalls in mind.


Compatibility Considerations

    If you want your program to run on a wide variety of PCs and PS/2s, you
    must design compatibility into the program. As the various IBM video
    subsystems have evolved, programmers have developed several approaches to
    compatibility. These include

    ■  Installable programs

    ■  Self-installing programs

    ■  Hardware-independent programming environments

    We've already mentioned how many software vendors provide video
    compatibility by distributing software that has its video output routines
    in separate, installable modules: Before the software can be used, the
    video routines must be linked to the rest of the application. This lets
    you write programs that take full advantage of each video subsystem's
    capabilities without sacrificing compatibility.

    However, the installation process can be cumbersome, both for a programmer
    who must write the installation program and for an end-user who must
    install video routines properly. You can eliminate the installation
    process if you make your application self-installing. The key to doing
    this is to incorporate a routine in your program that identifies which
    video subsystem the program is running on. The program can then tailor its
    own video output to the capabilities and limitations of the video
    hardware.

    You can use several different programming techniques to identify the video
    subsystem. In PS/2s, ROM BIOS offers a service that reports the video
    hardware configuration (see Chapter 9), but in the PC/XT/AT family you
    must rely on improvised hardware identification techniques documented in
    the hardware technical manuals.

    Once a program has determined the video hardware configuration, it can
    produce appropriate output. For example, a program running on a Monochrome
    Display Adapter can use only one video mode with monochrome attributes. If
    the same program were running on a color subsystem, it could run with
    color attributes in text modes. If the program needed to produce graphics
    output, it could select a graphics mode with the highest possible
    resolution based on its identification of the video subsystem.

    In the simplest case, your program can use whatever video mode is in use
    when the program starts up. ROM BIOS interrupt 10H, service 0FH reports
    the current video mode number. If you're not using an assembly-language
    interface to the ROM BIOS, however, you may find it easier simply to use
    the program on the following page to inspect the ROM BIOS status variable
    at 0040:0049H that contains the video mode number.

    10 DEF SEG = &H0040
    20 VIDEO.MODE = PEEK(&H0049)

    You can avoid video hardware dependence in your programs if you use an
    operating environment like Digital Research's GEM or Microsoft Windows.
    These environments shield your program from the idiosyncrasies of video
    hardware by providing a set of consistent, hardware-independent
    subroutines to perform video I/O. The problem, of course, is that the
    end-user must also have a copy of the operating environment to be able to
    run your program.

    Whatever approach you take to video compatibility, be sure to consider
    several compatibility criteria. These criteria are not completely
    consistent with each other, reflecting the internal inconsistency in the
    design of the IBM personal computer and the variety of display formats
    that can be used. Still, there are overall guidelines for compatibility,
    which we'll outline here.

    First, text-only display output increases compatibility. Many PCs are
    still equipped with Monochrome Display Adapters, which cannot show graphic
    output. If you are weighing a text-versus-graphics decision in the design
    of a program, there are two factors to consider. On one hand, as many
    programs have dramatically demonstrated, you can create very effective
    drawings using only standard IBM text characters. On the other hand, it is
    more and more common for computers to include graphics capability. So, in
    the future, text-only output will probably lose its importance, and you'll
    be able to use graphics in your programs without worrying about
    compatibility.

    Second, the less your programs depend on color, the wider the range of
    computers with which they will be compatible. This does not mean that you
    need to avoid color for compatibility; it simply means that for maximum
    compatibility, programs should use color as an enhancement rather than as
    an essential ingredient. If programs can get along without color, they
    will be compatible with computers that use monochrome displays, including
    PCs with Monochrome Display Adapters, as well as Compaq Portable computers
    with built-in monochrome displays.

    In general, you must weigh the advantage of broad compatibility against
    the convenience and simplicity of writing programs for a narrower range of
    displays. Our own experience and judgment tell us that far too often
    programmers err by opting for a narrower range of displays, thereby
    greatly reducing the variety of computers their programs can be used on.
    Be forewarned.



────────────────────────────────────────────────────────────────────────────
Chapter 5  Disk Basics

    Disk Data Mapping
    Data Storage
    Bootable Disks

    DOS Disk Formats
    Diskette Formats
    Fixed-Disk Formats

    The Disk's Logical Structure

    How DOS Organizes the Disk

    The Logical Structure in Detail
    The Boot Sector
    The Root Directory
    The Files Area
    The File Allocation Table

    Comments
    Copy Protection

    Most computer systems have some way to store information permanently,
    whether it is on punched paper tape, bar-coded print media, magnetic disks
    or tape, or laser disks. By far the most widely used media in the PC and
    PS/2 family are diskettes (floppy disks) and fixed disks (hard disks).
    Diskettes and fixed disks come in various sizes and capacities but they
    all work in basically the same way: Information is magnetically encoded on
    their surfaces in patterns determined by the disk drive and by the
    software that controls the drive.

    When the PC family was introduced in 1981, it used one main type of
    storage device: the 51/4-inch diskette, which was double density, single
    sided, and soft sectored, and stored only 160 kilobytes (KB). Since then,
    higher-capacity 51/4-inch and 31/2-inch diskettes have become standard
    equipment on PCs and PS/2s, as have fixed disks with capacities from 10
    megabytes (MB) on the PC/XT to 314 MB on the PS/2 Model 80.

    Although the type of storage device is important, it is the way stored
    information is laid out and managed that concerns programmers most. In
    this chapter, we'll focus on how information is organized and stored on
    both diskettes and fixed disks. Much of the information provided in this
    chapter applies to RAM disks──that is, the simulation of disk storage in
    memory──as much as it does to conventional diskettes, fixed disks, and
    disk cartridges.


Disk Data Mapping

    To understand how data is organized on a disk, consider the physical
    structure of the disk itself and the drive mechanism that reads from and
    writes to it. We'll start with diskettes, but both diskettes and fixed
    disks have the same basic geometry.

    Inside a diskette's square plastic case is a circular platter made of
    tough plastic coated with a magnetic medium. A diskette drive stores data
    on the diskette by writing and reading magnetically encoded patterns that
    represent digital data. Because both sides of the diskette are coated,
    both sides can be used to store data.

    A diskette drive contains a motor that rotates the diskette at a constant
    speed. The drive has two read/write heads, one for each side of the
    diskette. The heads are mounted on an arm that moves them in unison to any
    position toward or away from the center of the disk. (The original IBM PC
    came with a diskette drive that had only one read/write head and could
    access only one side of a diskette. Most PC users perceived this as
    wasteful, so single-sided diskette drives gradually went the way of the
    dinosaur.)

    Like the tape heads in a common tape recorder, a diskette drive's
    read/write heads can magnetize the diskette medium to store data on the
    diskette; they can also retrieve data from the diskette by decoding the
    magnetically encoded patterns in the diskette medium.

    The geometry of a fixed disk is similar to that of a diskette. Fixed disks
    rotate much faster than diskettes, so the platters are made of
    magnetically coated metal or glass, not flexible plastic. Also, fixed
    disks usually consist of a stack of several platters that rotate together,
    so fixed-disk drives have multiple read/write heads──one for each disk
    surface.

Data Storage

    The way data is mapped on diskettes and fixed disks is a natural result of
    the geometry of the hardware. When a particular read/write head is held
    motionless, a ring of magnetic medium moves past it as the disk rotates.
    For each position of the read/write head, relative to the center of the
    disk, there is a corresponding ring of disk medium on which data can be
    stored. These rings are called tracks. (See Figure 5-1.)

    Because each disk track can store 4 KB or more of data, each track of data
    is divided into a number of smaller units called sectors. All sectors hold
    the same amount of data──typically, 512 bytes for diskettes and most fixed
    disks. The sectors and tracks are numbered sequentially, so you can locate
    any particular byte of data on a disk surface by specifying its track
    number and its sector number.

    Because two-sided diskettes and fixed disks have more than one disk
    surface, however, you need to think three-dimensionally to locate a byte
    of data. So the position of the read/write heads for these disks is
    described by a cylinder number. Like tracks, cylinders are numbered
    sequentially. If you think of a cylinder as a stack of tracks at a given
    position of the read/write heads, you can see that the location of a
    particular track is determined by specifying a cylinder number plus a
    read/write head.

    With this in mind, it's easy to make sense of the various diskette formats
    used in PC and PS/2 disk drives. (See Figure 5-2.) With the original
    single-sided IBM PC diskette drives you could use diskettes formatted with
    40 tracks, each of which contained eight sectors of data, so the capacity
    of the diskette was 40 x 8 x 512, or 160 KB. Now, with more accurate
    diskette drives and with high-density diskette media that can store more
    data per track, you can use diskettes with higher-capacity formats.
    Fixed-disk drives are mechanically more accurate than diskette drives, and
    their magnetic media are of comparatively higher density, so the number of
    tracks and the number of sectors per track are higher than for diskettes.

    ┌────────────────────────────────────────────────────────────────────────┐
    │ Figure 5-1 can be found on p.102 of the printed version of the book.   │
    └────────────────────────────────────────────────────────────────────────┘

    Figure 5-1.  One side of a diskette formatted with 40 concentric tracks
    and eight sectors per track.

    Manufacturers' terminology and advertising regarding these variations of
    disk format and disk-storage capacity is somewhat fuzzy. "Quad-density"
    refers to a diskette or drive that can use an 80-track diskette format.
    "High-density" and "high-capacity" generally refer to the PC/AT 1.2 MB or
    PS/2 1.44 MB diskette formats. "Double-density" diskettes can be formatted
    with eight or nine sectors per track, but they can't be used reliably with
    higher-capacity formats.

                                                    Sectors
    Disk                     Capacity    Cylinders   per Track    Heads
    ──────────────────────────────────────────────────────────────────────────
    51/4-inch diskette       160 KB      40           8           1
                            180 KB      40           9           1
                            320 KB      40           8           2
                            360 KB      40           9           2
                            1.2 MB      80          15           2
    31/2-inch diskette       720 KB      80           9           2
                            1.44 MB     80          18           2
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-2.  PC and PS/2 diskette formats.

Bootable Disks

    Regardless of their data formats, all diskettes and disks are potentially
    bootable; that is, they can contain the information necessary to get an
    operating system running at the time you start your computer. There is
    nothing special about the format of a bootable disk; it's just one that
    contains information that lets the ROM BIOS boot the operating system.
    Here's how it works.

    On all PC and PS/2 diskettes and fixed disks, the first sector on the
    disk──cylinder 0, head 0, sector 1──is reserved for a short bootstrap
    program. (The program has to be short because the size of a sector is only
    512 bytes.) The function of this bootstrap program is to read the bulk of
    the operating system into memory from elsewhere on the disk and then to
    transfer control to the operating system.

    When you start or restart your computer, the last tasks performed by the
    start-up ROM BIOS routines are reading the contents of the disk boot
    sector into memory and checking those contents for a bootstrap program.
    The BIOS does this checking by examining the last 2 bytes of the boot
    sector for a signature (55H and AAH) that indicates that the data in the
    boot sector represents a bootstrap program. If the signature value isn't
    correct, the BIOS assumes there's no bootstrap program in the boot sector
    and, therefore, that the disk isn't bootable.

    The bootstrap program's job is to copy the start-up program for an
    operating system from the disk into memory. There's no restriction on the
    size and location of the operating system's start-up program, so this
    stepwise transfer of control──from ROM BIOS to boot sector to operating
    system──can be used to start DOS, XENIX, OS/2, or even a stand-alone
    application.


DOS Disk Formats

    The diskette formats listed in Figure 5-2 aren't the only ones you can
    use for diskettes, but because diskettes are intended to be portable, the
    number of diskette formats that DOS recognizes is limited to those in the
    list. In the earliest releases of DOS, only the 160 KB and 320 KB formats
    could be used. Later DOS versions recognize higher-capacity diskette
    formats and fixed disks in addition to the original diskette formats
    (Figure 5-3).

    Disk                     Capacity        DOS Version      Media Descriptor
    ──────────────────────────────────────────────────────────────────────────
    51/4-inch diskette       160 KB          1.0              FEH
                            320 KB          1.1              FFH
                            180 KB          2.0              FCH
                            360 KB          2.0              FDH
                            1.2 MB          3.0              F9H
    31/2-inch diskette       720 KB          3.2              F9H
                            1.44 MB         3.3              F0H
    Fixed disk                               2.0              F8H
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-3.  Standard DOS disk formats. The media descriptor value is used
    by DOS to identify different disk formats.

Diskette Formats

    Beginning with version 2.0, DOS had the potential to recognize virtually
    any physical disk format. This became possible because DOS versions 2.0
    and later provide the necessary tools to write an installable device
    driver── a machine-language routine that can configure a disk drive to
    read or write different formats or allow you to hook up a non-IBM disk
    drive to your system. (See Appendix A for more on installable device
    drivers.)

    Fortunately, installable diskette device drivers have not led to a
    proliferation of nonstandard, incompatible diskette formats. Instead,
    software vendors and programmers have relied on the standard DOS formats
    listed in Figure 5-3. On 51/4-inch diskettes, the 360 KB nine-sector
    format is used most frequently, while on 31/2-inch diskettes, the 720 KB
    format is most common. These are not the highest capacity formats, but
    they can be used on machines that aren't equipped with higher-capacity
    diskette drives as well as on those that are.

    If you're interested in creating your own diskette formats, or in
    understanding DOS diskette formats in more detail, be sure to read about
    ROM BIOS disk services in Chapter 10.

Fixed-Disk Formats

    High-capacity fixed-disk systems present some special problems and
    opportunities. Fixed-disk formats vary much more than diskette formats do
    (Figure 5-4). Still, data is organized on fixed disks by cylinder, head,
    and sector numbers, just as it is on diskettes.

                                                    Sectors
    Disk                     Capacity    Cylinders   per Track    Heads
    ──────────────────────────────────────────────────────────────────────────
    Typical PC/XT            10 MB       306         17           4
    fixed disk
    PC/AT fixed disk         30 MB       733         17           5
    type 20
    PS/2 Model 30            20 MB       612         17           4
    fixed disk, type 26
    PS/2 Model 60            44 MB       732         17           7
    fixed disk, type 31
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-4.  Some typical fixed-disk formats. All use 512 bytes per
    sector.

    Because the storage capacity of a fixed disk is relatively large, some PC
    users prefer to use only part of the disk space for DOS and to use other
    portions of the disk for other operating systems. To facilitate this, the
    available space on a fixed disk can be split into as many as four logical
    partitions, each of which is accessed separately. Each partition's data
    can be kept completely separate from the data in the other partitions.
    Each partition can contain its own boot sector and operating system.

    The first sector on a fixed disk contains a 64-byte partition table
    (Figure 5-5) and a disk bootstrap program. The partition table indicates
    where each partition is located on the disk. The table also designates one
    bootable partition. The first sector in the bootable partition is a
    partition boot sector that the ROM BIOS can use to load an operating
    system.

    The disk bootstrap program examines the partition table to determine which
    one of the partitions is bootable. It then reads the partition's boot
    sector from the disk into memory. The partition boot sector contains a
    bootstrap program that reads the operating system from the disk into
    memory and transfers control to it.

    Because bootable partitions are indicated in a table, you can select among
    fixed-disk partitions simply by updating the table and restarting the
    computer. All operating systems capable of supporting fixed disks provide
    a utility program that lets you update the partition table. (The DOS
    utility FDISK is such a program.)

    Offset from
    Start of Entry Size (bytes)   Meaning
    ──────────────────────────────────────────────────────────────────────────
    00H            1              Boot indicator (80H = bootable, 0 = not
                                bootable)
    01H            1              Starting head number
    02H            2              Starting cylinder number (10 bits) and
                                sector number (6 bits)
    04H            1              System indicator:
                                    1 = primary DOS, 12-bit FAT
                                    2 = XENIX
                                    4 = primary DOS, 16-bit FAT
                                    5 = extended DOS
                                    8 = other non-DOS
    05H            1              Ending head number
    06H            2              Ending cylinder and sector numbers
    08H            4              Starting sector (relative to beginning of
                                disk)
    0CH            4              Number of sectors in partition
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-5.  The format of an entry in a fixed-disk partition table. The
    table consists of four such 16-byte entries, starting at offset 1BEH in
    the disk boot sector.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Be very careful if you access a fixed disk's boot sector. The
    information contained there is intended only for use by the ROM BIOS
    bootstrap loader. Should the data in a disk's boot sector be erased or
    corrupted, the entire contents of the disk may become inaccessible.
    ──────────────────────────────────────────────────────────────────────────


The Disk's Logical Structure

    Regardless of the type of disk you use, all DOS disks are logically
    formatted in the same way: The disk's sides, tracks, and sectors are
    identified numerically with the same notation, and certain sectors are
    always reserved for special programs and indexes that DOS uses to manage
    disk operations. Before we describe how DOS organizes space on a disk, we
    need to briefly cover the conventional notation used by DOS and the ROM
    BIOS to locate information.

    Diskette cylinder numbers start from 0 at the outside edge of the disk
    surface and increase toward the center of the disk. Read/write heads are
    also numbered from 0, but sector numbers start with 1. Any location on the
    disk can thus be described by a unique combination of cylinder, head, and
    sector numbers. This in fact is how the ROM BIOS services access disk
    data.

    DOS, however, does not recognize cylinders, heads, and sectors. Instead,
    DOS sees a disk as a linear sequence of logical sectors. The sequence of
    logical sectors begins with the first sector on a disk: Sector 1, cylinder
    0, head 0 (the boot sector) is DOS logical sector 0.

    Logical sectors are numbered from track to track in the same cylinder, and
    then are numbered from cylinder to cylinder. Thus the last sector in
    cylinder 0, head 0, is followed by the first sector in cylinder 0, head 1;
    the last sector in a cylinder is followed by the first sector in the next
    cylinder. See page 300 for information on converting DOS notation to ROM
    BIOS notation and vice versa.

    The use of logical sector numbers lets DOS avoid having to deal with
    cylinder, head, and sector numbers that vary among different types of
    disk-drive hardware. However, this same feature means that DOS is limited
    in the amount of disk space it can access on a particular disk drive.
    Because DOS maintains logical sector numbers as 16-bit integers, it can
    recognize, at most, 65,536 logical sectors on a disk. Because the default
    size of a disk sector is 512 bytes, the largest disk DOS can manage is
    65,536 x 512, or 32 MB. This certainly is no problem on diskettes, but
    it's an unwelcome limitation for the many PC/AT and PS/2 users who have
    fixed disks larger than 32 MB.

    To get around this restriction, DOS version 3.3 introduced the notion of
    the extended DOS partition. With DOS 3.3, you can use the DOS utility
    program FDISK to allocate a fixed-disk partition as an extended DOS
    partition. You can format the extended partition as one or more separate
    logical drives. Thus, for example, you could use both a primary and an
    extended DOS partition on a fixed disk, with the primary partition as
    drive C and the extended partition as drives D and E.


How DOS Organizes the Disk

    When DOS formats a diskette, it erases and verifies every sector. In a
    fixed-disk partition, DOS verifies the integrity of each sector without
    erasing pre-existing data. (That is why a program like the Norton
    Utilities' Format Recover can retrieve data from a fixed disk after you
    have accidentally reformatted it.) On both diskettes and fixed disks, the
    format program reserves a certain amount of disk space to store control
    information and indexes that DOS uses to organize the data you store on
    the disk.

    Every DOS diskette or fixed-disk DOS partition is mapped into four
    separate areas. These areas, in the order they are stored, are the
    reserved area, the file allocation table (FAT), the root directory, and
    the files area. (See Figure 5-6.) The size of each area varies among
    formats, but the structure and the order of the areas don't vary.

                    ┌───────────────────┐
    Logical sector 0 │  Reserved area    │
                    ├───────────────────┤
                    │                   │
                    │ File allocation   │
                    │   table (FAT)     │
                    │                   │
                    ├───────────────────┤
                    │  Root directory   │
                    ├───────────────────┤
                    │                   │
                    │ Files area (files │
                    │and subdirectories)│
                    │                   │
                    │                   │
                    │                   │
                    └───────────────────┘

    Figure 5-6.  DOS disk map.

    The reserved area can be one or more sectors long; the first sector is
    always the disk boot sector (logical sector 0). A table within the boot
    sector specifies the size of the reserved area, the size (and number of
    copies) of the file allocation table, as well as the number of entries in
    the root directory. All diskettes have a reserved area of at least one
    sector, even if they aren't bootable.

    The file allocation table, or FAT, immediately follows the reserved area.
    The FAT maps the usage of all the disk space in the files area of the
    disk, including space used for files, space that hasn't been used, and
    space that is unusable due to defects in the disk medium. Because the FAT
    maps the entire usable data storage area of a disk, two identical copies
    of it are stored in case one is damaged. The size of a FAT depends on the
    size of the disk (or of the partition of a fixed disk): Larger disks
    usually require larger FATs. Figure 5-7 shows FAT sizes for several
    different disk sizes.

                                        Reserved                 Root
    Disk                     Capacity    Area        FAT          Directory
    ──────────────────────────────────────────────────────────────────────────
    51/4-inch diskette       360 KB      1 sector     4 sectors    7 sectors
                            1.2 MB      1           14           14
    31/2-inch diskette       720 KB      1            6            7
                            1.44 MB     1           18           14
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-7.  Reserved area, FAT, and root-directory overhead for some
    common DOS diskette formats.

    The root directory is the next item on a DOS disk. It is used as a table
    of contents, identifying each file on the disk with a directory entry that
    contains several pieces of information, including the file's name, size,
    and location on the disk. The size of the root directory varies with the
    disk format. (See Figure 5-7.)

    The files area, which occupies the bulk of the available disk space, is
    used to store files; in DOS versions 2.0 and later, the files area may
    contain subdirectories as well as files. For both files and
    subdirectories, space in the files area is allocated as needed in chunks
    of contiguous sectors called clusters. As with the sizes of the FAT and
    the root directory, a DOS disk's cluster size varies with the format. (See
    Figure 5-8.) The number of sectors in a cluster is always a power of 2;
    generally, the cluster size is one sector for single-sided diskettes, two
    sectors for double-sided diskettes, and four or more for fixed disks.

    Disk                                 Capacity           Cluster Size
    ──────────────────────────────────────────────────────────────────────────
    51/4-inch diskette                   360 KB             2 sectors
                                        1.2 MB             1
    31/2-inch diskette                   720 KB             2
                                        1.44 MB            1
    Typical PC/XT fixed disk             10 MB              8
    PC/AT fixed disk, type 20            30 MB              4
    PS/2 Model 30, fixed disk, type 26   20 MB              4
    PS/2 Model 60, type 31               44 MB              4
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-8.  Cluster size for some common DOS disk formats.


The Logical Structure in Detail

    Now it's time to delve a little more deeply into each of the four sections
    of a disk: the boot sector, the root directory, the files area, and the
    FAT.

The Boot Sector

    The boot sector on a DOS diskette or in a DOS partition on a fixed disk
    consists primarily of a short machine-language program that starts the
    process of loading DOS into memory. As we mentioned, to perform this task
    the ROM BIOS checks to see whether the disk is bootable and then proceeds
    accordingly.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    A bootable disk contains the start-up programs for an operating system
    or for a stand-alone application that runs without operating-system
    support. In the case of DOS, a bootable disk contains two hidden files
    that represent the DOS start-up routines and essential low-level DOS
    functions. See Chapter 3, page 45 for details about these files.
    ──────────────────────────────────────────────────────────────────────────

    You can inspect the boot program by using the DOS DEBUG utility, which
    combines the ability to read data from any sector on a disk with the
    ability to disassemble──or unassemble──machine language into
    assembly-language code. If you want to learn more about the boot program
    and you aren't intimidated by DEBUG's terse command format, place a
    bootable diskette in drive A and enter the following commands to display
    the diskette's boot program:

    DEBUG
    L 0 0 0 1           ; load first logical sector
    U 0 L 3             ; unassemble and list first and second bytes

    At this point, DEBUG will display the first instruction in the boot
    program, a JMP to the address that contains the rest of the program. Use
    DEBUG's U command with the address specified in the JMP to inspect the
    rest of the boot program. For example, if the first instruction is JMP
    0036, enter

    U 0036          ; unassemble and list next portion of boot program

    For all disk formats (except diskettes formatted with eight sectors per
    track) you will find some key parameters in the boot sector, beginning
    with the 11th byte. (See Figure 5-9.) These parameters are part of the
    BIOS parameter block used by DOS to control any disk-type device. If
    you're using DEBUG to inspect the boot sector of a diskette in drive A,
    you can see a hexadecimal dump of the BIOS parameter block by entering the
    following command:

    D 0B L 1B

    Offset         Length         Description
    ──────────────────────────────────────────────────────────────────────────
    03H            8 bytes        System ID
    0BH            1 word         Number of bytes per sector
    0DH            1 byte         Number of sectors per cluster
    0EH            1 word         Number of sectors in reserved area
    10H            1 byte         Number of copies of FAT
    11H            1 word         Number of root directory entries
    13H            1 word         Total number of sectors
    15H            1 byte         DOS media descriptor
    16H            1 word         Number of sectors per FAT
    18H            1 word         Number of sectors per track
    1AH            1 word         Number of heads (sides)
    1CH            1 word         Number of hidden sectors
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-9.  The BIOS parameter block in the boot sector.

The Root Directory

    The root directory on a diskette or in a fixed-disk partition is created
    by the DOS FORMAT program. The root directory's size is determined by
    FORMAT, so the number of root directory entries is limited. (See Figure
    5-10.)

    Disk                          Capacity      Size           Number of
                                                                Entries
    ──────────────────────────────────────────────────────────────────────────
    51/4-inch diskette            180 KB         4 sectors      64
                                360 KB         7             112
                                1.2 MB        14             224
    31/2-inch diskette            720 KB         7             112
                                1.44 MB       14             224
    Typical PC/XT fixed disk      10 MB         32             512
    PC/AT fixed disk, type 20     30 MB         32             512
    PS/2 Model 30, fixed disk,    20 MB         32             512
    type 26
    PS/2 Model 60, fixed disk,    44 MB         32             512
    type 31
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-10.  Root directory sizes for some common DOS disk formats.

    In DOS versions 1.0 and later, which did not support subdirectories, the
    size of the root directory limited the number of files that could be
    stored on a diskette. This restriction disappeared in DOS versions 2.0 and
    later, where file names could be placed in subdirectories as well as in
    the root directory.

    The root directory contains a series of 32-byte directory entries. Each
    directory entry contains the name of a file, a subdirectory, or a disk
    volume label. The directory entry for a file contains such basic
    information as the file's size, its location on the disk, and the time and
    date it was most recently modified. This information is contained in the
    eight fields listed in Figure 5-11.

                                        Size
    Offset      Description              (bytes)     Format
    ──────────────────────────────────────────────────────────────────────────
    00H         Filename                  8          ASCII characters
    08H         Filename extension        3          ASCII characters
    0BH         Attribute                 1          Bit coded
    0CH         Reserved                 10          Unused; zeros
    16H         Time                      2          Word, coded
    18H         Date                      2          Word, coded
    1AH         Starting cluster number   2          Word
    1CH         File size                 4          Integer
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-11.  The eight parts of a directory entry.

    Offset 00H: The filename

    The first 8 bytes in a directory entry contain the filename, stored in
    ASCII format. If the filename is less than eight characters, it is filled
    out to the right with blanks (CHR$(32)). Letters should be uppercase,
    because lowercase letters will not be properly recognized. Normally,
    blanks should not be embedded in the filename, as in AA BB. Most DOS
    command programs, such as DEL and COPY, will not recognize filenames with
    embedded blanks. BASIC works successfully with these filenames, however,
    and DOS services usually can too. (See Chapters 16 and 17.) This
    capability suggests some useful tricks, such as creating files that cannot
    easily be erased.

    Two codes, used to indicate special situations, may appear in the first
    byte of the filename field. When a file is deleted, DOS sets the first
    byte of the filename field in its directory entry to E5H to indicate that
    the directory entry can be reused for another filename. In DOS versions
    2.0 and later, the first byte of a directory entry can also be set to 00H
    to indicate the end of the list of directory entries.

    When a file is erased, only two things on the disk are affected: The first
    byte of the directory entry is set to E5H, and the file's space-allocation
    chain in the FAT is wiped out (we'll cover this in the section on the
    FAT). All other directory information about the file is retained,
    including the rest of its name, its size, and even its starting cluster
    number. The lost information can be recovered, with suitably sophisticated
    methods, provided that the directory entry has not been reused for another
    file. Be forewarned, though, that whenever a new directory entry is
    needed, DOS uses the first available entry, quickly recycling an erased
    file's entries and making recovery more problematic.

    Offset 08H: The filename extension

    Directly following the filename is the standard filename extension, stored
    in ASCII format. It is 3 bytes long and, like the filename, is padded with
    blanks if it is less than the full three-character length. While a
    filename must have at least one ordinary character in it, the extension
    can be all blanks. Generally, the rules that apply to the filename also
    apply to the filename extension.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    When the directory contains a volume ID label entry, the filename and
    extension fields are treated as one combined field of 11 bytes. In this
    case, embedded blanks are permitted.
    ──────────────────────────────────────────────────────────────────────────

    Offset 0BH: The file attribute

    The third field of the directory entry is 1 byte long. The bits of the
    attribute byte are individually coded as bits 0 through 7, as shown in
    Figure 5-12, and each bit is used to categorize the directory entry.

        Bit
    7 6 5 4 3 2 1 0          Meaning
    ──────────────────────────────────────────────────────────────────────────
    . . . . . . . 1          Read-only
    . . . . . . 1 .          Hidden
    . . . . . 1 . .          System
    . . . . 1 . . .          Volume label
    . . . 1 . . . .          Subdirectory
    . . 1 . . . . .          Archive
    . 1 . . . . . .          Unused
    1 . . . . . . .          Unused
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-12.  The 8 file-attribute bits.

    Bit 0, the low-order bit, is set to mark a file as read-only. In this
    state, the file is protected from being changed or deleted by any DOS
    operation. We should point out that many DOS services ignore this
    attribute, so even though bit 0 can provide worthwhile protection for
    data, it is not foolproof.

    Bit 1 marks a file as hidden and bit 2 marks a file as a system file.
    Files marked as hidden, system, or both, cannot be seen by ordinary DOS
    operations, such as the DIR command. Programs can gain access to such
    files only by using DOS services to search explicitly for hidden or system
    files. There is no particular significance to the system attribute; it
    exists to perpetuate a feature of CP/M and has absolutely nothing to do
    with DOS.

    ──────────────────────────────────────────────────────────────────────────
    Subdirectories
    There are two types of directories: root directories and subdirectories.
    The contents and use of each type are essentially the same (both store
    the names and locations of files on the disk) but their characteristics
    are different. The root directory has a fixed size and is stored in a
    fixed location on the disk. A subdirectory has no fixed size and can be
    stored anywhere on the disk. Any version of DOS numbered 2.0 or later
    can use subdirectories.

                    Root Directory
                            │
            ┌─────────────────┼────────────────────────────────┐
            │                 │                                │
        Programs    Word-processing data                Accounting data
    subdirectory     subdirectory                      subdirectory
                            │                                │
                    ┌───────┴────────┐               ┌───────┴────────┐
                    │                │               │                │
                Letters          Reports      Current year      Prior year
                subdirectory     subdirectory   subdirectory     subdirectory

    A subdirectory is stored in a disk's files area, just like any other
    file. The format of directory entries in a subdirectory is identical to
    the format of entries in a root directory, but a subdirectory is not
    limited in size. Like an ordinary file, a subdirectory can grow without
    bounds as long as disk space is available to hold it.

    A subdirectory is always attached to a parent directory, which can be
    either the root directory or another subdirectory. When you nest
    subdirectories, one within another, they are related in the form of a
    tree structure.

    A parent directory has one entry for each of its subdirectories. A
    subdirectory entry is just like a filename entry, except that the
    attribute byte marks the entry as a subdirectory and the file-size field
    is set to 0. The actual size of the subdirectory can be found by tracing
    its allocation chain through the FAT.

    When DOS creates a subdirectory, it places two special entries in it,
    with . and . . as filenames. These act like entries for further
    subdirectories, but . actually refers to the present subdirectory and .
    . refers to its parent directory. The starting cluster number in each of
    these directory entries gives the location of the subdirectory itself or
    of its parent. When the starting cluster number is 0, the parent of the
    subdirectory is the root directory.

    If the size of a "normal" file is reduced, you can generally count on
    DOS to release any unused space. In the case of subdirectories, however,
    clusters of space that are no longer used (because the directory entries
    that occupied that space are erased) are not released until the entire
    subdirectory is deleted.
    ──────────────────────────────────────────────────────────────────────────

    Bit 3 marks a directory entry as a volume label. A volume label entry is
    properly recognized only in the root directory, and uses only a few of the
    eight fields available in the directory entry: The label itself is stored
    in the filename and extension fields, which are treated as one unified
    field for this purpose; the size and starting cluster fields are not used,
    but the date and time fields are.

    Bit 4, the subdirectory attribute, identifies a directory entry as a
    subdirectory. Because subdirectories are stored like ordinary data files,
    they need a supporting directory entry. All the directory fields are used
    for these entries, except the file-size field, which is zero. The actual
    size of a subdirectory can be found simply by following its space
    allocation chain in the FAT.

    Bit 5, the archive attribute, was created to assist in making backup
    copies of the many files that can be stored on a fixed disk. This bit is 0
    on all files that haven't changed since they were last backed up; DOS sets
    this bit to 1 whenever a file is created or modified.

    Offset 0CH: Reserved

    This 10-byte area is set aside for possible future uses. All 10 bytes are
    normally set to 0.

    Offset 16H: The time

    This field contains a 2-byte value that marks the time that the file was
    created or last changed. It is used in conjunction with the date field,
    and the two together can be treated as a single 4-byte unsigned integer.
    This 4-byte integer can be compared with those in other directory entries
    for greater-than, less-than, or equal values. The time, by itself, is
    treated as an unsigned word integer. It is based on a 24-hour clock and is
    built out of the hour, minutes, and seconds with this formula:

    Time=(Hourx2048)+(Minutesx32)+(Seconds÷2)

    The 2-byte word used to store the time is one bit too short to store all
    the seconds, so seconds are stored in units of 2 seconds from 0 through
    29; a value of 5, for example, would represent 10 seconds. The time
    11:32:10 would be stored as the value 5C05H (decimal 23557).

    Offset 18H: The date

    This field contains a 2-byte value that marks the date the file was
    created or last changed. It is used in conjunction with the time field,
    and the two together can be treated as a single 4-byte unsigned integer
    that can be compared with those in other directory entries for
    greater-than, less-than, or equal values. The date, by itself, is treated
    as an unsigned word integer that is built out of the year, month, and day
    with this formula:

    Date=((Year-1980)x512)+(Monthx32)+Day

    This formula compresses the year by subtracting 1980 from it. Thus, the
    year 1988 is calculated as a value of 8. Using this formula, a date such
    as December 12, 1988 is stored by the formula as 118CH (decimal 4492):

    (1988-1980)x512+12x32+12=4492

    Although this scheme allows for years up through 2107, the highest year
    supported by DOS is 2099.

    Offset 1AH: The starting cluster number

    The seventh field of a directory entry is a 2-byte value that gives the
    starting cluster number for the file's data space. This cluster number
    acts as the entry point into the file's space allocation chain in the FAT.
    For files with no space allocated and for volume-label entries, the
    starting cluster number is 0.

    Offset 1CH: The file size

    The last field of a directory entry gives the size of the file in bytes.
    It is coded as a 4-byte unsigned integer, which allows file sizes to grow
    very large──4,294,967,295 bytes, to be exact──large enough for all
    practical purposes.

    DOS uses the file size in a file's directory entry to determine the exact
    size of the file. Because a file's disk space is allocated in clusters of
    512 bytes or more, the actual disk space occupied by a file is usually
    greater than the value in the directory entry. On disk, the space between
    the end of the file and the end of the last cluster in the file is wasted.

The Files Area

    All data files and subdirectories are stored in the files area, which
    occupies the last and largest part of each disk.

    DOS allocates space to files, one cluster at a time, on an as-needed
    basis. (Remember, a cluster is one or more consecutive sectors; the number
    of sectors per cluster is a fixed characteristic of each disk format.) As
    a file is being created, or as an existing file is extended, the file's
    allocated space grows. When more space is needed, DOS allocates another
    cluster to the file. In DOS versions 1 and 2, the first available cluster
    is always allocated to the file. Later versions of DOS select clusters by
    more complicated rules that we won't go into here.

    Under ideal conditions, a file is stored in one contiguous block of space.
    However, a file might be broken into several noncontiguous blocks,
    especially if information is added to an existing file or a new file is
    stored in the space left by an erased file. So it's not unusual for one
    file's data to be scattered throughout the disk.

    This file fragmentation slows access to the file's data to some degree.
    Also, it is much harder to "unerase" a file you have unintentionally
    erased if it is fragmented, simply because you have to do a lot more
    searching for the individual clusters that make up the file's data space.
    But fragmentation has no other effect, and programs generally do not need
    to be concerned about where on a disk their data is stored. To determine
    if a file is fragmented, use CHKDSK or a program such as the Norton
    Utilities.

    If you are concerned about diskette file fragmentation, the DOS COPY
    command lets you transfer fragmented files to a newly formatted disk. DOS
    allocates contiguous space for the copied files. This simple technique
    also works for fixed-disk files, but it is much less convenient unless you
    have an extra, newly formatted fixed disk to use. If you think that
    fixed-disk file fragmentation is slowing down a particular application,
    you can purchase any of several fixed-disk utility programs to rearrange
    fragmented fixed-disk files and make them contiguous. Most of the time,
    however, file fragmentation has little impact on the speed of your
    programs.

    Whether you ever look at your fragmented files or not, you should know how
    DOS uses the file allocation table (FAT) to allocate disk space and how
    the FAT forms a space allocation chain to connect all of the clusters that
    make up a file.

The File Allocation Table

    The file allocation table (FAT) is DOS's map of how space is utilized in
    the files area of a disk. We've already discussed how space for the FAT
    itself is reserved on a diskette or in a fixed-disk partition. Now we'll
    describe how the FAT is formatted and used.

    For most disk formats, DOS maintains two copies of the FAT, just in case
    one of them is damaged or becomes unreadable. Curiously, the CHKDSK
    program, which tests for most errors that can occur in the FAT and in
    directories, does not even notice if the two FATs are different.

    The organization of the FAT is simple: There is one entry in the FAT for
    each cluster in the files area. A FAT entry can contain any of the values
    listed in Figure 5-13. If the value in a FAT entry doesn't mark an
    unused, reserved, or defective cluster, then the cluster that corresponds
    to the FAT entry is part of a file, and the value in the FAT entry itself
    indicates the next cluster in the file.

    This means that the space that belongs to a given file is mapped by a
    chain of FAT entries, each of which points to the next entry in the chain.
    (See Figure 5-14.) The first cluster number in the chain is the starting
    cluster number in the file's directory entry. When a file is created or
    extended, DOS allocates clusters to the file by searching the FAT for
    unused clusters (that is, clusters whose FAT entries are 0) and adding
    them to the chain. Conversely, when a file is truncated or deleted, DOS
    frees the clusters that had been allocated to the file by clearing the
    corresponding FAT entries.

    12-bit Value             16-bit Value            Meaning
    ──────────────────────────────────────────────────────────────────────────
    0                        0                       Unused cluster
    FF0-FF6H                 FFF0-FFF6H              Reserved cluster
    FF7H                     FFF7H                   Bad cluster
    FF8-FFFH                 FFF8-FFFFH              Last cluster in a file
    (other values)                                   Next cluster in a file
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-13.  FAT values.

                File-  Extension            Starting
                name                        cluster
    Directory   ┌─────┬────┬─────────────────┬────┬─┐
        entry   │ALPHA│TEXT│                 │0003│ │
                └─────┴────┴─────────────────┴──┬─┴─┘
                        ┌────────────────────────┘
                        │┌─────────────┐┌─────────┐
            ──┬────┬─▼┴─┬────┬────┬─▼┴─┬────┬──▼──┬────┬──
    FAT       │0000│0006│0000│0000│0000│0008│FFFFH│0000│
            ──┴────┴────┴────┴────┴────┴────┴─────┴────┴──
                    2    3    4    5    6    7     8    9

    Figure 5-14.  Disk-space allocation using the FAT.

    The FAT can be formatted with either 12-bit or 16-bit entries. The 12-bit
    format is used for diskettes and fixed-disk partitions with no more than
    4078 clusters. (A fixed-disk's partition table indicates whether a DOS
    partition's FAT uses 12-bit or 16-bit entries.) The entries in a 12-bit
    FAT are harder to access because they don't fit neatly into the 16-bit
    word size of the 8086 family of microprocessors, but a 12-bit FAT takes up
    less room on a diskette, where disk space is scarcer.

    The first two entries in the FAT are reserved for use by DOS. The first
    byte of the FAT contains the same media descriptor value that appears in
    the BIOS parameter block in the disk boot sector. The remaining bytes of
    the first two entries are filled with the value 0FFH. Because the first
    two cluster numbers (0 and 1) are reserved, cluster number 2 corresponds
    to the first cluster of available disk space in the files area.

    Reading the values in the FAT is simple enough for a 16-bit FAT: Multiply
    a given cluster number by 2 to find the byte offset of the corresponding
    FAT entry. In the 16-bit FAT in Figure 5-15, for example, the byte offset
    of the FAT entry for cluster 2 is 04H, and the value in that entry is
    0003; the byte offset of the FAT entry for cluster 3 is 06H, and the value
    in that entry is 0004; and so on.

    For a 12-bit FAT, the computation is a bit trickier, because each pair of
    FAT entries occupies 3 bytes (0 and 1 occupy the first 3 bytes, 2 and 3
    occupy the next 3 bytes, and so forth). Given any cluster number, you can
    find the FAT entry by multiplying the cluster number by 3, dividing by 2,
    and then using the whole number of the result as a displacement into the
    FAT. By grabbing a word at that address, you have the three hex digits of
    the FAT entry, plus one extraneous hex digit, which can be removed by any
    one of several quick machine-language instructions. If the cluster number
    is even, you discard the high-order digit; if it is odd, you discard the
    low-order digit. Try this on the 12-bit FAT in Figure 5-15. You'll find
    that the entries are the same as in the 16-bit FAT in Figure 5-15.

    (a) 16-bit FAT

        Reserved     Cluster Cluster Cluster Cluster Cluster Cluster Cluster Cl
                        2       3       4       5       6       7       8
    ┌──────┴─────┐  ┌──┴─┐  ┌──┴─┐  ┌──┴─┐  ┌──┴─┐  ┌──┴─┐  ┌──┴─┐  ┌──┴─┐  ┌─
    F8  FF  FF  FF  03  00  04  00  05  00  06  00  0A  00  08  00  FF  FF  23



    (b) 12-bit FAT

    Reserved    Clusters    Clusters    Clusters    Clusters
                2 and 3     4 and 5     6 and 7     8 and 9
    ┌────┴───┐  ┌────┴───┐  ┌────┴───┐  ┌────┴───┐  ┌────┴───┐
    FO  FF  FF  03  40  00  05  60  00  0A  80  00  FF  3F  12

    Figure 5-15.  The first few entries in a 16-bit FAT (a) and in a 12-bit
    FAT (b).

    As we have said, the first two FAT entries, in both 12-bit and 16-bit
    formats, are not used to indicate the status of clusters; instead, they
    are set aside so that the very first byte of the FAT can be used as a
    media descriptor byte that indicates the format of the disk. (See Figure
    5-16.) However, you should not assume that these IDs uniquely identify
    formats: they don't necessarily. If you considered every disk format in
    use, you'd find quite a few duplications. Beware.

                                                    Sectors      Media
    Disk                     Capacity    Heads       per Track    Descriptor
    ──────────────────────────────────────────────────────────────────────────
    51/4-inch diskette       160 KB      1             8          FEH
                            320 KB      2             8          FFH
                            180 KB      1             9          FCH
                            360 KB      2             9          FDH
                            1.2 MB      2            15          F9H
    31/2-inch diskette       720 KB      2             9          F9H
                            1.44 MB     2            18          F0H
    Fixed disk                                                    F8H
    ──────────────────────────────────────────────────────────────────────────

    Figure 5-16.  DOS media descriptor values.

    Your programs can learn the format of a disk by reading and inspecting the
    FAT media descriptor byte. The easy way to do this is to use DOS function
    1BH (decimal 27). For more information about this function, see page 335.

    Special notes on the FAT

    Normally, programs do not look at or change a disk's FAT; they leave the
    FAT completely under the supervision of DOS. The only exceptions are
    programs that perform space-allocation functions not supported by DOS──for
    example, programs that recover erased files, such as the UnErase program
    in the Norton Utilities program set.

    Be aware that a FAT can be logically damaged; for example, an allocation
    chain can be circular, referring back to a previous link in the chain; or
    two chains can converge on one cluster; or a cluster can be orphaned,
    meaning that it is marked as in use even though it is not part of any
    valid allocation chain. Also, an end-of-file marker (FFFH or FFFFH) may be
    missing. The DOS programs CHKDSK and RECOVER are designed to detect and
    repair most of these problems as well as can reasonably be done.

    For special notes on the interaction of the space allocation chain in the
    FAT and DOS's record of a file's size, see page 117.


Comments

    Although this chapter has included detailed information for direct use of
    the logical structure of the disk itself, including the boot sector, FAT,
    and directories, it is not a good idea to use these elements directly
    unless you have a compelling reason. In fact, except where such use is
    completely unavoidable, as in a copy-protection program, it's unwise to
    incorporate any knowledge of the disk format in your programs. On the
    whole, your best approach is to consider the standard hierarchy of
    operations and use the highest level of services that can satisfy your
    needs:

    ■  First choice: Language services (the facilities provided by your
        programming language; for example, BASIC's OPEN and CLOSE statements)

    ■  Second choice: DOS services (described in Chapters 16 and 17)

    ■  Third choice: ROM BIOS disk services (described in Chapter 10)

    ■  Last choice: Direct control (for example, direct programming of the
        disk-drive controller through commands issued via I/O ports)

    Most disk operations for the PC family can be handled quite easily with
    the services that your programming language provides. There are, however,
    two obvious circumstances that can call for more exotic methods. One,
    which we've already mentioned, occurs when your programming involves
    control of a disk on the same level exercised by DOS. This level of
    control would be called for if you were writing a program similar to DOS's
    CHKDSK or the Norton Utilities. The other circumstance involves copy
    protection. In one way or another, all diskette copy-protection schemes
    involve some type of unconventional diskette I/O. This type of control
    usually leads to the use of the ROM BIOS services, but may also lead to
    the extreme measure of directly programming the disk-drive controller
    itself.

Copy Protection

    A variety of copy-protection schemes are commercially available. Some are
    simple, others are more complex. If you're interested in devising your own
    scheme, however, here are some things to consider.

    For diskettes, there are dozens of ways to approach copy protection.
    Perhaps the most common methods involve reformatting the sectors in
    certain tracks on the diskette by using the ROM BIOS format routines.
    Because DOS cannot read sectors that don't conform to its specific
    formats, the DOS COPY program can't copy a disk that has an occasional odd
    sector size interspersed with normal sectors. This DOS limitation inspired
    a number of companies to produce copy programs that can read and copy
    sectors of any size, so it is not a particularly effective means of copy
    protection.

    On a more advanced level, there are two special aspects of diskette copy
    protection that are worth noting. First, some of the most exotic and
    unbreakable protection schemes have been based on the discovery of
    undocumented abilities hidden in the diskette-drive controller. Second,
    some protection schemes are intentionally or unintentionally dependent
    upon the particular characteristics of different diskette drives. This
    means that a copy-protected program may function on one model of computer
    but fail to function on another model, even though the copy protection has
    not been tampered with. If you use a copy-protection scheme, keep this in
    mind.

    Many of the copy-protection techniques used on diskettes are not
    appropriate for fixed disks, mainly because most fixed-disk users need to
    be able to make backup copies of programs on their fixed disks. This means
    you should avoid copy-protection schemes that prevent fixed-disk backups
    by making it impossible for DOS or the ROM BIOS to read part of the disk.
    Most of the fixed-disk copy-protection schemes in use today rely on
    data-encryption techniques, which discourage software piracy without
    preventing legitimate copying.

    In an encrypted program, the program's executable code and data are stored
    on the disk in an encrypted, hard-to-unravel format. When you execute the
    program, a special start-up program decrypts the encrypted code and data
    so that it can be used. The start-up program might also rely on data saved
    in hidden files or subdirectories to decrypt the main program.

    There is no particular additional guidance that we can give you here,
    except to remind you that variety and ingenuity are the keys to successful
    copy protection.



────────────────────────────────────────────────────────────────────────────
Chapter 6  Keyboard Basics

    Keyboard Operation
    Keystrokes and Scan Codes
    Communicating with the ROM BIOS
    Translating the Scan Codes
    Entering ASCII Codes Directly

    Keyboard Data Format
    The ASCII Keys
    The Special Keys

    ROM BIOS Keyboard Control
    The Insert State
    The Caps Lock State
    The Num Lock State
    The Keyboard-Hold State
    The Toggle-Key States

    Comments

    This chapter is about the IBM PC and PS/2 keyboards. The first part of
    this chapter explains how the keyboard interacts with the computer on a
    hardware and software level. In the second part, we'll describe how the
    ROM BIOS treats keyboard information and makes it available to programs.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    If you plan to play around with keyboard control, we urge you to read
    the comments on page 140 first and then apply the information in this
    chapter to your programs only if you have a reason to do so (for
    example, if you are creating a keyboard-enhancer program to modify the
    operation of the keyboard; see the sidebar on page 133 for more
    information on such programs). If you have any such application in mind,
    take a look at the ROM BIOS keyboard services in Chapter 11.
    ──────────────────────────────────────────────────────────────────────────

    The keyboard has undergone several modifications since the IBM PC was
    released. The original IBM PC keyboard had 83 keys. The PC/AT was
    introduced with an 84-key keyboard that changed the locations of several
    keys on the 83-key keyboard and added one new key, the Sys Req key.

    IBM later upgraded the AT with a 101/102-key keyboard that provided extra
    function keys and a new keyboard layout. The 101/102-key keyboard became
    standard equipment in the PS/2 series. The 101/102-key layout includes two
    extra function keys (F11 and F12), a number of duplicate shift and control
    keys, and modifications to several keys and keyboard combinations found in
    the 83- and 84-key layouts (Pause, Alt-Sys Req, and Print Screen).

    A trend in IBM's keyboard design has been to increase the similarity
    between the PC and PS/2 keyboards and the keyboards on their mainframe
    display terminals. For example, the 101/102-key keyboard's 12 function
    keys (F1 through F12) are reminiscent of the Program Function (PF) keys on
    IBM mainframe display terminals. Similarly, the Sys Req key is like the
    Sys Req key in IBM mainframe terminals: A mainframe terminal-emulator
    program running on a PC or PS/2 could use the Sys Req key for the same
    purpose a mainframe terminal would──to switch among terminal sessions or
    to initiate a keyboard reset function.

    Another trend in IBM's keyboard design has been to accommodate non-English
    alphabets in the keyboard layout. The English-language version of the
    101/102-key keyboard released in the United States and United Kingdom has
    101 keys, but for other languages the same keyboard has an extra key next
    to the left Shift key, a different arrangement of keys around the Enter
    key, and a different map of ASCII characters to key locations. From a
    programmer's point of view, however, these two keyboards are so similar
    that IBM describes them together in its technical documentation──and we'll
    do the same in this chapter.


Keyboard Operation

    The keyboard unit contains a dedicated microprocessor that performs a
    variety of jobs, all of which help cut down on system overhead. The main
    duty of the keyboard microprocessor is to watch the keys and report to the
    main computer whenever a key is pressed or released. If any key is pressed
    continuously, the keyboard microprocessor sends out a repeat action at
    specific intervals. The keyboard microprocessor controller also has
    limited diagnostic and error-checking capabilities and has a buffer that
    can store key actions in the rare instance that the main computer is
    temporarily unable to accept them.

    The PC/AT and PS/2s have sophisticated keyboard control circuitry that can
    perform several functions the original IBM PC and PC/XT keyboard cannot.
    These features include programmable typematic control, programmable
    scan-code sets, and improved hardware for error detection.

    On the 83-key keyboard, the typematic delay and repeat rate are built into
    the hardware: A key must be pressed for 0.5 seconds before auto-repeat
    begins, and the repeat rate is about 10 characters per second. With the
    PC/AT and PS/2 keyboards, you can modify the typematic delay and rate by
    programming the keyboard controller. The most convenient way to do this is
    through the ROM BIOS keyboard services described in Chapter 11.

    The keyboard controller in the PC/AT and PS/2s can also assign any of
    three different sets of scan-code values to the keys on the 84- and
    101/102-key layouts. By default, however, the ROM BIOS establishes a
    scan-code set that is compatible with that used on the 83-key keyboard.
    You will probably find use for the alternative scan-code sets only if your
    program bypasses the ROM BIOS and processes scan codes directly. (See the
    PC/AT and PS/2 technical reference manuals for details.)

    The improved error-detection ability of the AT and PS/2 keyboard
    controllers is largely invisible to your programs; the keyboard hardware
    and the ROM BIOS service routines are very reliable. The most common
    errors you may encounter are a full ROM BIOS keyboard buffer or a key
    combination that the PS/2 ROM BIOS cannot process. In both situations, the
    ROM BIOS generates a warning beep to inform you that something unusual has
    occurred. (For example, try holding down both pairs of Ctrl and Alt keys
    on a PS/2 keyboard.)

Keystrokes and Scan Codes

    Each time you press or release one of the keys on the keyboard, the
    keyboard circuits transmit a sequence of one or more 8-bit numbers through
    the connector cable to the computer. This sequence, called a scan code,
    uniquely identifies the key you pressed. The keyboard produces different
    scan codes, depending on whether the key was pressed or released. Whenever
    you press a key, the scan-code byte contains a number ranging from 01H
    through 58H. When you release the key, the keyboard generates a scan code
    80H higher than the keystroke scan code by setting bit 7 of the scan-code
    byte to 1. For example, when you press the letter Z, the keyboard
    generates a scan code of 2CH; when you release it, the keyboard generates
    a scan code of ACH (2CH + 80H). The keyboard diagrams in Figures 6-1,
    6-2, and 6-3 show the standard keyboard keys and their associated scan
    codes.

    ┌────────────────────────────────────────────────────────────────────────┐
    │ Figure 6-1 can be found on p.128 of the printed version of the book.   │
    └────────────────────────────────────────────────────────────────────────┘

    Figure 6-1.  Scan codes for the 83-key keyboard (PC, PC/XT). Scan-code
    values are in hex.

    ┌────────────────────────────────────────────────────────────────────────┐
    │ Figure 6-2 can be found on p.128 of the printed version of the book.   │
    └────────────────────────────────────────────────────────────────────────┘

    Figure 6-2.  Scan codes for the 84-key keyboard (PC/AT). Scan-code values
    are in hex.

    ┌────────────────────────────────────────────────────────────────────────┐
    │ Figure 6-3 can be found on p.129 of the printed version of the book.   │
    └────────────────────────────────────────────────────────────────────────┘

    Figure 6-3.  Scan codes for the 101/102-key keyboard (PC/AT and PS/2).
    Scan-code values are in hex.

    If you compare the scan codes for the 83-, 84-, and 101/102-key keyboards,
    you'll see that a key generates the same scan code regardless of its
    location on the keyboard. For example, the Esc key has a scan code of 01H,
    whether it's next to the 1 key, next to the Num Lock key, or by itself in
    the upper-left corner. (The 101/102-key keyboard can actually generate
    different scan codes, but the start-up ROM BIOS suppresses this by
    configuring the keyboard to be compatible with the 83-key keyboard.)

    The 101/102-key layout contains duplicate shift and control keys that
    don't exist on the other keyboards. The 101/102-key keyboard distinguishes
    between duplicate keys by transmitting multiple-byte scan codes. For
    example, the two Alt shift keys have different scan codes: The left Alt
    key has a scan code of 38H, and the right Alt key has a 2-byte scan code,
    E0H 38H.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    The multiple-byte scan codes for shift and control keys can vary
    depending on whether one of the shift keys (Ctrl, Alt, Shift), Num Lock,
    or Caps Lock is pressed at the same time. See IBM's PS/2 technical
    reference manuals for details.
    ──────────────────────────────────────────────────────────────────────────

    The 101/102-key keyboard also assigns special scan codes to certain
    keystroke combinations. The Alt-Sys Req combination is intended to be the
    same as the Sys Req key on the 84-key layout, so the 101/102-key keyboard
    transmits the same scan code, 54H. Because the Print Screen key has the
    same function as the Shift-PrtSc combination in the other keyboard
    layouts, the 101/102-key keyboard transmits a Shift key scan code (E0H
    2AH) followed by the PrtSc scan code (E0H 37H). The Pause key's scan code,
    E1H 1DH 45H, resembles the scan-code sequence for the Ctrl-Num Lock
    combination, but when you press Ctrl-Pause (that is, Ctrl-Break), the
    keyboard transmits E0H 46H E0H C6H, which is derived from the scan code
    for the Scroll Lock (Break) key on the 83- and 84-key keyboards. Figure
    6-4 lists these keystroke combinations and their associated codes.

    101/102-key Keyboard     84-key Keyboard         Scan Code
    Keystroke Combination    Equivalent              Transmitted
    ──────────────────────────────────────────────────────────────────────────
    Alt-Sys Req              Sys Req                 54H
    Print Screen             Shift-Print Screen      E0H 2AH
                                                    E0H 37H
    Ctrl-Break               Ctrl-Break              E0H 46H E0H C6H
    ──────────────────────────────────────────────────────────────────────────

    Figure 6-4.  Scan codes for special keystroke combinations on the
    101/102-key keyboard.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    The "compact" keyboard available for the PS/2 Model 25 is really a
    101/102-key keyboard in disguise. The numeric keypad is mapped to a
    group of 14 keys on the main keyboard, and the Num Lock key is the shift
    state of the Scroll Lock key. However, keyboard scan codes and ROM BIOS
    processing are the same for the compact version as for the full-size
    101/102-key keyboard.
    ──────────────────────────────────────────────────────────────────────────

    Any program that processes keyboard scan codes must be aware of which
    machine it's running on and which keyboard is in use. Fortunately, few
    programs need to respond directly to keyboard scan codes──the ROM BIOS
    keyboard service routines translate scan codes into meaningful information
    that a program can use. The following sections describe this translation
    process more fully.

Communicating with the ROM BIOS

    The keyboard-controller circuitry on the computer's system board monitors
    the keyboard for input. The keyboard controller generates interrupt 09H
    each time it receives a byte of data from the keyboard. The ROM BIOS
    contains an interrupt 09H handler that reads the byte from the keyboard
    controller and processes it. (I/O port 60H contains the keyboard data
    byte.) The interrupt 09H handler translates scan codes into 2-byte values
    that are generally more useful to a program than the original scan codes.

    The low-order byte of each 2-byte keyboard value contains the ASCII value
    corresponding to each key pressed. The high-order byte usually contains
    the corresponding keyboard scan code.

    Special keys, such as the function keys and the numeric-keypad keys, have
    a 0 in the low-order byte, with the keyboard scan code in the high-order
    byte. (More about this later, on page 134.)

    The ROM BIOS routines place the translated byte-pairs in a queue, which is
    kept in low memory in location 0040:001EH. The byte-pairs are stored there
    until they are requested by a program, such as DOS or interpreted BASIC,
    that expects to read keyboard input.

Translating the Scan Codes

    The scan-code translation job is moderately complicated because the IBM
    keyboard recognizes two types of keys that change the meaning of a
    keystroke: shift keys and toggle keys.

    The shift keys

    Three keys──Ctrl, Shift, and Alt──are known as shift keys: They change the
    shift state, and thereby the meaning, of whatever key they are used with.
    For example, when you press Shift-C, you get a capital C; when you press
    Ctrl-C, you generate the "break" character. The ROM BIOS recognizes that
    all subsequent key actions will be influenced by that shift state as long
    as a shift key is pressed.

    The toggle keys

    In addition to the shift keys, two toggle keys also affect the keyboard's
    shift state: the Caps Lock key and the Num Lock key. When activated, Caps
    Lock reverses the shift state of the alphabet keys; it doesn't affect the
    other keys. When activated, the Num Lock key disables cursor-control
    functions on the numeric keypad. Toggle keys are activated with a single
    keystroke and remain active until released by a second keystroke.

    The shift-key and toggle-key status information is kept by the ROM BIOS in
    a low-memory location (0040:0017H), where you can use or change it. When
    you press a shift key or a toggle key, the ROM BIOS sets a specific bit in
    one of these two bytes. When the ROM BIOS receives the release scan code
    of a shift key, it switches the status bit back to its original shift
    state.

    Whenever the ROM BIOS receives a scan code for an ordinary keystroke, such
    as the letter z or a right arrow key, it first checks the shift state and
    then translates the key into the appropriate 2-byte code. (We'll discuss
    the status bytes in more detail on page 137.)

    The combination keys

    While the ROM BIOS routine is translating scan codes, it checks for Sys
    Req keystrokes and for certain shift-key combinations; specifically, it
    checks for the Ctrl-Alt-Del, Shift-PrtSc, Ctrl-Num Lock, and Ctrl-Break
    combinations. These five command-like key actions cause the ROM BIOS to
    perform a specific task immediately.

    Ctrl-Alt-Del causes the computer to reboot. Ctrl-Alt-Del is probably used
    more often than any other special key combination. It works dependably as
    long as the keyboard interrupt service is working. If the interrupt
    service is not working, turn the power off, wait a few seconds, then turn
    it on again; the power-on program resets all interrupt vectors and
    services.

    Shift-PrtSc (Print Screen on the 101/102-key keyboard) causes the ROM BIOS
    interrupt 09H handler to execute software interrupt 05H. The default
    interrupt 05H handler is also part of the ROM BIOS; it prints a "snapshot"
    of the current contents of the screen.

    Ctrl-Num Lock (Pause on the 101/102-key keyboard) suspends operation of a
    program until another keystroke occurs.

    Ctrl-Break causes the ROM BIOS to generate software interrupt 1BH and to
    set bit 7 of the byte at 0040:0071H to 1. The default DOS handler for
    interrupt 1BH simply sets a flag internal to DOS that causes DOS to
    interpret Ctrl-Break as Ctrl-C. You can override the default DOS action
    for Ctrl-Break by pointing the interrupt 1BH vector (located at
    0000:006CH) to your own interrupt handler.

    Sys Req (on the 84-key keyboard) and Alt-Sys Req (on the 101/102-key
    keyboard) cause the ROM BIOS to issue interrupt 15H with AH = 85H. Your
    program can provide its own interrupt 15H handler that intercepts and
    processes Sys Req keystrokes. (See Chapter 12 for details.)

    These are the only key combinations that are especially meaningful to the
    ROM BIOS. When an invalid combination is reported from the keyboard, the
    ROM BIOS simply ignores it and moves on to the next valid key action.

    Two more features of the PC keyboard should be presented before we discuss
    the details of keyboard coding: repeat key action and duplicate keys.

    Repeat key action

    The PC keyboard features automatic repeat key action, a process called
    typematic by IBM. The circuitry inside the keyboard monitors how long each
    key is pressed, and if a key is held down longer than a defined interval,
    the circuitry generates repeat key actions. This typematic action is
    reported as successive keystroke scan codes, without the intervening
    key-release codes. This makes it possible for an interrupt 09H handler to
    distinguish between actual keystrokes and typematic action. However, the
    ROM BIOS does not always distinguish between the two. The ROM BIOS
    keyboard-handling routine treats each automatic repeat key action as
    though the key were actually pressed and interprets the key accordingly.

    ──────────────────────────────────────────────────────────────────────────
    Keyboard-enhancer programs
    Thanks to the flexible software design of the PC, it's possible to
    create programs that customize the keyboard. Such programs are called
    keyboard-enhancer programs.

    Keyboard-enhancer programs monitor the scan codes that come in from the
    keyboard and respond to them in ways that aren't supported by the ROM
    BIOS or by DOS. Typically, these programs are fed instructions, called
    keyboard macros, that tell them what keystrokes to look for and what
    changes to make. The change might involve suppressing a keystroke
    (acting as if it never happened), replacing one keystroke with another,
    or replacing one keystroke with a long series of keystrokes. The most
    common use of keyboard macros is to abbreviate frequently used phrases;
    for example, you might instruct a keyboard enhancer to convert a key
    combination, such as Alt-S, into a salutation you use in your
    correspondence, such as Sincerely yours. You can also use keyboard
    macros to condense multiple-keystroke program commands to a single
    keystroke.

    Keyboard enhancers work by combining the powers of two special
    facilities──one that's part of DOS and one that's part of the PC's ROM
    BIOS. The DOS facility allows the enhancer program to remain resident in
    the computer's memory, quietly monitoring the operation of the computer
    while the ordinary control of the computer is turned over to a
    conventional program, such as a word processor. The ROM BIOS facility
    lets programs divert the stream of keyboard information so that it can
    be inspected and changed before it is passed on to a program. These
    programs use the DOS Terminate and Stay Resident facility to stay active
    in memory while other programs are run; then they use the ROM BIOS
    keyboard-monitoring facility to preview keyboard data and change it as
    needed.
    ──────────────────────────────────────────────────────────────────────────

    For example, if you press and hold the A key long enough for the keyboard
    to begin generating successive keystroke signals, then the ROM BIOS will
    create a series of As to be passed on to whatever program is reading
    keyboard data. On the other hand, when you press and hold a shift key, the
    ROM BIOS sets bits in its status bytes in segment 40H. While you hold the
    shift key down, the ROM BIOS continues to set the same bits to 1. When you
    release the key, the ROM BIOS resets the status bits. All this boils down
    to the simple fact that the ROM BIOS treats repeat key actions in a
    sensible way, acting on them or ignoring them as needed.

    Duplicate keys

    We've already described how the keyboard differentiates duplicate keys by
    assigning different scan codes to each. The ROM BIOS translates duplicate
    keys into the same ASCII character codes. For example, if you press either
    of the two asterisk keys, the ROM BIOS returns ASCII 2AH (the ASCII code
    for an asterisk); if you press either of the two Ctrl keys on a
    101/102-key keyboard, the ROM BIOS sets the appropriate bit in its
    shift-state byte.

    The ROM BIOS also lets programs tell the difference between duplicate
    keys, in some cases. Remember that the ROM BIOS translates each keystroke
    into a scan code as well as an ASCII code. A program that requests a
    keystroke from the ROM BIOS can inspect the scan code to determine which
    key was pressed. In the case of shift keys, a program can inspect the BIOS
    shift-state bytes at 0040:0017H and 0040:0018H to determine exactly which
    shift keys are pressed. (See the discussion of the shift-state bytes on
    pages 137 and 138.)

Entering ASCII Codes Directly

    We should mention that the PC keyboard, in conjunction with the ROM BIOS,
    provides an alternate way to enter nearly any ASCII character code. This
    is done by holding down the Alt key and then entering the decimal ASCII
    character code from the numeric keypad on the right side of the keyboard.
    This method lets you enter any ASCII code from 01H through FFH (decimal 1
    through 255).


Keyboard Data Format

    Once a keyboard action is translated, it is stored as a pair of bytes in
    the ROM BIOS buffer. We call the low-order byte the main byte and the
    high-order byte the auxiliary byte. The contents of these bytes will vary,
    depending on whether an ASCII key or a special key was pressed.

The ASCII Keys

    When the main byte is an ASCII character value from 01H to FFH, one of two
    events has occurred: One of the standard keyboard characters was pressed,
    or an ASCII character was entered directly using the Alt-number method
    mentioned above. (See Appendix C for the complete ASCII character set.)
    For these ASCII characters, the auxiliary byte contains the scan code of
    the pressed key. (The scan code is 0 for characters entered with
    Alt-number.) Usually you can ignore this scan code. DOS does not report
    keyboard scan codes, nor do high-level programming language functions like
    getch() in C or INKEY$ in BASIC. However, a program can examine the
    auxiliary byte (scan code) to differentiate among duplicate keyboard
    characters.

The Special Keys

    When the main byte is null (00H), it means that a special, non-ASCII key
    was pressed. The special keys include function keys, shifted function
    keys, cursor-control keys such as Home and End, and some of the Ctrl- and
    Alt-key combinations. When any of these keys are pressed by themselves or
    in combination with other keys, the auxiliary byte contains a single value
    that indicates which key was pressed. Figure 6-5 lists these values in a
    rough mixture of logical and numeric order. (For a complete breakdown of
    ROM BIOS key codes, see the IBM BIOS Interface Technical Reference
    Manual.)

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    With the 101/102-key keyboard, the main byte value for the gray
    cursor-control keys is E0H. This value distinguishes these keys from
    their counterparts on the numeric keypad, which have a main byte value
    of 00H.
    ──────────────────────────────────────────────────────────────────────────

╓┌─┌──────────────────┌─────────────────┌────────────────────────────────────╖
            Value
    (hex)              (dec)             Keys Pressed
    ──────────────────────────────────────────────────────────────────────────
    3BH                59                F1
    3CH                60                F2
    3DH                61                F3
    3EH                62                F4
    3FH                63                F5
    40H                64                F6
    41H                65                F7
    42H                66                F8
    43H                67                F9
    44H                68                F10
    85H                133               F11
    86H                134               F12

    54H                84                Shift-F1
    55H                85                Shift-F2
            Value
    (hex)              (dec)             Keys Pressed
    ──────────────────────────────────────────────────────────────────────────
    55H                85                Shift-F2
    56H                86                Shift-F3
    57H                87                Shift-F4
    58H                88                Shift-F5
    59H                89                Shift-F6
    5AH                90                Shift-F7
    5BH                91                Shift-F8
    5CH                92                Shift-F9
    5DH                93                Shift-F10
    87H                135               Shift-F11
    88H                136               Shift-F12

    5EH                94                Ctrl-F1
    5FH                95                Ctrl-F2
    60H                96                Ctrl-F3
    61H                97                Ctrl-F4
    62H                98                Ctrl-F5
    63H                99                Ctrl-F6
            Value
    (hex)              (dec)             Keys Pressed
    ──────────────────────────────────────────────────────────────────────────
    63H                99                Ctrl-F6
    64H                100               Ctrl-F7
    65H                101               Ctrl-F8
    66H                102               Ctrl-F9
    67H                103               Ctrl-F10
    89H                137               Ctrl-F11
    8AH                138               Ctrl-F12

    68H                104               Alt-F1
    69H                105               Alt-F2
    6AH                106               Alt-F3
    6BH                107               Alt-F4
    6CH                108               Alt-F5
    6DH                109               Alt-F6
    6EH                110               Alt-F7
    6FH                111               Alt-F8
    70H                112               Alt-F9
    71H                113               Alt-F10
            Value
    (hex)              (dec)             Keys Pressed
    ──────────────────────────────────────────────────────────────────────────
    71H                113               Alt-F10
    8BH                139               Alt-F11
    8CH                140               Alt-F12

    78H                120               Alt-1
    79H                121               Alt-2
    7AH                122               Alt-3
    7BH                123               Alt-4
    7CH                124               Alt-5
    7DH                125               Alt-6
    7EH                126               Alt-7
    7FH                127               Alt-8
    80H                128               Alt-9
    81H                129               Alt-0
    82H                130               Alt-Hyphen
    83H                131               Alt-=

    10H                16                Alt-Q
            Value
    (hex)              (dec)             Keys Pressed
    ──────────────────────────────────────────────────────────────────────────
    10H                16                Alt-Q
    11H                17                Alt-W
    12H                18                Alt-E
    13H                19                Alt-R
    14H                20                Alt-T
    15H                21                Alt-Y
    16H                22                Alt-U
    17H                23                Alt-I
    18H                24                Alt-O
    19H                25                Alt-P

    1EH                30                Alt-A
    1FH                31                Alt-S
    20H                32                Alt-D
    21H                33                Alt-F
    22H                34                Alt-G
    23H                35                Alt-H
    24H                36                Alt-J
            Value
    (hex)              (dec)             Keys Pressed
    ──────────────────────────────────────────────────────────────────────────
    24H                36                Alt-J
    25H                37                Alt-K
    26H                38                Alt-L

    2CH                44                Alt-Z
    2DH                45                Alt-X
    2EH                46                Alt-C
    2FH                47                Alt-V
    30H                48                Alt-B
    31H                49                Alt-N
    32H                50                Alt-M

    0FH                15                Shift-Tab

    47H                71                Home
    48H                72                Up arrow
    49H                73                PgUp

            Value
    (hex)              (dec)             Keys Pressed
    ──────────────────────────────────────────────────────────────────────────

    4BH                75                Left arrow

    4DH                77                Right arrow

    4FH                79                End

    50H                80                Down arrow
    51H                81                PgDn
    52H                82                Insert
    53H                83                Del

    72H                114               Ctrl-PrtSc
    73H                115               Ctrl-Left arrow
    74H                116               Ctrl-Right arrow
    75H                117               Ctrl-End
    76H                118               Ctrl-PgDn
    77H                119               Ctrl-Home
            Value
    (hex)              (dec)             Keys Pressed
    ──────────────────────────────────────────────────────────────────────────
    77H                119               Ctrl-Home

    84H                132               Ctrl-PgUp
    ──────────────────────────────────────────────────────────────────────────


    Figure 6-5.  ROM BIOS auxiliary byte values for the special keys.

    Codes generated by the ROM BIOS for the complete set of characters and
    special keys are handled differently in different programming languages.
    BASIC, for example, takes a mixed approach to the special keys. When you
    use ordinary input statements, BASIC returns the ASCII characters and
    filters out any special keys. Some of these keys can be acted on with the
    ON KEY statement, but you can use the BASIC INKEY$ function to get
    directly to the ROM BIOS coding for keyboard characters and find out
    immediately what special key was pressed. If the INKEY$ function returns a
    1-byte string, it is reporting an ordinary or extended ASCII keyboard
    character. If INKEY$ returns a 2-byte string, the first byte in the string
    is the ROM BIOS's main byte and will always be 00H; the second byte is the
    auxiliary byte and will indicate which special key was pressed.


ROM BIOS Keyboard Control

    The ROM BIOS stores keyboard status information in several portions of the
    ROM BIOS data area in segment 40H in low memory. Your programs can use
    some of the ROM BIOS status variables to check the keyboard status or to
    modify ROM BIOS keyboard processing.

    The two keyboard status bytes at locations 0040:0017H (shown in Figure
    6-6) and 0040:0018H (shown in Figure 6-7) are coded with individually
    meaningful bits that indicate which shift keys and toggle keys are active.
    All the standard models of the PC family have these two bytes, although
    the bits representing the Sys Req, left Alt, and left Ctrl keys are
    updated only for the keyboards that support these keys.

    The status byte at 0040:0017H is particularly useful because it
    establishes the state of ROM BIOS keystroke processing. Changes to this
    status byte affect the next keystroke that the ROM BIOS processes.

        Bit
    7 6 5 4 3 2 1 0          Meaning
    ──────────────────────────────────────────────────────────────────────────
    X . . . . . . .          Insert state: 1 = active; 0 = inactive
    . X . . . . . .          Caps Lock: 1 = active; 0 = inactive
    . . X . . . . .          Num Lock: 1 = active; 0 = inactive
    . . . X . . . .          Scroll Lock: 1 = active; 0 = inactive
    . . . . X . . .          1 = Alt pressed
    . . . . . X . .          1 = Ctrl pressed
    . . . . . . X .          1 = Left Shift pressed
    . . . . . . . X          1 = Right Shift pressed
    ──────────────────────────────────────────────────────────────────────────

    Figure 6-6.  The coding of the keyboard status byte at location
    0040:0017H. Bits 4─7 are toggles; their values change each time the key is
    pressed. Bits 0─3 are set only while the corresponding key i s pressed.

        Bit
    7 6 5 4 3 2 1 0          Meaning
    ──────────────────────────────────────────────────────────────────────────
    X . . . . . . .          1 = Ins pressed
    . X . . . . . .          1 = Caps Lock pressed
    . . X . . . . .          1 = Num Lock pressed
    . . . X . . . .          1 = Scroll Lock pressed
    . . . . X . . .          1 = Hold state active (Ctrl-Num Lock or Pause)
    . . . . . X . .          1 = Sys Req key pressed
    . . . . . . X .          1 = Left Alt key pressed
    . . . . . . . X          1 = Left Ctrl key pressed
    ──────────────────────────────────────────────────────────────────────────

    Figure 6-7.  The coding of the keyboard status byte at location
    0040:0018H. These bits are set only while the corresponding key is
    pressed.

The Insert State

    The ROM BIOS keeps track of the insert state in bit 7 of byte 0040:0017H.
    However, every program we know of ignores this bit and keeps its own
    record of the insert state. This means that you should not rely on this
    status bit to tell you anything about the current state of Insert key
    processing.

The Caps Lock State

    Some programmers force the Caps Lock state to be active by setting bit 6
    of byte 0040:0017H. This can confuse or irritate some program users, so we
    don't recommend it. However, this trick works reliably and precedent
    exists for using it. If you do you'll see that the ROM BIOS updates the
    LED indicator on the 84- and 101/102-key keyboards accordingly. This also
    occurs when you update the Num Lock or Scroll Lock states.

The Num Lock State

    Because the Num Lock key's location on the keyboard makes it susceptible
    to inadvertent keystrokes, some programmers force the Num Lock toggle (bit
    5 of byte 0040:0017H) to a predetermined state at the beginning of a
    program. For example, clearing the Num Lock status bit before requesting
    user input from the keypad forces keypad keystrokes to be processed as
    direction keys instead of numbers, even if the Num Lock key was pressed
    accidentally. This can be particularly helpful with the 83-key keyboard
    for the IBM PC and PC/XT because this keyboard has no status LEDs and
    provides no visual indication of the Num Lock state.

The Keyboard-Hold State

    The ROM BIOS establishes the keyboard-hold (pause) state when it detects a
    Ctrl-Num Lock or Pause keystroke. During keyboard hold, the ROM BIOS
    executes a do-nothing loop until a printable key is pressed; it doesn't
    return control of the computer to whatever program is running until this
    happens. This feature is used to suspend the operation of the computer.

    During keyboard hold, all hardware interrupts are handled normally. For
    example, if a disk drive generates an interrupt (signaling the completion
    of a disk operation), the disk interrupt handler receives the interrupt
    and processes it normally. But when the interrupt handler finishes
    working, it passes control back to whatever was happening when the
    interrupt took place──which is that endless do-nothing loop inside the ROM
    BIOS. So, during the keyboard hold, the computer can respond to external
    interrupts but programs are normally completely suspended. The keyboard
    BIOS continues to handle interrupts that signal key actions, and when it
    detects a normal keystroke (for example, the Spacebar or a function key,
    but not just a shift key), it ends the keyboard hold, finally returning
    control to whatever program was running.

    The keyboard-hold state is of no practical use in programming, except that
    it provides a standard way for users of our programs to suspend a
    program's operation.

    Be aware that the keyboard-hold state is not "bullet-proof." A program can
    continue working through the keyboard hold by acting on an external
    interrupt, such as the clock-tick interrupt. If a program really wanted to
    avoid being put on hold, it could set up an interrupt handler that would
    work through the hold state, or it could simply turn the hold state off
    whenever the hold state was turned on.

The Toggle-Key States

    Notice that bits 4 through 7 in the bytes at 0040:0017H and 0040:0018H
    refer to the same keys. In the first byte, the bits show the current state
    of the toggle keys; in the second byte, they show whether or not the
    corresponding toggle key is pressed.

    You can read the status of any of these bits to your heart's content, but
    few, if any, are likely to be useful in your programs. With the partial
    exception of controlling the Caps Lock state, we don't think it's wise to
    change any of the shift-state bits (bits 4 through 6 of byte 0040:0017H).
    And it is potentially very disruptive to change any of the key-is-pressed
    bits (bits 0 through 3 of byte 0040:0017H or any bits in byte 0040:0018H).


Comments

    If you want to gain a deeper understanding of the PC's keyboard operation,
    study the ROM BIOS program listing in the IBM technical reference manuals
    for the PC, PC/XT, or PC/AT. If you do this, be careful to avoid making a
    simple mistake that is common when anyone first studies the ROM BIOS,
    particularly the interrupts used by the ROM BIOS. The ROM BIOS provides
    two different interrupts for the keyboard: one that responds to keyboard
    hardware interrupts (interrupt 09H) and collects keyboard data into the
    low-memory buffer, and one that responds to a software interrupt
    requesting keyboard services (interrupt 16H, decimal 22) and passes data
    from the low-memory buffer to DOS and your programs. It is easy to confuse
    the operation of these two interrupts, and it is just as easy to further
    confuse them with the break-key interrupts, 1BH and 23H (decimal 27 and
    35). The table in Figure 6-8 lists the keyboard interrupts.

    Interrupt
    Hex   Dec          Origin of         Use
                        Interrupt
    ──────────────────────────────────────────────────────────────────────────
    09H    9           Keyboard          Signals keyboard action.

    16H   22           User program      Invokes standard BIOS keyboard
                                        services. (See Chapter 11.)

    1BH   27           ROM BIOS          Occurs when Ctrl-Break is pressed
                                        under BIOS control; a routine is
                                        invoked if you create it.

    23H   35           DOS               If you create it, an interrupt
                                        routine is invoked when a break-key
                                        combination is pressed under DOS
                                        control.
    ──────────────────────────────────────────────────────────────────────────

    Figure 6-8.  The interrupts related to keyboard action.

    A general theme running throughout this book advises you not to play fast
    and loose, but to play by the rules. This means, again, to write programs
    that are general to the IBM PC family rather than tied to the quirks of
    any one model, and to write programs that use portable means (such as DOS
    or ROM BIOS services) to manipulate data, instead of direct hardware
    programming. These rules apply to keyboard programming as much as they do
    to any other type of programming.



────────────────────────────────────────────────────────────────────────────
Chapter 7  Clocks, Timers, and Sound Generation

    Clocks and Timers
    The CPU Clock
    System Timers
    Using the System Timer Tick

    The Physics of Sound

    How the Computer Produces Sound
    Timer-Chip Sound Control
    Direct Speaker Control

    Speaker Volume and Sound Quality

    The Real-Time Clock
    Using the Date and Time
    Setting the Alarm

    Clocks and timers are the heartbeat of a computer. The computer's
    essential functions of computation and data transfer take place in step
    with the pulses generated by electronic clocks. PCs and PS/2s play host to
    several clocks and timers that you should know about:

    ■  The system timer generates "clock-ticks" and other timing pulses at
        precisely controlled intervals.

    ■  The sound generator produces tones through a speaker with a wide range
        of frequencies and durations.

    ■  The real-time clock/calendar keeps track of the date and time and can
        also serve as an "alarm clock." (This is supported only in the PC/AT
        and PS/2s.)

    To understand how to use the system timer, the sound generator, and the
    real-time clock, you need to know about the basic clock and timing
    mechanisms in PCs and PS/2s. That is what we'll outline in this chapter.


Clocks and Timers

    PCs and PS/2s have several clocks and timers that run at different rates
    and perform different functions. Some of them are intrinsic to the circuit
    design of these computers; their operation is independent of software
    control. Others are designed to support timing functions in software; the
    operation of these timers can be controlled by software through ROM BIOS
    services or by direct hardware programming.

The CPU Clock

    Probably the most basic of the timed events in a PC or PS/2 is the
    step-by-step operation of the computer's CPU, whose speed is determined by
    the frequency of a special oscillator circuit that generates
    high-frequency pulses at regular intervals. This frequency is the CPU's
    clock speed, and it determines how quickly the CPU can carry out its
    functions.

    The CPU oscillator keeps time for the CPU in much the same way a metronome
    keeps time for a musician. At each tick of the CPU clock (that is, at each
    pulse in the CPU oscillator's signal), the CPU carries out part of one
    machine instruction. All instructions require two or more clock cycles to
    complete. For example, the register INC instruction requires two clock
    cycles to execute; more complicated instructions like CALL and MUL take a
    longer amount of time.

    In IBM PCs and PC/XTs, the CPU's clock speed is 4,772,727 cycles per
    second, or about 4.77 megahertz. (A megahertz, or MHz, is one million
    cycles per second.) One CPU clock cycle thus lasts about 1/4,772,727 of a
    second, or about 210 nanoseconds (billionths of a second). With this clock
    frequency, a 2-cycle INC instruction executes in roughly 420 nanoseconds
    (0.42 microseconds or millionths of a second).

    The odd clock speed of 4.77 MHz was actually a convenient frequency for
    the designers of the original PC to use. In fact, the CPU clock frequency
    is derived from a basic oscillator frequency of 14.31818 MHz, which is
    commonly used in television circuitry. Dividing the basic frequency by 3
    gives the CPU clock frequency. Dividing by 4 gives a clock rate of 3.57955
    MHz, which is the frequency of the color burst signal used in color
    televisions and in the PC's Color Graphics Adapter. Dividing the basic
    frequency by 12 gives 1.19318 MHz, which is the clock frequency used by
    the PC's system timers.

    In later, faster members of the PC and PS/2 family, the CPU clock speed is
    higher, so the overall computational speed of these computers is greater.
    The 80286 and 80386 processors also execute many machine instructions in
    fewer clock cycles than the 8088 used in the PC and PC/XT. For example,
    the register PUSH instruction in the 8088 executes in 15 clock cycles; in
    the 80286 the same instruction takes 3 cycles; and in the 80386 only 2
    cycles. The combination of a higher CPU clock rate and faster machine
    instructions means that the 80286- and 80386-based members of the PC
    family execute programs significantly faster than do the 8088- and
    8086-based machines. (See Figure 7-1.)

                                                    Approximate Speed
                                        CPU Clock   Relative to
    Model                    CPU         Frequency   4.77 MHz IBM PC
    ──────────────────────────────────────────────────────────────────────────
    PC                       8088        4.77 MHz    1.0
    PC/XT                    8088        4.77 MHz    1.0
    PC/AT                    80286       6 MHz       3.4
                                        8 MHz       4.8
    PS/2 models 25 and 30    8086        8 MHz       2.5
    PS/2 models 50 and 60    80286       10 MHz      6.1
    PS/2 Model 80            80386       16 MHz      12.5
                                        20 MHz      15.5
    ──────────────────────────────────────────────────────────────────────────

    Figure 7-1.  CPU clock frequencies and relative computation speeds for PCs
    and PS/2s.

System Timers

    Apart from the operation of the CPU, other basic hardware and software
    functions occur at regular intervals based on a preset clock frequency.
    For example, the dynamic RAM chips that constitute the computer's main
    memory must be accessed at regular intervals to refresh the information
    represented in them. Also, ROM BIOS and operating system functions such as
    keeping track of the time of day require the computer to generate a
    "clock-tick" signal at a predetermined rate. All PCs and PS/2s have
    circuitry that generates the necessary timing signals.

    In the PC and PC/XT, an Intel 8253-5 programmable timer/counter chip
    produces the RAM refresh and timer-tick signals. In the PC/AT, an Intel
    8254-2 is used in the same way. The PS/2 models 25 and 30 use an 8253-5
    for the timer tick, but RAM refresh timing is a function of a custom
    integrated circuit. In the PS/2 models 50, 60, and 80, all timing
    functions are implemented in custom silicon. Despite these hardware
    variations, the timer programming interface is the same in all PCs and
    PS/2s.

    In the PC/XT/AT family, the timer chip has three output channels, each
    with a particular dedicated function:

    ■  Channel 0 is the system clock-tick timer. When the computer is cold
        booted, the ROM BIOS programs the timer to oscillate with a frequency
        of about 18.2 ticks per second. This signal is tied to the computer's
        interrupt controller in such a way that interrupt 08H is generated each
        time the clock ticks.

    ■  Channel 1 is always dedicated to producing the RAM refresh timing
        signal; it's not intended for use in software applications.

    ■  Channel 2 is used to control the computer's speaker: The frequency of
        the timer's channel 2 signal determines the frequency of the sound
        emitted by the loudspeaker. (We'll come back to this later.)

    PS/2 models 50, 60, and 80 also have a timer channel 3. The signal
    produced on channel 3 is tied to the computer's nonmaskable interrupt
    (interrupt 02H), and can be used by an operating system as a "watchdog" to
    ensure that some other critical function, such as servicing a clock-tick
    interrupt, does not crash the computer by taking too long to execute.

Using the System Timer Tick

    In all PCs and PS/2s, the input oscillator to the system timer circuit has
    a frequency of 1.19318 MHz. On each cycle, the timer chip decrements the
    values in a set of internal 16-bit counters, one for each of the timer's
    output channels. When the value in a counter reaches 0, the chip generates
    a single output pulse on the corresponding channel, resets the count, and
    starts counting down again.

    When the ROM BIOS initializes the system timer, it stores a countdown
    value of 0 in the count register for channel 0. This means that the timer
    chip decrements the counter 2^16 times between output pulses on channel 0,
    so output pulses occur 1,193,180/65,536, or about 18.2 times per second.
    The output from timer channel 0 is used as the signal on interrupt request
    level 0 (IRQ0), so interrupt 08H occurs whenever channel 0 of the system
    timer counts down to 0──that is, 18.2 times per second.

    The ROM BIOS contains an interrupt handler for interrupt 08H that
    increments a running count of clock ticks at 0040:006CH in the BIOS data
    area. This same interrupt handler also decrements the byte at 0040:0040H;
    if the value in the byte reaches 0, the interrupt handler issues a command
    to the diskette drive controller to turn off the diskette drive motor if
    it's on.

    The ROM BIOS interrupt 08H handler also issues software interrupt 1CH,
    which is intended for use in programs that want to be notified when a
    system timer tick occurs. A program can detect when each timer tick occurs
    simply by pointing the interrupt 1CH vector at 0000:0070H to its own
    interrupt handler. If you use an interrupt 1CH handler in a program,
    however, be aware that the ROM BIOS interrupt 08H handler does not allow
    subsequent clock-tick interrupts on IRQ0 to occur until your interrupt 1CH
    handler returns. If you install an interrupt 1CH handler, be certain that
    it doesn't keep IRQ0 disabled for too long or the system may crash.

    The system timer tick and its interrupt are useful in programs that must
    perform a simple task at a regular interval regardless of what else is
    going on in the computer. The timer-tick interrupt has the highest
    priority of any of the hardware interrupts (except the nonmaskable
    interrupt), so the code in the corresponding interrupt 08H and 1CH
    handlers takes precedence over all other system software.

    For this reason, the timer tick is used primarily in operating system
    software and in memory-resident "pop-up" programs like SideKick or the
    Norton Guides. Such programs have their own timer-tick interrupt handlers
    that check whether it is time to pop up on the screen. These programs
    generally rely on the system timer tick to occur at the default frequency
    of 18.2 ticks per second.

    Because timer-tick function is so essential to the proper operation of the
    computer, you should change the output frequency of system timer channel 0
    only if you are careful to preserve the functionality of the ROM BIOS
    interrupt 08H handler. For example, BASIC uses the timer tick to measure
    the duration of tones created with the PLAY or SOUND command. However,
    because the standard rate of 18.2 ticks per second is not fast enough to
    provide the precision that some kinds of music demand, BASIC reprograms
    the timer to tick four times faster, which causes interrupt 08H to occur
    72.8 times per second instead of 18.2 times per second. When BASIC counts
    against the quadruple rate, it is able to more accurately reproduce the
    proper tempo of a piece of music.

    BASIC can do this because it has a special interrupt 08H handler that
    calls the default interrupt 08H handler on every fourth timer tick. This
    ensures that the usual interrupt 08H functions still occur 18.2 times per
    second. If you reprogram system timer channel 0 to a nonstandard rate,
    your program should use the same technique of preserving interrupt 08H
    functionality.

    Programming system timer channel 2, the sound frequency generator, is not
    as demanding, because no ROM BIOS or operating system functions rely on
    it. Before we cover the programming details, however, we'll describe some
    of the basic mechanics of creating sounds with a computer.


The Physics of Sound

    Sounds are simply regular pulses or vibrations in air pressure. Sound is
    produced when air particles are set into motion by a vibrating source.
    When the vibrating source pushes out, it compresses the air particles
    around it. As it pulls in, the pressure release pulls the particles apart.
    A vibration composed of both the pressing and the pulling actions causes
    air particles to bump into each other. This motion begins a chain reaction
    that carries the vibration through the air away from the original source.
    Such a motion is called a sound wave.

    The speaker in the IBM PCs and PS/2s is made to vibrate by the electrical
    impulses sent to it by the computer. Because computers normally deal with
    binary numbers, the voltages they produce are either high or low. Every
    transition from one voltage state to another either pushes the speaker
    cone out or relaxes it. A sound is produced when the voltage to the
    speaker goes from low to high to low again, causing the speaker to move
    out and then in. This single vibration, consisting of a pulse out and a
    pulse in, is called a cycle. Through the speaker, a single cycle of sound
    is heard as a click. A continuous sound is produced when a continuous
    stream of pulses is sent to the speaker. As the pulse rate increases, so
    does the pitch of the tone. For example, if you pulse the speaker in and
    out 261.63 times a second (that is, at a rate of 261.63 hertz, or cycles
    per second), you hear the musical note known as middle C. Figure 7-2
    lists the frequencies required to generate other musical notes.

╓┌─┌───────┌───────────────┌──────┌───────────────┌───────┌───────────────┌──►
    Note    Frequency       Note   Frequency       Note    Frequency       Note
    ───────────────────────────────────────────────────────────────────────────
    C0      16.35           C2     65.41           C4      261.63          C6
    C#0     17.32           C#2    69.30           C#4     277.18          C#6
    D0      18.35           D2     73.42           D4      293.66          D6
    D#0     19.45           D#2    77.78           D#4     311.13          D#6
    E0      20.60           E2     82.41           E4      329.63          E6
    F0      21.83           F2     87.31           F4      349.23          F6
    F#0     23.12           F#2    92.50           F#4     369.99          F#6
    Note    Frequency       Note   Frequency       Note    Frequency       Note
    ───────────────────────────────────────────────────────────────────────────
    F#0     23.12           F#2    92.50           F#4     369.99          F#6
    G0      24.50           G2     98.00           G4      392.00          G6
    G#0     25.96           G#2    103.83          G#4     415.30          G#6
    A0      27.50           A2     110.00          A4      440.00          A6
    A#0     29.14           A#2    116.54          A#4     466.16          A#6
    B0      30.87           B2     123.47          B4      493.88          B6
    C1      32.70           C3     130.81          C5      523.25          C7
    C#1     34.65           C#3    138.59          C#5     554.37          C#7
    D1      36.71           D3     146.83          D5      587.33          D7
    D#1     38.89           D#3    155.56          D#5     622.25          D#7
    E1      41.20           E3     164.81          E5      659.26          E7
    F1      43.65           F3     174.61          F5      698.46          F7
    F#1     46.25           F#3    185.00          F#5     739.99          F#7
    G1      49.00           G3     196.00          G5      783.99          G7
    G#1     51.91           G#3    207.65          G#5     830.61          G#7
    A1      55.00           A3     220.00          A5      880.00          A7
    A#1     58.27           A#3    233.08          A#5     932.33          A#7
    B1      61.74           B3     246.94          B5      987.77          B7
                                                                            C8
    Note    Frequency       Note   Frequency       Note    Frequency       Note
    ───────────────────────────────────────────────────────────────────────────
                                                                            C8
    ───────────────────────────────────────────────────────────────────────────


    Note: Equal Tempered Chromatic Scale; A4 = 440
        American Standard pitch──adopted by the American Standards
        Association in 1936

    Figure 7-2.  Eight octaves of musical note frequencies.

    The average person can hear sounds ranging from roughly 20 to 20,000
    hertz. The IBM PC can generate sounds through its speaker at frequencies
    that could theoretically range from about 18 to more than a million hertz,
    far beyond the range of human hearing. To give this frequency range some
    perspective, compare it to an average human voice, which has a range of
    only 125 to 1000 hertz.

    The speaker that comes with the standard IBM personal computers has no
    volume control and is not really intended for accurate sound reproduction.
    As a result, different frequencies will produce different effects; some
    may sound louder than others and some may have a more accurate pitch. This
    variation is a by-product of the speaker design and is not something you
    can control.


How the Computer Produces Sound

    You can generate sounds through the speaker in two ways, using one or both
    of two different sound sources. One method is to write a program that
    turns the speaker on and off by manipulating two speaker bits in the I/O
    port that provides access to the speaker-control circuitry. When you use
    this method, your program controls the timing of the pulse and the
    resulting sound frequency. The other method is to use channel 2 of the
    system timer chip to pulse the speaker at a precise frequency. Using the
    timer chip is a more popular method for two reasons: Because speaker
    pulses are controlled by the timer chip instead of a program, the CPU can
    devote its time to the other demands of the computer system; and the timer
    chip is not dependent on the working speed of the CPU, which varies
    according to which PC or PS/2 model you use. The program method and timer
    method can be used together or separately to create many simple and
    complex sounds.

Timer-Chip Sound Control

    The programmable timer chip is the heart of the standard PC models'
    sound-making abilities. As we have seen, channel 2 of the timer chip is
    dedicated to sound generation. To create sounds, you must program channel
    2 properly and then use the pulses from channel 2 to drive the speaker.

    The timer can be programmed to produce pulses at whatever frequency you
    want, but because it does not keep track of how long the sound continues,
    the sound will continue forever unless it is turned off. Therefore, your
    programs must choose when to end a sound through some sort of timing
    instruction.

    Programming the timer chip

    To program timer channel 2, load the timer chip with an appropriate
    countdown value for the channel 2 counter. (The timer chip holds this
    value in an internal register so that it can reset the counter each time
    it reaches zero.) The countdown value takes effect immediately after you
    load it into the timer chip. The timer chip decrements the counter with
    each cycle of its 1.19318 MHz clock until the counter reaches zero, and
    then it sends an output pulse on channel 2 to the sound generator
    circuitry and starts counting down again.

    In effect, the timer "divides" the countdown value into the clock
    frequency to produce an output frequency. The result is that the timer
    sends out a series of pulses that produce a sound of a certain frequency
    when you turn on the speaker.

    The controlling count and the resulting frequency have a reciprocal
    relationship, as shown by these formulas:

    Count=1,193,180÷Frequency
    Frequency=1,193,180÷Count

    You can see that a low-frequency (low-pitched) sound is produced by a high
    count and that a high-frequency (high-pitched) sound is produced by a low
    count. A count of 100 would produce a high pitch of roughly 11,931 cycles
    per second, and a count of 10,000 would produce a low pitch of about 119
    cycles per second.

    You can produce just about any frequency, within the limitations of 16-bit
    arithmetic. The lowest frequency is 18.2 hertz with a divisor of 65,535
    (FFFFH), and the highest is 1.193 megahertz with a divisor of 1. BASIC
    holds this to a practical range of 37 through 32,767 hertz. The following
    program demonstrates that the actual frequency range of the internal
    speaker is even less than BASIC provides.

    Once you calculate the count that you need for the frequency you want, you
    send it to the timer channel 2 registers. This is done with three port
    outputs. The first port output notifies the timer that the count is coming
    by sending the value B6H (decimal 182) to port 43H (decimal 67). The next
    two outputs send the low- and high-order bytes of the count, a 16-bit
    unsigned word, to port 42H (decimal 66)──the low-order byte followed by
    the high-order byte. The BASIC program on the following page illustrates
    the process.

    10 COUNT = 1193280! / 3000      ' 3000 is the desired frequency
    20 LO.COUNT = COUNT MOD 256     ' calculate low-order byte value
    30 HI.COUNT = COUNT / 256       ' calculate high-order byte value
    40 OUT &H43, &HB6               ' get timer ready
    50 OUT &H42, LO.COUNT           ' load low-order byte
    60 OUT &H42, HI.COUNT           ' load high-order byte

    Activating the speaker

    After you have programmed the timer, you still need to activate the
    speaker circuitry in order to use the signal that the timer is generating.
    As with most other parts of the PC and PS/2, the speaker is manipulated by
    sending certain values to a specific port, a process illustrated in Figure
    7-3. The speaker is controlled by changing the values of bits 0 and 1 at
    I/O port 61H (decimal 97). Only 2 of the port's 8 bits are used by the
    speaker: the low-order bits numbered 0 and 1. The other 6 bits are used
    for other purposes, so it is important that you don't disturb them while
    working with the speaker.

            Get                               Send pulses
            timer        Port                 to
    ┌─────┐ ready        43H  ┌──────────────┐speaker┌───────────┐
    │     ├──────────────────►│              ├──────►│           │
    │     │ Load              │    8253-5    │       │           │
    │     │ frequency    Port │ Programmable │       │           │    ┌─────┐
    │     │ count        42H  │    timer     │       │           │  ┌─┘     │
    │ CPU ├──────────────────►│              │       │ Amplifier ├─►│Speaker│
    │     │                   └──────────────┘       │           │  └─┐     │
    │     │ Turn on                             Port │           │    └─────┘
    │     │ speaker                             61H  │           │
    │     ├─────────────────────────────────────────►│           │
    └─────┘                                          └───────────┘

    Figure 7-3.  How sound frequencies are generated through the system timer
    and speaker.

    The lowest bit, bit 0, controls transmission of the timer chip's output
    signal to the speaker. The second bit, bit 1, controls the pulsing of the
    speaker. Both bits must be set to make the speaker respond to the timer
    chip's signal. You can turn them on without disturbing the nonspeaker bits
    with an operation like this:

    70 OLD.PORT = INP (&H61)          ' read the value at port 61H
    80 NEW.PORT = (OLD.PORT OR &H03)  ' set bits 0 and 1
    90 OUT &H61, NEW.PORT             ' turn speaker on

Direct Speaker Control

    The timer controls the speaker by sending periodic signals that pulse the
    speaker in and out. You can do the same thing with a program that sends in
    or out signals directly to the speaker. Do this by setting bit 0 of port
    61H (decimal 97) to 0 to turn the speaker off and then alternately setting
    bit 1 on and off to pulse the speaker. When you use this method, the speed
    of the program determines the frequency of the sound; the faster the
    program executes, the higher the pitch. The following BASIC program is an
    example of this method:

    10 X = INP (&H61) AND &HFC   ' read port value, turn off bits 1 and 0
    20 OUT &H61, X               ' pull speaker in
    30 OUT &H61, X OR 2          ' push speaker out
    40 GOTO 20

    The actions in lines 20 and 30 pulse the speaker in and out. Each one is a
    half-cycle, and the two together produce one complete sound cycle.

    This example runs as fast as BASIC can process it, producing as high a
    note as possible. If you needed more range in your application, you could
    use a faster language and insert deliberate delays equal to half the
    frequency cycle time between each complete cycle (half the cycle time,
    because each ON or OFF operation is a half-cycle). No matter what language
    you use, you must include a duration count to end the sound. To produce
    different sounds at a particular frequency, such as clicking or buzzing
    sounds, just vary the delays between pulses.

    Despite all these wonderful possibilities, generating sounds through the
    speaker by direct program action is not a good way to make sounds. It has
    three big disadvantages compared to the use of the timer:

    ■  A program requires the constant attention of the CPU, so the computer
        has a hard time getting any other work done.

    ■  The frequency is at the mercy of the speed of the computer; that is,
        the same program would make a lower or higher sound on a slower or
        faster model.

    ■  The clock-tick interrupts interfere with the smoothness of the sound,
        making a warble. The only way to avoid this is to suspend the clock
        tick by disabling the interrupts──and that disrupts the computer's
        sense of time.

    As far as we know, there is only one advantage to making sounds using the
    direct method: With the proper control over the program delays, the direct
    method lets you make a low-fidelity polyphonic sound. Be forewarned,
    though, that this requires some very clever and tedious programming and,
    all in all, may not be worth the trouble.


Speaker Volume and Sound Quality

    The computer's internal speaker has no volume control of any kind and,
    like all speakers, varies in how well it responds to different
    frequencies; some frequencies may sound louder than others. In the case of
    a crude speaker like that found in most PCs and PS/2s, the loudness of the
    sound varies widely with the frequency. You can use the following program
    to test this──it may help you choose the best sound pitch for your
    purpose:

    10 PLAY "MF"                            ' plays each sound separately
    20 FREQUENCY = 37
    30 WHILE FREQUENCY < 32000              ' use all frequencies to
                                            32000 Hz
    40   PRINT USING "##,###"; FREQUENCY    ' display frequency
    50   SOUND FREQUENCY, 5                 ' produce sound with
                                            duration of 5
    60   FREQUENCY = FREQUENCY * 1.1        ' increment frequency by 1/10
    70 WEND

    Be aware that the speakers in the various PC and PS/2 models may not sound
    alike, partly because the materials of each system housing resonate
    differently as speaker enclosures. Try the following samples on two
    different models and be prepared for these variations in sound:

    100 'sound samples
    110 '
    120 'warble (two rapidly alternating tones)
    130 FOR N% = 0 TO 5
    140  SOUND 440, .7
    150  SOUND 466.16, .5
    160 NEXT
    170 WHILE(INKEY$="") : WEND     ' wait for a keystroke
    180 '
    190 'two tones played quickly
    200 SOUND 900, .1
    210 SOUND 760, 1
    220 WHILE(INKEY$="") : WEND
    230 '
    240 'random noise
    250 X = INP(&H61) AND &HFC
    260 I=20                        ' changing I changes the noise
    270 FOR N% = 0 TO 500
    280  IF (RND * 100 < I) THEN OUT &H61,X OR 2 : OUT &H61,X
    290 NEXT


The Real-Time Clock

    The PC/AT and the PS/2s all have a real-time clock that keeps track of
    the current date and time. In the PC/AT, the real-time clock is part of
    the Motorola MC146818 chip that supports the PC/AT's nonvolatile CMOS RAM.
    In the PS/2s, the real-time clock is in custom silicon. In all these
    machines, the real-time clock runs off a battery so that the time and date
    are maintained even while the computer is turned off.

Using the Date and Time

    When you boot a PC/AT or PS/2, the ROM BIOS start-up routines read the
    time of day from the real-time clock and convert it into the corresponding
    number of timer ticks. This value is used to initialize the 4-byte count
    stored at 0040:006CH in the ROM BIOS data area. All versions of DOS use
    this count value to determine the current time of day. Starting in version
    3.0, DOS also obtains the current date from the real-time clock and
    initializes its own internal record of the date at boot-up time.

    To work with the current date and time in a program, we recommend that you
    use the DOS date and time services (Chapter 16) to get and set the
    current values. You could also use ROM BIOS services to access the
    real-time clock (Chapter 10). However, if you call the ROM BIOS to change
    the date or time, DOS may not be aware of the change and may assume an
    incorrect time or date.

Setting the Alarm

    The real-time clock's alarm feature generates an interrupt at a specific
    time. To take advantage of this feature, you must create an interrupt
    handler that performs an action when the alarm interrupt occurs. You can
    even make this action independent of other programs by leaving the
    interrupt handler resident in memory with a DOS
    Terminate-and-Stay-Resident service. (See Chapters 16 and 17.)

    The ROM BIOS provides a set of services through interrupt 1AH that give
    you access to the real-time clock's alarm feature. See Chapter 12 for
    more details.



────────────────────────────────────────────────────────────────────────────
Chapter 8  ROM BIOS Basics

    The ROM BIOS Philosophy

    The ROM BIOS Service Interrupts

    ROM BIOS Service Operating Characteristics

    Creating an Assembly-Language Interface
    The Basic Form of an Interface Routine

    Advanced BIOS Interface

    One secret of successful programming for the PC family lies in the
    effective use of the software that is built right into the machine: the
    ROM BIOS services. Conceptually, the ROM BIOS services are sandwiched
    between the hardware and the high-level languages (including the operating
    system). They work directly with the computer's hardware and peripheral
    devices, performing some of the system's most fundamental tasks, such as
    reading and writing individual bytes of data to the display screen or
    disk. DOS services and programming-language services are often built from
    these basic functions and enhanced to make a particular process more
    efficient. You can enhance your programs in the same way by plugging them
    directly into the ROM BIOS, thereby gaining access to an extremely
    powerful set of tools and using your computers in the way that IBM
    intended them to be used.

    That last point is worth emphasizing. IBM has gone to considerable lengths
    to create a clean and well-defined method for directing the operation of
    the computer through the ROM BIOS services. As each new PC model is
    designed, IBM (and any other computer maker who is faithfully extending
    the PC family) makes sure its ROM BIOS services are thoroughly compatible
    with those of the other members of the family. As long as you control your
    computers through the ROM BIOS, whether directly or indirectly, you are
    safe from any compatibility problems. If you bypass the ROM BIOS and
    program directly to the hardware, you are not only asking for trouble, but
    you are also severely limiting the range and viability of your programs.

    That's not to say that you should always use ROM BIOS services when
    they're available. The input/output functions provided in DOS and in
    high-level programming languages often provide the same services as the
    ROM BIOS, but in a form that is easier to use within your programs.
    However, when a program needs more direct access to the computer's
    input/output devices than DOS or your programming language can provide,
    the ROM BIOS services are usually the answer.

    The next five chapters discuss the ROM BIOS service routines. Fortunately,
    the routines fall naturally into groups derived from the hardware devices
    they support, so the video services, disk services, and keyboard services
    can all be reviewed separately. But before you take a closer look at the
    individual services, you need to find out how to incorporate them into
    your programs. This chapter sets the stage by explaining what goes into
    writing an interface routine, the bridge between programming languages and
    the ROM BIOS services. First, a word on how the ROM BIOS operates.


The ROM BIOS Philosophy

    All ROM BIOS services are invoked by interrupts. Each interrupt
    instruction selects a particular entry in the interrupt vector table in
    low memory. The addresses of all ROM BIOS service routines are stored in
    this table. This design makes it possible for any program to request a
    service without knowing the specific memory location of the ROM BIOS
    service routine. It also allows the services to be moved around, expanded,
    or adapted without affecting the programs that use the services. Although
    IBM has tried to maintain the absolute memory location of some parts of
    the ROM BIOS, it would be foolish to use these addresses because they may
    change in the future. The standard, preferred, and most reliable way to
    invoke a ROM BIOS service is to use its interrupt rather than its absolute
    address.

    The ROM BIOS services could be supervised by one master interrupt, but
    instead they are divided into subject categories, each with its own
    controlling interrupt. This design lets each interrupt handler be easily
    replaced. For example, if a hardware manufacturer created a radically
    different video display that operated under a completely new ROM BIOS
    program, the manufacturer could provide the new ROM BIOS program along
    with the hardware. The new ROM BIOS program might be stored in RAM, and it
    would replace the one part of IBM's ROM BIOS that was used with the old
    hardware. By making the ROM BIOS modular, IBM has made it easier to
    improve and extend the capabilities of its computers.


The ROM BIOS Service Interrupts

    The twelve ROM BIOS interrupts fall into five groups (Figure 8-1):

    ■  Six interrupts serve specific peripheral devices.

    ■  Two interrupts report on the computer's equipment.

    ■  One interrupt works with the time/date clock.

    ■  One interrupt performs the print-screen operation.

    ■  Two interrupts place the computer into another state altogether,
        activating ROM BASIC and the system start-up routine.

    As you'll see, most of the interrupts are tied to a group of subservices
    that actually do the work. For example, the video service interrupt 10H
    (decimal 16) has 25 subservices that do everything from setting the video
    mode to changing the size of the cursor. You call a subservice by invoking
    its governing interrupt and specifying the subservice number in register
    AH. This process is explained in the example at the end of this chapter.

╓┌─┌──────────────────┌──────────────────────────────────────────────────────╖
    Interrupt
    Hex   Dec          Use
    ──────────────────────────────────────────────────────────────────────────
    Peripheral Devices Services
    10H   16           Video-display services (see Chapter 9)
    13H   19           Diskette services (see Chapter 10)
    Interrupt
    Hex   Dec          Use
    ──────────────────────────────────────────────────────────────────────────
    13H   19           Diskette services (see Chapter 10)
    14H   20           Communications services (see Chapter 12)
    15H   21           System services (see Chapter 12)
    16H   22           Standard keyboard services (see Chapter 11)
    17H   23           Printer services (see Chapter 12)

    Equipment Status Services
    11H   17           Equipment-list service (see Chapter 12)
    12H   18           Memory-size service (see Chapter 12)

    Time/Date Service
    1AH   26           Time and date services (see Chapter 12)

    Print-Screen Service
    5H   5             Print-screen service (see Chapter 12)

    Special Services
    18H   24           Activate ROM BASIC (see Chapter 12)
    Interrupt
    Hex   Dec          Use
    ──────────────────────────────────────────────────────────────────────────
    18H   24           Activate ROM BASIC (see Chapter 12)
    19H   25           Activate bootstrap start-up routine (see Chapter 12)
    ──────────────────────────────────────────────────────────────────────────


    Figure 8-1.  The 12 ROM BIOS services.


ROM BIOS Service Operating Characteristics

    The ROM BIOS services use some common calling conventions that provide
    consistency in the use of registers, flags, the stack, and memory. We'll
    outline the characteristics of these operating conventions, beginning with
    the segment registers.

    The code segment register (CS) is automatically reserved, loaded, and
    restored as part of the interrupt process. Consequently, you don't have to
    worry about your program's CS. The DS and ES registers are preserved by
    the ROM BIOS service routines, except in the few cases where they are
    explicitly used. The stack segment register (SS) is left unchanged, and
    the ROM BIOS services depend on you to provide a working stack.
    (Everything depends on a working stack!)

    The stack requirements of the ROM BIOS services are not spelled out and
    can vary considerably, particularly because some services invoke other
    services. Generally, however, most programs ought to be working with a
    much larger stack than the ROM BIOS services need.

    The ROM BIOS varies in its usage of the other 8086 registers. The
    instruction pointer (IP) is preserved by the same mechanism that preserves
    the code segment. In effect, the stack pointer (SP) is preserved because
    all the ROM BIOS services leave the stack clean, popping off anything that
    was pushed on during the service-routine execution.

    As usual, the general-purpose registers, AX through DX, are considered
    fair game. The standard rule is not to expect any contents of these
    registers to be maintained when you pass control to another routine, and
    that applies to the ROM BIOS services as well. If you closely inspect the
    coding of the services in the IBM technical reference manuals, you will
    find that one or more registers are left undisturbed in one service or
    another, but you would be foolish to try to take advantage of this. As a
    general rule, when a simple result is returned from a subroutine, it is
    left in the AX register; this applies to both the ROM BIOS and to all
    programming languages. We'll see how often this really happens when we
    cover the ROM BIOS services in detail.

    The index registers (SI and DI) can be changed, exactly like the AX
    through DX registers. The stack frame register (BP) can also be changed by
    a few ROM BIOS service routines.

    The various flags in the flag register are routinely changed as a
    by-product of the instruction steps in the ROM BIOS routines. You should
    not expect any of them to be preserved. In a few instances, the carry flag
    (CF) or the zero flag (ZF) is used to signal the overall success or
    failure of a requested operation.

    These details are important but rather tedious, and there is little reason
    for you to pay much attention to them. If your programs follow the general
    interface rules given in the next section, and if they follow the specific
    requirements of your programming language (covered in Chapters 19 and
    20), you may not need to be concerned with them at all.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    If you set out to use the ROM BIOS services in your programs, you'll
    naturally be concerned about the possible conflicts between the services
    and the operating conventions that your language follows. Put your mind
    at ease. You will find that you do not have to take any extraordinary
    precautions to protect your programming language from the ROM BIOS, or
    vice versa.
    ──────────────────────────────────────────────────────────────────────────


Creating an Assembly-Language Interface

    In order to make direct use of the ROM BIOS services from your programs,
    you generally need to create an assembly-language interface routine to
    link the programming language to the ROM BIOS. When we say "interface
    routine," we are referring to the conventional program-development
    subroutines──subroutines that are assembled into object modules (.OBJ
    files) and then linked into working programs (.EXE or .COM files in DOS).
    For more on this subject, see Chapter 19.

    Working with assembly language can seem a fearsome task if you are not
    already comfortable with it. While there are plenty of good reasons to be
    intimidated by assembly language──after all, it is the most difficult and
    demanding kind of programming──it's really not that difficult to create an
    assembly-language interface routine.

    ──────────────────────────────────────────────────────────────────────────
    ROM BIOS Interrupt Conflicts
    In the hardware specification for the 8086 family of microprocessors,
    Intel reserved interrupt numbers 00H through 1FH for use by the
    microprocessor itself. (See Figure 8-2.) Unfortunately, IBM had
    appropriated several of these reserved interrupt numbers for its own use
    in the design of the IBM PC. This wasn't a problem with the PC and
    PC/XT, which used the Intel 8088, because the 8088 predefined only
    interrupts 00H through 04H.

    When the PC/AT appeared, however, IBM's use of Intel's reserved
    interrupt numbers led to a conflict. The reason: The AT's 80286 chip
    predefines some of the same interrupt numbers that IBM's ROM BIOS uses.
    The conflict appears when you use the 80286 BOUND instruction to
    validate an array index, because the 80286 signals an out-of-bounds
    array index by executing interrupt 05H──which IBM had previously
    assigned to the ROM BIOS print-screen function. If you aren't careful, a
    program that executes the BOUND instruction can unexpectedly print the
    screen.

    To resolve the conflict, you must install an interrupt 05H handler that
    inspects the code that caused the interrupt: This handler can determine
    whether the interrupt was executed in software or by the CPU. You can
    also avoid this problem by using a protected-mode operating system like
    OS/2, which bypasses the ROM BIOS. If you use DOS, however, be aware
    that a programming error can occasionally lead to unexpected execution
    of a ROM BIOS routine.
    ──────────────────────────────────────────────────────────────────────────

    Interrupt     CPU                          Function
    ────────────────────────────────────────────────────────────────────────
    00H           8088,8086,80286,80386        Divide error
    01H           8088,8086,80286,80386        Single-step
    02H           8088,8086,80286,80386        NMI (nonmaskable interrupt)
    03H           8088,8086,80286,80386        Breakpoint (INT 3)
    04H           8088,8086,80286,80386        Overflow (INTO)
    05H           80286,80386                  BOUND out of range
    06H           80286,80386                  Invalid opcode
    07H           80286,80386                  Coprocessor not available
    08H           80286,80386                  Double exception (double
                                                fault)
    09H           80286,80386                  Coprocessor segment overrun
    0AH           80386                        Invalid task-state segment
    0BH           80386                        Segment not present
    0CH           80386                        Stack fault
    0DH           80286,80386                  General protection exception
    0EH           80386                        Page fault
    10H           80286,80386                  Coprocessor error
    ────────────────────────────────────────────────────────────────────────

    Figure 8-2.  Predefined hardware interrupts in Intel microprocessors.

    To create your own interfaces, you will need to have an assembler that is
    compatible with the DOS standards for object files. All the examples we
    give here are for the Microsoft Macro Assembler.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Interpreted BASIC can work with machine-language subroutines put
    directly into memory. Preparing the sort of assembler subroutine that
    will work with BASIC can be done as easily with DEBUG's A (assemble)
    command as it can with an ordinary assembler. See Chapter 20 for more
    on this subject.
    ──────────────────────────────────────────────────────────────────────────

The Basic Form of an Interface Routine

    An interface routine's form varies with its intended use. An
    assembly-language interface is a handshaker between your programming
    language and a ROM BIOS service, so it has to be tailored to meet the
    needs of both ends. It matters which programming language is being used;
    it matters which ROM BIOS service is being invoked; and it matters whether
    any data is being passed in one direction or the other. However, the
    general outline of an assembly-language interface is basically the same,
    no matter what you are doing.

    One of the best ways to understand how an assembly-language interface is
    coded is to view it as five nested parts, which are outlined here:

    Level 1: General assembler overhead
        Level 2: Subroutine assembler overhead
        Level 3: Entry code
            Level 4: Get parameter data from caller
            Level 5: Invoke ROM BIOS service
            Level 4: Pass back results to caller
        Level 3: Exit code
        Level 2: Finish subroutine assembler overhead
    Level 1: Finish general assembler overhead

    In this outline, Levels 1 and 2 tell the assembler what's going on, but
    don't produce any working instructions. Levels 3 through 5 produce the
    actual machine-language instructions.

    We'll examine each of these levels to show you the rules and explain
    what's going on. Don't forget that the specific requirements of an
    interface routine change for different circumstances. We'll point out the
    few design elements that are universal to all routines.

    Here is a simple ROM BIOS interface routine. It's designed to be called
    from a C program, but the elements of the interface design are the same
    whether you use this routine as is or adapt it to another programming
    language.

    _TEXT               SEGMENT      byte public 'CODE'
                        ASSUME       cs:_TEXT

                        PUBLIC       _GetMemSize
    _GetMemSize         PROC         near

                        push         bp
                        mov          bp,sp

                        int          12H
                        pop          bp
                        ret

    _GetMemSize         ENDP

    _TEXT               ENDS

                        END

    In the next few pages we'll examine the construction of this routine.

    Level 1: General assembler overhead

    Here is an outline of a typical Level-1 section of an interface routine,
    with the lines numbered for reference:

    1-1  _TEXT        SEGMENT    byte public 'CODE'
    1-2               ASSUME     cs:_TEXT

    (Levels 2 through 5 appear here)

    1-3  _TEXT        ENDS
    1-4               END

    Line 1-1 is a SEGMENT directive that declares the name of a logical
    grouping of executable machine instructions and informs the assembler (and
    any person who reads the source code) that what follows consists of
    executable code. Line 1-2, the ASSUME directive, tells the assembler to
    associate the CS register with any address labels in the _TEXT segment.
    This makes sense because the CS register is used by the 8086 to address
    executable code.

    Line 1-3 ends the segment started in line 1-1, and line 1-4 marks the end
    of the source code for this routine.

    The names _TEXT and CODE conform to the conventions used by virtually all
    C language compilers for PCs and PS/2s, as do the BYTE and PUBLIC
    attributes. Alternative names and attributes are available to advanced
    programmers, but for now we'll stick with the simplest.

    Level 2: Subroutine assembler overhead

    Next, let's look at an outline of a typical Level 2, the assembler
    overhead for a subroutine (called a procedure in assembler parlance). The
    sample on the following page shows some typical Level-2 coding.

    2-1                  PUBLIC   _GetMemSize
    2-2  _GetMemSize     PROC     near

    (Levels 3 through 5 appear here)

    2-3  _GetMemSize     ENDP

    Line 2-1 instructs the assembler to make the name of the procedure,
    _GetMemSize, public information, which means that the link program can
    then connect it to other routines that refer to it by name.

    Lines 2-2 and 2-3 bracket the procedure, named _GetMemSize. PROC and ENDP
    are mandatory and surround any procedure, with PROC defining the beginning
    of the procedure and ENDP signaling the end of it. Again, the near
    attribute on the PROC statement follows the conventions established for
    linking assembly-language routines to C programs. In more advanced C
    programs and in routines linked with programs written in languages like
    FORTRAN and BASIC, you must sometimes use a different attribute, far.
    (More about this in Chapter 20.)

    Level 3: Entry and exit code

    Levels 3, 4, and 5 contain actual executable instructions. In Level 3, the
    assembly-language routine handles the housekeeping overhead required if a
    subroutine is to work cooperatively with the calling program. The key to
    this cooperation is the stack.

    When the calling program transfers control to the subroutine, it does so
    by means of a CALL instruction. (In this example, the instruction would be
    CALL _GetMemSize.) When this instruction executes, the 8086 pushes a
    return address──the address of the instruction following the CALL──onto
    the stack. Later, the assembly-language routine can return control to the
    calling program by executing a RET instruction, which pops the return
    address off the stack and transfers control to the instruction at that
    address.

    If any parameters are to be passed to the assembly-language routine, the
    calling program pushes them onto the stack before it executes the CALL
    instruction. Thus, when the routine gets control, the value on top of the
    stack is the return address, and any parameters are found on the stack
    below the return address. If you keep in mind that the stack grows from
    higher to lower addresses and that each value on the stack is 2 bytes in
    size, you end up with the situation depicted in Figure 8-3.

    To access the parameters on the stack, most compilers and
    assembly-language programmers copy the value in SP into register BP. In
    this way the values on the stack can be accessed even within a routine
    that changes SP by pushing parameters or calling a subroutine. The
    conventional way of doing this is shown by the code on the next page.

    3-1        push       bp         ; preserve the current contents of BP
    3-2        mov        bp,sp      ; copy SP to BP

    (Levels 4 and 5 appear here)

    3-3        pop        bp
    3-4        ret

    After lines 3-1 and 3-2 have executed, the stack is addressable as in
    Figure 8-4. (In a moment, we'll show how useful this is.) When it's time
    to return control to the calling program, the routine restores the
    caller's BP register value (line 3-3) and then executes a RET instruction
    (line 3-4).

                    Bottom of stack
                            
                    │       │        │
                    │       │        │
    Higher addresses ├────────────────┤
                    │   Parameter    │
                    ├────────────────┤◄──── SP + 4
                    │   Parameter    │
                    ├────────────────┤◄──── SP + 2
                    │ Return address │
    Lower addresses └────────────────┘◄──── SP

    Figure 8-3.  The stack at the time a subroutine is called.

    Bottom of stack
            
    │       │        │
    │       │        │
    ├────────────────┤
    │   Parameter    │
    ├────────────────┤◄──── BP + 6
    │   Parameter    │
    ├────────────────┤◄──── BP + 4
    │ Return address │
    ├────────────────┤◄──── BP + 2
    │  Caller's BP   │
    └────────────────┘◄──── BP

    Figure 8-4.  The stack after register BP is initialized.

    If you think about it, you'll realize that things could be more
    complicated. For example, a calling program might use either a near or a
    far CALL instruction to transfer control to a subroutine. If your program
    uses far subroutine calls by convention (instead of the near calls used by
    default in C), the PROC directive (Line 2-2) would require the far
    attribute instead of near. This would instruct the assembler to generate a
    far RET instruction instead of a near RET.

    Furthermore, with a far calling convention, the return address on the
    stack would be 4 bytes in size instead of 2 bytes, so the first parameter
    would be at address [BP + 6] instead of [BP + 4] as shown in Figure 8-4.
    In this book, however, we'll stick to the most straightforward case: near
    PROCs and 2-byte return addresses.

    Level 4: Get parameter data from caller

    Level 4 deals with the parameters by passing them from the caller to the
    ROM BIOS, and with the results by passing them from the ROM BIOS to
    the caller. (Note, however, that the sample program contains no parameters
    from the caller.) The caller's parameters are on the stack, either in the
    form of data or addresses. (See Chapter 20 for help with this.) The
    registers, mostly AX through DX, are used for ROM BIOS input and output.
    The trick here──and it can be tricky──is to use the correct stack offsets
    to find the parameters. We'll sneak up on this problem in stages.

    First, you get to the parameters on the stack by addressing relative to
    the address stored in BP in lines 3-1 and 3-2. (Refer to Figure 8-2 to
    determine how items on the stack relate to the value in BP.) When more
    than one parameter is present on the stack, you must decide which
    parameter is which. Most languages push their parameters onto the stack in
    the order they are written. This means that the last parameter is the one
    closest to the top of the stack, at [BP + 4]. However, C uses the reverse
    order, so that the parameter at [BP + 4] is the first one written in the
    calling program.

    Parameters normally take up 2 or 4 bytes on the stack, although 2 bytes is
    more common. If any of these parameters were 4 bytes in size, you would
    need to adjust the subsequent references accordingly.

    If data were placed on the stack, then you could get it immediately by
    addressing it like this: [BP + 4]. If an address were placed on the stack,
    two steps would be needed: First, you would get the address, and second,
    you would use the address to get the data. A Level-4 example showing both
    data ([BP + 4]) and address ([BP + 6]) retrieval follows on the next page.

    4-1        mov     ax,[bp+4]       ; value of parameter1
    4-2        mov     bx,[bp+6]       ; address of parameter2
    4-3        mov     dx,[bx]         ; value of parameter2

    (Level 5 appears here)

    4-4        mov    bx,[bp+6]        ; address of parameter2 (again)
    4-5        mov    [bx],dx          ; store new value at parameter2 address

    All of these MOV instructions move data from the second operand to the
    first operand. Line 4-1 grabs data right off the stack and slaps it into
    the AX register. Lines 4-2 and 4-3 get data by means of an address on the
    stack: Line 4-2 gets the address (parking it in BX), and then line 4-3
    uses that address to get to the actual data, which is moved into DX. Lines
    4-4 and 4-5 reverse this process: Line 4-4 gets the address again, and
    then line 4-5 moves the contents of DX into that memory location.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    A crucial bit of assembler notation is demonstrated here: BX refers to
    what's in BX, and [BX] refers to a memory location whose address is in
    BX. A reference like [BP + 6] indicates a memory location 6 bytes past
    the address stored in register BP.
    ──────────────────────────────────────────────────────────────────────────

    While sorting out these references may not be a snap, if you think it
    through carefully, it works out right.

    Level 5: Invoke ROM BIOS service

    Level 5 is our final step: It simply invokes the ROM BIOS service.

    Once all registers contain appropriate values (usually passed from
    the calling program and copied into registers by means of the stack), the
    routine can transfer control to the ROM BIOS using an interrupt:

    5-1        int     12h

    In this example, this single INT instruction does all the work for you.
    The ROM BIOS returns the computer's memory size in register AX, where C
    expects the routine to leave it when the routine returns control to the
    calling program. In other cases, you might need to leave a result
    elsewhere, as in Lines 4-4 and 4-5, above.

    Most ROM BIOS interrupts, however, provide access to several different
    services. In such cases, you must specify a service number in register AH
    before you execute the interrupt. For example, to access the first video
    service, you would execute the commands on the following page.

    mov     ah,0            ; AH=service number 0
    int     10h             ; ROM BIOS video services interrupt

    This five-step process outlines the basic principles of nearly all aspects
    of an assembly-language interface. In the following chapters, you'll see
    how this design is used in specific examples.


Advanced BIOS Interface

    To conclude this chapter we'd like to mention the alternative BIOS
    interface that IBM introduced in the PS/2 models 50, 60, and 80. This
    Advanced BIOS (ABIOS) interface addresses some of the major design
    shortcomings of the interrupt-based interface described in this chapter.

    The traditional, interrupt-based ROM BIOS interface is limited in two
    important ways:

    ■  It cannot be used in protected mode in a PS/2 Model 50, 60, or 80.

    ■  It provides poor support for multitasking, so an operating system that
        offers multitasking cannot rely on the traditional ROM BIOS interface.

    IBM's solution to these problems is the Advanced BIOS interface in the
    PS/2 models 50, 60, and 80. Through the Advanced BIOS interface, BIOS
    services are accessed through a set of address tables and common data
    areas designed for use in protected mode as well as with a multitasking
    operating system. However, the complexity of the Advanced BIOS interface
    makes it better suited to supporting an operating system than to
    supporting applications programs. Unless you're writing a protected-mode,
    multitasking operating system, we recommend that you keep using the
    traditional ROM BIOS interface that is common to all computers in the PC
    family.



────────────────────────────────────────────────────────────────────────────
Chapter 9  ROM BIOS Video Services

    Accessing the ROM BIOS Video Services
    Service 00H (decimal 0): Set Video Mode
    Service 01H (decimal 1): Set Cursor Size
    Service 02H (decimal 2): Set Cursor Position
    Service 03H (decimal 3): Read Cursor Position
    Service 04H (decimal 4): Read Light-Pen Position
    Service 05H (decimal 5): Set Active Display Page
    Service 06H (decimal 6): Scroll Window Up
    Service 07H (decimal 7): Scroll Window Down
    Service 08H (decimal 8): Read Character and Attribute
    Service 09H (decimal 9): Write Character and Attribute
    Service 0AH (decimal 10): Write Character
    Service 0BH (decimal 11): Set 4-Color Palette
    Service 0CH (decimal 12): Write Pixel
    Service 0DH (decimal 13): Read Pixel
    Service 0EH (decimal 14): Write Character in Teletype Mode
    Service 0FH (decimal 15): Get Current Video Mode
    Service 10H (decimal 16): Color Palette Interface
    Service 11H (decimal 17): Character Generator Interface
    Service 12H (decimal 18): "Alternate Select"
    Service 13H (decimal 19): Write Character String
    Service 1AH (decimal 26): Read/Write Display Combination Code
    Service 1BH (decimal 27): Return Functionality/State Information
    Service 1CH (decimal 28): Save/Restore Video State

    Comments and Example

    In this chapter, we will discuss each of the video, or screen-control,
    services provided by the ROM BIOS. We have devoted most of the chapter to
    detailed descriptions of each video service. Beginning on page 194, we
    have included some programming hints and an assembly-language routine that
    makes use of some of the video services. For a more general discussion of
    video hardware in the PC family, see Chapter 4. For information on
    low-memory locations used by the ROM BIOS for video status information,
    turn to page 54.


Accessing the ROM BIOS Video Services

    The ROM BIOS video services are all requested by generating interrupt 10H
    (decimal 16). There are 25 principal services available under this
    interrupt. (See Figure 9-1.) Like all other ROM BIOS services, the video
    services are numbered from 00H and are selected by placing the service
    number in the AH register. The services usually require you to specify
    additional parameters in register AL, BX, CX, or DX. We'll cover the
    purpose and placement of the parameters under each service description.

╓┌─┌────────────────────────┌────────────────────────────────────────────────╖
    Service
    Hex   Dec                Description
    ──────────────────────────────────────────────────────────────────────────
    00H    0                 Set Video Mode.
    01H    1                 Set Cursor Size.
    02H    2                 Set Cursor Position.
    03H    3                 Read Cursor Position.
    04H    4                 Read Light-Pen Position.
    05H    5                 Set Active Display Page.
    06H    6                 Scroll Window Up.
    07H    7                 Scroll Window Down.
    08H    8                 Read Character and Attribute.
    09H    9                 Write Character and Attribute.
    0AH   10                 Write Character.
    0BH   11                 Set 4-Color Palette.
    0CH   12                 Write Pixel.
    0DH   13                 Read Pixel.
    0EH   14                 Write Character in Teletype Mode.
    0FH   15                 Get Current Video Mode.
    10H   16                 Color Palette Interface.
    Service
    Hex   Dec                Description
    ──────────────────────────────────────────────────────────────────────────
    10H   16                 Color Palette Interface.
    11H   17                 Character Generator Interface.
    12H   18                 "Alternate Select".
    13H   19                 Write Character String.
    14H   20                 (PC convertible only)
    15H   21                 (PC convertible only)
    1AH   26                 Read/Write Display Combination Code.
    1BH   27                 Return Functionality/State Information.
    1CH   28                 Save/Restore Video State.
    ──────────────────────────────────────────────────────────────────────────


    Figure 9-1.  The 25 video services.

Service 00H (decimal 0): Set Video Mode

    Service 00H (decimal 0) is used to configure your video subsystem into one
    of the 20 video modes listed in Figure 9-2. For details of the video
    modes, see page 72.

    You may recall from our discussion in Chapter 4 that modes 00H through
    06H apply to the standard Color Graphics Adapter; mode 07H applies to the
    Monochrome Display Adapter; modes 0DH through 10H were added for the
    Enhanced Graphics Adapter; and modes 11H through 13H were introduced with
    the Multi-Color Graphics Array (PS/2 models 25 and 30) and Video Graphics
    Array (PS/2 models 50, 60, and 80).

    Mode        Type         Resolution  Colors      Video Subsystem
    ──────────────────────────────────────────────────────────────────────────
    00H, 01H    Text         40 x 25     16          CGA, EGA, MCGA, VGA
    02H, 03H    Text         80 x 25     16          CGA, EGA, MCGA, VGA
    04H, 05H    Graphics     320 x 200   4           CGA, EGA, MCGA, VGA
    06H         Graphics     640 x 200   2           CGA, EGA, MCGA, VGA
    07H         Text         80 x 25     Mono        MDA, EGA, VGA
    08H, 09H,
    0AH                                              (PCjr only)
    0BH,0CH                                          (used internally by EGA
                                                    BIOS)
    0DH         Graphics     320 x 200   16          EGA,VGA
    0EH         Graphics     640 x 200   16          EGA,VGA
    0FH         Graphics     640 x 350   Mono        EGA,VGA
    10H         Graphics     640 x 350   16          EGA,VGA
    11H         Graphics     640 x 480   2           MCGA,VGA
    12H         Graphics     640 x 480   16          VGA
    13H         Graphics     320 x 200   256         MCGA,VGA
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-2.  Video modes available through ROM BIOS video service 00H.

    Normally, the ROM BIOS clears the screen memory buffer when the mode is
    set, even if it is set to the same mode again and again. In fact,
    resetting the same video mode can be an easy way to clear the screen. In
    some versions of DOS, in fact, the DOS command CLS clears the screen this
    way. Setting the video mode also sets the color palette to default color
    values, however, so don't rely on service 00H to clear the screen if
    you're working with colors; use video service 06H instead.

    On the EGA, MCGA, and VGA, you can also tell the ROM BIOS not to clear the
    screen when it sets up the video mode. Do this by adding 80H (decimal 128)
    to the video mode number you specify in AL. For example, to change to 640
    x 200, 2-color mode without clearing the screen, call service 00H with AL
    = 86H. Use this feature with caution, though. Displayable video data is
    formatted differently in different modes, so a screenful of useful data in
    one video mode may become unintelligible when you switch to another mode
    without clearing the screen.

    See Chapter 4, page 72 for more on video modes. See page 58, memory
    location 0040:0049H, for more on how a record of the mode is stored in
    memory. See service 0FH (decimal 15) to find out how to determine the
    current video mode.

Service 01H (decimal 1): Set Cursor Size

    Service 01H (decimal 1) controls the form and size of the blinking cursor
    that appears in text modes. The default cursor appears as one or two
    blinking scan lines at the bottom of a character display position. You can
    change the default cursor size by redefining the number of lines that are
    displayed.

    The Color Graphics Adapter (CGA) can display a cursor that has 8 scan
    lines, numbered from 0 at the top to 7 at the bottom. The Monochrome
    Display Adapter (MDA) and the EGA can display a cursor that has 14 scan
    lines, also numbered from the top, from 0 through 13. Both the MCGA and
    the VGA have default text characters that are 16 scan lines high, so the
    maximum size of the text cursor in default PS/2 text modes is 16 scan
    lines. You set the cursor size by specifying the starting and ending scan
    lines. (These are the same as the start and stop parameters of BASIC's
    LOCATE statement.) The start line number is loaded into the CH register
    and the stop line number into the CL register. Default cursor settings are
    CH = 6, CL = 7 for the CGA, CH = 11, CL = 12 for the MDA and EGA, and CH =
    13, CH = 14 for the MCGA and VGA.

    You will notice that the valid scan line numbers occupy only four of the
    bits (bits 0 through 3) placed in these registers. If bit 5 of CH is set
    on by specifying a value of 20H (decimal 32), the cursor will disappear.
    This is one of two techniques that you can use to remove the cursor in the
    text modes. The other technique is to actually move it off the screen, say
    to row 26, column 1. When a graphics mode is set, bit 5 is automatically
    set to keep the cursor from being displayed. Because there is no true
    cursor in the graphics modes, you must simulate one with the solid-block
    character, DFH (decimal 223), or with a change of background attributes.

Service 02H (decimal 2): Set Cursor Position

    Service 02H (decimal 2) sets the position of the cursor using row and
    column coordinates. In text modes, multiple display pages can exist, each
    one having an independently recorded cursor position. Even though the
    graphics modes have no visible cursor, they keep track of the logical
    cursor position in the same way as the text modes. This logical cursor
    position is used to control character I/O.

    The cursor position is specified by placing a row number in register DH, a
    column number in DL, and a display page number in BH. The numbering for
    the rows and columns begins with coordinates 0,0 in the top left corner.
    The graphics modes also use the character row and column coordinates to
    identify the cursor location, rather than pixel coordinates. The display
    page number must be set to 0 in CGA-compatible graphics modes, although
    the EGA and VGA both support multiple display pages in 16-color graphics
    modes as well as in text modes.

    See Figure 9-3 for a summary of register settings. See page 87 for more
    on display pages. See service 03H for the reverse operation: Read cursor
    position.

    Service Number           Parameters
    ──────────────────────────────────────────────────────────────────────────
    AH = 02H                 DH = row number
                            DL = column number
                            BH = page number
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-3.  Registers values for setting the cursor position using
    service 02H.

Service 03H (decimal 3): Read Cursor Position

    Service 03H (decimal 3) is the opposite of services 01H and 02H. When you
    specify the page number in BH, the ROM BIOS reports the cursor size by
    returning the starting scan line in CH and the ending scan line in CL. In
    addition, it reports the cursor position by returning the row in DH and
    the column in DL. (See Figure 9-4.)

    Service Number           Returns
    ──────────────────────────────────────────────────────────────────────────
    AH = 03H                 BH = page number (set to 0 in graphics modes)
                            DH = row number
                            DL = column number
                            CH = starting scan line of cursor
                            CL = ending scan line of cursor
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-4.  Values reported by video service 03H.

Service 04H (decimal 4): Read Light-Pen Position

    Service 04H (decimal 4) reports the light-pen status on a CGA or EGA,
    specifically whether or not the pen has been triggered, and where it is on
    the screen if it has been triggered.

    Register AH is set to indicate triggering: If AH = 01H, the light pen has
    been triggered; if AH = 00H, it has not been triggered. If the pen has
    been triggered, the ROM BIOS determines the light pen's character column
    and pixel row (y-coordinate) from the video hardware. From these, the ROM
    BIOS computes the character row and pixel column (x-coordinate). The
    results are returned in registers BX, CX, and DX as shown in Figure 9-5.

    Service Number           Returns
    ──────────────────────────────────────────────────────────────────────────
    AH = 04H                 DH = character row number
                            DL = character column number
                            CH = pixel line number (CGA and EGA video modes
                            04H, 05H, and 06H)
                            CX = pixel line number (all other EGA video
                            modes)
                            BX = pixel column number
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-5.  Light-pen position values returned by service 04H.

Service 05H (decimal 5): Set Active Display Page

    Service 05H (decimal 5) selects the active display page for text modes 0
    through 3 and also for 16-color EGA and VGA graphics modes. You specify
    the page number in register AL. (See Figure 9-6.) In text modes, page
    numbers range from 0 through 7. Don't forget, however, that the CGA
    hardware can display only four different 80-column pages, so CGA pages 4
    through 7 overlap pages 0 through 3 when you're in 80 x 25 text mode. On
    the EGA and in the PS/2 video subsystems, you can also select among
    multiple display pages in 16-color graphics modes.

    Service Number           Parameters
    ──────────────────────────────────────────────────────────────────────────
    AH = 05H                 AL = new display page number
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-6.  The registers used to set the active display page using
    service 05H.

    In all video modes, page 0 is used by default. Page 0 is located at the
    beginning of display memory, with higher page numbers in higher memory
    locations. See page 87 for more on display pages.

Service 06H (decimal 6): Scroll Window Up

    Service 06H (decimal 6) and companion service 07H are used to define a
    rectangular window of text on the screen and to scroll the window's
    contents up or down one or more lines. To accomplish the scrolling effect,
    blank lines are inserted at the bottom of the window area with service 06H
    (at the top with service 07H) and the top lines of the window (the bottom
    lines with service 07H) are scrolled off and disappear.

    The number of lines to be scrolled is specified in AL. If AL = 00H, the
    entire window is blanked. (The same thing would happen if you scrolled
    more lines than the window size allowed.) The location or size of the
    window is specified in the CX and DX registers: CH is the top row, and DH
    is the bottom row; CL is the left column, and DL is the right column. The
    display attribute for the new blank lines inserted by the two services is
    taken from BH. Figure 9-7 summarizes the register settings for both
    services 06H and 07H.

    When you fill a window with lines of text, you'll discover that window
    scrolling is normally a two-stage process: When a new line is ready to be
    written in the window, service 06H (or service 07H) scrolls the current
    window contents. Then the new line is filled with text using the cursor-
    positioning and character-writing services. The following example
    demonstrates this window action.

    DEBUG                   ; invoke DEBUG from DOS utilities
    A                       ; ask to assemble instructions
    INT 10                  ; create interrupt 10H instruction
    [Return]                ; finish assembling
    R AX                    ; ask to see and change contents of AX
    0603                    ; specify service 06H (scroll up), using
                            ; 3-line window
    R CX                    ; ask to see and change contents of CX
    050A                    ; specify top left corner: row 5, column 10
    R DX                    ; ask to see and change contents of DX
    1020                    ; specify bottom right corner: row 16, column 32
    D 0 L 180               ; fill screen with nonsense
    G =100 102              ; execute INT 10H, then stop

    Service Number           Parameters
    ──────────────────────────────────────────────────────────────────────────
    AH = 06H (scroll up)     AL = number of lines to scroll
    AH = 07H (scroll down)   CH = row number of upper-left corner
                            CL = column number of upper-left corner
                            DH = row number of lower-right corner
                            DL = column number of lower-right corner
                            BH = display attribute for blank lines
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-7.  Register values for scrolling using services 06H and 07H.

    See Chapter 8 for more on assembly-language routines. See the IBM DOS
    Technical Reference Manual for more on DEBUG.

Service 07H (decimal 7): Scroll Window Down

    Service 07H (decimal 7) is, as we've already mentioned, the mirror image
    of service 06H. The difference between the two services is the scrolling
    action. In service 07H, the new blank lines appear at the top of the
    window and the old lines disappear at the bottom. The opposite scrolling
    action takes place in service 06H. See Figure 9-7 under service 06H for
    the register parameter settings.

Service 08H (decimal 8): Read Character and Attribute

    Service 08H (decimal 8) is used to read characters "off the screen," that
    is, directly out of the display memory. This service is unusually spiffy
    because it works in both text and graphics modes.

    In graphics modes, the same character-drawing tables used to write
    characters are also used to recognize them by a pattern-matching
    operation. Even if you create your own character set in graphics mode,
    this service will be able to recognize them. In text modes, of course, the
    ASCII character codes are directly available in the display memory.

    Service 08H returns the ASCII character code of the character in AL. (See
    Figure 9-8.) In graphics modes, if the character doesn't match any
    characters in the graphics character set, the ROM BIOS returns ASCII code
    0. In text modes, the service also returns the character's color
    attributes in AH. Remember to specify a display page number in BH when you
    call this service.

    Service Number Parameters                   Returns
    ──────────────────────────────────────────────────────────────────────────
    AH = 08H       BH = active display          AL = ASCII character read from
                    page number                  cursor location
                                                AH = attribute of text
                                                character (text modes only)
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-8.  The registers used to read a character and attribute with
    service 08H.

    See page 82 for more on text characters and attribute bytes. See page
    84 for more on text- and graphics-mode characters. See Appendix C for
    more on ASCII characters.

Service 09H (decimal 9): Write Character and Attribute

    Service 09H (decimal 9) writes one or more copies of a single character
    and its color attribute. The character is specified in AL, and the
    text-mode attribute or graphics-mode color is specified in BL. The number
    of times the character is to be written (one or more times) is placed in
    CX, and BH contains the display page number. (See Figure 9-9.)

    Service Number           Parameters
    ──────────────────────────────────────────────────────────────────────────
    AH = 09H                 AL = ASCII character to write to screen
                            BL = attribute value (text modes) or foreground
                            color (graphics modes)
                            BH = background color (video mode 13H only) or
                            display page number (all other modes)
                            CX = number of times to write character and
                            attribute
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-9.  The registers used to write a text character and attribute
    using service 09H.

    The ROM BIOS writes the character and its color attributes as many times
    as requested, starting at the current cursor location. Although the cursor
    is not moved, duplicate characters are written at subsequent screen
    locations. In text mode, the duplicated characters will successfully wrap
    around from line to line, which increases the usefulness of this service.
    In graphics mode, the characters will not wrap around.

    Service 09H is quite useful both for writing individual characters and for
    replicating a character. The repeat operation is most often used to
    rapidly lay out blanks or other repeated characters, such as the
    horizontal lines that are part of box drawings. (See Appendix C.) When
    you want to make a single copy of the character, be sure to set the count
    in CX to 1. If it's set to 0, the number of repetitions will be a lot more
    than you want.

    Service 09H has an advantage over the similar service 0EH, in that you
    can control the color attributes. However, its one disadvantage is that
    the cursor is not automatically advanced.

    In graphics modes, the value specified in BL is the foreground color──the
    color of the pixels that make up the character drawing. Normally the ROM
    BIOS displays the character with the specified foreground color on a black
    background. If, however, you set bit 7 of the color value in BL to 1, then
    the ROM BIOS creates the character's new foreground color by using an
    exclusive OR operation (XOR) to combine each of the previous foreground
    pixels with the value in BL. The same feature also applies to the
    character and pixel writing services, services 0AH and 0CH.

    Here's an example of what can happen when the ROM BIOS uses the XOR
    operation to display a character. Imagine you're in 320 x 200, 4-color
    graphics mode and the screen is completely filled with white pixels. If
    you now write a white character in the usual way, with a color value of
    03H (white) in register BL, the ROM BIOS displays a white character on a
    black background. If, however, you write the same character with a color
    value of 83H (bit 7 set to 1), the ROM BIOS uses XOR to display a black
    character on a white background.

    See page 82 for more on display attributes in text modes. See page 84
    for more on color attributes in graphics modes.

Service 0AH (decimal 10): Write Character

    Service 0AH (decimal 10) is the same as service 09H (write character and
    attribute to cursor location) with one exception: Service 09H lets you
    change the existing screen color attribute in text mode but service 0AH
    does not.

    However, in graphics mode you must still specify a color in BL (see
    Figure 9-10), which makes the description of this service as only a
    character-writing service partly incorrect. Service 0AH has the same
    graphics color rules as services 09H and 0CH: The color can be used
    directly or used with XOR and the existing color. (See service 09H for an
    explanation.)

    See page 82 for more on display attributes in text modes. See page 84
    for more on color attributes in graphics modes.

    Service Number           Parameters
    ──────────────────────────────────────────────────────────────────────────
    AH = 0AH                 AL = ASCII character to write to screen
                            BL = foreground color (graphics modes only)
                            BH = background color (video mode 13H only) or
                            display page number (all other modes)
                            CX = number of times to write character
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-10.  The registers used to write a character using service 0AH.

Service 0BH (decimal 11): Set 4-Color Palette

    Service 0BH (decimal 11) actually consists of two subservices. You select
    either subservice 00H or subservice 01H by storing the proper value in
    register BH. (See Figure 9-11.) Subservice 00H lets you set the border
    color in CGA alphanumeric modes or the background color in CGA 320 x 200,
    4-color graphics mode. You designate the border color in BL with a value
    between 00H and 0FH.

    Subservice 01H lets you select one of the two 4-color palettes used in 320
    x 200, 4-color mode. The value in BL specifies which of the two hardware
    palettes to use. A value of 0 designates the red-green-brown palette, and
    a value of 1 selects the cyan-magenta-white palette. (See page 77 for
    more on color palettes.)

    This service was designed primarily for use with the CGA. Use service
    10H to control colors in other video modes on the EGA, MCGA, and VGA.

    Service Number Subservice Number            Parameters
    ──────────────────────────────────────────────────────────────────────────
    AH = 0BH       BH = 00H                     BL = border or background
                                                color
                    BH = 01H                     BL = palette number (0 or 1)
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-11.  Color control in CGA-compatible video modes using service
    0BH.

Service 0CH (decimal 12): Write Pixel

    Service 0CH (decimal 12) writes an individual pixel. You specify the
    pixel's location on the screen by passing its column (x-coordinate) in
    register CX and its row (y-coordinate) in DX. Remember that pixel rows and
    columns are not the same as the character row and column you use in other
    services to locate the cursor or to display a character. Pixel coordinates
    correspond to individual dots, not to characters.

    If you're using a graphics mode that supports multiple display pages, be
    sure to specify the display page number in register BH. (See Figure
    9-12.) Also, when you specify the pixel's color in register AL, you have
    the option of setting bit 7 of the color value to 1. As in service 09H,
    this tells the BIOS to display the pixel with an XORed color value. (See
    service 09H for an explanation.)

    Service Number           Parameters
    ──────────────────────────────────────────────────────────────────────────
    AH = 0CH                 AL = pixel color
                            BH = display page number
                            DX = row number of pixel
                            CX = column number of pixel
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-12.  The registers used to write a pixel using service 0CH.

    See page 91 for more on pixels in graphics modes.

Service 0DH (decimal 13): Read Pixel

    Service 0DH (decimal 13) is the reverse of service 0CH: It reads a pixel's
    color value rather than writing it. A pixel has only a single color
    attribute, which is returned through service 0DH. (The read-character
    service 08H returns both a color and an ASCII character code.) The row is
    specified in DX, the column in CX, and the display page in BH. The pixel
    color value is returned in AL. (See Figure 9-13.) All high-order bits of
    the value returned in AL are set to 0, as you would expect.

    Service Number Parameters                   Returns
    ──────────────────────────────────────────────────────────────────────────
    AH = 0DH       BH = display page number     AL = pixel color value
                    DX = row number of pixel
                    CX = column number of pixel
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-13.  The registers used to read a pixel using service 0DH.

Service 0EH (decimal 14): Write Character in Teletype Mode

    Service 0EH (decimal 14) is the workhorse service of conventional
    character output. It writes individual characters to the screen in what is
    known as teletype (TTY) mode. This makes the screen act as the simplest
    and crudest form of printer──exactly what is needed for routine text
    output. As such, this service has no regard for such niceties as color,
    blinking characters, or control over the cursor location.

    With this service, the character is written at the current cursor location
    and the cursor is advanced one position, wrapping to new lines or
    scrolling the screen as needed. The character to be written is specified
    in register AL.

    In text modes, the character is displayed as in service 0AH; that is, with
    the color attributes already in use at the screen location where the
    character is written. In graphics modes, however, you must also specify
    the foreground color value to be used for the character. (See Figure
    9-14.)

    There are four characters that service 0EH reacts to according to their
    ASCII meaning: 07H (decimal 7)──beep, 08H (decimal 8)──backspace, 0AH
    (decimal 10)──line feed, and 0DH (decimal 13)──carriage return. All other
    characters are displayed normally.

    The primary advantage of this service over service 09H is that the cursor
    is automatically moved; the advantage of service 09H is that you can
    control the color attribute. Now, if you could only combine the two....

    Service Number           Parameters
    ──────────────────────────────────────────────────────────────────────────
    AH = 0EH                 AL = ASCII character to write
                            BL = foreground color (in graphics modes only)
                            BH = display page (IBM PC BIOS dated 10/19/81 or
                            earlier)
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-14.  The registers used to write a character in teletype mode
    using service 0EH.

Service 0FH (decimal 15): Get Current Video Mode

    Service 0FH (decimal 15) returns the current video mode and two other
    useful pieces of information: the screen width in characters (80 or 40)
    and the display page number.

    The video mode number, as explained under service 00H, is returned in AL.
    The screen width is returned in AH as a number of characters per line. The
    display page number will be returned in BH. (See Figure 9-15.)

    Service Number           Returns
    ──────────────────────────────────────────────────────────────────────────
    AH = 0FH                 AL = current display mode
                            AH = number of characters per line
                            BH = active display page
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-15.  Information returned by service 0FH.

    See page 72 for more on video modes. See page 58, memory location
    0040:0049H, for more on how a record of the mode is kept.

Service 10H (decimal 16): Color Palette Interface

    Service 10H (decimal 16) was introduced with the PCjr and carried forward
    in the EGA and PS/2 ROM BIOS. It consists of a set of subservices (Figure
    9-16) that let you control palette colors, blinking, and (on the MCGA and
    VGA) the video DAC. Be aware that different subservices are supported with
    different hardware. Before you use these subservices in a program, be sure
    your program "knows" which subsystem it's running on. (Video service 1AH
    can provide this information to a program.)

    Subservice Number        Description
    ──────────────────────────────────────────────────────────────────────────
    AL = 00H                 Update a specified palette register.
    AL = 01H                 Specify the border color.
    AL = 02H                 Update all 16 palette registers plus border.
    AL = 03H                 Select background intensity or blink attribute.
    AL = 07H                 Read a specified palette register.
    AL = 08H                 Read the border color register.
    AL = 09H                 Read all 16 palette registers plus border.
    AL = 10H                 Update a specified video DAC color register.
    AL = 12H                 Update a block of video DAC color registers.
    AL = 13H                 Set video DAC color paging.
    AL = 15H                 Read a specified video DAC color register.
    AL = 17H                 Read a block of video DAC color registers.
    AL = 1AH                 Get video DAC color paging status.
    AL = 1BH                 Gray-scale a block of video DAC color registers.
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-16.  Subservices available through video BIOS service 10H.

    Subservice 00H (decimal 0) updates one of the 16 palette registers on an
    EGA or VGA. You specify the palette register number in BL and a new
    palette register value in BH when you call this subservice. The VGA BIOS
    also supports subservice 07H (decimal 7), which performs the complementary
    operation: When you call subservice 07H with a palette register number in
    BL, the ROM BIOS returns that palette register's current contents in BH.
    (Subservice 07H isn't available in the EGA BIOS because the EGA has
    write-only palette registers.)

    Subservice 01H (decimal 1) sets the border color on an EGA or VGA. You
    pass the color value to the BIOS in register BH when you call this
    subservice. The VGA BIOS supports subservice 08H, which returns the
    current border color value in BH, but again this complementary subservice
    isn't available on the EGA.

    Here are two tips about setting the border color on an EGA or VGA. First,
    in most EGA video modes the border area is very small, and selecting any
    border color other than black results in a narrow, smeared border. On the
    VGA, the border is better. Second, if compatibility with the CGA is
    important, remember that you can also use video service 0BH (page 180) to
    set the border color.

    Subservice 02H (decimal 2) updates all 16 palette registers, plus the
    border color, with a single ROM BIOS call. Before you call subservice 02H,
    you must store all 16 palette register values plus the border color value
    in a 17-byte table. You then pass the address (segment and offset) of this
    table to the BIOS in registers ES and DX when you call this subservice.
    The VGA also provides a subservice that lets you read the palette
    registers back into a table: When you call subservice 09H (decimal 9) with
    ES:DX pointing to a 17-byte table, the ROM BIOS fills the table with the
    16 current palette register values and the border color.

    Subservice 03H (decimal 3) lets you selectively enable or disable the
    blinking attribute. The ROM BIOS uses blinking by default, but if you
    prefer to have a full range of 16 background colors instead of only 8, you
    can use subservice 03H to disable blinking. The value you pass in register
    BL determines whether blinking is enabled (BL = 01H) or disabled (BL =
    00H).

    Subservices 10H (decimal 16) and 15H (decimal 21) are supported only by
    the MCGA and VGA BIOS. These two subservices give you direct access to one
    of the 256 color registers in the video digital to analog convertor (DAC).
    To update a video DAC color register, call subservice 10H with the color
    register number in BX and 6-bit red, green, and blue color values in
    registers DH, CH, and CL. To read a specified color register, place the
    color register number in BX and use subservice 15H, which returns the RGB
    values in DH, CH, and CL.

    The related subservices 12H (decimal 18) and 17H (decimal 23) operate on a
    block of video DAC color registers instead of only one. To use subservice
    12H, create a table of 3-byte red-green-blue values. Then place the
    segment-offset address of the table in ES and DX, the first color register
    number to update in BX, and the number of registers to update in CX. When
    you call subservice 12H, the ROM BIOS stores each red-green-blue value in
    turn into the block of color registers you specified in BX and CX.

    The complementary subservice 17H requires you to pass the address of a
    table in ES:DX, along with a starting register number in BX and a register
    count in CX. The ROM BIOS fills the table with the red-green-blue values
    it reads from the block of color registers you specified.

    On the VGA, which has both palette registers and video DAC color
    registers, you can use subservices 13H (decimal 19) and 1AH (decimal 26)
    to switch rapidly between different palettes. By default, the ROM BIOS
    configures the VGA hardware so that color decoding is the same as on the
    EGA: Each of the 16 palette registers contains a 6-bit value that
    specifies one of the first 64 video DAC registers, and these 64 color
    registers specify the 64 colors available in the EGA palette.

    Subservice 13H lets you use the other three color pages, or groups of 64
    video DAC color registers. (See Figure 9-17.) If you call subservice 13H
    with BH = 01H and BL = 01H, for example, the BIOS configures the VGA
    hardware to display colors from the second group of 64 color registers
    (color page 1). To use the first group (color page 0) again, you could
    call the same subservice with BH = 00H and BL = 01H. If, for example, you
    used the default, EGA-compatible colors in color page 0, and their
    gray-scale equivalents in color page 1, you could switch rapidly between
    the two with a single call to subservice 13H.

    If you need to switch rapidly between more than four palettes, you can use
    subservice 13H with BH = 01H and BL = 00H to configure the VGA color
    decoding hardware to use 4-bit palette register values instead of 6-bit
    values. In this case, each palette register value can specify one of only
    16 different video DAC registers. This makes 16 color pages available,
    each comprising 16 color registers. You can select any of the 16 color
    pages using subservice 13H with BL = 01H.

    Parameters                           Description
    ──────────────────────────────────────────────────────────────────────────
    BL = 00H           BH = 00H          Use four 64-register pages.
                        BH = 01H          Use sixteen 16-register pages.
    BL = 01H           BH = n            Color page number.
                                        (n = 00H─03H if using 64-register
                                        pages
                                        n = 00H─0FH if using 16-register
                                        pages)
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-17.  Video DAC color paging with service 10H, subservice 13H.

    The VGA ROM BIOS supplements subservice 13H with a complementary function,
    subservice 1AH. This subservice returns the color page status in BL (16-
    or 64-register color pages) and BH (current color page number).

    With subservice 1BH (decimal 27) on the MCGA and VGA, you can convert the
    color values in a block of consecutive video DAC color registers to
    corresponding shades of gray. Call this subservice with BX containing the
    number of the first video DAC register to convert, and with CX containing
    the number of registers to update.

Service 11H (decimal 17): Character Generator Interface

    Service 11H (decimal 17) first appeared in the EGA ROM BIOS. The many
    subservices available in service 11H were augmented and expanded in the
    PS/2 ROM BIOS to provide full support for the new video subsystems (MCGA
    and VGA) introduced with the PS/2s.

    To make sense of the many service 11H subservices, it helps to consider
    them in four groups (Figure 9-18):

    ■  Subservices in the first group (subservices 00H through 04H) change the
        character set used in text modes.

    ■  Subservices in the second group (subservices 10H through 14H) change
        the text-mode character set as well as the displayed height of
        text-mode characters.

    ■  Subservices in the third group (subservices 20H through 24H) update
        graphics-mode character sets.

    ■  The subservice in the fourth group (subservice 30H) returns information
        about the character sets currently displayed and about the character
        sets available to the ROM BIOS.

    Subservices 00H (decimal 0), 01H (decimal 1), 02H (decimal 2) and 04H
    (decimal 4) all change the character set used to display text-mode
    characters on the EGA, MCGA, or VGA. Subservices 01H, 02H, and 04H are the
    easiest to use. You need specify only which available tables in character
    generator RAM should contain the character set. Thus, for example, a call
    to service 11H with AL = 02H and BL = 00H instructs the ROM BIOS to use
    its 8 x 8 characters in the first (default) table in character generator
    RAM.

    If you want to define your own characters you need to use subservice 00H,
    as follows: Place a table of the bit patterns that define the characters
    in a buffer. Then call subservice 00H with the address of the table in
    ES:BP, the number of characters in CX, the ASCII code of the first
    character in the table in DX, and the number of bytes in each character's
    bit pattern in BH.

    Subservice 03H (decimal 3) lets you select among text-mode character sets
    once they are loaded into character generator RAM. The EGA and MCGA have
    four such tables; the VGA has eight. The value in BL specifies which one
    or two of the tables is to be used to display text-mode characters. On the
    EGA and MCGA, bits 0 and 1 of BL specify one table, and bits 2 and 3
    specify a second table. If the two bit fields specify the same table,
    that's the table that will be used for all text-mode characters.

╓┌─┌─────────────────────────────┌───────────────────────────────────────────╖
    Subservice Number             Description
    ──────────────────────────────────────────────────────────────────────────
    Load a text-mode character set:
    AL = 00H                      Load a user-specified character set.
    AL = 01H                      Load the ROM BIOS 8 x 14 character set.
    AL = 02H                      Load the ROM BIOS 8 x 8 character set.
    AL = 03H                      Select displayed character set.
    AL = 04H                      Load the ROM BIOS 8 x 16 character set
                                (MCGA, VGA only).

    Load a text-mode character set and adjust the displayed character height:
    AL = 10H                      Load a user-specified character set.
    AL = 11H                      Load the ROM BIOS 8 x 14 character set.
    AL = 12H                      Load the ROM BIOS 8 x 8 character set.
    AL = 14H                      Load the ROM BIOS 8 x 16 character set
                                (MCGA, VGA only).

    Subservice Number             Description
    ──────────────────────────────────────────────────────────────────────────

    Load a graphics-mode character set:
    AL = 20H                      Load a CGA-compatible, user-specified
                                character set.
    AL = 21H                      Load a user-specified character set.
    AL = 22H                      Load the ROM BIOS 8 x 14 character set.
    AL = 23H                      Load the ROM BIOS 8 x 8 character set.
    AL = 24H                      Load the ROM BIOS 8 x 16 character set
                                (MCGA, VGA only).

    Get character generator information:
    AL = 30H                      Get character generator information.
    ──────────────────────────────────────────────────────────────────────────


    Figure 9-18.  Subservices available through video BIOS service 11H.

    Subservices 10H (decimal 16), 11H (decimal 17), 12H (decimal 18), and 14H
    (decimal 20) are similar to subservices 00H, 01H, 02H, and 04H. The
    difference is that with these higher-numbered subservices, the ROM BIOS
    not only loads a character set but also adjusts the displayed character
    height appropriately. This difference is obvious if you compare the effect
    of executing subservice 02H and subservice 12H to load the ROM BIOS 8 x 8
    character set. With subservice 02H, the 8 x 8 characters are used without
    adjusting the displayed character height, so if you're in a default ROM
    BIOS text mode, you'll see 25 rows of characters. With subservice 12H, the
    ROM BIOS adjusts the displayed character height so that in a default ROM
    BIOS text mode you see 43 rows of characters on an EGA or 50 rows of
    characters on a VGA.

    Subservices 20H through 24H (decimal 32 through decimal 36) are related to
    subservices 00H through 04H in that they also load character sets into
    memory. However, this third group of subservices is designed for use only
    in graphics modes. Subservice 20H loads a CGA-compatible set of 8 x 8
    characters into RAM. To use subservice 20H, place a table containing the
    bit patterns for ASCII characters 80H through FFH into memory, and pass
    the address of this table to the ROM BIOS in registers ES:BP. Subservices
    21H through 24H are similar to subservices 00H, 01H, 02H, and 04H. Call
    them with 00H in BL, the number of displayed character rows in DL, and
    (for subservice 21H) the number of bytes in each character's bit pattern
    in CX.

    Subservice 30H (decimal 48) returns several pieces of handy information
    regarding the ROM BIOS character generator. This subservice reports the
    height of the displayed character matrix in CX and the number of the
    bottom character row in DL. For example, if you call subservice 30H in the
    default EGA text mode (80 x 25), the BIOS returns 14 in CX and 24 in DL.

    Parameter          Returns
    ──────────────────────────────────────────────────────────────────────────
    BH = 00H           CGA-compatible 8 x 8 graphics-mode characters
                        (contents of interrupt 1FH vector)
    BH = 01H           Current graphics-mode characters (contents of
                        interrupt 43H vector)
    BH = 02H           ROM BIOS 8 x 14 characters
    BH = 03H           ROM BIOS 8 x 8 characters
    BH = 04H           Second half of ROM BIOS 8 x 8 character table
    BH = 05H           ROM BIOS 9 x 14 alternate characters
    BH = 06H           ROM BIOS 8 x 16 characters (MCGA and VGA only)
    BH = 07H           ROM BIOS 9 x 16 alternate characters (VGA only)
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-19.  Character bit pattern table addresses returned in ES:BP by
    subservice 30H of video ROM BIOS service 11H.

    Subservice 30H also returns the address of any of several bit pattern
    tables for the default ROM BIOS character sets. The value you pass in BH
    when you call this subservice determines which address the ROM BIOS
    returns in ES:BP. (See Figure 9-19.)

Service 12H (decimal 18): "Alternate Select"

    Service 12H (decimal 18) made its debut along with service 11H in the EGA
    BIOS. It, too, is supported in the ROM BIOS in all PC/2 video subsystems.
    IBM's name for this service derives from the purpose of one of the
    subservices of service 12H, namely, to select an alternate print-screen
    routine for the ROM BIOS Shift-PrtSc function. The name lingers on even
    though service 12H has been expanded by adding a number of unrelated
    subservices. (See Figure 9-20.)

    Subservice Number        Description
    ──────────────────────────────────────────────────────────────────────────
    BL = 10H                 Return video configuration information.
    BL = 20H                 Select alternate print-screen routine.
    BL = 30H                 Select scan lines for VGA text modes.
    BL = 31H                 Enable/disable default palette loading.
    BL = 32H                 Enable/disable CPU access to video RAM.
    BL = 33H                 Enable/disable gray-scale summing.
    BL = 34H                 Enable/disable ROM BIOS cursor emulation.
    BL = 35H                 PS/2 display switch interface.
    BL = 36H                 Enable/disable video refresh.
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-20.  Subservices available through video BIOS service 12H.

    Subservice 10H (decimal 16) reports on the configuration of an EGA or VGA.
    The value returned in BH indicates whether the current video mode is color
    (BH = 00H) or monochrome (BH = 01H). BL contains a number between 0 and 3
    that represents the amount of RAM installed on an EGA (0 means 64 KB; 1
    means 128 KB; 2 means 192 KB; 3 means 256 KB). The value in CH reflects
    the status of input from the EGA feature connector, and CL contains the
    settings of the EGA configuration switches.

    Subservice 20H (decimal 32) is provided for the convenience of users of
    the EGA or a VGA adapter. It replaces the motherboard ROM BIOS
    print-screen routine with a more flexible routine in the adapter ROM BIOS.
    Unlike the motherboard ROM BIOS routine, the adapter BIOS routine can
    print a snapshot of a text-mode screen that has more than 25 rows of
    characters. In PS/2s, of course, the motherboard routine can already do
    this, eliminating the need for this subservice.

    Subservice 30H (decimal 48) lets you specify how many scan lines to
    display in VGA text modes. The default ROM BIOS text modes contain 400
    scan lines. When you call subservice 30H, the value you pass in register
    AL can instruct the ROM BIOS to use a different vertical resolution: If AL
    = 00H, ROM BIOS text modes will display 200 scan lines, as they do on a
    CGA. If AL = 01H, text modes will display an EGA-compatible 350 scan
    lines. Finally, when AL = 02H, the ROM BIOS uses its default resolution of
    400 scan lines.

    When you use subservice 30H, the vertical resolution does not change until
    the next time a program uses video ROM BIOS service 00H to select a text
    mode. Thus, changing the vertical resolution actually requires you to make
    two different ROM BIOS calls: one to specify the resolution and another to
    set up the text mode.

    Subservice 31H (decimal 49) lets you enable or disable palette loading
    when the ROM BIOS sets up a new MCGA or VGA video mode. Calling subservice
    31H with AL = 01H disables palette loading, so you can subsequently change
    video modes without changing the colors in a previously-loaded palette. A
    call with AL = 00H enables default palette loading.

    Subservices 32H (decimal 50) and 35H (decimal 53) are provided for
    programmers who want to use two different video subsystems in the same
    PS/2 computer. In particular, these routines support the use of a VGA
    alongside the built-in MCGA subsystem in a PS/2 Model 30.

    Subservice 32H enables or disables buffer and port addressing according to
    the value passed in AL (AL = 00H means enable; AL = 01H means disable).
    This feature is important if any addresses in the two video subsystems
    overlap: Before accessing one subsystem, you must disable addressing in
    the other one.

    Subservice 35H provides a complete switching interface that lets you
    selectively access both an MCGA and a VGA in the same computer. This
    subservice relies on the function provided through subservice 32H to
    independently enable and disable each video subsystem. See Chapter 13 and
    the IBM BIOS Interface Technical Reference manual for details.

    Subservice 33H (decimal 51) tells the ROM BIOS whether or not to average
    colors to gray scales when it establishes a new video mode on an MCGA or
    VGA. A call to this subservice with AL = 01H disables the gray-scaling; a
    call with AL = 00H enables gray-scaling. You can also use this subservice
    to force the ROM BIOS to use a gray-scale palette even if you're using a
    color monitor.

    Subservice 34H (decimal 52) enables or disables text-mode cursor emulation
    on the VGA. When you call this subservice with AL = 00H, the ROM BIOS
    emulates CGA text-mode cursor sizing whenever you change

    video modes or update the cursor size. When called with AL = 01H, this
    subservice disables text-mode cursor emulation.

    Subservice 36H (decimal 54) lets you enable or disable VGA video refresh.
    Calling this subservice with AL = 01H disables refresh, and a call with AL
    = 00H enables refresh. When you disable refresh, the screen goes blank,
    but reads and writes to the video buffer are somewhat faster than when
    refresh is enabled. If you are writing a program that needs to run as fast
    as possible, and if you don't mind having the screen go blank while you
    access the video buffer, then consider using subservice 36H to temporarily
    blank the screen while you update it.

Service 13H (decimal 19): Write Character String

    Service 13H (decimal 19), allows you to write a string of characters to
    the display screen. Through the four subservices that make up this
    service, you can specify the character attributes individually or as a
    group. You can also move the cursor to the end of the string or leave it
    in place, depending on which subservice you choose.

    The subservice number is placed in AL, the pointer to the string in ES:BP,
    the length of the string in CX, the starting position where the string is
    to be written in DX, and the display page number in BH.

    Subservices 00H (decimal 0) and 01H (decimal 1) write a string of
    characters to the screen using the attribute specified in register BL.
    With subservice 00H, the cursor is not moved from the location specified
    in register DX; with subservice 01H, the cursor is moved to the location
    following the last character in the string.

    Subservices 02H (decimal 2) and 03H (decimal 3) write a string of
    characters and attributes to the screen, writing first the character and
    then the attribute. With subservice 02H, the cursor is not moved from the
    location specified in register DX; with subservice 03H, the cursor is
    moved to the location following the last character in the string.

    Service 13H is available only in the PC/AT, EGA, PS/2s, and later versions
    of the PC/XT ROM BIOS.

Service 1AH (decimal 26): Read/Write Display Combination Code

    Service 1AH (decimal 26) was introduced in the ROM BIOS in the PS/2s, but
    it is also part of the ROM BIOS of the VGA. This service returns a 2-byte
    code that indicates which combination of video subsystems and video
    displays is found in your computer. The display combination codes
    recognized by this ROM BIOS service are listed in Figure 9-21. Service
    1AH lets you select either of two subservices using the value in register
    AL; subservice 00H or subservice 01H.

    Subservice 00H (decimal 0) returns a 2-byte display combination code in
    register BX. If your computer has two different video subsystems, the
    value in BL indicates which one is active; that is, which is currently
    being updated by the video ROM BIOS. The value in BH indicates the
    inactive subsystem. If your computer has only video subsystem, the value
    in BH is zero.

    Subservice 01H (decimal 1) performs the reverse function of subservice
    00H. It lets you change the current display combination code known to the
    ROM BIOS. Don't use this subservice, however, unless you know exactly what
    you're doing. It's a rare program indeed that requires you to change the
    ROM BIOS's idea of what the video hardware actually is.

    Code               Video Subsystem
    ──────────────────────────────────────────────────────────────────────────
    00H                (No display)
    01H                MDA
    02H                CGA
    03H                (Reserved)
    04H                EGA with color display
    05H                EGA with monochrome display
    06H                Professional Graphics Controller
    07H                VGA with monochrome display
    08H                VGA with color display
    09H,0AH            (Reserved)
    0BH                MCGA with monochrome display
    0CH                MCGA with color display
    0FFH               (Unknown)
    ──────────────────────────────────────────────────────────────────────────

    Figure 9-21.  Display combination codes returned by video BIOS service
    1AH.

Service 1BH (decimal 27): Return Functionality/State Information

    Service 1BH (decimal 27) is available in all PS/2s as well as with the
    VGA. It returns a great deal of detailed information regarding the
    capabilities of the ROM BIOS as well as the current ROM BIOS and video
    hardware status.

    Service 1BH returns this information in a 64-byte buffer whose address is
    passed in registers ES:DI. In addition to this address, you must also
    specify an "implementation type" value of 0 in register BX. (Presumably
    future IBM video products will recognize implementation type values other
    than 0.)

    The BIOS fills the buffer with information about the current video mode
    (the mode number, character columns and rows, number of colors

    available) as well as about the video hardware configuration (total video
    memory available, display combination code, and so on). See the IBM BIOS
    Interface Technical Reference manual for details on the buffer format.

    In the first 4 bytes of the buffer, the ROM BIOS returns a pointer to a
    table of "static" functionality information. This table lists nearly all
    of the features the ROM BIOS and the video hardware can support: the video
    modes available, support for palette switching, RAM-loadable character
    sets, light-pen support, and many other details.

    When you write a program that runs on a PS/2 or in a system with a VGA
    adapter, service 1BH offers a simple and consistent way for your program
    to determine what the video subsystem's current and potential capabilities
    are. Unfortunately, you can't rely on this service if your program must be
    compatible with non-PS/2 computers. Neither the PC motherboard ROM BIOS
    nor the EGA BIOS supports this service. A program can determine whether
    service 1BH is supported by examining the value returned by this service
    in AL; this value is 1BH if the service is supported.

Service 1CH (decimal 28): Save/Restore Video State

    Service 1CH (decimal 28) is provided by the ROM BIOS only in the PS/2
    models 50, 60, and 80, and with VGA adapters. (In other words, where you
    find a VGA you also find service 1CH.) This BIOS service lets you preserve
    all information that describes the state of the video BIOS and hardware.
    The ROM BIOS can preserve three types of information: the video DAC state,
    the BIOS data area in RAM, and the current values in all video control
    registers.

    You can select three different subservices with the value you pass in
    register AL: subservices 00H, 01H, and 02H.

    Subservice 00H (decimal 0) is designed to be called before subservices 01H
    or 02H. Subservice 00H requires you to specify which of the three types of
    information you want to preserve, by setting one or more of the three
    low-order bits of the value in CX. When this service returns, BX contains
    the size of the buffer you will need to store the information.

    Subservice 01H (decimal 1) saves the current video state information in
    the buffer whose address you pass in ES:BX. Then you can change video
    modes, reprogram the palette, or otherwise program the ROM BIOS or video
    hardware.

    Subservice 02H (decimal 2) lets you restore the previous video state.


Comments and Example

    In cruising through the ROM BIOS video services, you've seen how they work
    individually. Once you have that information in mind, the next question
    usually is: Given a choice between using the ROM BIOS services directly or
    using higher-level services such as the DOS services or the services built
    into your programming language, which is best? The general advice that we
    always give is to use the highest-level services that will accomplish what
    you want to do. In this case, there is no specific reason for you to avoid
    using the ROM BIOS video services──you can't do any great harm by using
    them. But in the next chapter on the diskette services, we'll argue the
    case the other way, advising you to avoid using the ROM BIOS diskette
    services because more risk is associated with them.

    The video capabilities of the PC models are remarkable, and the ROM BIOS
    services give you full use of them. The DOS services, as you'll see in
    Chapters 14 through 18, are rather weak and provide only the simplest
    character services. Likewise, many programming languages (for example,
    Pascal and C) only provide a dressed-up version of the DOS services and
    nothing more. So, if you need to use the PC's fancy screen capabilities
    and if you aren't using a language such as BASIC that provides the
    services you need, you should be using the ROM BIOS services. Getting
    control of the display screen is one of the very best reasons for using
    the ROM BIOS services.

    Using the ROM BIOS services directly usually calls for an
    assembly-language interface, so we'll give you an example of how one can
    be set up. For the example, we'll set up a module in a format that would
    be called by C. We'll make the module switch to video mode 1 (40-column
    text in color) and set the border color to blue.

    Here is the assembly module (see Chapter 8, page 161, for general notes
    on the format):

    _TEXT           SEGMENT         byte public 'CODE'
                    ASSUME          cs:_TEXT

                    PUBLIC          _Blue40
    _Blue40         PROC            near

                    push            bp       ; save previous BP value
                    mov             bp,sp    ; use BP to access the stack


    ; set video mode

                    mov            ah,0      ; BIOS service number
                    mov            al,1      ; video mode number
                    int            10h       ; call BIOS to set 40x25 text mode

    ; set border color

                    mov            ah,0Bh    ; BIOS service number
                    mov            bh,0      ; subservice number
                    mov            bl,1      ; color value (blue)
                    int            10h       ; call BIOS to set border color

                    pop            bp        ; restore previous BP value
                    ret

    _Blue40         ENDP

    _TEXT           ENDS



────────────────────────────────────────────────────────────────────────────
Chapter 10  ROM BIOS Disk Services

    The ROM BIOS Disk Services
    Service 00H (decimal 0): Reset Disk System
    Service 01H (decimal 1): Get Disk Status
    Service 02H (decimal 2): Read Disk Sectors
    Service 03H (decimal 3): Write Disk Sectors
    Service 04H (decimal 4): Verify Disk Sectors
    Service 05H (decimal 5): Format Disk Track
    Service 06H (decimal 6): Format PC/XT Fixed-Disk Track
    Service 07H (decimal 7): Format PC/XT Fixed Disk
    Service 08H (decimal 8): Get Disk-Drive Parameters
    Service 09H (decimal 9): Initialize Fixed-Disk Parameter Tables
    Service 0AH and 0BH (decimal 10 and 11): Read and Write Long
    Service 0CH (decimal 12): Seek to Cylinder
    Service 0DH (decimal 13): Alternate Fixed-Disk Reset
    Service 10H (decimal 16): Test for Drive Ready
    Service 11H (decimal 17): Recalibrate Drive
    Service 15H (decimal 21): Get Disk Type
    Service 16H (decimal 22): Diskette Change Status
    Service 17H (decimal 23): Set Diskette Type
    Service 18H (decimal 24): Set Media Type for Format
    Service 19H (decimal 25): Park Heads
    Service 1AH (decimal 26): Format ESDI Unit

    Disk-Base Tables

    Comments and Examples

    We're now going to cover the disk services provided by the ROM BIOS. To
    understand the logical structure of the contents of a disk, see Chapter
    5, particularly pages 106 through 121. For information about the
    higher-level disk services provided by DOS, see Chapters 15 through 18.

    Generally speaking, disk operations are best left to disk operating
    systems. If you decide to use any of the ROM BIOS disk services, we
    recommend that you read the section entitled "Comments and Examples" on
    page 212 of this chapter.


The ROM BIOS Disk Services

    The original IBM PC ROM BIOS offered only six different disk services. As
    the diskette and fixed-disk subsystems of the PC and PS/2 family have
    become increasingly sophisticated, the number of ROM BIOS services that
    support disk I/O has increased. To keep the ROM BIOS software modular and
    flexible, IBM separated the support routines for fixed-disk subsystems
    from the diskette support routines. Nevertheless, the number of BIOS disk
    services has grown from six on the original IBM PC to 22 in the PS/2s.
    (See Figure 10-1.)

    All ROM BIOS disk services are invoked with interrupt 13H (decimal 19) and
    selected by loading the service number into the AH register. Disk drives
    are identified by a zero-based number passed in DL, with the high-order
    bit set to 1 to indicate a fixed disk. Thus the first diskette drive in
    the computer is identified by drive number 00H, and the first fixed disk
    is designated by drive number 80H.

    The ROM BIOS uses a set of descriptive parameter tables called disk-base
    tables to gain information about the capabilities of the disk controller
    hardware and the disk media. The ROM BIOS maintains the segmented
    addresses of the disk-base tables it uses in interrupt vectors: The
    address of the table for the current diskette drive is in the interrupt
    1EH vector (0000:0074H); addresses of tables for the first and second
    fixed drives are in interrupt vectors 41H (0000:0104H) and 46H
    (0000:0118H).

    For most programmers, the disk-base tables are an invisible part of the
    disk services. However, some disk-base parameters may occasionally need to
    be changed for special purposes. For this reason we include a brief
    description of the disk-base table toward the end of this chapter.

    The following sections describe each of the ROM BIOS services.

╓┌─┌───────────┌────────────────────────────────────┌────────────┌───────────╖
    Service     Description                          Diskette     Fixed Disk
    ──────────────────────────────────────────────────────────────────────────
    00H         Reset Disk System.                  x            x
    01H         Get Disk Status.                    x            x
    02H         Read Disk Sectors.                  x            x
    03H         Write Disk Sectors.                 x            x
    04H         Verify Disk Sectors.                x            x
    05H         Format Disk Track.                  x            x
    06H         Format PC/XT Fixed-Disk Track.                   x
    07H         Format PC/XT Fixed Disk.                         x
    08H         Get Disk-Drive Parameters.          x            x
    09H         Initialize Fixed-Disk Parameter                   x
                Tables.
    0AH         Read Long.                                       x
    Service     Description                          Diskette     Fixed Disk
    ──────────────────────────────────────────────────────────────────────────
    0AH         Read Long.                                       x
    0BH         Write Long.                                      x
    0CH         Seek to Cylinder.                                x
    0DH         Alternate Fixed-Disk Reset.                      x
    10H         Test for Drive Ready.                            x
    11H         Recalibrate Drive.                               x
    15H         Get Disk Type.                      x            x
    16H         Get Diskette Change Status.         x
    17H         Set Diskette Type.                  x
    18H         Set Media Type for Format.          x
    19H         Park Heads.                                      x
    1AH         Format ESDI Unit.                                x
    ──────────────────────────────────────────────────────────────────────────


    Figure 10-1.  The ROM BIOS disk services.

Service 00H (decimal 0): Reset Disk System

    Service 00H resets the disk controller and drive. This service does not
    affect the disk itself. Instead, a reset through service 00H forces the
    ROM BIOS disk-support routines to start from scratch for the next disk
    operation by recalibrating the disk drive's read/write head──an operation
    that positions the head on a certain track. This reset service is normally
    used after an error in any other drive operation.

    When you call service 00H for a fixed-disk drive, the ROM BIOS also resets
    the diskette-drive controller. If you want to reset the fixed-disk
    controller only, use service 0DH. (See page 207.)

Service 01H (decimal 1): Get Disk Status

    Service 01H (decimal 1) reports the disk status in register 0AH. The
    status is preserved after each disk operation, including the read, write,
    verify, and format operations. By preserving the disk status, an
    error-handling or error-reporting routine can be completely independent of
    the routines that operate the disk. This can be very useful. Under the
    right circumstances, you can rely on DOS or your programming language to
    drive the disk (a wise choice; see "Comments and Examples" on page 212),
    and at the same time have your program find out and report the details of
    what went wrong. See Figure 10-2 for details of the status byte.

╓┌─┌────────────────────────┌────────────────────────────────────────────────╖
    Value (hex)              Meaning
    ──────────────────────────────────────────────────────────────────────────
    00H                      No error
    01H                      Bad command
    02H                      Address mark not found
    03H                      Write attempted on
                            write-protected disk☼
    04H                      Sector not found
    05H                      Reset failed☼
    06H                      Diskette removed☼
    07H                      Bad parameter table☼
    08H                      DMA overrun
    09H                      DMA across 64 KB boundary
    0AH                      Bad sector flag☼
    0BH                      Bad cylinder☼
    0CH                      Bad media type☼
    0DH                      Invalid number of sectors on format☼
    0EH                      Control data address mark detected☼
    Value (hex)              Meaning
    ──────────────────────────────────────────────────────────────────────────
    0EH                      Control data address mark detected☼
    0FH                      DMA arbitration level out of range☼
    10H                      Bad CRC or ECC
    11H                      ECC corrected data error☼
    20H                      Controller failed
    40H                      Seek failed
    80H                      Time out
    AAH                      Drive not ready☼
    BBH                      Undefined error☼
    CCH                      Write fault☼
    EOH                      Status error☼
    FFH                      Sense operation failed
    ──────────────────────────────────────────────────────────────────────────


    Figure 10-2.  The value of the disk status byte returned in register AH by
    service 01H.

Service 02H (decimal 2): Read Disk Sectors

    Service 02H (decimal 2) reads one or more disk sectors into memory. If you
    want to read more than one sector, every sector must be on the same track
    and read/write head. This is largely because the ROM BIOS doesn't know how
    many sectors might be on a track, so it can't know when to switch from one
    head or track to another. Usually, this service is used for reading either
    individual sectors or an entire trackful of sectors for bulk operations
    such as DISKCOPY in DOS. Various registers are used for control
    information in a read operation. They are summarized in Figure 10-3.

    Parameters                           Status Results
    ──────────────────────────────────────────────────────────────────────────
    DL = drive number                    If CF = 0, then no error and AH = 0

    DH = head number                     If CF = 1, then error and AH contains
                                        service 01H status bits

    CH = cylinder number☼
    low-order 8 bits of cylinder
    number☼

    CL = sector number☼
    high-order 2 bits of cylinder number
    plus 6-bit sector number☼

    AL = number of sectors to be read
    ES:BX = address of buffer
    ──────────────────────────────────────────────────────────────────────────

    Figure 10-3.  The registers used for control information by the read,
    write, verify, and format services.

    DL contains the drive number, and DH contains the diskette side or
    fixed-disk read/write head number.

    CH and CL identify, for diskettes, the cylinder and sector number to be
    read. CH contains the cylinder number, which should be less than the total
    number of cylinders on the formatted diskette. (See Chapter 5 for a table
    of standard IBM formats.) Of course, the cylinder number can be higher
    with non-IBM formats or with some copy-protection schemes. CL contains the
    sector number.

    For fixed disks, there may be more than 256 cylinders, so the ROM BIOS
    requires you to specify a 10-bit cylinder number in CH and CL: You must
    place the 8 low-order bits of the cylinder number in CH. The 2 high-order
    bits of CL contain the 2 high-order bits of the cylinder number. The 6
    low-order bits of CL designate the sector number to be read. Don't forget
    that sectors are numbered from 1, unlike drives, cylinders, or heads
    (sides).

    AL contains the number of sectors to be read. For diskettes, this is
    normally either 1, 8, 9, 15, or 18. We are warned by IBM not to request 0
    sectors.

    ES:BX contains the buffer location. The location of the memory area where
    the data will be placed is provided by a segmented address given in this
    register pair.

    The data area should be big enough to accommodate as much as is read; keep
    in mind that while normal DOS sectors are 512 bytes, sectors can be as
    large as 1024 bytes. (See the format service that follows.) When this
    service reads more than one sector, it lays the sectors out in memory one
    right after another.

    CF (the carry flag) contains the error status of the operation. The result
    of the operation is actually reported through a combination of the carry
    flag and the AH register. If CF = 0, no error occurred, AH will also be 0,
    and, for a diskette, the number of sectors read will be returned in AL. If
    CF = 1, an error did occur, and AH will contain the status value detailed
    under service 01H, the status service.

    When using service 02H with a diskette drive or any other active diskette
    service, remember that the diskette-drive motor takes some time to reach a
    working speed and that none of these services waits for this to happen.
    Although our own experience with the ROM BIOS diskette services suggests
    that this is rarely a problem, IBM recommends that any program using these
    services try three times before assuming that an error is real and that it
    use the reset service between tries. The logic of the suggested operation
    is as follows (partly expressed in BASIC):

    10 ERROR COUNT = 0
    20 WHILE ERROR.COUNT < 3
    30 ' do read/write/verify/format operation
    40 ' error checking here: if no error goto 90
    50   ERROR.COUNT = ERROR.COUNT + 1
    60 ' do reset operation
    70 WEND
    80 ' act on error
    90 ' carry on after success

    Be sure to see the section on page 209 for the effect of the disk-base
    table on the reset operation.

Service 03H (decimal 3): Write Disk Sectors

    Service 03H (decimal 3) writes one or more sectors to a disk──the reverse
    of service 02H. All registers, details, and comments given for service
    02H also apply to service 03H. (Also see Figure 10-3.) The disk sectors
    must be formatted before they can be written to.

Service 04H (decimal 4) : Verify Disk Sectors

    Service 04H (decimal 4) verifies the contents of one or more disk sectors.
    This operation is not what many people think it is: No comparison is made
    between the data on the disk and the data in memory. The verification
    performed by this service simply checks that the sectors can be found and
    read and that the cyclical redundancy check (CRC) is correct. The CRC acts
    as a sophisticated parity check for the data in each sector and will
    detect most errors, such as lost or scrambled bits, very reliably.

    Most programmers use the verify service to check the results of a write
    operation after using service 03H, but you can verify any part of a disk
    at any time. The DOS FORMAT program, for example, verifies each track
    after it is formatted. However, many people regard verification as an
    unnecessary operation because the disk drives are so reliable and because
    ordinary error reporting works so well. Even DOS doesn't verify a write
    operation unless you ask it to with the VERIFY ON command.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    It's worth pausing here to note that there is nothing unusual or
    alarming about having "bad tracks" marked on a disk, particularly a
    fixed disk. In fact, it is quite common for a fixed disk to have a few
    bad patches on it. The DOS FORMAT program notices bad tracks and marks
    them as such in the disk's file-allocation table. Later, the bad-track
    marking tells DOS that these areas should be bypassed. Bad tracks are
    also common on diskettes; with a diskette, unlike a fixed disk, you have
    the option of throwing away the defective media and using only perfect
    disks.
    ──────────────────────────────────────────────────────────────────────────

    The verify service operates exactly as do the read and write services and
    uses the same registers. The only difference between them is that the
    verify operation does not use any memory area and therefore does not use
    the register pair ES:BX.

Service 05H (decimal 5) : Format Disk Track

    Service 05H (decimal 5) formats one track. The format service operates as
    do the read and write services except that you need not specify a sector
    number in CL. All other parameters are as shown in Figure 10-3.

    Because formatting is done one full track at a time, you cannot format
    individual sectors. However, on a diskette you can specify individual
    characteristics for each sector on a track.

    Every sector on a diskette track has 4 descriptive bytes associated with
    it. You specify these 4 bytes for each sector to be formatted by creating
    a table of 4-byte groups and passing the table's address in the register
    pair ES:BX. When you format a disk track, the 4-byte groups are written to
    the diskette immediately in front of the individual sectors in the track.
    The 4 bytes of data associated with a sector on the disk are known as
    address marks and are used by the disk controller to identify individual
    sectors during the read, write, and verify operations. The 4 bytes are
    referred to as C for cylinder, H for head, R for record (or sector
    number), and N for number of bytes per sector (also called the size code).

    When a sector is being read or written, the diskette controller searches
    the diskette track for the sector's ID, the essential part of which is R,
    the record or sector number. The cylinder and head parameters are not
    actually needed in this address mark because the read/write head is
    positioned mechanically at the proper track and the side is selected
    electronically, but they are recorded and tested as a safety check.

    The size code (N) can take on any one of the four standard values shown in
    Figure 10-4. The normal setting is code 2 (512 bytes).

    Sectors are numbered on the diskette in the order specified by R. On
    diskettes, the sectors are normally numbered in numeric sequence (unless
    rearranged for copy protection), but on fixed disks the order of the
    sectors can be rearranged (interleaved), either for better performance or
    to create timing differences for copy-protection purposes. The actual
    interleave used on a fixed disk depends on the capabilities of the
    disk-controller hardware. For example, the PC/XT's fixed disk has its
    sectors interleaved so that logically consecutive sectors are physically
    located six sectors apart.

    N              Sector Size (bytes)          Sector Size (KB)
    ──────────────────────────────────────────────────────────────────────────
    0               128                         1/8
    1               256                         1/4
    2               512                         1/2
    3               1024                        1
    ──────────────────────────────────────────────────────────────────────────

    Figure 10-4.  The four standard sizes of the N size code.

    To format a diskette track using service 05H, perform the following steps:

    1.  Call service 17H to inform the ROM BIOS what kind of diskette is to
        be formatted. (See page 208 for more about service 17H.) This service
        needs to be called only once.

    2.  Call service 18H to describe the diskette media to the ROM BIOS. (See
        page 209.)

    3.  Create a table of address marks for the track. There must be a 4-byte
        entry in the table for each sector. For example, for track 0, side 1
        of a typical nine-sector DOS diskette, the table would contain nine
        entries:

        0 1 1 2  0 1 2 2  0 1 3 2  ... 0 1 9 2

    4.  Call service 05H to format the track.

    The method for formatting a fixed-disk track is somewhat different. You
    should omit the calls to services 17H and 18H (steps 1 and 2 above)
    because there is no need to describe the disk media to the ROM BIOS. Also,
    with a PC/AT or PS/2, the table whose address you pass in 3 step has a
    format that consists only of alternating flag bytes (00H = good sector,
    80H = bad sector) and sector number (R) bytes. With a PC/XT, you don't
    need a table at all. Instead, you call service 05H with an interleave
    value in AL, and the ROM BIOS does the rest.

    You may want to verify the formatting process by following each call to
    service 05H with a call to service 04H.

    When a diskette track is formatted, the diskette drive pays attention to
    the diskette's index hole and uses it as a starting marker to format the
    track. The index hole is ignored in all other operations (read, write, or
    verify), and tracks are simply searched for by their address marks.

    Nothing in this format service specifies the initial data value written
    into each formatted sector of a diskette. That is controlled by the
    disk-base table. (See page 209.)

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Service 05H should not be used with ESDI drives in PS/2s. Use service
    1AH instead.
    ──────────────────────────────────────────────────────────────────────────

    Using Service 05H for Copy Protection

    Diskette tracks can be formatted in all sorts of ways, but DOS can only
    read certain formats. Consequently, some copy-protection schemes are based
    on an unconventional format that prevents the ROM BIOS or the operating
    system from successfully reading and copying data. You can choose from
    several different copy-protection methods:

    ■  You can rearrange the order of the sectors, which alters the access
        time in a way that the copy-protection scheme can detect.

    ■  You can squeeze more sectors onto a track (10 is about the outside
        limit for 512-byte sectors on a 360 KB diskette).

    ■  You can simply leave out a sector number.

    ■  You can add a sector with an oddball address mark (for example, you can
        make C = 45 or R = 22).

    ■  You can specify one or more sectors to be an unconventional size.

    Any of these techniques can be used either for copy protection or for
    changing the operating characteristics of the diskette. Depending on what
    options are used, a conventionally formatted diskette may have its
    copy-protection characteristics completely hidden from DOS.

Service 06H (decimal 6): Format PC/XT Fixed-Disk Track

    This service is provided only in the PC/XT fixed-disk ROM BIOS. This
    service commands the XT's fixed-disk controller to format a track in which
    the disk media is defective. The disk controller records which sectors are
    defective in a table located in a reserved cylinder. The register
    parameters are the same as those shown in Figure 10-3, except that
    register AL contains a sector interleave value and no address need be
    specified in ES:BX.

Service 07H (decimal 7): Format PC/XT Fixed Disk

    This service, like service 06H, is supported only in the PC/XT fixed-disk
    ROM BIOS. It formats the entire fixed-disk drive, starting at the cylinder
    number specified in CH and CL. Register parameters for service 07H are the
    same as for service 05H (Figure 10-3), except that register AL contains a
    sector interleave value and no head number need be specified in register
    DH.

Service 08H (decimal 8): Get Disk-Drive Parameters

    In the PC/AT and PS/2 BIOS, service 08H (decimal 8) returns disk-drive
    parameters for the drive whose number you specify in DL. DL reports the
    number of disk drives attached to the disk controller, so diskette and
    fixed-disk drive counts are reported separately. DH reports the maximum
    head number, CH returns the maximum cylinder number, and CL returns the
    highest valid sector number plus the 2 high-order bits of the maximum
    cylinder number.

    For diskette drives, the PC/AT ROM BIOS (after 1/10/84) and the PS/2 ROM
    BIOS also report the drive type in BL: 01H = 360 KB, 5-1/4 inch; 02H = 1.2
    MB, 5-1/4 inch; 03H = 720 KB, 3-1/2 inch; 04H = 1.44 MB, 3-1/2 inch.

Service 09H (decimal 9): Initialize Fixed-Disk Parameter Tables

    Service 09H (decimal 9) establishes the disk-base tables for two
    fixed-disk drives for the PC/AT or PS/2 ROM BIOS. Call this service with a
    valid fixed-disk drive number in DL and with the interrupt 41H and 46H
    vectors containing the addresses of disk-base tables for two different
    fixed-disk drives. Because fixed disks are nonremovable, this service
    should only be used to install a "foreign" disk drive not recognized by
    the ROM BIOS or the operating system. For more details, see the IBM BIOS
    Interface Technical Reference Manual.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Do not use service 09H for PS/2 ESDI drives.
    ──────────────────────────────────────────────────────────────────────────

Service 0AH and 0BH (decimal 10 and 11): Read and Write Long

    Service 0AH (decimal 10) reads, and service 0BH (decimal 11) writes,
    "long" sectors on PC/AT or PS/2 fixed disks. A long sector consists of a
    sector of data plus a 4- or 6-byte error correction code (ECC) that the
    fixed-disk controller uses for error checking and error correction of the
    sector's data. These services use the same register parameters as parallel
    services 02H and 03H.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    The IBM BIOS Interface Technical Reference Manual states that services
    0AH and 0BH are "reserved for diagnostics," so stay away from these
    services unless you have a very good reason for using them.
    ──────────────────────────────────────────────────────────────────────────

Service 0CH (decimal 12): Seek to Cylinder

    Service 0CH (decimal 12) performs a seek operation that positions the disk
    read/write heads at a particular cylinder on a fixed disk. Register DL
    provides the drive ID, DH provides the head number, and CH and CL provide
    the 10-bit cylinder number.

Service 0DH (decimal 13): Alternate Fixed-Disk Reset

    For fixed-disk drives, this service is the same as service 00H (reset disk
    system) except that the ROM BIOS does not automatically reset the
    diskette-drive controller. This service is available only in the PC/AT and
    PS/2 ROM BIOS; it should not be used with the PS/2 ESDI drives.

Service 10H (decimal 16): Test for Drive Ready

    Service 10H (decimal 16) tests to see if a fixed-disk drive is ready. The
    drive is specified in register DL and the status is returned in register
    AH.

Service 11H (decimal 17): Recalibrate Drive

    Service 11H (decimal 17) recalibrates a fixed-disk drive. The drive is
    specified in register DL and the status is returned in register AH.

Service 15H (decimal 21): Get Disk Type

    Service 15H (decimal 21) returns information about the type of disk drive
    installed in a PC/AT or PS/2. Given the drive ID in register DL, it
    returns in register AH one of four disk-type indicators. If AH = 00H, no
    drive is present for the specified drive ID; if AH = 01H, a diskette drive
    that cannot sense when the disk has been changed (typical of many PC and
    PC/XT disk drives) is installed; if AH = 02H, a diskette drive that can
    sense a change of disks (drives like the AT's high-capacity diskette
    drives) is installed; finally, if AH = 03H, a fixed-disk drive is
    installed. When the drive type is 3, the register pair CX:DX contains a
    4-byte integer that gives the total number of disk sectors on the drive.

Service 16H (decimal 22): Diskette Change Status

    In the PC/AT and PS/2 ROM BIOS, service 16H (decimal 22) reports whether
    the diskette in the drive specified in DL was changed. The status is
    reported in AH (Figure 10-5).

    Remember several important points about service 16H. First, before you use
    this ROM BIOS service, call service 15H to ensure that the diskette-drive
    hardware can sense when a diskette is changed. Also, you should follow a
    call to service 16H with a call to service 17H (Set Diskette Type)
    whenever you detect a diskette change.

    Keep in mind that the hardware can only detect whether the diskette-drive
    door was opened; it cannot tell whether a different physical diskette was
    placed in the drive. You must still read data from the diskette to
    determine whether a different diskette is actually in the drive. Data such
    as a volume label, the root directory, or a file allocation table can help
    to uniquely identify a diskette.

    Value                    Meaning
    ──────────────────────────────────────────────────────────────────────────
    AH = 00H                 No diskette change.
    AH = 01H                 Service called with invalid parameter.
    AH = 06H                 Diskette has been changed.
    AH = 80H                 Diskette drive not ready.
    ──────────────────────────────────────────────────────────────────────────

    Figure 10-5.  Status values returned in AH by diskette service 16H.

Service 17H (decimal 23): Set Diskette Type

    In the PC/AT and PS/2 ROM BIOS, service 17H (decimal 23) describes the
    type of diskette in use in a specified drive. Call this service with a
    drive ID in register DL and a diskette-type ID in AL. (See Figure 10-6.)
    The ROM BIOS resets the diskette change status if it was previously set.
    It then records the diskette type in an internal status variable that can
    be referenced by other ROM BIOS services.

    Value                    Meaning
    ──────────────────────────────────────────────────────────────────────────
    AL = 01H                 320/360 KB diskette in 360 KB drive
    AL = 02H                 360 KB diskette in 1.2 MB drive
    AL = 03H                 1.2 MB diskette in 1.2 MB drive
    AL = 04H                 720 KB diskette in 720 KB drive (PC/AT or PS/2)
                            or 720 KB or 1.44 MB diskette in 1.44 MB drive
                            (PS/2)
    ──────────────────────────────────────────────────────────────────────────

    Figure 10-6.  Diskette-type ID values for diskette service 17H.

Service 18H (decimal 24): Set Media Type for Format

    Service 18H (decimal 24) describes the number of tracks and sectors per
    track to the ROM BIOS before it formats a diskette in a specified drive.
    These values are placed in registers CH, CL, and DL when you call this
    service (see Figure 10-3). This service is available only in the PC/AT
    and PS/2 ROM BIOS.

Service 19H (decimal 25): Park Heads

    Service 19H (decimal 25) parks the drive heads for the PS/2 fixed disk
    whose drive ID you specify in register DL. Calling this function causes
    the disk controller to move the drive heads away from the portion of the
    disk media where data is stored. This is a good idea if you plan to move
    the computer because it may prevent mechanical damage to the heads or to
    the surfaces of the disk media. On the Reference Diskette that accompanies
    every PS/2, IBM supplies a utility program that uses this ROM BIOS service
    to park the heads.

Service 1AH (decimal 26): Format ESDI Unit

    This service is provided only in the ROM BIOS of the ESDI (Enhanced Small
    Device Interface) adapter for high-capacity PS/2 fixed disks. It formats a
    fixed disk attached to this adapter. See the IBM BIOS Interface Technical
    Reference Manual for more details.


Disk-Base Tables

    As we mentioned near the beginning of this chapter, the ROM BIOS maintains
    a set of disk-base tables that describe the capabilities of each diskette
    drive and fixed-disk drive in the computer. During system startup, the ROM
    BIOS associates an appropriate disk-base table with each fixed-disk drive.
    (In the PC/AT and PS/2s, a data byte in the nonvolatile CMOS RAM
    designates which of several ROM tables to use.) There is no reason to
    change the parameters in the fixed-disk tables once they have been set up
    by the ROM BIOS. Doing so may lead to garbled data on the disk.

    The situation is different in the case of diskette drives. The parameters
    in the disk-base table associated with a diskette drive may need to be
    updated to accommodate different diskette formats. We'll spend the next
    few pages describing the structure of a disk-base table for a diskette
    drive and showing how a modified table can be useful.

    The disk-base table comprises the 11 bytes shown in Figure 10-7.

    Bytes 0 and 1 are referred to as the specify bytes. They are part of the
    command strings sent to the diskette-drive controller, which in IBM's
    technical reference manuals is also called the NEC (Nippon Electric
    Company) controller. The 4 high-order bits of byte 0 specify the step-rate
    time (SRT), which is the time the drive controller allows for the drive
    heads to move from track to track. The default ROM BIOS SRT value for
    diskette drives is conservative; for some drives, DOS reduces this value
    to speed up drive performance.

    Byte 2 specifies how long the diskette motor is to be left running after
    each operation. The motor is left on in case the diskette is needed again.
    The value is in units of clock ticks (roughly 18.2 ticks per second). All
    versions of the table have this set to 37 (25H)──meaning that the motor
    stays on for about 2 seconds.

    Offset         Use
    ──────────────────────────────────────────────────────────────────────────
    00H            Specify byte 1: step-rate time, head-unload time
    01H            Specify byte 2: head-load time, DMA mode
    02H            Wait time until diskette motor turned off
    03H            Bytes per sector: 0 = 128; 1 = 256; 2 = 512; 3 = 1024
    04H            Last sector number
    05H            Gap length between sectors for read/write operations
    06H            Data length when sector length not specified
    07H            Gap length between sectors for formatting operations
    08H            Data value stored in formatted sectors
    09H            Head-settle time
    0AH            Motor start-up time
    ──────────────────────────────────────────────────────────────────────────

    Figure 10-7.  The use of the 11 bytes in the disk-base table for a
    diskette drive.

    Byte 3 gives the sector length code──the same N code used in the format
    operation. (See page 203 under service 05H.) This is normally set to 2,
    representing the customary sector length of 512 bytes. In any read, write,
    or verify operation, the length code in the disk base must be set to the
    proper value, especially when working with sectors of unconventional
    length.

    Byte 4 gives the sector number of the last sector on the track.

    Byte 5 specifies the gap size between sectors, which is used when reading
    or writing data. In effect, it tells the diskette-drive controller how
    long to wait before looking for the next sector's address marking so that
    it can avoid looking at nonsense on the diskette. This length of time is
    known as the search gap.

    Byte 6 is called the data transfer length (DTL) and is set to FFH (decimal
    255). This byte sets the maximum data length when the sector length is not
    specified.

    Byte 7 sets the gap size between sectors when a track is formatted.
    Naturally, it is bigger than the search gap at offset 5. The normal format
    gap-size value varies with the diskette drive. For example, the value is
    54H for the PC/AT's 1.2 MB drive and 6CH for 3-1/2-inch PS/2 diskette
    drives.

    Byte 8 provides the data value stored in each byte of the sectors when a
    diskette track is formatted. The default value is F6H, the division
    symbol. You can change it to anything you want, if you can think of a good
    reason to do so.

    Byte 9 sets the head-settle time, which is how long the system waits for
    vibration to end after seeking to a new track. This value also depends on
    the drive hardware. On the original PC, the value was 19H (25
    milliseconds), but the ROM BIOS default for the PC/AT 1.2 MB drive and the
    PS/2 diskette drives is only 0FH (15 milliseconds).

    Byte 0AH (decimal 10), the final byte of the disk-base table, sets the
    amount of time allowed for the diskette-drive motor to get up to speed and
    is measured in 1/8 seconds.

    It's fun to tinker with the disk-base values; there are enough of them to
    give you an opportunity for all sorts of excitement and mischief. To do
    this, you need to write a program that builds your customized disk-base
    table in a buffer in memory. Then tell the ROM BIOS to use your table by
    carrying out the following steps:

    1.  Save the segmented address of the current disk base table. (This is
        the value in the interrupt 1EH vector, 0000:0078H.)

    2.  Store the segmented address of your modified table in the interrupt
        1EH vector.

    3.  Call ROM BIOS disk service 00H to reset the disk system. The ROM BIOS
        will reinitialize the diskette-drive controller with parameters from
        your table.

    When you're finished, be sure to restore the address of the previous
    disk-base table and reset the disk system again.


Comments and Examples

    In the last chapter, where we covered the ROM BIOS video services, we
    were able to recommend that you make direct use of the ROM BIOS services
    when DOS or your programming language does not provide the support you
    need. But in the case of the ROM BIOS disk services, things are different.

    For the disk operations that a program would normally want performed, the
    manipulation and supervision of disk input/output should be left to DOS
    and performed either through the conventional file services of a
    programming language or through the DOS services. (See Chapters 14
    through 18.) There are several reasons for this. The main reason is that
    it is far easier to let DOS do the work. The DOS facilities take care of
    all fundamental disk operations, including formatting and labeling disks,
    cataloging files, and basic read and write operations. Most of the time it
    isn't necessary to go any deeper into the system software. However, there
    are times when you may want to work with disk data in an absolute and
    precise way, usually for copy protection. This is when you should use the
    ROM BIOS services.

    For our example, we'll use C to call a couple of subroutines that use ROM
    BIOS functions 02H and 03H to read and write absolute disk sectors. We
    start by defining how we want the interface to look from the C side, which
    the following program illustrates. If you are not familiar with C and
    don't want to decipher this routine, you can pass it by and still get the
    full benefit by studying the assembly-language interface example that
    follows it.

    main()
    {
            unsigned char Buffer[512];      /* a 512-byte buffer for reading */
                                            /*  or writing one sector */

            int     Drive;
            int     C,H,R;                  /* address mark parameters */
            int     StatusCode;             /* status value returned by BIOS */

            StatusCode = ReadSector( Drive, C, H, R, (char far *)Buffer );
            StatusCode = WriteSector( Drive, C, H, R, (char far *)Buffer );
    }

    This C fragment shows how you would call the ROM BIOS read and write
    services from a high-level language. The functions ReadSector() and
    WriteSector() are two assembly-language routines that use interrupt 13H to
    interface with the ROM BIOS disk services. The parameters are familiar: C,
    H, and R are the cylinder, head, and sector numbers we described earlier.
    The C compiler passes the buffer address as a segment and offset because
    of the explicit type cast (char far *).

    The form of the assembly-language interface should be familiar if you read
    the general remarks in Chapter 8 on page 161 or studied the example in
    Chapter 9 on page 194. The assembly-language routines themselves copy the
    parameters from the stack into the registers. The trick is in how the
    cylinder number is processed: The 2 high-order bits of the 10-bit cylinder
    number are combined with the 6-bit sector number in CL.

    _TEXT           SEGMENT byte public 'CODE'
                    ASSUME  cs:_TEXT

                    PUBLIC  _ReadSector
    _ReadSector     PROC    near            ; routine to read one sector

                    push    bp
                    mov     bp,sp           ; address the stack through BP

                    mov     ah,2            ; AH = ROM BIOS service number 02h
                    call    DiskService

                    pop     bp              ; restore previous BP
                    ret

    _ReadSector     ENDP

                    PUBLIC  _WriteSector
    _WriteSector    PROC    near            ; routine to write one sector

                    push    bp
                    mov     bp,sp

                    mov     ah,3            ; AH = ROM BIOS service number 03h
                    call    DiskService

                    pop     bp
                    ret

    _WriteSector    ENDP


    DiskService     PROC    near            ; Call with AH = ROM BIOS service n

                    push    ax              ; save service number on stack
                    mov     dl,[bp+4]       ; DL = drive ID
                    mov     ax,[bp+6]       ; AX = cylinder number
                    mov     dh,[bp+8]       ; DH = head number
                    mov     cl,[bp+10]      ; CL = sector number
                    and     cl,00111111b    ; limit sector number to 6 bits
                    les     bx,[bp+12]      ; ES:BX -> buffer

                    ror     ah,1            ; move bits 8 and 9
                    ror     ah,1            ;  of cylinder number
                                            ;  to bits 6 and 7 of AH
                    and     ah,11000000b
                    mov     ch,al           ; CH = bits 0-7 of cylinder number
                    or      cl,ah           ; copy bits 8 and 9
                                            ;  of cylinder number
                                            ;  to bits 6 and 7 of CL

                    pop     ax              ; AH = ROM BIOS service number
                    mov     al,1            ; AL = 1 (# of sectors to read/writ
                    int     13h             ; call ROM BIOS service

                    mov     al,ah           ; leave return status
                    xor     ah,ah           ; # in AX

                    ret

    DiskService     ENDP

    _TEXT           ENDS

    Note how the code that copies the parameters from the stack to the
    registers is consolidated in a subroutine, DiskService. When you work with
    the ROM BIOS disk services, you'll find that you can often use subroutines
    similar to DiskService because most of the ROM BIOS disk services use
    similar parameter register assignments.



────────────────────────────────────────────────────────────────────────────
Chapter 11  ROM BIOS Keyboard Services

    Accessing the Keyboard Services
    Service 00H (decimal 0): Read Next Keyboard Character
    Service 01H (decimal 1): Report Whether Character Ready
    Service 02H (decimal 2): Get Shift Status
    Service 03H (decimal 3): Set Typematic Rate and Delay
    Service 05H (decimal 5): Keyboard Write
    Service 10H (decimal 16): Extended Keyboard Read
    Service 11H (decimal 17): Get Extended Keystroke Status
    Service 12H (decimal 18): Get Extended Shift Status

    Comments and Example

    Although the ROM BIOS services for the keyboard are not as numerous or as
    complicated as those for the display screen (Chapter 9) and for diskette
    drives (Chapter 10), the ROM BIOS keyboard services are important enough
    to warrant their own chapter. All other ROM BIOS services are gathered
    together in Chapter 12.


Accessing the Keyboard Services

    The keyboard services are invoked with interrupt 16H (decimal 22). As with
    all other ROM BIOS services, the keyboard services are selected according
    to the value in register AH. Figure 11-1 lists the ROM BIOS keyboard
    services.

    Service                  Description
    ──────────────────────────────────────────────────────────────────────────
    00H                      Read Next Keyboard Character.
    01H                      Report Whether Character Ready.
    02H                      Get Shift Status.
    03H                      Set Typematic Rate and Delay.
    05H                      Keyboard Write.
    10H                      Extended Keyboard Read.
    11H                      Get Extended Keystroke Status.
    12H                      Get Extended Shift Status.
    ──────────────────────────────────────────────────────────────────────────

    Figure 11-1.  The ROM BIOS keyboard services.

Service 00H (decimal 0): Read Next Keyboard Character

    Service 00H (decimal 0) reports the next keyboard input character. If a
    character is ready in the ROM BIOS keyboard buffer, it is reported
    immediately. If not, the service waits until one is ready. As described on
    page 134, each keyboard character is reported as a pair of bytes, which
    we call the main and auxiliary bytes. The main byte, returned in AL, is
    either 0 for special characters (such as the function keys) or else an
    ASCII code for ordinary ASCII characters. The auxiliary byte, returned in
    AH, is either the character ID for special characters or the standard
    PC-keyboard scan code that identifies which key was pressed.

    If no character is waiting in the keyboard buffer when service 00H is
    called, the service waits──essentially freezing the program that called
    it──until a character does appear. The service we'll discuss next allows a
    program to test for keyboard input without the risk of suspending program
    execution.

    Contrary to what some versions of the IBM PC Technical Reference Manual
    suggest, services 00H and 01H apply to both ordinary ASCII characters and
    special characters, such as function keys.

Service 01H (decimal 1): Report Whether Character Ready

    Service 01H (decimal 1) reports whether a keyboard input character is
    ready. This is a sneak-preview or look-ahead operation: Even though the
    character is reported, it remains in the keyboard input buffer of the ROM
    BIOS until it is removed by service 00H. The zero flag (ZF) is used as the
    signal: 1 indicates no input is ready; 0 indicates a character is ready.
    Take care not to be confused by the apparent reversal of the flag values──
    1 means no and 0 means yes, in this instance. When a character is ready
    (ZF = 0), it is reported in AL and AH, just as it is with service 00H.

    This service is particularly useful for two commonly performed program
    operations. One is test-and-go, where a program checks for keyboard action
    but needs to continue running if there is none. Usually, this is done to
    allow an ongoing process to be interrupted by a keystroke. The other
    common operation is clearing the keyboard buffer. Programs can generally
    allow users to type ahead, entering commands in advance; however, in some
    operations (for example, at safety-check points, such as "OK to end?")
    this practice can be unwise. In these circumstances, programs need to be
    able to flush the keyboard buffer, clearing it of any input. The keyboard
    buffer is flushed by using services 00H and 01H, as this program outline
    demonstrates:

    call service 01H to test whether a character is available in the
    keyboard buffer
    WHILE (ZF = 0)
            BEGIN
            call service 00H to remove character from keyboard buffer
            call service 01H to test for another character
            END

    Contrary to what some technical reference manuals suggest, services 00H
    and 01H apply to both ordinary ASCII characters and special characters,
    such as function keys.

Service 02H (decimal 2): Get Shift Status

    Service 02H (decimal 2) reports the shift status in register AL. The shift
    status is taken bit by bit from the first keyboard status byte, which is
    kept at memory location 0040:0017H. Figure 11-2 describes the settings of
    each bit. (See page 137 for information about the other keyboard status
    byte at 0040:0018H.)

        Bit
    7 6 5 4 3 2 1 0          Meaning
    ──────────────────────────────────────────────────────────────────────────
    X . . . . . . .          Insert state: 1 = active
    . X . . . . . .          CapsLock: 1 = active
    . . X . . . . .          NumLock: 1 = active
    . . . X . . . .          ScrollLock: 1 = active
    . . . . X . . .          1 = Alt pressed
    . . . . . X . .          1 = Ctrl pressed
    . . . . . . X .          1 = Left Shift pressed
    . . . . . . . X          1 = Right Shift pressed
    ──────────────────────────────────────────────────────────────────────────

    Figure 11-2.  The keyboard status bits returned to register AL using
    keyboard service 02H.

    Generally, service 02H and the status bit information are not particularly
    useful. If you plan to do some fancy keyboard programming, however, they
    can come in handy. You'll frequently see them used in programs that do
    unconventional things, such as differentiating between the left and right
    Shift keys.

Service 03H (decimal 3): Set Typematic Rate and Delay

    Service 03H (decimal 3) was introduced with the PCjr, but has been
    supported in both the PC/AT (in ROM BIOS versions dated 11/15/85 and
    later) and in all PS/2s. It lets you adjust the rate at which the
    keyboard's typematic function operates; that is, the rate at which a
    keystroke repeats automatically while you hold down a key. This service
    also lets you to adjust the typematic delay (the amount of time you can
    hold down a key before the typematic repeat function takes effect).

    To use this service, call interrupt 16H with AH = 03H, and AL = 05H. BL
    must contain a value between 00H and 1FH (decimal 31) that indicates the
    desired typematic rate (Figure 11-3). The value in BH specifies the
    typematic delay (Figure 11-4). The default typematic rate for the PC/AT
    is 10 characters per second; for PS/2s it is 10.9 characters per second.
    The default delay for both the PC/AT and PS/2s is 500 ms.

    ──────────────────────────────────────────────────────────────────────────
    00H = 30.0               0BH = 10.9              16H = 4.3
    01H = 26.7               0CH = 10.0              17H = 4.0
    02H = 24.0               0DH = 9.2               18H = 3.7
    03H = 21.8               0EH = 8.6               19H = 3.3
    04H = 20.0               0FH = 8.0               1AH = 3.0
    05H = 18.5               10H = 7.5               1BH = 2.7
    06H = 17.1               11H = 6.7               1CH = 2.5
    07H = 16.0               12H = 6.0               1DH = 2.3
    08H = 15.0               13H = 5.5               1EH = 2.1
    09H = 13.3               14H = 5.0               1FH = 2.0
    0AH = 12.0               15H = 4.6               20H through FFH -
                                                    Reserved
    ──────────────────────────────────────────────────────────────────────────

    Figure 11-3.  Values for register BL in keyboard service 03H. The rates
    shown are in characters per second.

    ──────────────────────────────────────────────────────────────────────────
    00H = 250
    01H = 500
    02H = 750
    03H = 1000
    04H through FFH - Reserved
    ──────────────────────────────────────────────────────────────────────────

    Figure 11-4.  Values for register BH in keyboard service 03H. The delay
    values shown are in milliseconds.

Service 05H (decimal 5): Keyboard Write

    Service 05H (decimal 5) is handy because it lets you store keystroke data
    in the keyboard buffer as if a key were pressed. You must supply an ASCII
    code in register CL and a keyboard scan code in CH. The ROM BIOS places
    these codes into the keyboard buffer following any keystroke data that may
    already be present there.

    Service 05H lets a program process input as if it were typed at the
    keyboard. For example, if you call service 05H with the following data,
    the result is the same as if the keys R-U-N-Enter were pressed:

    CH = 13H, CL = 52H, call service 05H (the R key)
    CH = 16H, CL = 55H, call service 05H (the U key)
    CH = 31H, CL = 4EH, call service 05H (the N key)
    CH = 1CH, CL = 0DH, call service 05H (the Enter key)

    If your program did this when it detected that the F2 function key was
    pressed, the result would be the same as if the word RUN followed by the
    Enter key had been typed. (If you use BASIC, this should sound familiar.)

    Beware: The keyboard buffer can hold only 15 character codes, so you can
    call service 05H a maximum of 15 consecutive times before the buffer
    overflows and the function fails.

Service 10H (decimal 16): Extended Keyboard Read

    Service 10H (decimal 16) performs the same function as service 00H, but
    lets you take full advantage of the 101/102-key keyboard: It returns ASCII
    character codes and keyboard scan codes for keys that don't exist on the
    older 84-key keyboard. For example, the extra F11 and F12 keys found on
    the 101/102-key keyboard are ignored by service 00H but can be read using
    service 10H.

    Another example: On the 101/102-key keyboard, an extra Enter key appears
    to the right of the numeric keypad. When this key is pressed, service 00H
    returns the same character code (0DH) and scan code (1CH) as it does for
    the standard Enter key. Service 10H lets you differentiate between the two
    Enter keys because it returns a different scan code (E0H) for the keypad
    Enter key.

Service 11H (decimal 17): Get Extended Keystroke Status

    Service 11H (decimal 17) is analogous to service 01H, but it, too, lets
    you use the 101/102-key keyboard to full advantage. The scan codes
    returned in register AH by this service distinguish between different keys
    on the 101/102-key keyboard.

Service 12H (decimal 18): Get Extended Shift Status

    Like services 10H and 11H, service 12H (decimal 18) provides additional
    support for the 101/102-key keyboard. Service 12H expands the function of
    service 02H to provide information on the extra shift keys provided on the
    101/102-key keyboard. This service returns the same value in register AL
    as service 02H (Figure 11-2), but it also returns an additional byte of
    flags in register AH (Figure 11-5).

    This extra byte indicates the status of each individual Ctrl and Alt key.
    It also indicates whether the Sys Req, Caps Lock, Num Lock, or Scroll Lock
    keys are currently pressed. This information lets you detect when a user
    presses any combination of these keys at the same time.

        Bit                Meaning
    7 6 5 4 3 2 1 0
    ──────────────────────────────────────────────────────────────────────────
    X . . . . . . .          Sys Req pressed
    . X . . . . . .          Caps Lock pressed
    . . X . . . . .          Num Lock pressed
    . . . X . . . .          Scroll Lock pressed
    . . . . X . . .          Right Alt pressed
    . . . . . X . .          Right Ctrl pressed
    . . . . . . X .          Left Alt pressed
    . . . . . . . X          Left Ctrl pressed
    ──────────────────────────────────────────────────────────────────────────

    Figure 11-5.  Extended keyboard status bits returned in register AH by
    keyboard service 12H.


Comments and Example

    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.



────────────────────────────────────────────────────────────────────────────
Chapter 12  Miscellaneous Services

    RS-232 Serial Communications Services
    Service 00H (decimal 0): Initialize Serial Port
    Service 01H (decimal 1): Send Out One Character
    Service 02H (decimal 2): Receive One Character
    Service 03H (decimal 3): Get Serial Port Status
    Service 04H (decimal 4): Initialize Extended Serial Port
    Service 05H (decimal 5): Control Extended Communications Port

    Miscellaneous System Services
    Service 00H (decimal 0): Turn On Cassette Motor
    Service 01H (decimal 1): Turn Off Cassette Motor
    Service 02H (decimal 2): Read Cassette Data Blocks
    Service 03H (decimal 3): Write Cassette Data Blocks
    Service 21H (decimal 33): Read or Write PS/2 POST Error Log
    Service 83H (decimal 131): Start or Cancel Interval Timer
    Service 84H (decimal 132): Read Joystick Input
    Service 86H (decimal 134): Wait During a Specified Interval
    Service 87H (decimal 135): Protected-Mode Data Move
    Service 88H (decimal 136): Get Extended Memory Size
    Service 89H (decimal 137): Switch to Protected Mode
    Service C0H (decimal 192): Get System Configuration Parameters
    Service C1H (decimal 193): Get ROM BIOS Extended Data Segment
    Service C2H (decimal 194): Pointing-Device Interface
    Service C3H (decimal 195): Enable/Disable Watchdog Timer
    Service C4H (decimal 196): Programmable Option Select

    ROM BIOS Hooks
    Service 4FH (decimal 79): Keyboard Intercept
    Service 80H (decimal 128): Device Open
    Service 81H (decimal 129): Device Close
    Service 82H (decimal 130): Program Termination
    Service 85H (decimal 133): Sys Req Keystroke
    Service 90H (decimal 144): Device Busy
    Service 91H (decimal 145): Interrupt Complete

    Printer Services
    Service 00H (decimal 0): Send 1 Byte to Printer
    Service 01H (decimal 1): Initialize Printer
    Service 02H (decimal 2): Get Printer Status

    Other Services
    Interrupt 05H (decimal 5): Print-Screen Service
    Interrupt 11H (decimal 17): Equipment-List Service
    Interrupt 12H (decimal 18): Memory-Size Service
    Interrupt 18H (decimal 24): ROM BASIC Loader Service
    Interrupt 19H (decimal 25): Bootstrap Loader Service
    Interrupt 1AH (decimal 26): Time-of-Day Services

    In this chapter, we'll be covering all ROM BIOS services that are either
    not important enough or not complex enough to warrant their own chapters:
    RS-232 serial communications services, system services, ROM BIOS hooks,
    and printer services. We'll also cover some services that are odd enough
    to be considered miscellaneous, even in a chapter of miscellany.


RS-232 Serial Communications Services

    This section discusses the RS-232 asynchronous serial communications port
    services in the ROM BIOS. Before we begin describing the ROM BIOS services
    in detail, you need to know a few important things about the serial
    communications port, particularly the terminology. We assume you have a
    basic understanding of data communications, but if you discover that you
    don't understand the following information, turn to one of the many
    specialty books on communications for some background information.

    Many words are used to describe the RS-232 data path in and out of the
    computer. One of the most common is port. However, this use of the word
    port is completely different from our previous use of the word. Throughout
    most of this book, we have used port to refer to the addressable paths
    used by the 8088 microprocessor to talk to other parts of the computer
    within the confines of the computer's circuitry. All references to port
    numbers, the BASIC statements INP and OUT, and the assembly-language
    operations IN and OUT refer to these addressable ports. The RS-232
    asynchronous serial communications port differs because it is a
    general-purpose I/O path, which can be used to interconnect many kinds of
    information-processing equipment outside the computer. Typically, the
    serial ports are used for telecommunications (meaning a telephone
    connection through a modem) or to send data to a serial-type printer.

    Four serial communications services are common to all IBM models. These
    services are invoked with interrupt 14H (decimal 20), selected through
    register AH, and numbered 00H through 03H. (See Figure 12-1.) The PS/2
    ROM BIOS contains two additional services that provide extended support
    for the more capable PS/2 serial port.

    The original design of the IBM personal computers allowed up to seven
    serial ports to be added, although a computer rarely uses more than one or
    two. The PS/2 ROM BIOS explicitly supports only four serial ports. No
    matter how many serial ports exist, the serial port number is specified in
    the DX register for all ROM BIOS serial communications services. The first
    serial port is indicated by 00H in DX.

    Service            Description
    ──────────────────────────────────────────────────────────────────────────
    00H                Initialize Serial Port.
    01H                Send Out One Character.
    02H                Receive One Character.
    03H                Get Serial Port Status.
    04H                Initialize Extended Serial Port.
    05H                Control Extended Communication Port.
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-1.  The RS-232 serial port services available through interrupt
    14H (decimal 20).

Service 00H (decimal 0): Initialize Serial Port

    Service 00H (decimal 0) sets the various RS-232 parameters and initializes
    the serial port. It sets four parameters: the baud rate, the parity, the
    number of stop bits, and the character size (also called the word length).
    The parameters are combined into one 8-bit code, which is placed in the AL
    register with the format shown in Figure 12-2. The bit settings for each
    code are shown in Figure 12-3. When the service is finished, the
    communication port status is reported in AX, just as it is for service
    03H. (See service 03H for the details.)

        Bit
    7 6 5 4 3 2 1 0          Use
    ──────────────────────────────────────────────────────────────────────────
    X X X . . . . .          Baud-rate code
    . . . X X . . .          Parity code
    . . . . . X . .          Stop-bit code
    . . . . . . X X          Character-size code
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-2.  The bit order of the serial port parameters passed in
    register AL to service 00H.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Although it is painfully slow, 300 baud used to be the most commonly
    used baud rate for personal computers using modems. A rate of 1200 baud
    is now the most common, particularly for serious applications that
    require faster transmission, but widespread use of at least 2400 baud
    communications is inevitable.
    ──────────────────────────────────────────────────────────────────────────

                            BAUD RATE
    Bit
    7 6 5                    Value                   Bits per Second
    ──────────────────────────────────────────────────────────────────────────
    0 0 0                    0                        110
    0 0 1                    1                        150
    0 1 0                    2                        300
    0 1 1                    3                        600
    1 0 0                    4                       1200
    1 0 1                    5                       2400
    1 1 0                    6                       4800
    1 1 1                    7                       9600
    ──────────────────────────────────────────────────────────────────────────

                            STOP BITS
    Bit                      Value                   Meaning
    2
    ──────────────────────────────────────────────────────────────────────────
    0                        0                       One
    1                        1                       Two
    ──────────────────────────────────────────────────────────────────────────

                            PARITY
    Bit                      Value                   Meaning
    4 3
    ──────────────────────────────────────────────────────────────────────────
    0 0                      0                       None
    0 1                      1                       Odd parity
    1 0                      2                       None
    1 1                      3                       Even parity
    ──────────────────────────────────────────────────────────────────────────

                            CHARACTER SIZE
    Bit                      Value                   Meaning
    1 0
    ──────────────────────────────────────────────────────────────────────────
    0 0                      0                       Not used
    0 1                      1                       Not used
    1 0                      2                       7-bit☼
    1 1                      3                       8-bit
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-3.  The bit settings for the four serial port parameters for
    service 00H.

Service 01H (decimal 1): Send Out One Character

    Service 01H (decimal 1) transmits one character out the serial port
    specified in DX. When you call service 01H, you place the character to be
    transmitted in AL. When service 01H returns, it reports the status of the
    communications port. If AH = 00H, then the service was successful.
    Otherwise bit 7 of AH indicates that an error occurred, and the other bits
    of AH report the type of error. These bits are outlined in the discussion
    of service 03H, the status service.

    The error report supplied through this service has one anomaly: Because
    bit 7 reports that an error has occurred, it is not available to indicate
    a time-out error (as the details in service 03H would suggest).
    Consequently, when this service or service 02H reports an error, the
    simplest and most reliable way to check the nature of the error is to use
    the complete status report given by service 03H, rather than the
    less-complete status code returned with the error through services 01H and
    02H.

Service 02H (decimal 2): Receive One Character

    Service 02H (decimal 2) receives one character from the communications
    line specified in DX and returns it in the AL register. The service waits
    for a character or any signal that indicates the completion of the
    service, such as a time-out. AH reports the success or failure of the
    service in bit 7, as explained in the discussion of service 01H. Again,
    consider the advice under service 01H for error handling and see service
    03H for the error codes.

Service 03H (decimal 3): Get Serial Port Status

    Service 03H (decimal 3) returns the complete serial port status in the AX
    register. The 16 status bits in AX are divided into two groups: AH reports
    the line status (which is also reported when errors occur with services
    01H and 02H), and AL reports the modem status, when applicable. Figure
    12-4 contains the bit codings of the status bits. Some codes report
    errors, and others simply report a condition.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    One special bit of information about the time-out error (AH, bit 7) is
    worth noting: The earliest version of the ROM BIOS for the original PC
    had a programming error that caused a serial-port time-out to be
    reported as a transfer-shift-register-empty/break-detect-error
    combination (bits 01010000 rather than 10000000). This has been
    corrected on all subsequent versions of the ROM BIOS, but it has caused
    many communications programs to treat these error codes skeptically. You
    may want to keep this in mind. See page 63 for details on identifying
    the ROM BIOS version dates and machine ID codes.
    ──────────────────────────────────────────────────────────────────────────

        Bit
    7 6 5 4 3 2 1 0          Meaning (when set to 1)
    ──────────────────────────────────────────────────────────────────────────
    AH Register (line status)
    1 . . . . . . .          Time-out error
    . 1 . . . . . .          Transfer shift register empty
    . . 1 . . . . .          Transfer holding register empty
    . . . 1 . . . .          Break-detect error
    . . . . 1 . . .          Framing error
    . . . . . 1 . .          Parity error
    . . . . . . 1 .          Overrun error
    . . . . . . . 1          Data ready

    AL Register (modem status)
    1 . . . . . . .          Received line signal detect
    . 1 . . . . . .          Ring indicator
    . . 1 . . . . .          Data-set-ready
    . . . 1 . . . .          Clear-to-send
    . . . . 1 . . .          Delta receive line signal detect
    . . . . . 1 . .          Trailing-edge ring detector
    . . . . . . 1 .          Delta data-set-ready
    . . . . . . . 1          Delta clear-to-send
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-4.  The bit coding for the status bytes returned in register AX
    by service 03H.

Service 04H (decimal 4): Initialize Extended Serial Port

    Service 04H (decimal 4) is available only in the PS/2 ROM BIOS. It expands
    the capabilities of service 00H to provide support for the PS/2's improved
    serial ports. If you compare service 04H with service 00H, you'll find
    that the four serial port initialization parameters passed in AL in
    service 00H are separated into four registers in service 04H (Figure
    12-5). Also, service 04H returns both modem and line status in register
    AX, exactly as service 03H does. Because service 04H has these expanded
    capabilities, you should generally use it instead of service 00H for PS/2
    serial port initialization.

                            BREAK (register AL)
    Value                    Meaning
    ──────────────────────────────────────────────────────────────────────────
    00H                      No break
    01H                      Break
    ──────────────────────────────────────────────────────────────────────────

                            PARITY (register BH)
    Value                    Meaning
    ──────────────────────────────────────────────────────────────────────────
    00H                      None
    01H                      Odd
    02H                      Even
    03H                      Stick parity odd
    04H                      Stick parity even
    ──────────────────────────────────────────────────────────────────────────

                            BAUD RATE (register CL)
    Value                    Meaning
    ──────────────────────────────────────────────────────────────────────────
    00H                      110 baud
    01H                      150 baud
    02H                      300 baud
    03H                      600 baud
    04H                      1200 baud
    05H                      2400 baud
    06H                      4800 baud
    07H                      9600 baud
    08H                      19,200 baud
    ──────────────────────────────────────────────────────────────────────────

                            STOP BITS (register BL)
    Value                    Meaning
    ──────────────────────────────────────────────────────────────────────────
    00H                      One
    01H                      Two (for word length = 6, 7, or 8)
                            11/2 (for word length = 5)
    ──────────────────────────────────────────────────────────────────────────

                            WORD LENGTH (register CH)
    Value                    Meaning
    ──────────────────────────────────────────────────────────────────────────
    00H                      5 bits
    01H                      6 bits
    02H                      7 bits
    03H                      8 bits
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-5.  Register values for serial port initialization with
    interrupt 14H, service 04H. (Register DX contains a serial port number
    between 0 and 3.)

Service 05H (decimal 5): Control Extended Communications Port

    This service, provided only by the PS/2 ROM BIOS, lets you read from or
    write to the modem control register of a specified serial communications
    port. When you call service 05H with AL = 00H and a serial port number in
    DX, service 05H returns with register BL containing the value in the modem
    control register of the specified serial port. When you call service 05H
    with AL = 01H, the ROM BIOS copies the value you pass in register BL into
    the modem control register for the specified port. In both cases, service
    05H returns the modem status and line status in registers AL and AH, as
    does service 03H.


Miscellaneous System Services

    The miscellaneous system services provided through interrupt 15H are
    indeed miscellaneous. (See Figure 12-6.) Many are intended primarily for
    writers of operating-system software. Most application programmers will
    find little use for these services in their programs, because the
    functions provided are better carried out by calls to the operating system
    than they are through the ROM BIOS. Some of these services, such as the
    pointing-device interface (subservice C2H), provide functionality not
    otherwise available in the ROM BIOS or in DOS; others are obsolete and
    virtually unusable.

╓┌─┌──────────────────┌──────────────────────────────────────────────────────╖
    Service            Description
    ──────────────────────────────────────────────────────────────────────────
    00H                Turn On Cassette Motor.
    01H                Turn Off Cassette Motor.
    02H                Read Cassette Data Blocks.
    03H                Write Cassette Data Blocks.
    21H                Read or Write PS/2 Power-On Self-Test Error Log.
    4FH                Keyboard Intercept.
    80H                Device Open.
    81H                Device Close.
    Service            Description
    ──────────────────────────────────────────────────────────────────────────
    81H                Device Close.
    82H                Program Termination.
    83H                Start or Cancel Interval Timer.
    84H                Read Joystick Input.
    85H                Sys Req Keystroke.
    86H                Wait During a Specified Interval.
    87H                Protected-Mode Data Move.
    88H                Get Extended Memory Size.
    89H                Switch to Protected Mode.
    90H                Device Busy.
    91H                Interrupt Complete.
    C0H                Get System Configuration Parameters.
    C1H                Get Extended BIOS Data Segment.
    C2H                Pointing-Device Interface.
    C3H                Enable/Disable Watchdog Timer.
    C4H                Programmable Option Select.
    ──────────────────────────────────────────────────────────────────────────


    Figure 12-6.  Miscellaneous system services available through interrupt
    15H.

    The four cassette tape services are used when working with the cassette
    tape connection, which is a part of only two PC models: the original PC
    and the now-defunct PCjr. The cassette port was created with the original
    PC on the assumption that a demand might exist for it. None did, and it
    has remained almost totally unused. Nevertheless, IBM does support the use
    of the cassette port, both through the ROM BIOS services discussed here
    and through BASIC, which lets you read and write either data or BASIC
    programs on standard audio cassette tape.

    The cassette port never proved worthwhile, however. Nobody sells PC
    programs on tape, and nobody has found much use for the cassette port,
    given the convenience of diskettes and hard disks.

Service 00H (decimal 0): Turn On Cassette Motor

    Service 00H (decimal 0) turns on the cassette motor, which is not an
    automatic operation of the ROM BIOS services as it is with the diskette
    services. Any program that is using this service can expect a slight delay
    while the motor starts.

Service 01H (decimal 1): Turn Off Cassette Motor

    Service 01H (decimal 1) turns off the cassette motor. This is not an
    automatic operation of the ROM BIOS services as it is with the diskette
    services.

Service 02H (decimal 2): Read Cassette Data Blocks

    Service 02H (decimal 2) reads one or more cassette data blocks. Cassette
    data is transferred in standard-size 256-byte blocks, just as diskette
    data normally uses a standard 512-byte sector. The number of bytes to be
    read is placed in the CX register. Although data is placed on tape in
    256-byte blocks, any number of bytes can be read or written. Consequently,
    the number of bytes placed in the CX register need not be a multiple of
    256. The register pair ES:BX is used as a pointer to the memory area where
    the data is to be placed.

    After the service is completed, DX contains the actual number of bytes
    read, ES:BX points to the byte immediately after the last byte
    transferred, and the carry flag (CF) is set or cleared to report the
    success or failure of the operation. On failure, AH returns an error code.
    (See Figure 12-7.)

    Code               Meaning
    ──────────────────────────────────────────────────────────────────────────
    01H                Cyclical redundancy check (CRC) error
    02H                Lost data transitions: bit signals scrambled
    04H                No data found on tape
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-7.  The error code returned by service 02H in register AH if the
    CF indicates a failure to read the data blocks.

Service 03H (decimal 3): Write Cassette Data Blocks

    Service 03H (decimal 3) writes one or more cassette data blocks of 256
    bytes each. (See service 02H.) As with service 02H, the CX register gives
    the count of bytes requested, and ES:BX points to the data area in memory.
    If the amount of data being written is not a multiple of 256 bytes, the
    last data block is padded out to full size.

    After the service is completed, CX should contain 00H, and ES:BX should
    point just past the last memory byte that was written.

    Curiously, no error signals are provided for this service, essentially
    because a cassette tape recorder can't inform the computer of any
    difficulties. This forces the ROM BIOS to write data in blind faith that
    all is well. Needless to say, it would be a good idea to read back any
    data written, just to check it.

Service 21H (decimal 33): Read or Write PS/2 POST Error Log

    Service 21H (decimal 33) is used internally by the ROM BIOS power-on
    self-test (POST) routines in PS/2s with the Micro Channel bus to keep
    track of hardware initialization errors. You will rarely, if ever, find
    use for this service in your own applications.

Service 83H (decimal 131): Start or Cancel Interval Timer

    This service lets a program set a specified time interval and lets the
    program check a flag to show when the interval expires. The program should
    call this service with AL = 00H, with the address of a flag byte in
    registers ES and BX, and with the time interval in microseconds in
    registers CX and DX. The high-order 16 bits of the interval should be in
    CX; the low-order 16 bits in DX.

    Initially, the flag byte should be 00H. When the time interval elapses,
    the ROM BIOS sets this byte to 80H. The program can thus inspect the flag
    byte at its own convenience to determine when the time interval has
    elapsed:

    Clear the flag byte
    Call service 83H to start the interval timer
    WHILE   (flag byte = 00H)
            BEGIN
            (do something useful)
            END

    The ROM BIOS interval timer uses the system time-of-day clock, which ticks
    about 1024 times per second, so the timer's resolution is approximately
    976 microseconds.

Service 84H (decimal 132): Read Joystick Input

    Service 84H (decimal 132) provides a consistent interface for programs
    that use a joystick or a related input device connected to IBM's Game
    Control Adapter. When you call this service with DX = 00H, the ROM BIOS
    reports the adapter's four digital switch input values in bits 4 through 7
    of register AL. Calling service 84H with DX = 01H instructs the BIOS to
    return the adapter's four resistive input values in registers AX, BX, CX,
    and DX.

    Service 84H is not supported on the IBM PC or in the original PC/XT BIOS
    (dated 11/08/82). Be sure to check the computer's model identification and
    ROM BIOS revision date before you rely on this BIOS service in a program.

Service 86H (decimal 134): Wait During a Specified Interval

    Like service 83H, service 86H (decimal 134) lets a program set a specified
    time interval to wait. Unlike service 83H, however, service 86H suspends
    operation of the program that calls it until the specified time interval
    has elapsed. Control returns to the program only when the wait has
    completed or if the hardware timer is unavailable.

Service 87H (decimal 135): Protected-Mode Data Move

    A program running in real mode can use service 87H to transfer data to or
    from extended (protected-mode) memory on a PC/AT or PS/2 Model 50, 60, or
    80. This service is designed to be used by a protected-mode operating
    system. The IBM-supplied VDISK utility also uses this function to copy
    data to and from a virtual disk in extended memory. See the IBM BIOS
    Interface Technical Reference Manual for details.

Service 88H (decimal 136): Get Extended Memory Size

    Service 88H (decimal 136) returns the amount of extended (protected-mode)
    memory installed in a PC/AT or PS/2 Model 50, 60, or 80. The value, in
    kilobytes, is returned in register AX.

    The amount of extended memory is established by the ROM BIOS POST
    routines. It includes extended memory installed beyond the first megabyte;
    that is, memory starting at 10000:0000H. Lotus/Intel/Microsoft "expanded"
    memory is not included in the value returned by service 88H.

Service 89H (decimal 137): Switch to Protected Mode

    Service 89H (decimal 137) is provided by the ROM BIOS as an aid to
    configuring an 80286-based computer (PC/AT, PS/2 Model 50 or 60) or an
    80386-based computer (PS/2 Model 80) for protected-mode operation. This
    ROM BIOS service is intended for operating systems that run in protected
    mode. To use this service, you must be thoroughly acquainted with
    protected-mode programming techniques. See the IBM BIOS Interface
    Technical Reference Manual for details.

Service C0H (decimal 192): Get System Configuration Parameters

    Service C0H (decimal 192) returns the address of a table of descriptive
    information pertaining to the hardware and BIOS configuration of a PC/AT
    (in ROM BIOS versions dated 6/10/85 and later) or PS/2. Figure 12-8 shows
    the structure of the table. You can find the meaning of the model and
    submodel bytes in Chapter 3, page 64.

    Offset         Size           Contents
    ──────────────────────────────────────────────────────────────────────────
    0              2 bytes        Size of configuration information table
    2              1 byte         Model byte
    3              1 byte         Submodel byte
    4              1 byte         ROM BIOS revision level
    5              1 byte         Feature information byte:
                                Bit 7:  Fixed-disk BIOS uses DMA Channel 3
                                Bit 6:  Cascaded interrupt level 2 (IRQ2)
                                Bit 5:  Real-time clock present
                                Bit 4:  BIOS keyboard intercept implemented
                                Bit 3:  Wait for external event supported
                                Bit 2:  Extended BIOS data area allocated
                                Bit 1:  Micro Channel bus present
                                Bit 0:  (Reserved)
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-8.  System configuration information returned by service C0H.

Service C1H (decimal 193): Get ROM BIOS Extended Data Segment

    Service C1H (decimal 193) returns the segment address of the ROM BIOS
    extended data area. The ROM BIOS clears the carry flag and returns the
    segment value in register ES if an extended BIOS data segment is in use.
    Otherwise, service C1H returns with the carry flag set.

    The ROM BIOS uses the extended data area for transient storage of data.
    For example, when you pass the address of a pointing-device interface
    subroutine to the BIOS, the BIOS stores this address in its extended data
    area.

Service C2H (decimal 194): Pointing-Device Interface

    Service C2H (decimal 194) is the ROM BIOS interface to the built-in PS/2
    pointing-device controller. This interface makes it easy to use an IBM
    PS/2 mouse.

    To use the interface, you must write a short subroutine to which the ROM
    BIOS can pass packets of status information about the pointing device.
    Your subroutine should examine the data in each packet and respond
    appropriately, for example by moving a cursor on the screen. The
    subroutine must exit with a far return without changing the contents of
    the stack.

    To use the ROM BIOS pointing-device interface, carry out the following
    sequence of steps:

    1.  Pass the address of your subroutine to the BIOS (subservice 07H).

    2.  Initialize the interface (subservice 05H).

    3.  Enable the pointing device (subservice 00H).

    At this point, the BIOS begins sending packets of status information to
    your subroutine. The BIOS places each packet on the stack and calls your
    subroutine with a far CALL so that the stack is formatted when the
    subroutine gets control as in Figure 12-9. The low-order byte of the X
    and Y data words contains the number of units the pointing device has
    moved since the previous packet of data was sent. (The Z data byte is
    always 0.) The status byte contains sign, overflow, and button
    information. (See Figure 12-10.)

    ┌────────────────┐
    │    Status      │
    ├────────────────┤◄──── SP + 10
    │    X data      │
    ├────────────────┤◄──── SP + 8
    │    Y data      │
    ├────────────────┤◄──── SP + 6
    │    Z data      │
    ├────────────────┤◄──── SP + 4
    │                │
    │ Return address │
    │                │
    └────────────────┘◄──── SP

    Figure 12-9.  Pointing-device data packet.

    Bit                      Meaning
    ──────────────────────────────────────────────────────────────────────────
    0                        Set if left button pressed
    1                        Set if right button pressed
    2─3                      (Reserved)
    4                        Set if X data is negative
    5                        Set if Y data is negative
    6                        Set if X data overflows
    7                        Set if Y data overflows
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-10.  Status byte in pointing-device data packet.

    When you use service C2H, the value you pass in register AL selects one of
    eight available subservices. (See Figure 12-11.) The actual register
    contents for each subservice are in Chapter 13, page 284.

    Subservice               Description
    ──────────────────────────────────────────────────────────────────────────
    00H                      Enable/disable pointing device.
    01H                      Reset pointing device.
    02H                      Set sample rate.
    03H                      Set resolution.
    04H                      Get pointing-device type.
    05H                      Initialize pointing device.
    06H                      Extended commands.
    07H                      Pass device-driver address to ROM BIOS.
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-11.  Subservices available in the BIOS pointing-device interface
    (interrupt 15H, service C2H).

Service C3H (decimal 195): Enable/Disable Watchdog Timer

    Service C3H (decimal 195) provides a consistent interface to the watchdog
    timer in the PS/2 models 50, 60, and 80. It lets an operating system
    enable the watchdog timer with a specified timeout interval or disable the
    timer. Because the watchdog timer is intended specifically for use in
    operating-system software, this ROM BIOS service will rarely be useful in
    your applications.

Service C4H (decimal 196): Programmable Option Select

    Like many other interrupt 15H services, service C4H (decimal 196) is
    intended for use by operating system software. This service provides a
    consistent interface to the Programmable Option Select feature of the
    Micro Channel architecture in the PS/2 models 50, 60, and 80.


ROM BIOS Hooks

    The ROM BIOS in the PC/AT and in the PS/2s provides a number of hooks.
    These hooks are implemented as interrupt 15H "services," but to use them
    you must write an interrupt 15H handler that processes only these services
    and passes all other interrupt 15H service requests to the ROM BIOS. (See
    Figure 12-12.) This arrangement lets different components of the BIOS
    communicate with each other and with operating-system or user-written
    programs in a consistent manner.

    The ROM BIOS hooks are intended primarily for use in operating systems and
    in programs written to augment operating-system or BIOS functions.
    However, neither DOS nor OS/2 uses these BIOS hooks, and few program
    applications have reason to. Still, you might find it worthwhile to
    examine what the ROM BIOS hooks do, if only to get an idea of how the ROM
    BIOS is put together and how an operating system can interact with it.

                .                         ─┐
                .                          │
                .                          │
                mov     ah,ServiceNumber   │
                int     15h                ├─ Executed within ROM BIOS
                .                          │
                .                          │
                .                          │
                                            ─┘          ─┐
    Userhandler  PROC  far  ; interrupt 15H vector      │
                            ; points here               │
                                                        │
                .                                      │
                .                                      │
                .                                      │
                cmp     ah,ServiceNumber               │
                je      Service                        ├─ User-written
                jmp     (to previous INT 15H handler)  │  interupt 15H
                                                        │  handler
    Service                                             │
                .                                      │
                .       (do something useful)          │
                .                                      │
                iret                                   │
    Userhandler  ENDP                                  ─┘

    Figure 12-12.  How the ROM BIOS hooks can be used.

Service 4FH (decimal 79): Keyboard Intercept

    In the PC/AT ROM BIOS (dated 06/10/85 and later) and in the PS/2 ROM BIOS,
    the keyboard interrupt handler (that is, the handler for hardware
    interrupt 09H) executes interrupt 15H with AH = 4FH and with AL equal to
    the keyboard scan code. This action has little effect: The ROM BIOS
    interrupt 15H, service 4FH (decimal 79) handler returns with the carry
    flag set, and the interrupt 09H handler continues processing the
    keystroke.

    If you write an interrupt handler for interrupt 15H, however, you can hook
    service 4FH and process keystrokes yourself. Install your handler by
    storing its segmented address in the interrupt 15H vector. (Be sure to
    save the previous contents of the interrupt 15H vector.) Your interrupt
    15H handler would do the following:

    IF (AH<>4FH)
            jump to default interrupt 15H handler
    ELSE
            process keyboard scan code in AL
            set or reset carry flag
            exit from interrupt handler

    If your handler processes the scan code in AL, it must either set or reset
    the carry flag before it returns control to the ROM BIOS interrupt 09H
    handler. Setting the carry flag indicates that the BIOS interrupt 09H
    handler should continue processing the scan code in AL: Clearing the carry
    flag causes the BIOS handler to exit without processing the scan code.

    The problem with using the ROM BIOS keyboard intercept is that other
    programs, including DOS itself, can and do process keystrokes before the
    ROM BIOS interrupt 09H handler ever has a chance to issue interrupt 15H.
    (These programs do this by pointing the interrupt 09H vector to their own
    handlers instead of to the default ROM BIOS handler.) Because your program
    can't determine if this is happening, you cannot rely on the ROM BIOS
    keyboard intercept to be called for every keystroke.

Service 80H (decimal 128): Device Open

    This hook lets programs determine when a particular hardware device is
    available for input or output. An installable device driver can issue
    interrupt 15H with AH = 80H to inform an operating system that the device
    was opened. The operating system's interrupt 15H handler can inspect BX
    for an identifying value for the device and CX for an ID value of the
    program that opened the device.

Service 81H (decimal 129): Device Close

    Like service 80H, this service is provided for programs that establish
    input/output connections to hardware devices to communicate with an
    operating system. Service 81H (decimal 129) is called by such a program
    with a device ID value in register BX and a program ID value in CX. An
    operating system's interrupt 15H handler can inspect these values to
    determine that a particular device was closed for input/output by a
    particular program.

Service 82H (decimal 130): Program Termination

    Service 82H (decimal 130) is provided by the ROM BIOS so that a program
    can signal its own termination to an operating system. When a program
    executes interrupt 15H with AH = 82H and an ID value in BX, the operating
    system can handle the interrupt and thus be informed that the program
    terminated.

Service 85H (decimal 133): Sys Req Keystroke

    When you press the Sys Req key on an 84-key keyboard or Alt-Sys Req on a
    101/102-key keyboard, the ROM BIOS keyboard interrupt handler executes
    interrupt 15H with AH = 85H. You can detect when this key is pressed by
    hooking interrupt 15H and inspecting the value in AH.

    When the Sys Req key is first pressed, the ROM BIOS issues interrupt 15H
    with AH = 85H and AL = 00H. When the key is released, the BIOS executes
    interrupt 15H with AH = 85H and AL = 01H. Thus the structure of an
    interrupt 15H handler that detects Sys Req keystrokes would be as follows:

    IF (AH<>85H)
                    jump to previous interrupt 15H handler
    ELSE IF (AL = 00H)
                    process Sys Req keystroke
        ELSE
                    process Sys Req key release
        exit from interrupt handler

Service 90H (decimal 144): Device Busy

    This service lets a device driver alert an operating system to the
    beginning of an input or output operation. An operating system's interrupt
    15H handler processes this information (for example) by preventing
    subsequent input/output to the device until the device signals, with
    service 91H, that it is no longer busy.

    The ROM BIOS device drivers for disks, the keyboard, and the printer all
    issue appropriate service 90H (decimal 144) interrupts. Each device is
    identified by a value in register AL. (See Figure 12-13.) These ID values
    are selected according to the following guidelines:

    ■  00H─7FH: Non-reentrant devices that can process only one I/O request at
        a time sequentially.

    ■  80H─BFH: Reentrant devices that can handle multiple I/O requests at
        once.

    ■  C0H─FFH: Devices that expect the operating system to wait for a
        predetermined period of time before returning control to the device.
        The operating system's interrupt 15H handler must set the carry flag to
        indicate that the wait has been carried out.

    Value                    Meaning
    ──────────────────────────────────────────────────────────────────────────
    00H                      Fixed disk
    01H                      Diskette
    02H                      Keyboard
    03H                      Pointing device
    80H                      Network
    FCH                      PS/2 fixed-disk reset
    FDH                      Diskette-drive motor start
    FEH                      Printer
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-13.  Device identification values for interrupt 15H, services
    90H and 91H.

Service 91H (decimal 145): Interrupt Complete

    Devices that use service 90H to notify an operating system that they are
    busy can subsequently use service 91H (decimal 145) to signal that an
    input/output operation has been completed. The identification value passed
    in AL should be the same as the value passed in service 90H.


Printer Services

    The ROM BIOS printer services support printer output through the parallel
    printer adapter. The three ROM BIOS printer services are invoked with
    interrupt 17H (decimal 23), requested through the AH register, and
    numbered 00H through 02H. (See Figure 12-14.) The general PC-family
    design allows more than one printer to be installed, so a printer number
    must be specified in register DX for all these services.

    Service                  Description
    ──────────────────────────────────────────────────────────────────────────
    00H                      Send One Byte to Printer.
    01H                      Initialize Printer.
    02H                      Get Printer Status.
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-14.  The three ROM BIOS printer services invoked through
    interrupt 17H (decimal 23).

Service 00H (decimal 0): Send 1 Byte to Printer

    Service 00H (decimal 0) sends the byte you specify to the printer. When
    the service is completed, AH is then set to report the printer status (see
    service 02H), which can be used to determine the success or failure of
    the operation. See the special notes on printer time-out under service
    02H.

Service 01H (decimal 1): Initialize Printer

    Service 01H (decimal 1) initializes the printer. To do this, the service
    simply sends two control codes (08H and 0CH) to the printer control port.
    As with the other two services, the printer status is reported in AH.

Service 02H (decimal 2): Get Printer Status

    Service 02H (decimal 2) reports the printer status in the AH register. The
    individual bit codes are shown in Figure 12-15.

    The printer time-out has caused some difficulty in the IBM personal
    computers. Any I/O driver needs to set a time limit for a response from
    the device being controlled. Ideally, this time limit should be short
    enough to ensure that an unresponsive device can be reported in a timely
    manner. Unfortunately, one normal printer operation can take a
    surprisingly long time: a page eject ("skip to the top of the next page").
    The time allowed varies from version to version of the ROM BIOS. Treat a
    time-out signal with care.

        Bit
    7 6 5 4 3 2 1 0          Meaning (when set to 1)
    ──────────────────────────────────────────────────────────────────────────
    1 . . . . . . .          Printer not busy (0 = busy)
    . 1 . . . . . .          Acknowledgment from printer
    . . 1 . . . . .          Out-of-paper signal
    . . . 1 . . . .          Printer selected
    . . . . 1 . . .          I/O error
    . . . . . 1 . .          Not used
    . . . . . . 1 .          Not used
    . . . . . . . 1          Time-out
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-15.  The printer status bits reported in the AH register by
    services 00H, 01H, and 02H.


Other Services

    We now come to the grab bag of all other ROM BIOS services. (See Figure
    12-16.) Some of these services are intended for use in program
    applications; others are more likely to be used in operating-system
    software. The following sections describe these six service interrupts.

    Interrupt                Description
    Hex   Dec
    ──────────────────────────────────────────────────────────────────────────
    05H    5                 Print-Screen Service
    11H   17                 Equipment-List Service
    12H   18                 Memory-Size Service
    18H   24                 ROM BASIC Loader Service
    19H   25                 Bootstrap Loader Service
    1AH   26                 Time-of-Day Services
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-16.  Six miscellaneous ROM BIOS services supported by IBM, and
    their associated interrupts.

Interrupt 05H (decimal 5): Print-Screen Service

    Interrupt 05H (decimal 5) activates the print-screen service: The keyboard
    support routines generate interrupt 05H in response to the Shift-PrtSc
    combination; any other programs that want to perform a print-screen
    operation can safely and conveniently do so by generating interrupt 05H.

    The print-screen service will maintain the current cursor position on the
    screen and successfully print any printable characters from the screen in
    either text or graphics mode. It uses both the standard video services
    (those that waltz the cursor around the screen and read characters from
    the screen buffer) and the standard printer services.

    This service directs all its output to printer number 0, the default
    printer. There are no input or output registers for this service. However,
    a status code is available at low-memory location 0050:0000H. (See page
    61.) If the byte at that location has a value of FFH (decimal 255), then
    a previous print-screen operation was not completed successfully. A value
    of 00H indicates that no error occurred, and that the print-screen
    operation is ready to go. A value of 01H indicates that a print-screen
    operation is currently in progress; any request for a second one will be
    ignored.

    The ROM BIOS print-screen routine cannot print images drawn on the screen
    in graphics modes. If you want to produce a printed screen snapshot in
    CGA-compatible graphics modes, use the DOS utility program GRAPHICS. This
    program installs a memory-resident, graphics-mode print-screen routine
    that hooks interrupt 05H. Once you execute GRAPHICS, pressing Shift-PrtSc
    or executing interrupt 05H while in a graphics mode will cause the
    graphics-mode print-screen routine to run.

Interrupt 11H (decimal 17): Equipment-List Service

    Interrupt 11H (decimal 17) reports what equipment is installed in the
    computer. This report contains the same information stored at low-memory
    location 0040:0010H. (See Chapter 3, page 55.) The report is coded as
    shown in Figure 12-17, in the bits of a 16-bit word, which is placed in
    register AX. See interrupt 12H for a related service.

    The equipment information is gathered on an as-accurate-as-possible basis
    and may not be exactly correct. Different methods are used for acquiring
    the information in the various models.

    The equipment list is determined only once at power-up time and is then
    left in memory. This means that you can change the equipment list under
    software control. For example, you could take some equipment off line so
    that it is not used. However, modifying the equipment list is risky
    business──don't bet on its success. See interrupt 19H for comments on how
    to modify the equipment list and get reliable results.

╓┌─┌───────────────────────────────────────────────────────┌─────────────────►
                            Bit
    15 14 13 12 11 10  9  8   7  6  5  4  3  2  1  0        Meaning
    ───────────────────────────────────────────────────────────────────────────
    X  X  .  .  .  .  .  .   .  .  .  .  .  .  .  .        Number of printers
    .  .  X  .  .  .  .  .   .  .  .  .  .  .  .  .        (Reserved)
                            Bit
    15 14 13 12 11 10  9  8   7  6  5  4  3  2  1  0        Meaning
    ───────────────────────────────────────────────────────────────────────────
    .  .  X  .  .  .  .  .   .  .  .  .  .  .  .  .        (Reserved)
    .  .  .  X  .  .  .  .   .  .  .  .  .  .  .  .        Game adapter: 1 = i
    .  .  .  .  X  X  X  .   .  .  .  .  .  .  .  .        Number of RSS-232 s
    .  .  .  .  .  .  .  X   .  .  .  .  .  .  .  .        (Not used)
    .  .  .  .  .  .  .  .   X  X  .  .  .  .  .  .        Number of diskette
    .  .  .  .  .  .  .  .   .  .  X  X  .  .  .  .        Initial video mode:
                                                            10 = 80-column colo
                                                            01 = 40-column colo
    .  .  .  .  .  .  .  .   .  .  .  .  X  X  .  .        PC with 64 KB mothe
                                                            system board RAM (1
                                                            10 = 48 KB; 01 = 32
                                                            PC/AT: (Not used)
                                                            PS/2s: Bit 3 = (unu
                                                            pointing device ins
    .  .  .  .  .  .  .  .   .  .  .  .  .  .  X  .        1 if math co-proces
    .  .  .  .  .  .  .  .   .  .  .  .  .  .  .  X        1 if any diskette d
                                                            see bits 7 and 6)
    ───────────────────────────────────────────────────────────────────────────
                            Bit
    15 14 13 12 11 10  9  8   7  6  5  4  3  2  1  0        Meaning
    ───────────────────────────────────────────────────────────────────────────
    ───────────────────────────────────────────────────────────────────────────


    Figure 12-17.  The bit coding for the equipment list reported in register
    AX and invoked by interrupt 11H (decimal 17).

    The format of the equipment list was defined for the original IBM PC. As a
    result, some parts of the list vary, depending on the PC model. For
    example, bits 2 and 3 originally indicated the amount of RAM installed on
    the motherboard. (Yes, in those days you could indeed have purchased a PC
    with as little as 16 KB of RAM.) In PS/2s, these bits have a different
    significance. (See Figure 12-17.)

Interrupt 12H (decimal 18): Memory-Size Service

    Interrupt 12H (decimal 18) invokes the service that reports the available
    memory size in kilobytes──the same information stored at low-memory
    location 0040:0013H. (See page 55.) The value is reported in AX. The
    memory-size value reflects only the amount of base memory available. In a
    PC/AT or PS/2 with extended (protected-mode) memory, you must use
    interrupt 15H, service 88H (Get Extended Memory Size), to determine the
    amount of extended memory installed.

    In the standard models of the PC, this value is taken from the setting of
    the physical switches inside the system unit. These switches are supposed
    to reflect the actual memory installed, although under some circumstances
    they are set to less memory than is actually present. In the PC/AT and
    PS/2s, the ROM BIOS POST determines the amount of memory in the system by
    exploring available RAM to see what is installed. If the BIOS is using an
    extended data area, this data area is allocated at the highest memory
    address available, so the value returned by this service excludes the
    amount of RAM reserved for the extended data area.

Interrupt 18H (decimal 24): ROM BASIC Loader Service

    Interrupt 18H (decimal 24) is normally used to activate ROM BASIC. Any
    program can activate BASIC (or whatever has replaced it) by generating
    interrupt 18H. This can be done to intentionally bring up ROM BASIC or
    also to abruptly shut down, or dead-end a program. However, see the next
    interrupt, number 19H, for a better way to dead-end a program.

Interrupt 19H (decimal 25): Bootstrap Loader Service

    Interrupt 19H (decimal 25) activates the standard bootstrap routine for
    the computer (which produces a similar result to powering on and nearly
    the same net result as the Ctrl-Alt-Del key combination). However, this
    bootstrap interrupt bypasses the lengthy memory check of the power-on
    routines as well as the reset operations of Ctrl-Alt-Del.

    The bootstrap loader works by reading the first sector of the first track
    (the boot sector) from the diskette in drive A into memory at 0000:7C00H.
    If the ROM BIOS cannot read from the diskette, it reads the boot sector
    from the hard disk in drive C instead. If both attempts fail, the BIOS
    executes interrupt 18H to bring up ROM BASIC. If the BIOS reads a sector
    from the disk but the sector doesn't contain an operating-system boot
    record, the BIOS issues an error message and waits for you to reboot or
    replace the offending diskette.

    We know of two uses for this interrupt service. One is to immediately shut
    down, or dead-end, the operation of the computer. This can be done by a
    program when it encounters an "illegal" situation, for example, by a
    copy-protected program that detects an apparent violation of copy
    protection.

    The other use for this service is to reboot the computer without going
    through the reset and restart operations, which would, for example,
    recalculate the memory size and equipment list reported by interrupts 11H
    and 12H. This interrupt is particularly useful for any program that
    modifies either of these two items. The reasoning is simple: If you want
    to change the equipment list or the memory size (for example, to set aside
    some memory for a RAM disk), you cannot reliably count on all programs──
    including DOS──to check the actual memory or equipment specifications each
    time they are used. But a program could set aside some memory, change the
    memory specification, and then use this interrupt to reboot the system.
    When that is done and DOS is activated, DOS would take its own record of
    the available memory from the value set by your program. Neither DOS nor
    any civilized DOS program would be aware of, or interfere with, the memory
    area that was set aside.

    To give you a brief example, here's a fragment of assembler code that will
    change the ROM BIOS's record of the memory size and then use interrupt 19H
    to reboot the computer:

    mov     ax,40H                   ; get BIOS data segment of hex 40...
    mov     es,ax                    ; ...into ES segment register
    mov     word ptr es:[13h],256    ; set memory to 256 KB
    int     19h                      ; reboot system

Interrupt 1AH (decimal 26): Time-of-Day Services

    Interrupt 1AH (decimal 26) provides the time-of-day services. Unlike other
    interrupts covered in this section but like all other ROM BIOS services,
    several services can be activated by this interrupt. When you execute
    interrupt 1AH, you specify the service number, as usual, in register AH.
    (See Figure 12-18.)

    Service            Description
    ──────────────────────────────────────────────────────────────────────────
    00H                Get Current Clock Count.
    01H                Set Current Clock Count.
    02H                Get Real-Time Clock Time.
    03H                Set Real-Time Clock Time.
    04H                Get Real-Time Clock Date.
    05H                Set Real-Time Clock Date.
    06H                Set Real-Time Clock Alarm.
    07H                Reset Real-Time Clock Alarm.
    09H                Get Real-Time Clock Alarm Time and Status.
    ──────────────────────────────────────────────────────────────────────────

    Figure 12-18.  The ROM-BIOS time-of-day services invoked by interrupt 1AH.

    The ROM BIOS maintains a time-of-day clock based on a count of
    system-clock ticks since midnight. The system clock "ticks" by generating
    interrupt 8 at specific intervals. On each clock tick, the ROM BIOS
    interrupt 08H service routine increments the clock count by 1. When the
    clock count passes 24 hours' worth of ticks, the count is reset to 0 and a
    record is made of the fact that midnight has been passed. This record is
    not in the form of a count, so you can't detect if two midnights have
    passed.

    The clock ticks at a rate that is almost exactly 1,193,180 ÷ 64 KB, or
    roughly 18.2 times a second. The count is kept as a 4-byte integer at
    low-memory location 0040:006CH. The midnight count value, used to compare
    against the rising clock count, is 1800B0H, or 1,573,040; when the clock
    hits the midnight count value, the byte at location 0040:0070H is set to
    01H and the count is reset. When DOS needs to know the time, it reads the
    clock count through the time-of-day service and calculates the time from
    this raw count. If it sees that midnight has passed, it also increments
    the date.

    You can use the following BASIC formulas to calculate the current time of
    day from the clock count:

    HOURS = INT(CLOCK / 65543)
    CLOCK = CLOCK - (HOURS * 65543)
    MINUTES = INT(CLOCK / 1092)
    CLOCK = CLOCK - (MINUTES * 1092)
    SECONDS = CLOCK / 18.2

    In reverse, we use the following formula to calculate a nearly correct
    clock count from the time:

    COUNT = (HOURS * 65543) + (MINUTES * 1092) + (SECONDS * 18.2)

    The ROM BIOS services in the PC/AT and PS/2s include time-of-day and date
    services that perform some of these tasks automatically.

    Service 00H (decimal 0): Get Current Clock Count

    Service 00H (decimal 0) returns the current clock count in two registers:
    the high-order portion in CX and the low-order portion in DX. AL = 00H if
    midnight has not passed since the last clock value was read or set; and AL
    = 01H if midnight has passed. The midnight signal is always reset when the
    clock is read. Any program using this service must use the midnight signal
    to keep track of date changes. DOS programs normally should not use this
    service directly. If they do, they must calculate and set a new date.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    It's curious that version 2.0 of DOS did not consistently update the
    date on the midnight signal. The next version of DOS (2.1) and all other
    versions of DOS do.
    ──────────────────────────────────────────────────────────────────────────

    Service 01H (decimal 1): Set Current Clock Count

    Service 01H (decimal 1) sets the clock count in location 0040:006CH using
    the values you pass in registers CX and DX. This service automatically
    clears the midnight flag at 0040:0070H.

    Service 02H (decimal 2): Get Real-Time Clock Time

    The PC/AT and the PS/2s have a real-time clock that maintains the current
    date and time in nonvolatile memory. This clock runs in parallel to the
    system timer referenced by services 00H and 01H. When you boot a PC/AT or
    PS/2, the ROM BIOS initializes the system timer count with the time
    indicated by the real-time clock.

    You can access the real-time clock directly using service 02H (decimal 2).
    This service returns the time in binary-coded decimal format (BCD) in
    registers CH (hours), CL (minutes), and DH (seconds). If the real-time
    clock is defective, the ROM BIOS sets the carry flag.

    Service 03H (decimal 3): Set Real-Time Clock Time

    This service complements service 02H. It lets you set the real-time clock
    on a PC/AT or PS/2, using the same register assignments as service 02H.
    Again, the hours, minutes, and seconds values are in BCD format.

    Service 04H (decimal 4): Get Real-Time Clock Date

    Service 04H (decimal 4) returns the current date as maintained by the
    real-time clock in a PC/AT or PS/2. The ROM BIOS returns century (19 or
    20) in register CH, the year in CL, the month in DH, and the day in DL.
    Again, the values are returned in BCD format. As in service 02H, the ROM
    BIOS sets the carry flag if the real-time clock is not operating.

    Service 05H (decimal 5): Set Real-Time Clock Date

    Service 05H (decimal 5) complements service 04H. This service sets the
    real-time clock date, using the same registers as service 04H.

    Service 06H (decimal 6): Set Real-Time Clock Alarm

    Service 06H (decimal 6) lets you create an "alarm" program that executes
    at a specific time. This alarm program must be memory-resident at the time
    the alarm occurs. To use this service, make your alarm program
    memory-resident using the DOS Terminate-and-Stay-Resident service (see
    page 302), and be sure that interrupt vector 4AH (0000:0128H) points to
    the start of your program. Then call service 06H to set the time for the
    alarm to occur.

    Service 06H uses the same register values as service 03H: CH contains
    hours in BCD format, CL contains minutes, and DH contains seconds. The ROM
    BIOS sets the carry flag when it returns from this service if the
    real-time clock is not operating or if the alarm is already in use.

    When the real-time clock time matches the alarm time, the BIOS executes
    interrupt 4AH, which transfers control to your alarm program. Your program
    can then take appropriate action (display a message, for example). Because
    the ROM BIOS activates your alarm program by executing an
    INT 4AH instruction, the program must exit with an IRET instruction.

    Service 07H (decimal 7): Reset Real-Time Clock Alarm

    Use service 07H (decimal 7) to disable the real-time clock alarm if it has
    been set by a previous call to service 06H.

    Service 09H (decimal 9): Get Real-Time Clock Alarm Time and Status

    On PS/2 models 25 and 30, you can determine the current status of the
    real-time alarm by executing interrupt 1AH, service 09H. This service
    reports the alarm status in register DL. If DL = 01H, the alarm is active,
    and the alarm time is returned in CH, CL, and DH. If DL = 00H, the alarm
    isn't enabled.


Chapter 13  ROM BIOS Services Summary
────────────────────────────────────────────────────────────────────────────

    Short Summary

    Long Summary

    This chapter summarizes the ROM BIOS service routines discussed in
    Chapters 8 through 12 in order to provide you with a quick reference
    guide.

    You can use this chapter to locate the ROM BIOS functions you need and to
    determine which registers they use. Where a particular service is very
    detailed or tricky to use, we'll refer you to the discussions in the
    chapters and to the IBM technical reference manuals.



Short Summary


    In this section, we briefly list all the ROM BIOS services so that they
    can be seen together, at a glance.

╓┌─┌────────────┌───┌───┌───────┌───────────────────────────┌────────────────╖
                Interrupt
    Subject      Hex Dec Service Description                 Notes
    ──────────────────────────────────────────────────────────────────────────
    Print screen 05H 5   N/A     Send screen contents to
                                printer.
    Video        10H 16  00H     Set video mode.
    Video        10H 16  01H     Set cursor size.
    Video        10H 16  02H     Set cursor position.
                Interrupt
    Subject      Hex Dec Service Description                 Notes
    ──────────────────────────────────────────────────────────────────────────
    Video        10H 16  02H     Set cursor position.
    Video        10H 16  03H     Read cursor position.
    Video        10H 16  04H     Read light-pen position.
    Video        10H 16  05H     Set active display page.
    Video        10H 16  06H     Scroll window up.
    Video        10H 16  07H     Scroll window down.
    Video        10H 16  08H     Read character and
                                attribute.
    Video        10H 16  09H     Write character and
                                attribute.
    Video        10H 16  0AH     Write character.
    Video        10H 16  0BH     Set 4-color palette.
    Video        10H 16  0CH     Write pixel.
    Video        10H 16  0DH     Read pixel.
    Video        10H 16  0EH     Write character in teletype
                                mode.
    Video        10H 16  0FH     Get current video mode.
    Video        10H 16  10H     EGA/VGA color palette
                Interrupt
    Subject      Hex Dec Service Description                 Notes
    ──────────────────────────────────────────────────────────────────────────
    Video        10H 16  10H     EGA/VGA color palette
                                interface.
    Video        10H 16  11H     EGA/VGA character generator
                                interface.
    Video        10H 16  12H     EGA/VGA "alternate
                                select."
    Video        10H 16  13H     Write character string.    PC/AT, PS/2, EGA,
                                                            VGA only
    Video        10H 16  1AH     Get/Set display combination PS/2 only
                                code.
    Video        10H 16  1BH     Functionality/State         PS/2 only
                                information.
    Video        10H 16  1CH     Save/Restore video state.  VGA only
    Equipment    11H 17  N/A     Get list of peripheral
                                equipment.
    Memory       12H 18  N/A     Get base memory size (in
                                KB).
    Disk         13H 19  00H     Reset disk system.
                Interrupt
    Subject      Hex Dec Service Description                 Notes
    ──────────────────────────────────────────────────────────────────────────
    Disk         13H 19  00H     Reset disk system.
    Disk         13H 19  01H     Get disk status.
    Disk         13H 19  02H     Read disk sectors.
    Disk         13H 19  03H     Write disk sectors.
    Disk         13H 19  04H     Verify disk sectors.
    Disk         13H 19  05H     Format disk track.
    Disk         13H 19  06H     Format disk track and set   PC/XT fixed disk
                                bad sector flags.          only
    Disk         13H 19  07H     Format drive starting at    PC/XT fixed disk
                                specified cylinder.        only
    Disk         13H 19  08H     Get current drive
                                parameters.
    Disk         13H 19  09H     Initialize fixed-disk
                                parameter tables.
    Disk         13H 19  0AH     Read long.
    Disk         13H 19  0BH     Write long.
    Disk         13H 19  0CH     Seek to cylinder.
    Disk         13H 19  0DH     Alternate disk reset.
                Interrupt
    Subject      Hex Dec Service Description                 Notes
    ──────────────────────────────────────────────────────────────────────────
    Disk         13H 19  0DH     Alternate disk reset.
    Disk         13H 19  10H     Test for drive ready.
    Disk         13H 19  11H     Recalibrate drive.
    Disk         13H 19  14H     Controller diagnostics.
    Disk         13H 19  15H     Get disk type.
    Disk         13H 19  16H     Change of diskette status.
    Disk         13H 19  17H     Set diskette type for
                                format.
    Disk         13H 19  18H     Set media type for diskette
                                format.
    Disk         13H 19  19H     Park heads.                PS/2s only
    Disk         13H 19  1AH     Format ESDI unit.          PS/2 models 50,
                                                            60, 80 only
    Serial port  14H 20  00H     Initialize serial port.
    Serial port  14H 20  01H     Send out one character.
    Serial port  14H 20  02H     Receive one character.
    Serial port  14H 20  03H     Get serial port status.
    Serial port  14H 20  04H     Extended serial port        PS/2s only
                Interrupt
    Subject      Hex Dec Service Description                 Notes
    ──────────────────────────────────────────────────────────────────────────
    Serial port  14H 20  04H     Extended serial port        PS/2s only
                                initialize.                Serial port
                                                            14H
                                                            20
                                                            05H
                                                            Extended serial
                                                            port control.
                                                            PS/2s only
    System       15H 21  00H     Turn on cassette motor.
    System       15H 21  01H     Turn off cassette motor.
    System       15H 21  02H     Read data blocks.
    System       15H 21  03H     Write data blocks.
    System       15H 21  21H     Read/write POST error log. PS/2 models 50,
                                                            60, 80 only
    System       15H 21  4FH     Keyboard intercept.        PC/AT, PS/2s only
    System       15H 21  80H     Device open.               PC/AT, PS/2s only
    System       15H 21  81H     Device close.              PC/AT, PS/2s only
    System       15H 21  82H     Program termination.       PC/AT, PS/2s only
                Interrupt
    Subject      Hex Dec Service Description                 Notes
    ──────────────────────────────────────────────────────────────────────────
    System       15H 21  82H     Program termination.       PC/AT, PS/2s only
    System       15H 21  83H     Start/stop interval timer. PC/AT, PS/2s only
    System       15H 21  84H     Joystick support.          PC/AT, PS/2s only
    System       15H 21  85H     Sys Req keystroke.         PC/AT, PS/2s only
    System       15H 21  86H     Wait.                      PC/AT, PS/2s only
    System       15H 21  87H     Protected-mode data move.  PC/AT, PS/2
                                                            models 50, 60, 80
    System       15H 21  88H     Get extended memory size.  PC/AT, PS/2
                                                            models 50, 60, 80
    System       15H 21  89H     Switch to protected mode.  PC/AT, PS/2
                                                            models 50, 60, 80
    System       15H 21  90H     Device busy.               PC/AT, PS/2s only
    System       15H 21  91H     Interrupt complete.        PC/AT, PS/2s only
    System       15H 21  C0H     Get system configuration
                                parameters.
    System       15H 21  C1H     Get extended BIOS data      PS/2s only
                                segment.
    System       15H 21  C2H     Pointing-device interface. PS/2s only
                Interrupt
    Subject      Hex Dec Service Description                 Notes
    ──────────────────────────────────────────────────────────────────────────
    System       15H 21  C2H     Pointing-device interface. PS/2s only
    System       15H 21  C3H     Enable/disable watchdog     PS/2 models 50,
                                timer.                     60, 80
    System       15H 21  C4H     Programmable Option Select  PS/2 models 50,
                                interface.                 60, 80
    Keyboard     16H 22  00H     Read next keystroke.
    Keyboard     16H 22  01H     Report whether keystroke
                                ready.
    Keyboard     16H 22  02H     Get shift status.
    Keyboard     16H 22  03H     Set typematic rate and      PC/AT, PS/2s only
                                delay.
    Keyboard     16H 22  05H     Write to keyboard buffer.  PC/AT, PS/2s only
    Keyboard     16H 22  10H     Extended keyboard read.    PC/AT, PS/2s only
    Keyboard     16H 22  11H     Extended keyboard status.  PC/AT, PS/2s only
    Keyboard     16H 22  12H     Extended shift status.     PC/AT, PS/2s only
    Printer      17H 23  00H     Send 1 byte to printer.
    Printer      17H 23  01H     Initialize printer.
    Printer      17H 23  02H     Get printer status.
                Interrupt
    Subject      Hex Dec Service Description                 Notes
    ──────────────────────────────────────────────────────────────────────────
    Printer      17H 23  02H     Get printer status.
    BASIC        18H 24  N/A     Switch control to ROM
                                BASIC.
    Bootstrap    19H 25  N/A     Reboot computer.
    Time         1AH 26  00H     Read current clock count.
    Time         1AH 26  01H     Set current clock count.
    Time         1AH 26  02H     Read real-time clock.      PC/AT, PS/2s only
    Time         1AH 26  03H     Set real-time clock.       PC/AT, PS/2s only
    Time         1AH 26  04H     Read date from real-time    PC/AT, PS/2s only
                                clock.
    Time         1AH 26  05H     Set date in real-time       PC/AT, PS/2s only
                                clock.
    Time         1AH 26  06H     Set alarm.                 PC/AT, PS/2s only
    Time         1AH 26  07H     Reset alarm.               PC/AT, PS/2s only
    Time         1AH 26  09H     Get alarm time and status. PS/2 Model 30
                                                            only
    ──────────────────────────────────────────────────────────────────────────



Long Summary


    In this section, we expand the previous summary table to show the register
    usage for input and output parameters. The preceding section is best used
    to quickly find which service you need; this section is best used to
    quickly find how to use each service.

╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Print Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Print screen.    05H N/A              N/A              Send screen
                                                            contents to
                                                            printer. Status and
                                                            result byte at
                                                            0050:0000H.

╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Set video mode.  10H AH = 00H         None             Video modes in AL:
                        AL = video mode                   00H: 40 x 25
                                                            16-color text
                                                            (gray-scaled on
                                                            composite
                                                            monitors).
                                                            01H: 40 x 25
                                                            16-color text.
                                                            02H: 80 x 25
                                                            16-color text
                                                            (gray-scaled on
                                                            composite
                                                            monitors).
                                                            03H: 80 x 25
                                                            16-color text.
                                                            04H: 320 x 200
                                                            4-color graphics.
                                                            05H: 320 x 200
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            05H: 320 x 200
                                                            4-color graphics
                                                            (gray-scaled on
                                                            composite
                                                            monitors).
                                                            06H: 640 x 200
                                                            2-color graphics.
                                                            07H: 80 x 25
                                                            monochrome text
                                                            (MDA, EGA, VGA).
                                                            0DH: 320 x 200
                                                            16-color graphics
                                                            (EGA, VGA).
                                                            0EH: 640 x 200
                                                            16-color graphics
                                                            (EGA, VGA).
                                                            0FH: 640 x 350
                                                            monochrome graphics
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            monochrome graphics
                                                            (EGA, VGA).
                                                            10H: 640 x 350
                                                            16-color graphics
                                                            (EGA, VGA).
                                                            11H: 640 x 480
                                                            2-color graphics
                                                            (MCGA, VGA).
                                                            12H: 640 x 480
                                                            16-color graphics
                                                            (VGA).
                                                            13H: 320 x 200
                                                            256-color graphics
                                                            (MCGA, VGA).
    ──────────────────────────────────────────────────────────────────────────
    Set cursor size. 10H AH = 01H         None             Useful values for
                        CH = starting                     CH and CL depend on
                        scan line                         video mode.
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        scan line                         video mode.
                        CL = ending
                        scan line
    ──────────────────────────────────────────────────────────────────────────
    Set cursor       10H AH = 02H         None
    position.            BH = display
                        page
                        DH = row
                        DL = column
    ──────────────────────────────────────────────────────────────────────────
    Read cursor      10H AH = 03H         CH = starting
    position.            BH = display     scan line
                        page             CL = ending scan
                                        line
                                        DH = row
                                        DL = column
    ──────────────────────────────────────────────────────────────────────────
    Read light-pen   10H AH = 04H         AH = pen trigger
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Read light-pen   10H AH = 04H         AH = pen trigger
    position.                             signal
                                        BX = pixel
                                        column
                                        CH = pixel row
                                        (CGA and EGA
                                        video modes 4,
                                        5, and 6)
                                        CX = pixel row
                                        (EGA except
                                        modes 4, 5, and
                                        6)
                                        DH = character
                                        row
                                        DL = character
                                        column
    ──────────────────────────────────────────────────────────────────────────
    Set active       10H AH = 05H         None
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Set active       10H AH = 05H         None
    display page.        AL = page number
    ──────────────────────────────────────────────────────────────────────────
    Scroll           10H AH = 06H         None
    window up.           AL = lines to
                        scroll up
                        BH = fill
                        attribute
                        CH = upper row
                        CL = left column
                        DH = lower row
                        DL = right
                        column
    ──────────────────────────────────────────────────────────────────────────
    Scroll window    10H AH = 07H         None
    down.                AL = lines to
                        scroll down
                        BH = fill
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        BH = fill
                        attribute
                        CH = upper row
                        CL = left column
                        DH = lower row
                        DL = right
                        column
    ──────────────────────────────────────────────────────────────────────────
    Read character   10H AH = 08H         AH = attribute
    and attribute.       BH = display     AL = character
                        page
    ──────────────────────────────────────────────────────────────────────────
    Write character  10H AH = 09H         None
    and attribute.       AL = character
                        BH = display
                        page
                        BL = attribute
                        CX = number of
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        CX = number of
                        characters to
                        repeat
    ──────────────────────────────────────────────────────────────────────────
    Write character. 10H AH = 0AH         None
                        AL = character
                        BH = page number
                        BL = color in
                        graphics mode
                        CX = number of
                        characters to
                        repeat
    ──────────────────────────────────────────────────────────────────────────
    Set color        10H AH = 0BH         None
    palette.             BH = palette
                        color ID
                        BL = color to be
                        used with
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        used with
                        palette ID
    ──────────────────────────────────────────────────────────────────────────
    Write pixel.     10H AH = 0CH         None
                        AL = color
                        BH = display
                        page
                        CX = pixel
                        column
                        DX = pixel row
    ──────────────────────────────────────────────────────────────────────────
    Read pixel.      10H AH = 0DH         AL = pixel value
                        BH = display
                        page
                        CX = pixel
                        column
                        DX = pixel row
    ──────────────────────────────────────────────────────────────────────────
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    ──────────────────────────────────────────────────────────────────────────
    Write character  10H AH = 0EH         None             Display page number
    in teletype          AL = character                    required only for
    mode.                BH = display                      IBM PC ROM BIOS
                        page                              dated 10/19/81 and
                        BL = color for                    earlier.
                        graphics mode
    ──────────────────────────────────────────────────────────────────────────
    Get current      10H AH = 0FH         AH = width in
    video mode.                           characters
                                        AL = video mode
                                        BH = display
                                        page
    ──────────────────────────────────────────────────────────────────────────
    Set one palette  10H AH = 10H         None             EGA, VGA.
    register.            AL = 00H
                        BH = palette
                        register value
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        register value
                        BL = palette
                        register number
    ──────────────────────────────────────────────────────────────────────────
    Set border       10H AH = 10H         None             EGA, VGA.
    register.            AL = 01H
                        BH = border
                        color
    ──────────────────────────────────────────────────────────────────────────
    Set all palette  10H AH = 10H         None             EGA, VGA.
    registers.           AL = 02H
                        ES:DX -> table
                        of palette
                        values
    ──────────────────────────────────────────────────────────────────────────
    Select           10H AH = 10H         None             EGA, VGA.
    background           AL = 03H
    intensity or         To enable
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    intensity or         To enable
    blink attribute.     background
                        intensity:
                        BL = 00H
                        To enable
                        blinking:
                        BL = 01H
    ──────────────────────────────────────────────────────────────────────────
    Read one palette 10H AH = 10H         BH = palette     VGA only.
    register.            AL = 07H         register value
                        BL = palette
                        register number
    ──────────────────────────────────────────────────────────────────────────
    Read border      10H AH = 10H         BH = border      VGA only.
    register.            AL = 08H         color
                                        value
    ──────────────────────────────────────────────────────────────────────────
    Read all palette 10H AH = 10H         ES:DX -> table   VGA only.
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Read all palette 10H AH = 10H         ES:DX -> table   VGA only.
    registers.           AL = 09H         of palette
                                        register values
    ──────────────────────────────────────────────────────────────────────────
    Update one       10H AH = 10H         None             MCGA, VGA.
    video DAC            AL = 10H
    color register.      BX = color
                        register number
                        DH = red value
                        CH = green value
                        CL = blue value
    ──────────────────────────────────────────────────────────────────────────
    Update block     10H AH = 10H                          MCGA, VGA.
    of video DAC         AL = 12H
    color registers.     BX = first
                        register to
                        update
                        CX = number of
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        CX = number of
                        registers to
                        update
                        ES:DX -> table
                        of
                        red-green-blue
                        values
    ──────────────────────────────────────────────────────────────────────────
    Set video DAC    10H AH = 10H         None             VGA only.
    color page.          AL = 13H
                        To select paging
                        mode:
                        BL = 00H
                        BH = 00H selects
                        4 pages of 64
                        registers, or
                        BH = 01H selects
                        16 pages of 16
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        16 pages of 16
                        registers
                        To select page:
                        BL = 01H
                        BH = page number
    ──────────────────────────────────────────────────────────────────────────
    Read one video   10H AH = 10H         DH = red value   MCGA, VGA.
    DAC color            AL = 15H         CH = green value
    register.            BX = color       CL = blue value
                        register number
    ──────────────────────────────────────────────────────────────────────────
    Read block of    10H AH = 10H         Table at ES:DX   MCGA, VGA.
    video DAC color      AL = 17H         updated
    registers.           BX = first
                        register number
                        CX = number
                        of registers
                        ES:DX -> table
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        ES:DX -> table
                        of
                        red-green-blue
                        values
    ──────────────────────────────────────────────────────────────────────────
    Get video DAC    10H AH = 10H         None             VGA only.
    color page.          AL = 1AH
                        BH = current
                        page
                        BL = current
                        paging mode
    ──────────────────────────────────────────────────────────────────────────
    Sum video DAC    10H AH = 10H         None             MCGA, VGA.
    color values to      AL = 1BH
    gray shades.         BX = first color
                        register
                        CX = number of
                        color registers
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        color registers
    ──────────────────────────────────────────────────────────────────────────
    Load             10H AH = 11H         None             EGA, MCGA, VGA.
    user-specified       AL = 00H
    alphanumeric         BH = bytes per
    character set.       character in
                        table
                        BL = character
                        generator RAM
                        block
                        CX = number of
                        characters
                        DX = first
                        character
                        ES:BP ->
                        character
                        definition table
    ──────────────────────────────────────────────────────────────────────────
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    ──────────────────────────────────────────────────────────────────────────
    Load ROM BIOS    10H AH = 11H         None             EGA, VGA.
    8 x 14               AL = 01H
    alphanumeric         BL = character
    character set.       generator RAM
                        block
    ──────────────────────────────────────────────────────────────────────────
    Load ROM BIOS    10H AH = 11H         None             EGA, MCGA, VGA.
    8 x 8                AL = 02H
    alphanumeric         BL = character
    character set.       generator RAM
                        block
    ──────────────────────────────────────────────────────────────────────────
    Select displayed 10H AH = 11H         None             EGA, MCGA, VGA.
    alphanumeric         AL = 03H
    character sets.      BL = character
                        block generator
                        RAM
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        RAM
    ──────────────────────────────────────────────────────────────────────────
    Load ROM BIOS    10H AH = 11H         None             MCGA, VGA.
    8 x 16               AL = 04H
    alphanumeric         BL = character
    character set.       generator RAM
                        block
    ──────────────────────────────────────────────────────────────────────────
    Load             10H AH = 11H         None             EGA, MCGA, VGA.
    user-specified       AL = 10H
    alphanumeric         BH = bytes per
    character set        character
    and adjust           definition
    displayed            BL = character
    character            generator RAM
    height.              block
                        CX = number of
                        characters
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        characters
                        DX = first
                        character
                        ES:BP ->
                        character
                        definition table
    ──────────────────────────────────────────────────────────────────────────
    Load ROM BIOS    10H AH = 11H         None             EGA, VGA.
    8 x 14               AL = 11H
    alphanumeric         BL = character
    character set        generator RAM
    and adjust           block
    displayed
    character
    height.
    ──────────────────────────────────────────────────────────────────────────
    Load ROM BIOS    10H AH = 11H         None             EGA, VGA.
    8 x 8                AL = 12H
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    8 x 8                AL = 12H
    alphanumeric         BL = character
    character set        generator RAM
    and adjust           block
    displayed
    character
    height.
    ──────────────────────────────────────────────────────────────────────────
    Load ROM BIOS    10H AH = 11H         None             VGA only.
    8 x 16               AL = 14H
    alphanumeric         BL = character
    character set        generator RAM
    and adjust           block
    displayed
    character
    height.
    ──────────────────────────────────────────────────────────────────────────
    Load             10H AH = 11H         None             EGA, MCGA, VGA.
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Load             10H AH = 11H         None             EGA, MCGA, VGA.
    user-specified       AL = 20H                          Copies ES:BP into
    8 x 8                ES:BP ->                          the interrupt 1FH
    graphics             character                         vector. Only
    character set.       definition table                  characters 80H
                                                            through FFH should
                                                            be defined.
    ──────────────────────────────────────────────────────────────────────────
    Load             10H AH = 11H         None             EGA, MCGA, VGA.
    user-specified       AL = 21H
    graphics             CX = bytes per
    character set.       character
                        definition
                        ES:BP ->
                        character
                        definition table
                        User-specified
                        number of
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        number of
                        character rows:
                        BL = 00H
                        DL = number of
                        character rows
                        14 character
                        rows:
                        BL = 01H
                        25 character
                        rows:
                        BL = 02H
                        43 character
                        rows:
                        BL = 03H
    ──────────────────────────────────────────────────────────────────────────
    Load ROM BIOS    10H AH = 11H         None             EGA, VGA.
    8 x 14 graphics      AL = 22H
    character set.       BL = (as for
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    character set.       BL = (as for
                        AL = 21H)
                        DL = (as for
                        AL = 21H)
    ──────────────────────────────────────────────────────────────────────────
    Load ROM BIOS    10H AH = 11H         None             EGA, MCGA, VGA.
    8 x 8 graphics       AL = 23H
    character set.       BL = (as for
                        AL = 21H)
                        DL = (as for
                        AL = 21H)
    ──────────────────────────────────────────────────────────────────────────
    Load ROM BIOS    10H AH = 11H         None             MCGA, VGA.
    8 x 16 graphics      AL = 24H
    character set.       BL = (as for
                        AL = 21H)
                        DL = (as for
                        AL = 21H)
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        AL = 21H)
    ──────────────────────────────────────────────────────────────────────────
    Get character    10H AH = 11H         CX = points      EGA, MCGA, VGA.
    generator            AL = 30H         DL = displayed
    information.         Contents of      character rows -
                        interrupt 1FH    1
                        vector:          ES:BP ->
                        BH = 00H         character table
                        Contents of
                        interrupt 43H
                        vector:
                        BH = 01H
                        Address of ROM
                        8 x 14
                        characters:
                        BH = 02H
                        Address of ROM
                        8 x 8
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        8 x 8
                        characters:
                        1BH = 03H
                        Address of
                        second half of
                        ROM 8 x 8 table:
                        BH = 04H
                        Address of ROM
                        9 x 14 alternate
                        characters:
                        BH = 05H
                        Address of ROM
                        8 x 16
                        characters:
                        BH = 06H
                        Address of ROM
                        9 x 16 alternate
                        characters:
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        characters:
                        BH = 07H
    ──────────────────────────────────────────────────────────────────────────
    Return video     10H AH = 12H         BH = default     EGA, VGA.
    configuration        BL = 10H         BIOS video mode
    information.                          (00H = color,
                                        01H =
                                        monochrome)
                                        BL = amount of
                                        video RAM (00H =
                                        64 KB, 01H = 128
                                        KB,
                                        02H = 192 KB,
                                        03H = 256 KB)
                                        CH = feature
                                        bits
                                        CL =
                                        configuration
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        configuration
                                        switches
    ──────────────────────────────────────────────────────────────────────────
    Select alternate 10H AH = 12H         None             EGA, MCGA, VGA.
    print screen         BL = 20H                          Updates INT 05H
    routine.                                               vector.
    ──────────────────────────────────────────────────────────────────────────
    Select scan      10H AH = 12H         AL = 12H         VGA only.
    lines for            BL = 30H
    alphanumeric         200 scan lines:
    modes.               AL = 00H
                        350 scan lines:
                        AL = 01H
                        400 scan lines:
                        AL = 02H
    ──────────────────────────────────────────────────────────────────────────
    Select default   10H AH = 12H         AL = 12H         MCGA, VGA.
    palette loading.     BL = 31H
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    palette loading.     BL = 31H
                        Enable default
                        palette loading:
                        AL = 00H
                        Disable default
                        palette loading:
                        AL = 01H
    ──────────────────────────────────────────────────────────────────────────
    Enable/disable   10H AH = 12H         AL = 12H         MCGA, VGA.
    video                BL = 32H
    addressing.          Enable video
                        addressing:
                        AL = 00H
                        Disable video
                        addressing:
                        AL = 01H
    ──────────────────────────────────────────────────────────────────────────
    Enable/disable   10H AH = 12H         AL = 12H         MCGA, VGA.
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Enable/disable   10H AH = 12H         AL = 12H         MCGA, VGA.
    gray-scale           BL = 33H
    summing.             Enable gray-
                        scale summing:
                        AL = 00H
                        Disable gray-
                        scale summing:
                        AL = 01H
    ──────────────────────────────────────────────────────────────────────────
    Enable/disable   10H AH = 12H         AL = 12H         VGA only.
    BIOS cursor          BL = 34H
    emulation.           Enable cursor
                        emulation:
                        AL = 00H
                        Disable cursor
                        emulation:
                        AL = 01H
    ──────────────────────────────────────────────────────────────────────────
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    ──────────────────────────────────────────────────────────────────────────
    Display switch   10H AH = 12H         AL = 12H         MCGA, VGA.
    interface.           BL = 35H
                        Initial adapter
                        video off:
                        AL = 00H
                        Initial planar
                        video on: AL =
                        01H
                        Switch active
                        video off: AL =
                        02H
                        Switch inactive
                        video on:
                        AL = 03H
                        ES:DX->128-byte
                        save area
    ──────────────────────────────────────────────────────────────────────────
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    ──────────────────────────────────────────────────────────────────────────
    Enable/disable   10H AH = 12H         AL = 12H         VGA only.
    video refresh.       BL = 36H
                        Enable refresh:
                        AL = 00H
                        Disable refresh:
                        AL = 01H
    ──────────────────────────────────────────────────────────────────────────
    Write string;    10H AH = 13H         None             PC/AT, EGA, MCGA,
    don't move           AL = 00H                          VGA.
    cursor.              BL = attribute
                        BH = display
                        page
                        DX = starting
                        cursor position
                        CX = length of
                        string
                        ES:BP -> start
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        ES:BP -> start
                        of string
    ──────────────────────────────────────────────────────────────────────────
    Write string;    10H AH = 13H         None             PC/AT, EGA, MCGA,
    move cursor          AL = 01H                          VGA.
    after string.        BL = attribute
                        BH = display
                        page
                        DX = starting
                        cursor position
                        CX = length of
                        string
                        ES:BP -> start
                        of string
    ──────────────────────────────────────────────────────────────────────────
    Write string of  10H AH = 13H         None             PC/AT, EGA, MCGA,
    alternating          AL = 02H                          VGA.
    characters and       BH = display
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    characters and       BH = display
    attributes;          page
    don't move           DX = starting
    cursor.              cursor position
                        CX = length of
                        string
                        ES:BP -> start
                        of string
    ──────────────────────────────────────────────────────────────────────────
    Write string of  10H AH = 13H         None             PC/AT, EGA, MCGA,
    alternating          AL = 03H                          VGA.
    characters and       BH = display
    attributes;          page
    move cursor.         DX = starting
                        cursor position
                        CX = length of
                        string
                        ES:BP -> start
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        ES:BP -> start
                        of string
    ──────────────────────────────────────────────────────────────────────────
    Get display      10H AH = 1AH         AL = 1AH         MCGA, VGA.
    combination          AL = 00H         BL = active      Values returned in
    code.                                 display          BL and BH:
                                        BH = inactive    00H: no display.
                                        display          01H: MDA or
                                                            compatible.
                                                            02H: CGA or
                                                            compatible.
                                                            04H: EGA with color
                                                            display.
                                                            05H: EGA with
                                                            monochrome display.
                                                            06H: Professional
                                                            Graphics
                                                            Controller.
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            Controller.
                                                            07H: VGA with
                                                            monochrome display.
                                                            08H: VGA with color
                                                            display.
                                                            0BH: MCGA with
                                                            monochrome display.
                                                            0CH: MCGA with
                                                            color display.
                                                            FFH: unknown.
    ──────────────────────────────────────────────────────────────────────────
    Set display      10H AH = 1AH         AL = 1AH         MCGA, VGA. See
    combination          AL = 01H                          table above for
    code.                BL = active                       values in BL and
                        display                           BH.
                        BH = inactive
                        display
    ──────────────────────────────────────────────────────────────────────────
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    ──────────────────────────────────────────────────────────────────────────
    BIOS             10H AH = 1BH         AL = 1BH         MCGA, VGA. See the
    functionality/       BX = 00H         Buffer at ES:DI  IBM BIOS Interface
    state                ES:DI -> 64-byte updated          Technical Reference
    information.         buffer                            Manual for table
                                                            format.
    ──────────────────────────────────────────────────────────────────────────
    Return           10H AH = 1CH         AL = 1CH         VGA only. Use this
    save/restore         AL = 00H         (if function     service before
    buffer size.         CX = requested   supported)       saving the current
                        states           BX =             video state.
                        (bit 0 = video   save/restore
                        hardware state;  buffer size in
                        bit 1 = video    64-byte blocks
                        BIOS data area;
                        bit 2 = video
                        DAC and color
                        registers)
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        registers)
    ──────────────────────────────────────────────────────────────────────────
    Save current     10H AH = 1CH                          VGA only. May
    video state.         AL = 01H                          disrupt current
                        CX = requested                    video state, so
                        states                            follow a call to
                        ES:BX ->                          this service with a
                        save/restore                      call to the
                        buffer                            "Restore Current
                                                            Video State"
                                                            service.
    ──────────────────────────────────────────────────────────────────────────
    Restore current  10H AH = 1CH         None             VGA only.
    video state.         AL = 02H
                        CX = requested
                        states
                        ES:BX ->
                        save/restore
    Video Services              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        save/restore
                        buffer

╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Equipment-List              Register
    Service          Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Get list of      11H None             AX = equipment   Bit settings in AX:
    peripheral                            list, bit-coded  00 = diskette drive
    attached                                               installed.
    equipment.                                             01 = math
                                                            coprocessor
                                                            installed.
                                                            02, 03 = system
                                                            board RAM in 16 KB
                                                            blocks (PCs with 64
                                                            KB motherboard
                                                            only).
    Equipment-List              Register
    Service          Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            only).
                                                            02 = pointing
                                                            device installed
                                                            (PS/2s only).
                                                            04, 05 = initial
                                                            video mode:
                                                            00 = unused;
                                                            01 = 40 x 25 color;
                                                            10 = 80 x 25 color;
                                                            11 = 80 x 25
                                                            monochrome.
                                                            06, 07 = number of
                                                            diskette drives -
                                                            1.
                                                            08 = (not used).
                                                            09, 10, 11 = number
                                                            of
                                                            RS-232 cards in
    Equipment-List              Register
    Service          Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            RS-232 cards in
                                                            system.
                                                            12 = game I/O
                                                            attached
                                                            (PC and PC/XT
                                                            only).
                                                            13 = internal modem
                                                            installed.
                                                            14, 15 = number of
                                                            parallel printers
                                                            attached.

╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Memory Service              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Get base         12H None             AX = memory size See also "Get
    memory size.                          (KB)             extended memory
    Memory Service              Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    memory size.                          (KB)             extended memory
                                                            size" (INT 15H,
                                                            AH = 88H).

╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Reset disk       13H AH = 00H         CF = success/    See INT 13H,
    system.              DL = drive       failure flag     service 01H, for
                        number           AH = status code status code values.
    ──────────────────────────────────────────────────────────────────────────
    Get disk status. 13H AH = 01H         AH = status code (F) = fixed disk
                        DL = drive       Status values    only.
                        number           (hex):           (D) = diskette
                                        AH = 00H: no     only.
                                        error
                                        AH = 01H: bad
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        AH = 01H: bad
                                        command
                                        AH = 02H:
                                        address mark not
                                        found
                                        AH = 03H: write
                                        attempted on
                                        write-protected
                                        disk (D)
                                        AH = 04H: sector
                                        not found
                                        AH = 05H: reset
                                        failed (F)
                                        AH = 06H:
                                        diskette removed
                                        (D)
                                        AH = 07H: bad
                                        parameter table
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        parameter table
                                        (F)
                                        AH = 08H: DMA
                                        overrun
                                        AH = 09H: DMA
                                        across 64 KB
                                        boundary
                                        AH = 0AH: bad
                                        sector flag (F)
                                        AH = 0BH: bad
                                        cylinder (F)
                                        AH = 0CH: bad
                                        media type (D)
                                        AH = 0DH:
                                        invalid number
                                        of sectors on
                                        format (F)
                                        AH = 0EH:
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        AH = 0EH:
                                        control data
                                        address mark
                                        detected (F)
                                        AH = 0FH: DMA
                                        arbitration
                                        level out of
                                        range (F)
                                        AH = 10H: bad
                                        CRC or ECC
                                        AH = 11H: ECC
                                        corrected data
                                        error (F)
                                        AH = 20H:
                                        controller
                                        failed
                                        AH = 40H: seek
                                        failed
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        failed
                                        AH = 80H: time
                                        out (F) or drive
                                        not ready (D)
                                        AH = AAH: drive
                                        not ready (F)
                                        AH = BBH:
                                        undefined error
                                        (F)
                                        AH = CCH: write
                                        fault (F)
                                        AH = E0H: status
                                        error (F)
                                        AH = FFH: sense
                                        operation failed
                                        (F)
    ──────────────────────────────────────────────────────────────────────────
    Read disk        13H AH = 02H         CF = success/    Status codes in AH:
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Read disk        13H AH = 02H         CF = success/    Status codes in AH:
    sectors.             AL = number      failure flag     See INT 13H,
                        of sectors       AH = status code service 01H.
                        CH = track       AL = number of
                        number           sectors read
                        CL = sector
                        number
                        DH = head
                        number
                        DL = drive
                        number
                        ES:BX = pointer
                        to buffer
    ──────────────────────────────────────────────────────────────────────────
    Write disk       13H AH = 03H         CF = success/    Status codes in AH:
    sectors.             AL = number of   failure flag     See INT 13H,
                        sectors          AH = status code service 01H.
                        CH = track       AL = number of
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        CH = track       AL = number of
                        number           sectors written
                        CL = sector
                        number
                        DH = head
                        number
                        DL = drive
                        number
                        ES:BX = pointer
                        to buffer
    ──────────────────────────────────────────────────────────────────────────
    Verify disk      13H AH = 04H         CF = success/    Status codes in AH:
    sectors.             AL = number      failure flag     See INT 13H,
                        of sectors       AH = status code service 01H.
                        CH = track       AL = number of
                        number           sectors verified
                        CL = sector
                        number
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        number
                        DH = head number
                        DL = drive
                        number
    ──────────────────────────────────────────────────────────────────────────
    Format disk      13H AH = 05H         CF = success/    Status codes in AH:
    track                AL = interleave  failure flag     See INT 13H,
    (cylinder).          value (PC/XT     AH = status code service 01H.
                        only)                             See Chapter 10 for
                        CH = cylinder                     contents
                        number (bits                      of table.
                        0─7)
                        CL = cylinder
                        number (bits
                        8─9)
                        DH = head number
                        DL = drive
                        number
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        number
                        ES:BX -> table
                        of sector format
                        information
    ──────────────────────────────────────────────────────────────────────────
    Format disk      13H AH = 06H         CF = success/    PC/XT fixed disk
    track and set        AL = interleave  failure flag     only.
    bad sector           value            AH = status code
    flags.               CH = cylinder
                        number (bits
                        0─7)
                        CL = cylinder
                        number (bits
                        8─9)
                        DH = head number
                        DL = drive
                        number
    ──────────────────────────────────────────────────────────────────────────
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    ──────────────────────────────────────────────────────────────────────────
    Format drive     13H AH = 07H         CF = success/    PC/XT fixed disk
    starting at          AL = interleave  failure flag     only.
    specified            value            AH = status code
    cylinder.            CH = cylinder
                        number (bits
                        0─7)
                        CL = cylinder
                        number (bits
                        8─9)
                        DH = head number
                        DL = drive
                        number
    ──────────────────────────────────────────────────────────────────────────
    Get current      13H AH = 08H         CF = success/    Status codes in AH:
    drive                                 failure flag     See INT 13H,
    parameters.                           AH = status code service 01H.
                                        DL = number of
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        DL = number of
                                        drives
                                        DH = max.
                                        read/write head
                                        number
                                        CL (bits 6─7) =
                                        max. cylinder
                                        number
                                        (bits 8─9)
                                        CL (bits 0─5) =
                                        max.
                                        sector number
                                        CH = max. number
                                        of cylinders
                                        (bits 0─7)
    ──────────────────────────────────────────────────────────────────────────
    Initialize       13H AH = 09H         CF = success/    Interrupt 41H
    fixed-disk           DL = drive       failure flag     points to table for
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    fixed-disk           DL = drive       failure flag     points to table for
    base tables.         number           AH = status code drive 0.
                                                            Interrupt 46H
                                                            points to table for
                                                            drive 1.
                                                            Status codes in AH:
                                                            See INT 13H,
                                                            service 01H.
    ──────────────────────────────────────────────────────────────────────────
    Read long.       13H AH = 0AH         CF = success/    Status codes in AH:
                        DL = drive       failure flag     See INT 13H,
                        number           AH = status code service 01H.
                        DH = head
                        number
                        CH = cylinder
                        number
                        CL = sector
                        number
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        number
                        ES:BX -> buffer
    ──────────────────────────────────────────────────────────────────────────
    Write long.      13H AH = 0BH         CF = success/    Status codes in AH:
                        DL = drive       failure flag     See INT 13H,
                        number           AH = status code service 01H.
                        DH = head
                        number
                        CH = cylinder
                        number
                        CL = sector
                        number
                        ES:BX -> buffer
    ──────────────────────────────────────────────────────────────────────────
    Seek to          13H AH = 0CH         CF = success/    Status codes in AH:
    cylinder.            DL = drive       failure flag     See INT 13H,
                        number           AH = status code service 01H.
                        DH = head
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        DH = head
                        number
                        CH = cylinder
                        number
    ──────────────────────────────────────────────────────────────────────────
    Alternate        13H AH = 0DH         CF = success/    Status codes in AH:
    disk reset.          DL = drive       failure flag     See INT 13H,
                        number           AH = status code service 01H.
    ──────────────────────────────────────────────────────────────────────────
    Test for         13H AH = 10H         CF = success/    Status codes in AH:
    drive ready.         DL = drive       failure flag     See INT 13H,
                        number           AH = status code service 01H.
    ──────────────────────────────────────────────────────────────────────────
    Recalibrate      13H AH = 11H         CF = success/    Status codes in AH:
    drive.               DL = drive       failure flag     See INT 13H,
                        number           AH = status code service 01H.
    ──────────────────────────────────────────────────────────────────────────
    Controller       13H AH = 14H         CF = success/    Status codes in AH:
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Controller       13H AH = 14H         CF = success/    Status codes in AH:
    diagnostics.                          failure flag     See INT 13H,
                                        AH = status code service 01H.
    ──────────────────────────────────────────────────────────────────────────
    Get disk type.   13H AH = 15H         CF = success/    Disk types:
                        DL = drive       failure flag     AH = 00H: disk not
                        number           AH = disk type   there.
                                        CX, DX = number  AH = 01H: diskette,
                                        of 512-byte      no change detection
                                        sectors          present.
                                        (fixed-disk      AH = 02H: diskette,
                                        only)            change detection
                                                            present.
                                                            AH = 03H: fixed
                                                            disk.
    ──────────────────────────────────────────────────────────────────────────
    Change of        13H AH = 16H         AH = diskette
    diskette status.     DL = drive       change status:
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    diskette status.     DL = drive       change status:
                        number           00H = no
                                        diskette change
                                        01H = invalid
                                        parameter
                                        06H = diskette
                                        changed
                                        80H = drive not
                                        ready
    ──────────────────────────────────────────────────────────────────────────
    Set diskette     13H AH = 17H         CF = success/    Diskette type set
    type for format.     AL = diskette    failure flag     in AL:
                        type             AH = status code AL = 01H: 360 KB
                        DL = drive                        diskette in 360 KB
                        number                            drive.
                                                            AL = 02H: 360 KB
                                                            diskette in 1.2 MB
                                                            drive.
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            drive.
                                                            AL = 03H: 1.2 MB
                                                            diskette in 1.2 MB
                                                            drive.
                                                            AL = 04H: 720 KB
                                                            diskette in 720 KB
                                                            drive.
    ──────────────────────────────────────────────────────────────────────────
    Set media type   13H AH = 18H         CF = success/    Only in PC/AT BIOS
    for diskette         CH = number of   failure flag     dated 11/15/85 and
    format.              tracks (bits     AH = status code later, PC/XT BIOS
                        0─7)             ES:DI -> 11-byte dated 1/10/86 and
                        CL (bits 6─7) =  parameter table  later, and PS/2s.
                        number of tracks (disk-base
                        (bits 8─9)       table)
                        CL (bits 0─5) =
                        sectors per
                        track
    Disk Services               Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        track
                        DL = drive
                        number
    ──────────────────────────────────────────────────────────────────────────
    Park heads.      13H AH = 19H         CF = success/    PS/2s only.
                        DL = drive       failure flag
                        number           AH = status code
    ──────────────────────────────────────────────────────────────────────────
    Format Unit.     13H AH = 1AH         None             For PS/2 fixed
                                                            disks used with IBM
                                                            Enhanced Small
                                                            Device Interface
                                                            (ESDI) adapter. See
                                                            the IBM BIOS
                                                            Interface
                                                            Technical Reference
                                                            Manual.

╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Serial Port                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Initialize       14H AH = 00H         AX = serial port Serial port
    serial port.         AL = serial port status           parameter
                        parameters                        bit settings:
                        DX = serial port                  bits 0─1 = word
                        number                            length:
                                                            10 = 7 bits; 11 = 8
                                                            bits.
                                                            bit 2 = stop bits:
                                                            0 = 1; 1 = 2.
                                                            bits 3─4 = parity:
                                                            00, 10 = none; 01 =
                                                            odd;
                                                            11 = even.
                                                            bits 5─7 = baud
                                                            rate:
                                                            000 = 110;
                                                            001 = 150;
    Serial Port                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            001 = 150;
                                                            010 = 300;
                                                            011 = 600;
                                                            100 = 1200;
                                                            101 = 2400;
                                                            110 = 4800;
                                                            111 = 9600.
                                                            For PC/XT/AT family
                                                            only. For PS/2s,
                                                            use subservice 04H,
                                                            "Extended serial
                                                            port initialize."
                                                            See page 280.
    ──────────────────────────────────────────────────────────────────────────
    Send one         14H AH = 01H         AH = status code Status bit
    character to         AL = character                    settings: See INT
    serial port.         DX = serial port                  14H, service 03H.
                        number
    Serial Port                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        number
    ──────────────────────────────────────────────────────────────────────────
    Receive one      14H AH = 02H         AH = status code Status bit
    character from       DX = serial port AL = character   settings: See INT
    serial port.         number                            14H, service 03H.
    ──────────────────────────────────────────────────────────────────────────
    Get serial port  14H AH = 03H         AX = status code Status code bit
    status.              DX = serial port                  settings:
                        number                            AH bit settings:
                                                            bit 0 = data ready.
                                                            bit 1 = overrun
                                                            error.
                                                            bit 2 = parity
                                                            error.
                                                            bit 3 = framing
                                                            error.
                                                            bit 4 = break
                                                            detected.
    Serial Port                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            detected.
                                                            bit 5 =
                                                            transmission buffer
                                                            register empty.
                                                            bit 6 =
                                                            transmission shift
                                                            register empty.
                                                            bit 7 = time out.
                                                            AL bit settings:
                                                            bit 0 = delta
                                                            clear-to-send.
                                                            bit 1 = delta
                                                            data-set-ready.
                                                            bit 2 =
                                                            trailing-edge ring
                                                            detected.
                                                            bit 3 = change,
                                                            receive line signal
    Serial Port                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            receive line signal
                                                            detected.
                                                            bit 4 =
                                                            clear-to-send.
                                                            bit 5 =
                                                            data-set-ready.
                                                            bit 6 = ring
                                                            detected.
                                                            bit 7 = receive
                                                            line signal
                                                            detected.
    ──────────────────────────────────────────────────────────────────────────
    Extended serial  14H AH = 04H         AH = line status PS/2s only. See
    port initialize.     AL = break       AL = modem       Chapter 12
                        BH = parity      status           for details.
                        BL = stop bit
                        CH = word length
                        CL = baud rate
    Serial Port                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        CL = baud rate
                        DX = serial port
                        number (0─3)
    ──────────────────────────────────────────────────────────────────────────
    Extended serial  14H AH = 05H         AH = line status For PS/2s only. See
    port control.        DX = serial port AL = modem       Chapter 12 for
                        number           status           details.
                        (0, 1, 2, 3)     If called with
                        To read modem    AL = 00H:
                        control          BL = modem
                        register:        control register
                        AL = 00H         value
                        To write modem
                        control
                        register:
                        AL = 01H
                        BL = value for
                        modem control
    Serial Port                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        modem control
                        register

╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Turn on cassette 15H AH = 00H         AH = 00H         IBM PC only.
    motor.                                CF = 0
    ──────────────────────────────────────────────────────────────────────────
    Turn off         15H AH = 01H         AH = 00H         IBM PC only.
    cassette motor.                       CF = 0
    ──────────────────────────────────────────────────────────────────────────
    Read cassette    15H AH = 02H         ES:BX -> last    IBM PC only.
    data blocks.         CX = number      byte
                        of bytes         read + 1
                        ES:BX -> data    DX = number of
                        area             bytes read
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        area             bytes read
                                        CF = 0 (no
                                        error)
                                        or 1 (error)
    ──────────────────────────────────────────────────────────────────────────
    Write cassette   15H AH = 03H         CF = success/    IBM PC only.
    data blocks.         CX = number of   failure flag
                        bytes            ES:BX -> last
                        ES:BX -> data    byte
                        area             written + 1
                                        CX = 00H
    ──────────────────────────────────────────────────────────────────────────
    Read/Write       15H AH = 21H         AH = 00H         PS/2 models 50, 60,
    power-on             To read error    If called with   80.
    self-test error      log:             AL = 00H:
    log.                 AL = 00H         BX = number of
                        To write error   POST
                        log:             error codes
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        log:             error codes
                        AL = 01H         logged
                        BH = device code ES:DI -> POST
                        BL = error code  error log
                                        If called with
                                        AL = 01H:
                                        CF = status (0:
                                        no error; 1: log
                                        full)
    ──────────────────────────────────────────────────────────────────────────
    Keyboard         15H AH = 4FH                          See Chapter 12 for
    intercept.                                             details.

    ──────────────────────────────────────────────────────────────────────────
    Device open.     15H AH = 80H                          See Chapter 12 for
                                                            details.
    ──────────────────────────────────────────────────────────────────────────
    Device close.    15H AH = 81H                          See Chapter 12 for
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Device close.    15H AH = 81H                          See Chapter 12 for
                                                            details.
    ──────────────────────────────────────────────────────────────────────────
    Program          15H AH = 82H                          See Chapter 12 for
    termination.                                           details.
    ──────────────────────────────────────────────────────────────────────────
    Start/stop       15H AH = 83H         If called with   PC/AT and PS/2
    interval timer       To start         AL = 00H:        models 50, 60, 80.
    (event wait).        interval timer:  CF = 0 (if timer At completion of
                        AL = 00H         started) or      specified interval,
                        CX,DX = time in  CF = 1 (if timer the high-order bit
                        microseconds     already running  of the byte at
                        ES:BX -> 1-byte  or               ES:BX is set to 1.
                        flag             function not
                        To stop interval supported)
                        timer:           If called with
                        AL = 01H         AL = 01H:
                                        CF = 0 (if timer
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        CF = 0 (if timer
                                        canceled)
                                        CF = 1 (if
                                        function
                                        not supported)
    ──────────────────────────────────────────────────────────────────────────
    Joystick         15H AH = 84H         If called with   Not supported by PC
    support.             To read          DX = 00H:        or XT BIOS prior to
                        switches:        AL = switch      01/10/86.
                        DX = 00H         settings
                        To read          (bits 4─7)
                        resistive        CF = 0 (if
                        inputs:          switches
                        DX = 00H         successfully
                                        read)
                                        or CF = 1
                                        (if
                                        unsuccessful)
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        unsuccessful)
                                        If called with
                                        DX = 01H:
                                        AX = stick A
                                        x-value
                                        BX = stick A
                                        y-value
                                        CX = stick B
                                        x-value
                                        DX = stick B
                                        y-value
    ──────────────────────────────────────────────────────────────────────────
    Sys Req          15H AH = 85H                          See Chapter 12 for
    keystroke.           AL = key status                   details.
    ──────────────────────────────────────────────────────────────────────────
    Wait during      15H AH = 86H         CF = 0 (if       PC/AT and PS/2s
    a specified          CX,DX = time in  successful)      only.
    interval.            microseconds     CF = 1 (timer
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    interval.            microseconds     CF = 1 (timer
                                        already running
                                        or
                                        function not
                                        supported)
    ──────────────────────────────────────────────────────────────────────────
    Protected-mode   15H AH = 87H                          PC/AT and PS/2
    data move.                                             models 50, 60, 80.
                                                            See the IBM BIOS
                                                            Technical Reference
                                                            Manual for details.
    ──────────────────────────────────────────────────────────────────────────
    Get extended     15H AH = 88H         AX = memory size PC/AT and PS/2
    memory size.                          (KB)             models 50, 60, 80.
    ──────────────────────────────────────────────────────────────────────────
    Switch to        15H AH = 89H                          PC/AT and PS/2
    protected mode.                                        models 50, 60, 80.
                                                            See the IBM BIOS
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            See the IBM BIOS
                                                            Technical Reference
                                                            Manual for details.
    ──────────────────────────────────────────────────────────────────────────
    Device busy.     15H AH = 90H                          See Chapter 12 for
                                                            details.
    ──────────────────────────────────────────────────────────────────────────
    Interrupt        15H AH = 91H                          See Chapter 12 for
    complete.                                              details.
    ──────────────────────────────────────────────────────────────────────────
    Get system       15H AH = C0H         AH = 0           See Chapter 12 for
    configuration                         CF = 0           details. Not
    parameters.                           ES:BX -> ROM     supported in PC, XT
                                        BIOS system      BIOS prior to
                                        configuration    01/10/86, or AT
                                        parameters       prior to 06/10/85.
    ──────────────────────────────────────────────────────────────────────────
    Get extended     15H AH = C1H         CF = 0           PS/2s only.
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Get extended     15H AH = C1H         CF = 0           PS/2s only.
    BIOS data                             ES = extended
    segment.                              BIOS data
                                        segment address
    ──────────────────────────────────────────────────────────────────────────
    Enable/disable   15H AH = C2H         CF = 0 if        PS/2s only.
    pointing device.     AL = 00H         successful;
                        To enable:       1 if error
                        BH = 00H         AH = status:
                        To disable:      00H: no error
                        BH = 01H         01H: invalid
                                        function call
                                        02H: invalid
                                        input
                                        03H: interface
                                        error
                                        04H: resend
                                        05H: no device
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        05H: no device
                                        driver installed
    ──────────────────────────────────────────────────────────────────────────
    Reset pointing   15H AH = C2H         CF = 0 if        PS/2s only.
    device.              AL = 01H         successful;
                                        1 if error
                                        AH = status
                                        (as above)
                                        BH = 00H (device
                                        ID)
                                        BL = undefined
    ──────────────────────────────────────────────────────────────────────────
    Set pointing-    15H AH = C2H         CF = 0 if        PS/2s only.
    device sample        AL = 02H         successful;
    rate.                BH = sample      1 if error
                        rate:            AH = status
                        00H: 10/second   (as above)
                        01H: 20/second
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        01H: 20/second
                        02H: 40/second
                        03H: 60/second
                        04H: 80/second
                        05H: 100/second
                        06H: 200/second
    ──────────────────────────────────────────────────────────────────────────
    Set pointing-    15H AH = C2H         CF = 0 if        PS/2s only.
    device               AL = 03H         successful;
    resolution.          BH = resolution: 1 if error
                        00H: 1           AH = status
                        count/millimeter (as above)
                        01H: 2
                        count/millimeter
                        02H: 4
                        count/millimeter
                        03H: 8
                        count/millimeter
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        count/millimeter
    ──────────────────────────────────────────────────────────────────────────
    Get              15H AH = C2H         CF = 0 if        PS/2s only.
    pointing-device      AL = 04H         successful; 1 if
    type.                                 error
                                        AH = status (as
                                        above)
                                        BH = device ID
    ──────────────────────────────────────────────────────────────────────────
    Initialize       15H AH = C2H         CF = 0 if        PS/2s only.
    pointing device.     AL = 05H         successful; 1 if
                        BH = data packet error
                        size (1─8 bytes) AH = status (as
                                        above)
    ──────────────────────────────────────────────────────────────────────────
    Extended         15H AH = C2H         CF = 0 if        PS/2s only. See
    pointing-device      AL = 06H         successful;      Chapter 12 for
    commands.            To get status:   1 if error       contents of status
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    commands.            To get status:   1 if error       contents of status
                        BH = 00H         AH = status (as  bytes.
                        To set scaling   above)
                        to 1:1:          If called with
                        BH = 01H         BH = 00H:
                        To set scaling   BL = status byte
                        to 2:1:          1
                        BH = 02H         CL = status byte
                                        2
                                        DL = status byte
                                        3
    ──────────────────────────────────────────────────────────────────────────
    Pass             15H AH = C2H         CF = 0 if        PS/2s only.
    pointing-device      AL = 07H         successful;
    driver address       ES:BX -> device  1 if error
    to BIOS.             driver           AH = status (as
                                        above)
    ──────────────────────────────────────────────────────────────────────────
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    ──────────────────────────────────────────────────────────────────────────
    Enable/disable   15H AH = C3H         CF = 0           PS/2 models 50, 60,
    watchdog timer.      BX = timer count if successful    80 only.
                        (01H─FFH)
                        To enable:
                        AL = 01H
                        To disable:
                        AL = 00H
    ──────────────────────────────────────────────────────────────────────────
    Programmable     15H AH = C4H         If called with   PS/2 models 50, 60,
    Option Select        To get POS       AL = 00H:        80 only.
    (POS) interface.     register base    AL = 00H
                        address:         DX = base POS
                        AL = 00H         register address
                        To enable slot   If called with
                        for POS setup:   AL = 01H:
                        AL = 01H         AL = 01H
                        To enable an     BL = slot number
    System                      Register
    Services☼        Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        To enable an     BL = slot number
                        adapter:         If called with
                        AL = 02H         AL = 02H:
                                        AL = 02H

╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Keyboard                    Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Read next        16H AH = 00H         AH = scan code
    keystroke.                            AL = ASCII
                                        character code
    ──────────────────────────────────────────────────────────────────────────
    Report whether   16H AH = 01H         ZF = 0 if
    keystroke ready.                      keystroke
                                        available
                                        AH = scan code
                                        (if ZF = 0)
    Keyboard                    Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        (if ZF = 0)
                                        AL = ASCII
                                        character code
                                        (if ZF = 0)
    ──────────────────────────────────────────────────────────────────────────
    Get shift        16H AH = 02H         AL = shift       Shift status bits:
    status.                               status bits      bit 7 = 1: Insert
                                                            state active
                                                            bit 6 = 1: Caps
                                                            Lock active
                                                            bit 5 = 1: Num Lock
                                                            active
                                                            bit 4 = 1: Scroll
                                                            Lock active
                                                            bit 3 = 1: Alt
                                                            pressed
                                                            bit 2 = 1: Ctrl
                                                            pressed
    Keyboard                    Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            pressed
                                                            bit 1 = 1: left
                                                            Shift pressed
                                                            bit 0 = 1: right
                                                            Shift pressed
    ──────────────────────────────────────────────────────────────────────────
    Set typematic    16H AH = 03H         None             PC/AT (BIOS dated
    rate and delay.      AL = 05H                          11/15/85 and later)
                        BL = typematic                    and PS/2s only. See
                        rate                              Chapter 11 for
                        BH = delay value                  rate and values.
    ──────────────────────────────────────────────────────────────────────────
    Write to         16H AH = 05H         AL = 00H         PC/XT (BIOS dated
    keyboard buffer.     CH = scan code   (success);       01/10/86 and
                        CL = ASCII       AL = 01H         later), PC/AT (BIOS
                        character code   (keyboard        dated 11/15/85 and
                                        buffer full)     later), and PS/2s
                                                            only.
    Keyboard                    Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                                            only.
    ──────────────────────────────────────────────────────────────────────────
    Extended         16H AH = 10H         AH = scan code   PC/XT (BIOS dated
    keyboard read.                        AL = ASCII       01/10/86 and
                                        character code   later), PC/AT (BIOS
                                                            dated 11/15/85 and
                                                            later), and PS/2s
                                                            only.
    ──────────────────────────────────────────────────────────────────────────
    Extended         16H AH = 11H         If no keystroke  PC/XT (BIOS dated
    keyboard status.                      available:       01/10/86 and
                                        ZF = 1           later), PC/AT (BIOS
                                        If keystroke     dated 11/15/85 and
                                        available:       later), and PS/2s
                                        ZF = 0           only.
                                        AH = scan code
                                        AL = ASCII
                                        character code
    Keyboard                    Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        character code
    ──────────────────────────────────────────────────────────────────────────
    Extended shift   16H AH = 12H         AL = shift       PC/XT (BIOS dated
    status.                               status           01/10/86 and
                                        (as above)       later), PC/AT (BIOS
                                        AH = extended    dated 11/15/85 and
                                        shift            later), and PS/2s
                                        status:          only.
                                        bit 7: Sys Req
                                        is pressed
                                        bit 6: CapsLock
                                        is pressed
                                        bit 5: NumLock
                                        is pressed
                                        bit 4:
                                        ScrollLock
                                        is pressed
                                        bit 3: right Alt
    Keyboard                    Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        bit 3: right Alt
                                        is pressed
                                        bit 2: right
                                        Ctrl
                                        is pressed
                                        bit 1: left Alt
                                        is pressed
                                        bit 0: left Ctrl
                                        is pressed

╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Printer Services            Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Send 1 byte to   17H AH = 00H         AH = success/    Status bit
    printer.             AL = character   failure status   settings:
                        DX = printer     flags            bit 7 = 1: not busy
                        number                            bit 6 = 1:
    Printer Services            Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        number                            bit 6 = 1:
                                                            acknowledge
                                                            bit 5 = 1: out of
                                                            paper
                                                            bit 4 = 1: selected
                                                            bit 3 = 1: I/O
                                                            error
                                                            bit 2 = unused
                                                            bit 1 = unused
                                                            bit 0 = time out
    ──────────────────────────────────────────────────────────────────────────
    Initialize       17H AH = 01H         AH = status code Status code bit
    printer.             DX = printer                      settings as above.
                        number
    ──────────────────────────────────────────────────────────────────────────
    Get printer      17H AH = 02H         AH = status code Status code bit
    status.              DX = printer                      settings as above.
                        number
    Printer Services            Register
                    Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        number





╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Miscellaneous               Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Switch control   18H None             N/A              No return, so no
    to                                                     possible output.
    ROM BASIC.
    ──────────────────────────────────────────────────────────────────────────
    Reboot computer. 19H None             N/A              No return, so no
                                                            possible output.


    Miscellaneous               Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────





╓┌─┌────────────────┌───┌────────────────┌────────────────┌──────────────────╖
    Time-of-Day                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    Read current     1AH AH = 00H         AL > 00H if time Timer-tick
    clock count.                          of day has       frequency is about
                                        passed           18.2 ticks/second,
                                        midnight         or about 65,543
                                        CX = tick count, ticks/hour.
                                        high word
                                        DX = tick count,
                                        low word
    ──────────────────────────────────────────────────────────────────────────
    Time-of-Day                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
    ──────────────────────────────────────────────────────────────────────────
    Set current      1AH AH = 01H         None
    clock count.         CX = tick count,
                        high word
                        DX = tick count,
                        low word
    ──────────────────────────────────────────────────────────────────────────
    Read real-time   1AH AH = 02H         CH = hours       PC/AT and PS/2s
    clock.                                (in BCD)         only. Daylight
                                        CL = minutes     savings option not
                                        (in BCD)         available in PC/AT
                                        DH = seconds     BIOS dated
                                        (in BCD)         01/10/84.
                                        CF = 1 if clock
                                        not operating
                                        DL = 01H if
                                        daylight savings
                                        time option set
    Time-of-Day                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        time option set
    ──────────────────────────────────────────────────────────────────────────
    Set real-time    1AH AH = 03H                          Input values in
    clock.               CH = hours                        BCD.
                        CL = minutes                      PC/AT and PS/2s
                        DH = seconds                      only. Daylight
                        DL = 01H for                      savings option not
                        automatic                         available in PC/AT
                        adjustment for                    BIOS dated
                        daylight savings                  01/10/84.
                        time
    ──────────────────────────────────────────────────────────────────────────
    Read date from   1AH AH = 04H         DL = day (in     PC/AT and PS/2s
    real-time clock.                      BCD)             only.
                                        DH = month (in
                                        BCD)
                                        CL = year (in
                                        BCD)
    Time-of-Day                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        BCD)
                                        CH = century (19
                                        or 20 in BCD)
                                        CF = 1 if clock
                                        not operating
    ──────────────────────────────────────────────────────────────────────────
    Set date in      1AH AH = 05H                          PC/AT and PS/2s
    real-time clock.     DL = day                          only.
                        (in BCD)
                        DH = month
                        (in BCD)
                        CL = year
                        (in BCD)
                        CH = century (19
                        or 20, in BCD)
    ──────────────────────────────────────────────────────────────────────────
    Set alarm.       1AH AH = 06H         CF = 1 if clock  Place address for
                        CH = hours       not operating or alarm routine in
    Time-of-Day                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                        CH = hours       not operating or alarm routine in
                        (in BCD)         alarm already    interrupt 4AH
                        CL = minutes     set              vector before using
                        (in BCD)                          this service.
                        DH = seconds
                        (in BCD)
    ──────────────────────────────────────────────────────────────────────────
    Reset alarm.     1AH AH = 07H         None             Disables alarm
                                                            previously set with
                                                            INT 1AH, service
                                                            06H.
    ──────────────────────────────────────────────────────────────────────────
    Get alarm time   1AH AH = 09H         CH = hours (in   PS/2 models 25, 30
    and status.                           BCD)             only.
                                        CL = minutes (in
                                        BCD)
                                        DH = seconds (in
                                        BCD)
    Time-of-Day                 Register
    Services         Int Input            Output           Notes
    ──────────────────────────────────────────────────────────────────────────
                                        BCD)
                                        DL = alarm
                                        status:
                                        00H: alarm not
                                        enabled
                                        01H: alarm
                                        enabled
    ──────────────────────────────────────────────────────────────────────────




────────────────────────────────────────────────────────────────────────────
Chapter 14  DOS Basics

    The Pros and Cons of Using the DOS Services
    DOS: A Disk-Service Cornucopia
    DOS and Video: A Difficult Match

    DOS Version Differences

    Diskette Format Considerations

    Comments

    Chapters 15 through 18 focus on the program support services provided by
    DOS. These DOS services are the entire set of operations that DOS provides
    to programs. The last chapter in the series, Chapter 18, summarizes their
    technical details. In this chapter, we introduce some of the main concerns
    a programmer often faces when working with the DOS services.

    Programs access DOS services through a set of interrupts. Interrupt
    numbers 20H through 3FH (decimal 32 through 63) are reserved for use by
    DOS. Although 10 of these interrupts can be used in programs, most DOS
    services are invoked in much the same way as the ROM BIOS services:
    through one umbrella interrupt, interrupt 21H (decimal 33). You can access
    a variety of DOS functions by specifying a function number in register AH
    at the time you call interrupt 21H.


The Pros and Cons of Using the DOS Services

    The question of whether or not to use the DOS services arises naturally
    during the design and development of sophisticated programs. Our general
    advice, echoed throughout this book, is for you to use the highest
    available services that will accomplish what you need. This means that,
    whenever possible, you should use the built-in services of your
    programming language first, resorting only when necessary to direct use of
    the DOS services or the ROM BIOS services, and resorting only in extreme
    circumstances to direct programming of the computer's hardware.

    In practical terms, either a program can be written entirely within the
    confines of the programming language's facilities or nearly all of its I/O
    work must be done outside the programming language, at a lower level. When
    a lower level of programming is needed, with very few exceptions the DOS
    services are best suited for disk operations. When you are working with
    the keyboard or other I/O devices, either the DOS routines or the ROM BIOS
    routines will be adequate, depending on the application. But for low-level
    video-display programming, the situation is more complex. Satisfactory
    screen output almost always seems to call for the ROM BIOS services and
    direct hardware programming, even though in some cases screen output is
    best left in the hands of DOS. We'll see why in a moment.

DOS: A Disk-Service Cornucopia

    When you inspect the full range of tools and services placed in your hands
    by programming languages, by DOS, by the ROM BIOS, and by the computer's
    hardware, it becomes quite clear that the richest concentration of
    disk-oriented services exists at the DOS level. This almost goes without
    saying, because DOS, as a disk operating system, is inherently strongest
    in its support of disk operations.

    As discussed in Chapters 16 and 17, the majority of services that DOS
    performs are directly connected to the manipulation of disk files. Even
    some services that are nominally controlled by a program, such as loading
    and executing another program (interrupt 21H, function 4BH), involve
    disk-file operations. From this perspective, DOS is not so much a disk
    operating system as it is a system of disk services designed for use by
    your programs. When you are developing programs for the IBM personal
    computer family, you should approach DOS from this standpoint: Think of
    DOS as a cornucopia of disk operations placed at your service.

DOS and Video: A Difficult Match

    Unfortunately, DOS does not provide much in the way of video output
    services. In fact, the available DOS services are limited to a
    character-only, "glass teletype" interface that is rapidly becoming an
    anachronism in these days of high-resolution color graphics.

    To achieve attractive, high-performance video output, you must rely on the
    ROM BIOS or on direct programming of the video hardware. As we have seen,
    IBM has maintained a fairly consistent programming interface to its video
    hardware, so many programmers make a practice of bypassing DOS and using
    lower-level video programming techniques.

    But when you bypass DOS, you encounter a problem: Two different programs
    can't reliably share the video hardware. Consider what can happen, for
    example, if you write a program that configures the video hardware in a
    way that conflicts with the configuration used by a memory-resident
    "pop-up" program like SideKick. If your program runs in a video mode that
    the pop-up program doesn't recognize, the pop-up program's output may
    appear incomprehensible on the screen. Worse, the pop-up program may
    reconfigure the video subsystem for its own purposes and leave your
    program's video output in limbo.

    The problem is amplified in multitasking operating environments, such as
    Microsoft Windows or OS/2, where programs generally share access to the
    screen. In these environments, a program can bypass the operating system
    and gain complete control of the screen only if the operating system
    suspends video output from all other concurrently executing programs. Thus
    a program that ties up the video hardware can delay the multitasking
    execution of background programs.

    The designers of OS/2 and Microsoft Windows attacked this problem by
    providing a sophisticated gamut of video output services. These video
    output services not only resolve conflicts between programs that want to
    access the video display, but they also provide very good performance. To
    get the best video performance in the world of DOS, however, you must
    either resort to ROM BIOS calls and direct hardware programming or else
    rely on the video output services provided by your programming language
    (which themselves bypass DOS).

    When trying to decide which method to use, you should consider the
    probable lifetime of your programs and the range of machines they might be
    used on. For a PC-specific game program with an expected life of a few
    months (common for games), you have little reason to worry about these
    issues. This is not the case for a generalized business or professional
    application, which should be usable for many years and in many
    environments. Make your choice and place your bets.


DOS Version Differences

    DOS has evolved since the release of version 1.0 in 1981. Even though each
    new release has contained both improvements and bug-fixes, the driving
    force behind each release has been a hardware change, and a hardware
    change has usually involved a disk-drive change. (See Figure 14-1.)

    In all but versions 2.1 and 3.1, changes to DOS involved significant
    modifications to disk support (including new disk-storage formats). The
    main change to 2.1 was relatively minor, but was disk-related: The
    diskette control head-settle time was adjusted to allow for differences in
    the performance of the half-height drives used in the PCjr and Portable
    PC. Version 2.1 also corrected a few of the known bugs in 2.0. Version 3.1
    incorporated networking functions that were designed for version 3.0, but
    not ready when 3.0 was released. The following list summarizes the main
    differences between these versions:

    Version        Release Date   Hardware Change
    ──────────────────────────────────────────────────────────────────────────
    1.0            August 1981    Original IBM PC (single-sided diskette
                                drive)
    1.1            May 1982       Double-sided diskette drive
    2.0            March 1983     PC/XT
    2.1            October 1983   PCjr and Portable PC
    3.0            August 1984    PC/AT
    3.1            March 1985     PC Network
    3.2            January 1986   Support for 3-1/2-inch diskette drives
    3.3            April 1987     PS/2s
    ──────────────────────────────────────────────────────────────────────────

    Figure 14-1.  DOS releases and associated changes to hardware.

    Version 1.0 supported the single-sided, 8-sector diskette format. All
    basic DOS services were included in this release.

    Version 1.1 added support for double-sided diskettes. The DOS services
    remained the same.

    Version 2.0 added support for 9-sector diskettes (both single- and
    double-sided) and for the PC/XT fixed disk. The DOS services were enhanced
    extensively in this version. (See Chapter 17.)

    Version 2.1 added neither new disk formats nor new DOS services; it did,
    however, adjust its disk operation timing to benefit the PCjr and the
    Portable PC.

    Version 3.0 added support for the PC/AT's 1.2 MB diskette drive and
    additional fixed-disk formats. It also laid the groundwork for network
    disks.

    Version 3.1 added network disks, which include a file-sharing capability.

    Version 3.2 introduced support for 3-1/2-inch diskette drives.

    Version 3.3 was announced concurrently with IBM's introduction of the
    PS/2s. Several new commands and functions were included specifically to
    support the PS/2 hardware.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Each version of DOS is compatible with prior versions, except in some
    very detailed respects (these sorts of details always seem to be
    unavoidable).
    ──────────────────────────────────────────────────────────────────────────

    With each release of DOS, there has been a question among software
    developers about which version of DOS to target.

    In particular, DOS versions 2.0 and later supported a much wider variety
    of disk hardware and provided significantly more programming services than
    did versions 1.0 and 1.1, so programs that used the more advanced features
    of the later DOS versions wouldn't run at all on versions 1.0 and 1.1.
    Fortunately, the number of people still using version 1.0 or 1.1 is very
    small, so most software developers target their applications toward
    versions 2.0 and later. The differences between these later DOS versions
    are relatively minor and can usually be accommodated in software that
    verifies which version of DOS is running.

    Far-sighted software developers must also tackle the question of
    compatibility with future versions of DOS. Both IBM and Microsoft are
    looking toward OS/2 as the logical successor to DOS. In this view, DOS is
    considered a "mature" product; that is, enhancements to future versions
    aren't likely to affect existing DOS programs.

    Microsoft has published guidelines to help DOS software developers write
    programs that can later be converted for use under OS/2. In our
    discussions of DOS services in the next few chapters, we'll point out
    several techniques that can help ensure the future compatibility of your
    DOS programs.

    In any case, a program can detect which version of DOS it is running under
    by using DOS function 30H (decimal 48). Unless you can be sure of your
    audience, you should include this safeguard in your programs and always
    check to be certain that the correct DOS version is installed.


Diskette Format Considerations

    If you're planning to share or sell your programs, you must decide which
    diskette format you'll use to distribute your software. Initially, most
    software vendors used single-sided 5-1/4-inch diskettes with eight sectors
    per track, because this format was the lowest common denominator that
    could be read by all versions of DOS. Later, as single-sided diskette
    drives became virtually extinct, software publishers adopted the
    double-sided 5-1/4-inch diskette format as an acceptable medium.

    If you sell software for both PCs and PS/2s, however, you must contend
    with 3-1/2-inch as well as 5-1/4-inch diskette formats. In this case, you
    should probably stick to the 720 KB format for 3-1/2-inch disks. You
    should also offer a choice of diskette sizes, because both 5-1/4-inch and
    3-1/2-inch formats are in widespread use and will be for some time to
    come.


Comments

    Technical information about DOS has become much easier to find since the
    early days, when the only reliable sources of information were the DOS
    technical reference manuals. Nowadays, many PC programming magazines
    discuss DOS programming techniques. Several good reference books on
    various detailed aspects of DOS programming, including memory-resident
    programs, installable device drivers, and exception handlers, are also
    available.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Two "official" sources of detailed information about DOS are the DOS
    technical reference manuals distributed by IBM and The MS-DOS
    Encyclopedia (published by Microsoft Press).
    ──────────────────────────────────────────────────────────────────────────



────────────────────────────────────────────────────────────────────────────
Chapter 15  DOS Interrupts

    The Five Main DOS Interrupts
    Interrupt 20H (decimal 32): Program Terminate
    Interrupt 21H (decimal 33): General DOS Services
    Interrupts 25H and 26H (decimal 37 and 38): Absolute Disk Read and
    Write
    Interrupt 27H (decimal 39): Terminate and Stay Resident

    The Multiplex Interrupt

    The Three DOS Address Interrupts
    Interrupt 22H (decimal 34): Terminate Address
    Interrupt 23H (decimal 35): Ctrl-C Handler Address
    Interrupt 24H (decimal 36): Critical Error-Handler Address

    The DOS Idle Interrupt

    The Program Segment Prefix (PSP)
    The Internal Structure of the PSP

    An Example

    In this chapter we'll describe how to communicate with DOS through
    interrupts. (See Figure 15-1.) DOS reserves all 32 interrupt numbers from
    20H through 3FH (decimal 32 through decimal 63) for its own use. DOS
    provides system services through five of these interrupts (20H, 21H, 25H,
    26H, and 27H). These interrupts can be called directly from a program with
    the INT instruction. DOS uses the interrupt vectors for four others (22H,
    23H, 24H, and 28H) to contain the addresses of routines called by DOS
    itself; you can substitute your own routines for the default DOS routines
    by updating one of these interrupt vectors. Interrupt 2FH is reserved for
    communication between memory-resident programs. The other 22 interrupts
    reserved by DOS are not intended for use in your programs.

    Interrupt  Number
    Hex        Dec        Description
    ──────────────────────────────────────────────────────────────────────────
    20H        32         Program Terminate
    21H        33         General DOS Services
    22H        34         Terminate Address
    23H        35         Ctrl-C Handler Address
    24H        36         Critical Error-Handler Address
    25H        37         Absolute Disk Read
    26H        38         Absolute Disk Write
    27H        39         Terminate and Stay Resident
    28H        40         DOS Idle Interrupt
    2FH        47         Multiplex Interrupt
    ──────────────────────────────────────────────────────────────────────────

    Figure 15-1.  DOS interrupts.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    You can use any of the 10 interrupts described in this chapter in your
    programs. Nevertheless, there is some overlap between the services
    provided through the separate interrupts described in this chapter and
    the functions available through interrupt 21H. When you have a choice,
    use the interrupt 21H functions described in Chapters 16 and 17. We'll
    point out why as we describe each DOS interrupt.
    ──────────────────────────────────────────────────────────────────────────


The Five Main DOS Interrupts

    Of the DOS interrupts described in this chapter, five have built-in
    interrupt-handling programs, each of which performs a particular task.

Interrupt 20H (decimal 32): Program Terminate

    Interrupt 20H (decimal 32) is used to exit from a program and pass control
    back to DOS. It is similar to interrupt 21H, function 00H. (See page
    325.) These services can be used interchangeably with any version of DOS
    to end a program.

    Interrupt 20H does not automatically close files opened with interrupt
    21H, functions 0FH or 16H when it terminates a program, so you should
    always use interrupt 21H, function 10H to close such files before
    exiting. If a modified file is not formally closed, its new length will
    not be recorded in the file directory.

    A program can set three operational addresses through DOS interrupts 22H,
    23H, and 24H, as we will see shortly. As part of the clean-up operations
    performed by DOS for interrupt 20H, these addresses are restored to the
    values they had before the program was executed. Resetting these addresses
    is essential if the program that invoked interrupt 20H was executed as the
    "child" of another program. It serves to protect the "parent" program from
    using routines intended for the "child." (See DOS function 4BH [decimal
    75] in Chapter 17.)

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    When DOS executes a program, it constructs a program segment prefix
    (PSP), a 256-byte block of memory that contains control information
    that, among other things, is referenced by DOS when a program is
    terminated. (We discuss the PSP in detail at the end of this chapter.)
    DOS depends on the CS register to point to the PSP when the interrupt
    20H terminate service is invoked. If the CS register points elsewhere,
    DOS may crash.

    In practice, we recommend that you terminate your programs with
    interrupt 21H, function 4CH, which is more flexible and less
    restrictive than interrupt 20H. The only reason to use interrupt 20H is
    to maintain compatibility with DOS version 1.0.
    ──────────────────────────────────────────────────────────────────────────

Interrupt 21H (decimal 33): General DOS Services

    You can take advantage of a wide range of DOS functions through interrupt
    21H (decimal 33). Each function has a unique number you specify when you
    execute interrupt 21H. Chapters 16 and 17 cover the gamut of interrupt
    21H services in detail.

Interrupts 25H and 26H (decimal 37 and 38): Absolute Disk Read and Write

    Interrupt 25H (decimal 37) and its companion, interrupt 26H (decimal 38),
    are used to read and write specific disk sectors. They are the only DOS
    services that ignore the logical structure of a disk and work only with
    individual sectors, paying no attention to the locations of files, file
    directories, or the File Allocation Table.

    Interrupts 25H and 26H are similar to the corresponding ROM BIOS disk
    services, except that the sectors are located by a different numbering
    method. With the ROM BIOS services, the sectors are selected by their
    three-dimensional coordinate locations (cylinder, head, and sector),
    whereas with interrupts 25H and 26H, the sectors are selected by their
    sequential logical sector numbers. (DOS's sector-numbering system is
    discussed on page 109.)

    The following BASIC formula converts three-dimensional coordinates used by
    the ROM BIOS to logical sector numbers used by DOS:

    LOGICAL.SECTOR = (SECTOR - 1) + (HEAD * SECTORS.PER.TRACK) +
    (CYLINDER * SECTORS.PER.TRACK * NUMBER.OF.HEADS)

    And here are the formulas for converting logical sector numbers to
    three-dimensional coordinates:

    SECTOR = 1 + LOGICAL.SECTOR MOD SECTORS.PER.TRACK
    HEAD = (LOGICAL.SECTOR \ SECTORS.PER.TRACK) MOD NUMBER.OF.HEADS
    CYLINDER = LOGICAL.SECTOR \ (SECTORS.PER.TRACK * NUMBER.OF.HEADS)

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Don't forget that the ROM BIOS counts heads and cylinders from 0 but
    counts sectors from 1; DOS logical sectors are numbered from 0.
    ──────────────────────────────────────────────────────────────────────────

    To use interrupt 25H or 26H to read or write a block of logical sectors,
    load the necessary parameters into the CPU registers and execute the
    interrupt. The number of sectors is specified in the CX register, the
    starting sector number is specified in DX, and the memory address for data
    transfer is specified in DS:BX. The disk drive is selected by placing a
    number in the AL register: Drive A is 0, drive B is 1, and so on.

    Although ROM BIOS services work with true physical drives, DOS services
    work with logical drive numbers. DOS assumes every computer has at least
    two logical drives. If no physical drive B exists, DOS will simulate it by
    using the one physical drive as either A or B, whichever is needed. You
    can then remap these logical drives by using the DOS ASSIGN command.

    The results of interrupts 25H and 26H are reported in the carry flag (CF)
    and the AL and AH registers. If no error occurred, CF = 0. If an error did
    occur (CF = 1), AL and AH contain the error codes in two somewhat
    redundant groups. The AL codes in Figure 15-2 are based on those used by
    the DOS critical-error handler through interrupt 24H (see page 308), and
    the AH codes in Figure 15-3 are based on the error codes reported by the
    ROM BIOS (see page 201).

    Error Code         Meaning
    Hex    Dec
    ──────────────────────────────────────────────────────────────────────────
    00H     0          Write-protect error: attempt to write on protected
                        diskette
    01H     1          Unknown unit: invalid drive number
    02H     2          Drive not ready (e.g. no disk, or door open)
    04H     4          CRC (cyclical redundancy check) error: parity error
    06H     6          Seek error: move to requested cylinder failed
    07H     7          Unknown media: disk format not recognized
    08H     8          Sector not found
    0AH    10          Write error
    0BH    11          Read error
    0CH    12          General, nonspecific error
    0FH    15          Invalid disk change
    ──────────────────────────────────────────────────────────────────────────

    Figure 15-2.  The error-code values and meanings returned in the AL
    register following an error in a disk read or write through DOS interrupt
    25H or 26H.

    Error Code
    Hex    Dec         Meaning
    ──────────────────────────────────────────────────────────────────────────
    02H      2         Bad address mark: sector ID marking invalid or not
                        found
    03H      3         Write-protect error: attempt to write on protected disk
    04H      4         Bad sector: requested sector not on disk
    08H      8         DMA (direct memory access) failure
    10H     16         Bad CRC: read found invalid parity check of data
    20H     32         Controller failed: disk drive controller malfunction
    40H     64         Bad seek: move to requested track failed
    80H    128         Time out: drive did not respond
    ──────────────────────────────────────────────────────────────────────────

    Figure 15-3.  The error-code values and meanings returned in the AH
    register following an error in a disk read or write through DOS interrupt
    25H or 26H.

    Normally, interrupt handlers and other service routines leave the stack
    clean when they exit, returning it to its original size and contents. DOS
    interrupts 25H and 26H deliberately do not clean up the stack. Instead,
    they finish and return to the program with one word left on the stack.
    This word holds the contents of the flag register, showing how the flags
    were set when the program invoked the service. This is purportedly done to
    preserve the program's flag status before the service was used, because
    interrupts 25H and 26H use the flags for their return codes. We think this
    is a silly precaution because any program that needs to preserve the flags
    can simply do what programs normally do when they need something saved:
    PUSH them onto the stack themselves. Any program that uses interrupts 25H
    and 26H should POP the two extra flag-status bytes off the stack after the
    interrupt returns. These bytes can either be placed in the flags register
    with a POPF command (which should be done after testing CF for an error)
    or be discarded by incrementing the stack pointer register by 2 (ADD
    SP,2).

Interrupt 27H (decimal 39): Terminate and Stay Resident

    Interrupt 27H (decimal 39) invokes one of the most interesting of all the
    services provided by DOS.

    Like interrupt 20H, interrupt 27H ends a program, but does not erase it
    from memory. Instead, it leaves a specified portion of the program in
    memory (the program stays resident). The program and data that are made
    resident using interrupt 27H become, in effect, an extension of DOS and
    will not be overwritten by other programs.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    As with interrupt 20H, DOS versions 2.0 and later provide a more
    flexible alternative to interrupt 27H. This is interrupt 21H, function
    31H, which we recommend instead of interrupt 27H unless you are
    concerned about compatibility with DOS version 1.0. See Chapter 17 for
    more about interrupt 21H, function 31H.
    ──────────────────────────────────────────────────────────────────────────

    Interrupt 27H (or its function-call equivalent) is used by a number of
    sophisticated "pop-up" programs like SideKick. Terminate-and-stay-resident
    (TSR) programs typically use this service to establish new
    interrupt-handling routines that are meant to stay in effect indefinitely.
    Most often, these interrupt-handling routines replace existing DOS or ROM
    BIOS interrupt handlers in order to change or extend their operation. But
    the resident item is not limited to interrupt handlers and program
    instructions; it could just as easily be data. For example, the same
    programming technique could be used to load status information into a
    common area that various programs would share, allowing them to
    communicate indirectly.

    Normally, a TSR program is designed in two parts: a resident portion that
    remains in memory and a transient portion that installs the resident
    portion by updating interrupt vectors, initializing data, and calling the
    Terminate-and-Stay-Resident service. The transient portion does not remain
    in memory after interrupt 27H is executed.

    To accommodate this process, TSR programs are designed with the resident
    portion first (that is, at lower addresses). The transient portion
    computes the size of the resident portion and places this value in
    register DX when it executes interrupt 27H. DOS then leaves the resident
    portion in memory but reclaims the memory occupied by the transient
    portion for executing other programs.

    Anything left resident by this service normally remains resident as long
    as DOS is also resident. It is not unusual for several different programs
    to leave part of themselves resident. Programs that use this technique are
    usually sophisticated and complicated, so it is also not unusual for them
    to interfere with each other. To operate such a group of resident programs
    successfully, you must sometimes load them in a particular order──an order
    you may have to discover through experimentation (an unfair trick to play
    on an unsuspecting user).

    As with interrupt 20H, the ordinary terminate service, DOS resets the
    address vectors for interrupts 22H through 24H when it performs this
    terminate-and-stay-resident service. Therefore, you can't use this service
    to create resident interrupt handlers for the address interrupts. Although
    seemingly a limitation, this is actually fairly reasonable: The address
    interrupts are not meant to be used globally; they are meant to be used
    only by individual programs. (See the DOS address interrupts section that
    follows for further discussion.)


The Multiplex Interrupt

    The multiplex interrupt, interrupt 2FH (decimal 47), is used to
    communicate with memory-resident programs. This interrupt wasn't used in
    DOS version 1, but in version 2 the RAM-resident print spooler PRINT used
    it. In DOS versions 3.0 and later, the protocol for using interrupt 2FH
    was standardized to allow multiple memory-resident programs to share the
    interrupt. (That's why this interrupt is called the multiplex interrupt.)

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Most of the material in this chapter applies to all versions of DOS;
    however, interrupt 2FH is available only with DOS versions 3.0 and
    later.
    ──────────────────────────────────────────────────────────────────────────

    To use the multiplex interrupt, you must write a memory-resident TSR
    program that contains an interrupt handler for interrupt 2FH. (Use the DOS
    Terminate-and-Stay-Resident service to do this.) The transient portion of
    the TSR program must copy the address of the previous interrupt 2FH
    handler from the interrupt 2FH vector (0000:00BCH) to a variable in the
    resident portion. The transient portion then updates the interrupt 2FH
    vector with the address of the resident portion's interrupt 2FH handler so
    that when interrupt 2FH is subsequently executed, the TSR's handler gets
    control.

    When interrupt 2FH is executed, the resident interrupt 2FH handler does
    the following:

    IF      AH=IDnumber
    THEN    process the value in AL
            return from the interrupt (IRET)
    ELSE    jump to the previous interrupt 2FH handler

    This simple logic lets several memory-resident programs use the multiplex
    interrupt to communicate. The key is that every memory-resident program
    must have a unique ID number. Your program's interrupt 2FH handler should
    recognize one of the 64 values between C0H and FFH. (There are 256
    possible ID numbers, of course, but Microsoft and IBM reserve numbers 00H
    through BFH for use by DOS utilities.)

    When your program's interrupt 2FH handler gains control, it must first
    check the value in register AH. If the value in AH matches the program's
    ID number, the handler looks in AL to decide what to do next. If the
    values don't match, the handler simply jumps to the address of the
    previous interrupt 2FH handler.

    The interrupt 2FH handler considers the value in AL to be a function
    number and processes it accordingly, as described in the following
    paragraphs:

    Function 00H has a special meaning. It instructs the interrupt handler to
    return one of two values in AL:

    ■  A value of FFH indicates that an interrupt 2FH handler is resident in
        memory and available to process other function numbers.

    ■  A value of 01H indicates that the ID number in AH is in use.

    So, to detect whether a particular TSR program is installed in memory, a
    program executes interrupt 2FH with the TSR's ID number in AH and with AL
    = 00H. If the TSR is present in memory, it returns AL = FFH. If another
    TSR is using the ID number for its own purposes, that TSR returns AL =
    01H. Otherwise, any interrupt 2FH handlers in memory simply ignore the
    interrupt, causing the interrupt to return AL = 00H.

    The best-documented example of how to use the multiplex interrupt is the
    PRINT program supplied with DOS versions 3.0 and later. By examining how
    PRINT uses the multiplex interrupt, you can make better use of this
    interrupt in your own memory-resident programs.

    PRINT's multiplex ID number is 1. Any time interrupt 2FH is executed with
    this ID number in AH, PRINT's memory-resident interrupt handler processes
    the interrupt. Because six different functions are defined by PRINT (see
    Figure 15-4), a call to PRINT consists of executing interrupt 2FH with AH
    = 01H and a function number in AL.

    Each time you run PRINT, the program executes interrupt 2FH with AH = 01H
    and AL = 00H. The first time you run the program, the value returned in AL
    by the interrupt is 00H, so the program installs itself in memory. When
    you invoke PRINT a second time, the value returned in AL as a result of
    executing the multiplex interrupt with AH = 01H is FFH. This value is
    placed there by the memory-resident copy of PRINT, so the second
    invocation of the program knows not to install itself in memory.

    The second and subsequent invocations of PRINT can request any of five
    different functions by passing a function number to the first,
    memory-resident copy of the program. You could also use these functions in
    your own programs by placing the value 01H (PRINT's multiplex ID) in
    register AH, the function number in register AL, and then issuing
    interrupt 2FH.

    Function Number                      Description
    ──────────────────────────────────────────────────────────────────────────
    00H                                  Get installed status.
    01H                                  Submit file to print.
    02H                                  Remove file from print queue.
    03H                                  Cancel all files in print queue.
    04H                                  Hold print queue.
    05H                                  Release print queue.
    ──────────────────────────────────────────────────────────────────────────

    Figure 15-4.  PRINT functions defined through the multiplex interrupt.

    Function 01H submits a file to the print spooler for printing. To tell
    PRINT what is to be printed, you set the register pair DS:DX to point to a
    5-byte area called a submit packet. The first byte of the submit packet is
    a level code (which should be 0). The remaining 4 bytes of the submit
    packet are the segmented address of an ASCIIZ string (see page 350) that
    defines the pathname of the file to be printed. The pathname must be a
    single file. The global filename characters * and ? are not allowed.

    When a file is submitted using this function, it is added to the end of
    the queue, or list, of files to be printed. The files are printed in turn
    and are dropped from the queue after they're printed.

    Function 02H cancels individual files queued for printing. The register
    pair DS:DX points to the ASCIIZ string that defines which file is to be
    removed from the queue. In this case, the global filename characters * and
    ? can be used. In function 02H, DS:DX points directly to the filename
    string, rather than to a submit packet that points to the string.

    Function 03H cancels all files queued for printing. For both functions 02H
    and 03H, if the file currently being printed is canceled, PRINT stops
    printing the file and prints a short message to that effect.

    Function 04H gives programs access to the print queue so they can inspect
    it. The queue is frozen when this function is requested, so you don't have
    to worry about the list changing while you inspect it. Issuing any other
    PRINT function call will unfreeze the queue. Function 04H returns a
    pointer in the register pair DS:SI that points to a list of filenames
    queued for printing. Entries in the list are strings with a fixed length
    of 64 bytes. The end of the list is indicated by an entry that begins with
    a zero byte.

    The queue freeze imposed by function 04H doesn't need to halt the printing
    operation. But function 04H will suspend the removal from the queue of a
    file that is finished printing.

    Function 05H is essentially a null function that does nothing but unfreeze
    the queue of filenames frozen by function 04H. (The other four functions
    can do this, too.)


The Three DOS Address Interrupts

    DOS uses three interrupts, 22H through 24H (decimal 34 through 36), to
    handle three exceptional circumstances: the end of a program, a "break"
    keyboard action (Ctrl-Break or Ctrl-C on the standard PC keyboard), and
    any "critical error" (usually a disk error of some kind). Your programs
    can affect the action taken in each of these three circumstances by
    changing the corresponding interrupt vector to point to any operation you
    choose. This is why we call these interrupts the address interrupts.

    DOS maintains a default address setting for each of these interrupts,
    which is preserved at the beginning of a program's operation and restored
    after the program is finished. This allows your programs to freely change
    these vectors according to their needs without disturbing the operation of
    subsequent programs or the operation of DOS itself.

Interrupt 22H (decimal 34): Terminate Address

    The address associated with interrupt 22H (decimal 34) specifies where
    control of the computer will be passed when a program's execution ends
    with a call to DOS interrupt 20H or 27H, or with interrupt 21H, function
    00H, 31H, or 4CH. Interrupt 22H isn't designed to be executed directly by
    a program using the INT instruction. Instead, DOS uses the interrupt 22H
    vector to store the address of its own program termination routine.

    It's not a good idea to manipulate the DOS terminate address. The inner
    workings of the default DOS program termination routine are not
    documented, so writing a substitute routine that terminates a program
    cleanly without confounding DOS is difficult. If you are qualified to use
    this feature, then you probably understand it better than we can explain
    it.

Interrupt 23H (decimal 35): Ctrl-C Handler Address

    The address associated with interrupt 23H (decimal 35) points to the
    interrupt-handling routine that DOS invokes in response to the Ctrl-C key
    combination. Thus interrupt 23H is intended to be executed only by DOS,
    not by an application program. A few old-fashioned programs, such as the
    DOS editor EDLIN, use Ctrl-C as a command keystroke, but in most
    applications the Ctrl-C combination signals that the user wants to
    interrupt an ongoing process.

    DOS is a bit quirky about when it will respond to a Ctrl-C keystroke.
    Normally, DOS acts on a break only when it is reading from or writing to a
    character I/O device (the screen, keyboard, printer, or communications
    port). However, the BREAK ON command allows DOS versions 2.0 and later to
    act on Ctrl-C at the time of most other DOS system calls.

    DOS's default Ctrl-C handler terminates the program or batch file you are
    executing. However, if your program provides its own interrupt 23H
    handler, it can have DOS take any action you want.

    In general, a Ctrl-C handler can take three different courses of action:

    ■  It can perform some useful action, such as setting a flag, and then
        return to DOS with an interrupt return (IRET) instruction. In this
        case, DOS picks up where it left off, without terminating your
        program's execution.

    ■  It can set or clear the carry flag and then return to DOS with a far
        return instruction (RET 2) that discards the flags pushed on the stack
        when the interrupt 23H handler was called by DOS. If the carry flag is
        set, DOS terminates the interrupted program. If the carry flag is
        clear, DOS continues execution.

    ■  It can keep control without returning to DOS. This option is tricky,
        however, because you don't usually know what was on the stack at the
        moment DOS detected the Ctrl-C keystroke. An interrupt 23H handler that
        doesn't return to DOS should generally restore the stack pointer
        register (SP) to a predetermined value. It should also execute
        interrupt 21H, function 0DH, to flush DOS file buffers so that the DOS
        disk I/O system will be in a known state.

    The usual reason to write your own Ctrl-C handler is to let your program
    handle a keyboard break itself. Even if you want your program to terminate
    immediately after Ctrl-C is pressed, you may still need to clean up before
    your program terminates. For example, if you use interrupt 21H, functions
    0FH or 16H, to open a file, you should write your own Ctrl-C handler to
    close it because the default DOS Ctrl-C handler won't do so. Also, if you
    installed your own interrupt handlers for ROM BIOS or hardware interrupts,
    the DOS Ctrl-C handler won't restore them before it terminates your
    program. Again, your Ctrl-C handler should do this if necessary.

    If you do write your own Ctrl-C handler, don't forget the relationship
    between Ctrl-C and the keyboard Ctrl-Break combination. When you press
    Ctrl-Break, the ROM BIOS keyboard interrupt handler generates interrupt
    1BH. DOS's interrupt 1BH handler inserts a Ctrl-C key code into the
    keyboard input buffer. The next time DOS checks the keyboard buffer, it
    finds Ctrl-C and executes interrupt 23H. Thus, in effect, pressing
    Ctrl-Break has the same effect as pressing Ctrl-C, except that DOS detects
    the break generated by Ctrl-Break without first processing the intervening
    characters in the keyboard buffer.

Interrupt 24H (decimal 36): Critical Error-Handler Address

    The address associated with interrupt 24H (decimal 36) points to the
    interrupt-handling routine invoked whenever DOS detects a "critical
    error"── an emergency situation that prevents DOS from continuing with
    normal processing. Typically, the critical error is a disk error, but
    other errors are also reported, as we'll see.

    Like interrupt 23H, interrupt 24H is intended to be invoked only by DOS,
    not by an application program. However, an application can substitute its
    own interrupt 24H handler for the default DOS handler. The DOS default
    handler produces a familiar message (shown on the following page).

    Abort, Retry, Ignore?           (in DOS versions prior to 3.3)

    or

    Abort, Retry, Fail?             (in DOS versions 3.3 and later)

    If you substitute a customized interrupt 24H handler for the one DOS
    provides, you can tailor critical-error handling to the needs of your
    program.

    When DOS transfers control to a critical-error handler, it provides
    several sources of information about the error itself, and about the state
    of the system before the error occurred. These sources include the
    register pair BP:SI, the stack, the AH register, and the DI register. We
    will cover them one by one because this process is quite complicated.

    If you are operating under DOS version 2.0 or later, the register pair
    BP:SI is set to point to a device-header control block. Your
    critical-error handler can inspect the device header to learn more about
    the device (disk drive, printer, and so forth) that experienced the error.
    (See the DOS technical reference manuals for more about the device
    header.)

    When the critical-error handler gains control, the stack contains the
    complete register set of the program that issued the DOS function call
    that ended in the critical error. This information can be quite useful to
    an error handler that is intimately integrated with the active program.
    The usual method of accessing the information on the stack is to address
    the stack through register BP. You can access the stack as shown in Figure
    15-5 on the following page if the first two instructions in your
    critical-error handler are

    PUSH    BP
    MOV     BP,SP

    DOS indicates the nature of a critical error primarily through a
    combination of the high-order bit of the AH register and the low-order
    byte of the DI register (a curious choice, for sure). If the high-order
    bit of AH is 0, the error is related to a disk operation. If the same bit
    (bit 7 of AH) is 1, the error is something other than a disk error, as we
    shall discuss shortly.

    When the error is a disk-device error (high-order bit of AH is 0),
    register AL identifies the drive number (0 is drive A, 1 is drive B, and
    so on). Bits 0 through 5 of AH indicate further information about the
    error, as shown in Figure 15-6.

            ┌─────────────┐ ──┐
    [BP + 30] │    Flags    │   │
            ├─────────────┤   │
    [BP + 28] │     CS      │   ├── Flags and CS:IP pushed by the
            ├─────────────┤   │   interrupt 21H call that generated
    [BP + 26] │     IP      │   │   the error
            ├─────────────┤ ──┤
    [BP + 24] │     ES      │   │
            ├─────────────┤   │
    [BP + 22] │     DS      │   │
            ├─────────────┤   │
    [BP + 20] │     BP      │   │
            ├─────────────┤   │
    [BP + 18] │     DI      │   │
            ├─────────────┤   │
    [BP + 16] │     SI      │   ├── Registers at point of interrupt 21H call
            ├─────────────┤   │
    [BP + 14] │     DX      │   │
            ├─────────────┤   │
    [BP + 12] │     CX      │   │
            ├─────────────┤   │
    [BP + 10] │     BX      │   │
            ├─────────────┤   │
    [BP + 8] │     AX      │   │
            ├─────────────┤ ──┤
    [BP + 6] │    Flags    │   │
            ├─────────────┤   │
    [BP + 4] │     CS      │   ├── Flags and CS:IP pushed by DOS when it
            ├─────────────┤   │   called the critical-error handler
    [BP + 2] │     IP      │   │
            ├─────────────┤ ──┘
        [BP] │ Previous BP │
            └─────────────┘

    Figure 15-5.  Information passed on the stack to an interrupt 24H
    (critical-error) handler.

            Bit
    5 4 3 2 1 0        Value             Meaning
    ──────────────────────────────────────────────────────────────────────────
    . . . . . 0        0                 Read error
    . . . . . 1        1                 Write error
    . . . 0 0 .        0                 Error involved DOS system files
    . . . 0 1 .        1                 Error involved file allocation table
    . . . 1 0 .        2                 Error involved root directory
    . . . 1 1 .        3                 Error involved files area of disk
    . . 1 . . .        1                 Fail response allowed
    . 1 . . . .        1                 Retry response allowed
    1 . . . . .        1                 Ignore response allowed
    ──────────────────────────────────────────────────────────────────────────

    Figure 15-6.  The bit values and associated errors indicated in bits 0
    through 5 of the AH register when DOS invokes interrupt 24H.

    DOS returns additional information about the error in the low-order byte
    of register DI (Figure 15-7). The error codes in DI cover a variety of
    input/output devices, so you must rely on a combination of the information
    in AH and in DI to determine the exact nature of the critical error.

    If bit 7 of AH is set, the error is probably not a disk error, though it
    may be disk related. One disk-related error normally reported when bit 7
    of AH is set is an error in the disk's FAT. In DOS version 1, this is
    always the case. For versions 2.0 and later, the error handler should
    inspect bit 15 of the word that is offset 4 bytes into the device header
    (BP: [SI + 4]). If this bit is clear, the device is a block device (disk)
    and the error is a FAT error. If this bit is set, the device is a
    character device, in which case the low-order byte of DI defines the exact
    problem (the high-order byte should be ignored). DI error-code values
    shown in Figure 15-7 are essentially the same as those reported in AL for
    interrupts 25H and 26H (decimal 37 and 38).

    You can use the following interrupt 21H functions in your critical-error
    handler to report what's going on to the program's user:

    ■  Functions 01H through 0CH, which provide simple keyboard and display
        services

    ■  Function 30H, which returns the DOS version number

    ■  Function 59H, which returns extended error information in DOS versions
        3.0 and later

    Error Code
    Hex    Dec         Description
    ──────────────────────────────────────────────────────────────────────────
    00H     0          Write-protect error; attempt to write on protected
                        diskette
    01H     1          Unknown unit (invalid drive number)
    02H     2          Drive not ready (no diskette or drive door open)
    03H     3          Unknown command requested
    04H     4          Data error (CRC)
    05H     5          Bad request structure length
    06H     6          Seek error; move to requested cylinder failed
    07H     7          Unknown disk format
    08H     8          Sector not found
    09H     9          Printer out of paper
    0AH    10          Write fault
    0BH    11          Read fault
    0CH    12          General, nonspecific error
    0FH    15          Invalid disk change (DOS version 3.0 or later)
    ──────────────────────────────────────────────────────────────────────────

    Figure 15-7.  Errors indicated in the low-order byte of register DI when
    DOS invokes interrupt 24H.

    Don't call other DOS services within your critical-error handler, however,
    because other services may overwrite internal buffers or stacks that DOS
    will need when the error handler returns.

    Normally, an error-handler routine returns to DOS after doing whatever it
    chooses to do. DOS can then take one of four courses of action: It can
    ignore the error, try the operation again, terminate the program, or fail
    the requested operation and return to the program (DOS versions 3.1 and
    later). You tell DOS which course you want it to take by loading a value
    from Figure 15-8 into the AL register before executing an IRET to return
    to DOS.

    If you use a custom critical-error handler, it will remain in effect only
    as long as the program that installs it is running. When the program
    terminates, DOS replaces the contents of the interrupt 24H vector with the
    address of the default critical-error handler.

    AL                 Description
    ──────────────────────────────────────────────────────────────────────────
    00H                Ignore the error and press onward.
    01H                Retry the operation.
    02H                Terminate the program.
    03H                Fail the operation (DOS versions 3.1 and later).
    ──────────────────────────────────────────────────────────────────────────

    Figure 15-8.  Values that can be returned to DOS in register AL by an
    interrupt 24H (critical-error) handler.


The DOS Idle Interrupt

    DOS executes interrupt 28H (decimal 40) within interrupt 21H services that
    loop while waiting for an expected event, such as a keystroke. For
    example, if you execute the DOS keyboard-input service (interrupt 21H,
    service 01H), DOS executes interrupt 28H within an idle loop that waits
    for the next keystroke.

    The default DOS handler for interrupt 28H is merely an IRET instruction;
    that is, executing interrupt 28H normally does nothing at all. You can
    substitute your own interrupt 28H handler, however, that does something
    useful while DOS is otherwise idle. In particular, a memory-resident
    program can contain an interrupt 28H handler that is executed repeatedly
    whenever DOS is waiting for keyboard output.

    The biggest problem with installing your own interrupt 28H handler is that
    the handler can execute interrupt 21H to access DOS services only under
    very specific circumstances. Unfortunately, you must know many details
    about the way DOS internally processes interrupt 21H requests in order to
    use these safely within an interrupt 28H handler.


The Program Segment Prefix (PSP)

    When DOS loads a program, it sets aside a 256-byte block of memory for the
    program: the program segment prefix (PSP). The PSP contains a hodgepodge
    of information that DOS uses to help run the program. A PSP is associated
    with every DOS program, no matter what language the program is written in.
    However, for programming purposes, the information stored in the PSP is
    more relevant to programs written in assembly language than to programs
    written in high-level languages. This is because with high-level
    languages, the language is normally in charge of the program's working
    environment, memory usage, and file control──all the information that the
    PSP is concerned with. Therefore, you can normally make good use of the
    PSP only if your program is assembly-language based.

    Before we describe the different elements of the PSP, we need to look at
    the relationship between the PSP and the program it supports.

    DOS always builds a program's PSP in memory just below the memory area
    allocated to the program itself. When the program receives control from
    DOS, segment registers DS and ES point to the beginning of the PSP.
    Because it sometimes needs to locate PSP information, DOS keeps a copy of
    the PSP segment value internally.

    The best way to explain how the PSP and the program work together is to
    jump right into the PSP's internal structure. We will reveal the purpose
    and potential use of each element as we explain it.

The Internal Structure of the PSP

    As you will soon discover, the PSP contains a rather confusing mixture of
    items. (See Figure 15-9.) The background and history of DOS pull it in
    different directions──backward to the earlier CP/M system and forward to
    UNIX-type operating environments. As a result, the PSP contains elements
    that serve different purposes and are oriented to different programming
    methods. We'll discuss the elements in the order in which they appear.

    The field at offset 00H (2 bytes) contains bytes CDH and 20H, the
    interrupt 20H instruction. As we saw in the discussion of interrupt 20H in
    this chapter, this interrupt is only one of several standard ways for a
    program to terminate. This instruction is placed at the beginning of the
    PSP (at offset 00H) so that a program can end itself simply by jumping to
    this location when the CS points to the PSP. As you might guess, this is
    not the most sensible thing for a program to do; it's always best to go
    through the appropriate interrupt or function call. This odd method of
    terminating a program is a relic of the days when CP/M compatibility was
    important.

        Offset              Length
    Hex         Dec          (bytes)     Description
    ──────────────────────────────────────────────────────────────────────────
    00H           0            2         INT 20H instruction
    02H           2            2         Size of memory (in paragraphs)
    04H           4            1         (Reserved; normally 0)
    05H           5            5         Call to DOS function dispatcher
    0AH          10            4         Interrupt 22H (Terminate) address
    0EH          14            4         Interrupt 23H (Ctrl-C) address
    12H          18            4         Interrupt 24H (Critical Error)
                                        address
    16H          22           22         (Reserved)
    2CH          44            2         Environment segment address
    2EH          46           34         Reserved
    50H          80            3         INT 21H, RETF instructions
    53H          83            9         (Reserved)
    5CH          92           16         FCB #1
    6CH         108           20         FCB #2
    80H         128          128         Command-line parameters and default
                                        Disk Transfer Area (DTA)
    ──────────────────────────────────────────────────────────────────────────

    Figure 15-9.  The parts of the program segment prefix (PSP).

    The field at offset 02H (2 bytes) contains the segment address of the last
    paragraph of memory allocated to the program. DOS normally loads a program
    in the first free area of memory large enough to contain the program. A
    program can use this field to determine the actual size of the memory area
    allocated to it.

    In practice, there's a better way to determine the amount of memory
    allocated to a program. Interrupt 21H, function 4AH can return the size
    of any block of memory, not just the block into which a program is loaded.
    (See Chapter 17 for more on this DOS service.)

    The field at offset 05H (5 bytes) contains a long call to the DOS function
    dispatcher, the internal DOS routine that examines the function number you
    pass to DOS and executes the corresponding service routine. This field,
    too, is a remnant of the days when CP/M compatibility was important to DOS
    programmers. A program can make a near CALL to offset 05H in the PSP with
    a function number in register CL and get the same result as if it had
    loaded AH with the function number and executed interrupt 21H.

    Needless to say, this technique is not very useful in real-world DOS
    programs.

    The fields at offsets 0AH, 0EH, and 12H (4 bytes each) contain the
    segmented addresses of the default handlers for interrupt 22H (Terminate),
    23H (Ctrl-C), and 24H (Critical Error). These addresses are stored in the
    PSP for your convenience. If you substitute a customized interrupt handler
    for one of the DOS handlers, you can restore the default handler by
    copying its address from the PSP into the corresponding interrupt vector.

    In DOS versions 2.0 and later, the field at offset 2CH (2 bytes) contains
    the paragraph address of the program's environment block. The environment
    block contains a list of ASCIIZ strings (strings of ASCII characters, each
    terminated with a zero byte) that define various kinds of information. The
    end of the environment block is marked by a zero-length string (a single
    zero byte) where you would expect to find the first byte of the next
    string. Environment blocks that begin with a zero-length string contain no
    strings.

    Each environment string is of the form NAME = value, where NAME is
    capitalized and of any reasonable length and value can be almost anything.
    The environment thus consists of a list of global variables, each of which
    contains information that your program may be able to use. For example, if
    the environment block contains the PATH environment variable (that is, a
    string that starts with PATH=), any program──including DOS itself──can
    examine its environment block to determine which directories to search for
    executable files (and in what order). In this way the environment block
    provides a simple means of passing information to any program that
    examines it. (You can change the contents of the environment block with
    the DOS SET command.)

    DOS makes a copy of the environment block whenever it loads a program to
    be executed, and places the copy's paragraph address (segment) in the
    program's PSP. To obtain information from the environment block, a program
    must first obtain its segment from the PSP and then examine each of the
    zero-terminated strings. Some high-level languages contain functions that
    do this for you. For example, in C, the getenv() library function does all
    the work.

    Many sophisticated DOS programs rely on information in the environment
    block. Also, the concept of the environment is found in other powerful
    operating systems, including UNIX and OS/2. Whenever you need to pass
    user-configurable information to a program, we highly recommend the use of
    the environment block.

    The field at offset 50H contains two executable 8086 instructions: INT 21H
    and RETF (far return).

    This is another kludge that lets you invoke DOS functions somewhat
    indirectly. To use this feature, set up everything necessary to invoke a
    DOS interrupt 21H function (selecting the function in AH, and so forth).
    Then, instead of bravely performing an interrupt 21H (a 2-byte
    instruction), do a far call to offset 50H in the PSP (a 5-byte
    instruction).

    You might expect that this feature is another flash from the past, a bit
    of CP/M compatibility, but actually it was introduced with DOS version 2.0
    and will not work with previous versions of DOS. You might find that
    making a far call to offset 50H in the PSP is handy if you intend to patch
    the address of a different function dispatcher into your code, but in most
    cases, a simple INT 21H will suffice.

    The fields at offsets 5CH and 6CH support old-fashioned file processing,
    using file control blocks, or FCBs. FCBs can be used for file I/O with any
    version of DOS, but their use is discouraged with DOS versions 2.0 and
    later, where more modern file I/O is available through the use of file
    handles. See page 341 for more on file control blocks, and see page 350
    for more on file handles.

    This area of the PSP was designed to make life easier for programs that
    receive one or two filenames as parameters. The basic idea, and a good one
    we think, is to let DOS construct the necessary FCBs out of the first two
    command-line parameters (the parameters given on the command line,
    following the program name). If a program needs either or both FCBs, it
    can open and use them without having to decode the command-line parameters
    and construct the FCBs itself.

    If you use this feature of the PSP, you should be aware of three potential
    complications: First, the two FCBs overlap where they are placed. If your
    program needs only the first, fine; but if it needs the second FCB as
    well, one or both of them should be moved elsewhere before they are used.
    Second, these FCBs can involve FCB extensions, a fact overlooked in most
    DOS documentation for the PSP. Finally, if you use a DOS function that
    requires an extended FCB, you should be careful to copy the default FCBs
    to another area of memory where the FCB extensions won't overlap other
    data in the PSP.

    Keep in mind that the use of FCBs is considered obsolete, but if you want
    to use them, this information should help.

    The field at offset 80H serves two purposes: When DOS first builds the
    PSP, it fills this field with the command-line parameters typed by the
    user when the program was invoked. The length of the command line is in
    the byte at offset 80H. A string containing the command-line parameters
    follows at offset 81H.

    This string has some peculiarities: It does not contain the name of the
    program that was invoked. Instead, it begins with the character that
    immediately follows the program name, which is usually a blank.
    Separators, such as blanks or commas, are not stripped out or compressed.
    If you use the command line, you have to be prepared to scan through it,
    recognizing standard separators. Fortunately, high-level languages often
    provide functions that parse the command parameter string for you. In C,
    for example, the values argc and argv are passed to the main startup
    routine in every C program. These two values contain the number of
    command-line parameters and the address of a list of individual
    parameters. It's usually easier to rely on your high-level language to
    extract command-line parameters from the PSP than it is to do it yourself
    in assembly language.

    Starting with DOS version 2.0, the command line is modified in a
    particular way: DOS strips any redirection parameters (such as < or >) and
    reconstructs the parameter line as if these items were not there. As a
    result of these two operations on the command string, a program can
    neither find out if its standard I/O is being redirected nor find out its
    own name.

    The other purpose served by the field at offset 80H in the PSP is that of
    the default Disk Transfer Area. This default buffer area is established by
    DOS just in case you use a DOS service that calls for a DTA and haven't
    yet set up your own DTA buffer. See Chapters 16 and 17 for descriptions
    of the services that use or manipulate the DTA.


An Example

    This chapter's interface example shows how you can use an interrupt
    handler to process Ctrl-C keystrokes. The example consists of two
    assembly-language routines.

    The first routine, INT23Handler, gains control when DOS executes INT 23H
    in response to a Ctrl-C keystroke. This handler simply increments the
    value in a flag and then returns to DOS with an IRET instruction.

    Note how the flag _INT23Flag is addressed through the segment group
    DGROUP. In many languages, segments with different names are grouped
    together in one logical group so that they can all be addressed with the
    same segment register. In the case of Microsoft C, this group of segments
    is named DGROUP, and it includes the data segment (_DATA) used by the
    compiled C program.

    The second assembly-language routine, _Install() is designed to be called
    by a C program. This short routine calls a DOS interrupt 21H function that
    updates the interrupt 23H vector with the address of the interrupt
    handler. (The next few chapters contain more about this DOS function and
    about interrupt 21H services in general.)

    DGROUP          GROUP   _DATA

    _TEXT           SEGMENT byte public 'CODE'
                    ASSUME  cs:_TEXT,ds:DGROUP

    ;
    ; the interrupt 23H handler:

    INT23Handler    PROC    far
                    push    ds                      ; preserve all registers us
                    push    ax                      ; ... in this interrupt han

                    mov     ax,seg DGROUP           ; set DS to the segment whe
                    mov     ds,ax                   ; ... the flag is located
                    inc     word ptr _INT23flag     ; increment the flag

                    pop     ax                      ; restore regs and return
                    pop     ds
                    iret

    INT23Handler    ENDP

    ;
    ; the C-callable installation routine:

                    PUBLIC  _Install
    _Install        PROC    near

                    push    bp                      ; the usual C prologue
                    mov     bp,sp
                    push    ds                      ; preserve DS

                    push    cs                      ; set DS:DX to point to ...
                    pop     ds
                    mov     dx,offset INT23Handler  ; ... the interrupt handler
                    mov     ax,2523h                ; AH = DOS function number
                                                    ; AL = interrupt number
                    int     21h                     ; call DOS to update the ..
                                                    ; ... interrupt vector
                    pop     ds
                    pop     bp                      ; restore regs and return
                    ret

    _Install        ENDP

    _TEXT           ENDS
    ;
    ; the flag set by the interrupt 23H handler when Ctrl-C is pressed:

    _DATA           SEGMENT word public 'DATA'

                    PUBLIC  _INT23flag
    _INT23flag      DW      0                    ; flag (initial value = 0)
    _DATA           ENDS

    The snippet of C code that follows shows how you could use this interrupt
    23H handler in a program. This C program does nothing but wait for you to
    press Ctrl-C. When you do, the assembly-language interrupt 23H handler
    increments the flag. When the loop in the C program sees that the flag is
    nonzero, it displays a message and decrements the flag.

    extern int INT23flag;                         /* flag set when Ctrl-C is pr

    main()
    {
            int     KeyCode;


            Install();                            /* install the interrupt 23H

            do
            {
            while( INT23flag > 0 )
            {
                printf( "\nCtrl-C was pressed" );   /* ... show a message ... *
                --INT23flag;                        /* ... and decrement the fl
            }

            if( kbhit() )                         /* look for a keypress */
                KeyCode = getch();
            else
                KeyCode = 0;
            }
            while( KeyCode != 0x0D );               /* loop until Enter is pres
    }

    Although the C code is short, it suggests two important points. One is
    that you must give DOS the chance to detect a Ctrl-C keystroke each time
    you test your interrupt 23H flag. (Remember that DOS is guaranteed to
    check for Ctrl-C only when it reads or writes to a character input/output
    device.) In this program, C's kbhit() function calls DOS to check for
    keyboard activity and, at the same time, lets DOS check for Ctrl-C as
    well.

    Also, note how the interrupt handler increments the flag instead of merely
    setting it to "true" or "false." This lets the loop in the C program
    process rapid, successive interrupts without losing track of how many
    interrupts have occurred.



────────────────────────────────────────────────────────────────────────────
Chapter 16  DOS Functions: Version 1

    Interrupt 21H Functions: DOS Version 1
    Function 00H (decimal 0): Terminate
    Function 01H (decimal 1): Character Input with Echo
    Function 02H (decimal 2): Character Output
    Function 03H (decimal 3): Auxiliary Input
    Function 04H (decimal 4): Auxiliary Output
    Function 05H (decimal 5): Printer Output
    Function 06H (decimal 6): Direct Console Input/Output
    Function 07H (decimal 7): Direct Console Input Without Echo
    Function 08H (decimal 8): Console Input Without Echo
    Function 09H (decimal 9): String Output
    Function 0AH (decimal 10): Buffered Keyboard Input
    Function 0BH (decimal 11): Check Keyboard Status
    Function 0CH (decimal 12): Flush Keyboard Buffer, Read Keyboard
    Function 0DH (decimal 13): Flush Disk Buffers
    Function 0EH (decimal 14): Select Disk Drive
    Function 0FH (decimal 15): Open File
    Function 10H (decimal 16): Close File
    Function 11H (decimal 17): Find First Matching Directory Entry
    Function 12H (decimal 18): Find Next Matching Directory Entry
    Function 13H (decimal 19): Delete File
    Function 14H (decimal 20): Sequential Read
    Function 15H (decimal 21): Sequential Write
    Function 16H (decimal 22): Create File
    Function 17H (decimal 23): Rename File
    Function 19H (decimal 25): Get Current Disk
    Function 1AH (decimal 26): Set Disk Transfer Area
    Function 1BH (decimal 27): Get Default Drive Information
    Function 1CH (decimal 28): Get Specified Drive Information
    Function 21H (decimal 33): Read Random Record
    Function 22H (decimal 34): Write Random Record
    Function 23H (decimal 35): Get File Size
    Function 24H (decimal 36): Set FCB Random Record Field
    Function 25H (decimal 37): Set Interrupt Vector
    Function 26H (decimal 38): Create New Program Segment Prefix
    Function 27H (decimal 39): Read Random Records
    Function 28H (decimal 40): Write Random Records
    Function 29H (decimal 41): Parse Filename
    Function 2AH (decimal 42): Get Date
    Function 2BH (decimal 43): Set Date
    Function 2CH (decimal 44): Get Time
    Function 2DH (decimal 45): Set Time
    Function 2EH (decimal 46): Set Verify Flag

    The File Control Block
    FCB Fields
    Extended FCB Fields

    An Example

    The next three chapters describe the DOS functions accessed through
    interrupt 21H. DOS version 1 had 42 interrupt 21H functions. This variety
    of functions was strongly rooted in the 8-bit microcomputer tradition
    typified by the CP/M operating system, whose services many of the DOS
    functions resembled.

    DOS version 1 was adequate for diskette-based microcomputers with
    keyboards and video displays, but the advent of high-capacity fixed disks
    and a wider variety of diskette formats called for a new set of
    sophisticated disk file-management functions. These were supplied in DOS
    version 2, and roughly patterned after the disk file-management services
    used in the UNIX operating system. In version 3, DOS continued to evolve,
    but offered only a few new functions, primarily in support of new hardware
    such as the PC/AT, networks, and the PS/2s.

    Although some interrupt 21H functions introduced in later versions of DOS
    provide services similar to those in earlier versions, all version 1
    functions continue to be supported in later versions. When you have a
    choice between two similar functions, you should, in general, use the
    higher-numbered, more recent function. We'll point out why as we go along.


Interrupt 21H Functions: DOS Version 1

    All DOS function calls are invoked by interrupt 21H (decimal 33).
    Individual functions are selected by placing the appropriate function
    number in the AH register.

    The interrupt 21H function calls in DOS version 1 are organized into the
    logical groups shown in Figure 16-1. In an effort to make this figure as
    clear as possible, we have organized and described these function calls in
    a slightly different manner than does the DOS technical reference manual.
    Figure 16-2 lists the individual function calls.

            Function
    Hex                Dec               Group
    ──────────────────────────────────────────────────────────────────────────
    00H                0                 Nondevice function
    01H─0CH            1─12              Character device I/O
    0DH─24H            13─36             File management
    25H─26H            37─38             More nondevice functions
    27H─29H, 2EH       39─41, 46         More file management
    2AH─2DH            42─45             More nondevice functions
    ──────────────────────────────────────────────────────────────────────────

    Figure 16-1.  The logical groups of DOS version 1 function calls.

╓┌─┌──────────────┌──────────────┌───────────────────────────────────────────╖
        Function
    Hex            Dec            Description
    ──────────────────────────────────────────────────────────────────────────
    00H             0             Terminate
    01H             1             Character Input with Echo
    02H             2             Character Output
    03H             3             Auxiliary Input
    04H             4             Auxiliary Output
    05H             5             Printer Output
    06H             6             Direct Character Input/Output
    07H             7             Direct Character Input Without Echo
    08H             8             Character Input Without Echo
    09H             9             String Output
    0AH            10             Buffered Keyboard Input
    0BH            11             Check Keyboard Status
    0CH            12             Flush Keyboard Buffer, Read Keyboard
    0DH            13             Flush Disk Buffers
    0EH            14             Select Disk Drive
    0FH            15             Open File
    10H            16             Close File
    11H            17             Find First Matching Directory Entry
        Function
    Hex            Dec            Description
    ──────────────────────────────────────────────────────────────────────────
    11H            17             Find First Matching Directory Entry
    12H            18             Find Next Matching Directory Entry
    13H            19             Delete File
    14H            20             Sequential Read
    15H            21             Sequential Write
    16H            22             Create File
    17H            23             Rename File
    19H            25             Get Current Disk
    1AH            26             Set Disk Transfer Area
    1BH            27             Get Default Drive Information
    1CH            28             Get Specified Drive Information
    21H            33             Read Random Record
    22H            34             Write Random Record
    23H            35             Get File Size
    24H            36             Set FCB Random Record Field
    25H            37             Set Interrupt Vector
    26H            38             Create New Program Segment Prefix
    27H            39             Read Random Records
        Function
    Hex            Dec            Description
    ──────────────────────────────────────────────────────────────────────────
    27H            39             Read Random Records
    28H            40             Write Random Records
    29H            41             Parse Filename
    2AH            42             Get Date
    2BH            43             Set Date
    2CH            44             Get Time
    2DH            45             Set Time
    2EH            46             Set Verify Flag
    ──────────────────────────────────────────────────────────────────────────


    Figure 16-2.  DOS version 1 functions available through interrupt 21H.

    The design and organization of a few of these functions, particularly
    numbers 01H through 0CH, are screwball──to put it mildly. They are this
    way for historical reasons. Many details of DOS, and especially the
    details of DOS function calls, were designed to closely mimic the services
    provided by CP/M. This was an important and deliberate choice, made to
    make it much easier for 8-bit CP/M software to be converted to the 16-bit
    IBM PC and DOS. Although the creation of DOS provided a timely opportunity
    to break with and clean up the mistakes of the past, the real departure
    from the 8-bit tradition came with DOS version 2, as you will see in
    Chapter 17.

    The following pages describe the 42 original DOS function calls,
    universally used in all versions of DOS.

Function 00H (decimal 0): Terminate

    Function 00H (decimal 0) ends a program and passes control back to DOS. It
    is functionally identical to DOS interrupt 20H, discussed on page 299.
    Either can be used interchangeably to exit a program.

    DOS versions 2.0 and later provide an enhanced terminate service through
    function 4CH, which leaves a return code (an error code) in register AL
    when a program ends. DOS batch files can act on the return codes with the
    DOS subcommand ERRORLEVEL. Use function 4CH instead of function 00H if
    you want to use a return code to record errors that occur when a program
    ends. (See page 377.)

    Like DOS interrupt 20H, function 00H does not close files opened with
    functions 0FH or 16H. To ensure that the proper length of such files is
    recorded in the file directory, use function 10H to close them before
    calling function 00H. Also, as with interrupt 20H, you must be sure the
    PSP segment address is in the CS register before exiting.

Function 01H (decimal 1): Character Input with Echo

    Function 01H (decimal 1) waits for character input from the standard input
    device and returns it in the AL register when available. This function
    should be compared with the other keyboard function calls, particularly
    functions 06H, 07H, and 08H.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    In DOS version 1, the standard input device is always the keyboard; the
    standard output device is always the video screen. In later DOS
    versions, however, standard input and output can be redirected to other
    devices such as files. DOS processes characters from the standard input
    device without distinguishing whether the actual input source is the
    keyboard or a stream of characters redirected from a file.
    ──────────────────────────────────────────────────────────────────────────

    Here is how function 01H works: Keystrokes that result in an ASCII
    character are returned as 1 byte in AL and immediately reported by this
    function. The keystrokes that result in something other than an ASCII
    character (see page 135) generate 2 bytes, which must be obtained through
    two consecutive calls to this function.

    The usual way to use this function is to test whether it returns 00H in
    AL. If AL is not 00H, you have an ASCII character. If AL = 00H, you have a
    non-ASCII keystroke (which should be recorded), and this function should
    be repeated immediately to get the pseudo-scan code that represents the
    special key action. (See page 135 for a list of the actions, codes, and
    their meanings.) As with all the DOS keyboard input services, the scan
    code for ASCII characters is not available, even if the corresponding ROM
    BIOS keyboard services make it available. (See page 135.)

    The various DOS keyboard service functions are distinguished primarily by
    three criteria: whether they wait for input (or report no input when none
    is available); whether they echo input onto the display screen; and
    whether the standard break-key operation is active for that service.
    Function 01H performs all three operations: It waits for input, echoes
    input to the screen, and lets DOS execute interrupt 23H if Ctrl-C is
    pressed.

    Remember, function 01H always waits for the user to press a key before it
    returns to a program. If you don't want to wait, either use function
    0BH──before you call function 01H──to test whether a key was pressed, or
    use function 06H. Also, see functions 08H and 0CH for related services.

Function 02H (decimal 2): Character Output

    Function 02H (decimal 2) copies a single ASCII character from register DL
    to the standard output device. In DOS version 1, the standard output
    device is always the video screen; in later DOS versions, output can also
    be redirected to a file.

    In general, this function treats the ASCII control characters, such as
    backspace or carriage return, as commands. In the case of the backspace
    character, the display screen cursor is moved backward one column without
    erasing the previous character.

Function 03H (decimal 3): Auxiliary Input

    Function 03H (decimal 3) reads one character into AL from AUX the standard
    auxiliary device. The default auxiliary device is COM1, the first RS-232
    serial communications port. You can, however, use the DOS MODE command to
    assign other devices, such as COM2, to the auxiliary device.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    This function waits for input. It does not report status information
    about the many miseries that a serial port can suffer. If you want to
    know the status of the serial port, use the ROM BIOS communications-port
    services.
    ──────────────────────────────────────────────────────────────────────────

Function 04H (decimal 4): Auxiliary Output

    Function 04H (decimal 4) writes one character from register DL to the
    standard auxiliary device. See the remarks under function 03H.

Function 05H (decimal 5): Printer Output

    Function 05H (decimal 5) writes 1 byte from DL to the standard printer
    device, which is normally known as PRN: or LPT1: (although printer output
    can be redirected with the DOS MODE command to other devices). The default
    standard printer is always the first parallel printer, even if a serial
    port is used for printer output.

Function 06H (decimal 6): Direct Console Input/Output

    Function 06H (decimal 6) is a complex function that combines the
    operations of keyboard input and display output into one untidy package.
    As with everything else in DOS versions 2.0 and later, the I/O is not
    connected to the keyboard and display, but rather to the standard input
    and output devices (which default to the keyboard and display).

    Here is how this function works: The AL register is used for input and the
    DL register for output. If you call function 06H with DL = FFH (decimal
    255), the function performs input:

    ■  If a key was pressed, function 06H returns the corresponding ASCII code
        in AL and clears the zero flag.

    ■  If no key was pressed, function 06H sets the zero flag.

    If you call function 06H with any other value in DL, the function performs
    output: The character in DL is copied to the standard output device.

    Function 06H does not wait for keyboard input, and it does not echo input
    to the display screen. In addition, function 06H does not interpret Ctrl-C
    as a keyboard break; instead, it returns the value 03H (the ASCII value of
    Ctrl-C) in AL.

    Compare this function with functions 01H, 07H, and 08H. See function
    0CH for a variation of this service.

Function 07H (decimal 7): Direct Console Input Without Echo

    Function 07H (decimal 7) waits for character input from the standard input
    device and returns it in the AL register when available. It does not echo
    input to the display screen, and it does not recognize Ctrl-C as a
    keyboard break character.

    Function 07H works in the same way as function 01H: ASCII character key
    actions are returned as single bytes in AL and are immediately reported by
    this function. The non-ASCII function keystrokes (see page 135) generate
    2 bytes, which must be obtained through two consecutive calls to function
    07H.

    Compare this function with functions 01H, 06H, and 08H. If you want to
    use this function but don't want to wait when input is not ready, see
    function 0BH, which reports whether or not input is ready. See function
    0CH for a variation of this function.

Function 08H (decimal 8): Console Input Without Echo

    Function 08H (decimal 8) waits for input, does not echo, and breaks on a
    Ctrl-C. It is identical to function 01H, except it does not echo the input
    to the display screen (or standard output device).

    See the discussion under function 01H for a description of this function.
    Compare this function with functions 01H, 06H, and 07H. If you want to
    use this function but don't want to wait when input is not ready, see
    function 0BH, which reports whether or not input is ready. See function
    0CH for a variation of this function.

Function 09H (decimal 9): String Output

    Function 09H (decimal 9) sends a string of characters to the standard
    output device (which defaults to the display screen). The register pair
    DS:DX provides the address of the string. A $ character, ASCII 24H
    (decimal 36), marks the end of the string.

    Although this function can be far more convenient than the byte-by-byte
    display services (functions 02H and 06H), it is flawed by the use of a
    real, displayable character, $, as its string delimiter. This is not a
    recent mistake; it's another by-product of CP/M compatibility. You should
    never use this function with programs that output dollar signs.

Function 0AH (decimal 10): Buffered Keyboard Input

    Function 0AH (decimal 10) puts the power of the DOS editing keys to work
    in your programs. The function gets a complete string of input, which is
    presented to your programs whole, rather than character by character. If
    you assume that the input is actually from live keyboard action and is not
    redirected elsewhere, the full use of the DOS editing keys is available to
    the person who is typing the input string. When the Enter key is pressed
    (or a carriage return, ASCII 0DH (decimal 13), is encountered in the input
    file), the input operation is complete and the entire string is presented
    to your program.

    This function provides many advantages, particularly to those programs
    needing complete, coherent strings of keyboard input, rather than
    byte-by-byte input. The two foremost benefits are that you are spared the
    effort of writing detailed input-handling code, and your programs' users
    are given a familiar set of input editing tools: the DOS editing
    conventions.

    To use this function, you must provide DOS with an input buffer area where
    the input string will be built. The register pair DS:DX points to this
    buffer when you call the function. The first 3 bytes of this buffer have
    specific purposes:

    ■  The first byte indicates the working size of the buffer (the number of
        bytes that DOS can use for input).

    ■  The second byte is updated by DOS to indicate the actual number of
        bytes input.

    ■  The third byte is the beginning of the input string, which consists
        entirely of ASCII characters. The end of the input string is signaled
        by the carriage-return character, ASCII 0DH. Although the carriage
        return is placed in the buffer, it is not included in the character
        count that DOS returns in the second byte.

    By these rules, the longest buffer you can give DOS is 255 working bytes,
    and the longest string that DOS can return is 1 byte less than the working
    length. Because the first 2 bytes of the buffer are used for status
    information, the actual working size of the buffer is 2 bytes less than
    the buffer's overall size. This may explain some of the mysteries of the
    input conventions in both DOS and BASIC.

    If input continues beyond what DOS can place in the buffer (which is 1
    byte short of its working length), then DOS will discard any further
    input, beeping all the while, until a carriage return is encountered.

    See function 0CH for a variation of this function.

Function 0BH (decimal 11): Check Keyboard Status

    Function 0BH (decimal 11) reports whether input is ready from the keyboard
    (or standard input device). If a character is ready, AL = FFH (decimal
    255). If no input is ready, AL = 00H.

    DOS checks for Ctrl-C when you execute function 0BH, so a loop that
    contains a call to this function can be interrupted by a keyboard break.

Function 0CH (decimal 12): Flush Keyboard Buffer, Read Keyboard

    Function 0CH (decimal 12) clears the keyboard buffer in RAM and then
    invokes one of five DOS functions: function 01H, 06H, 07H, 08H, or 0AH.
    The AL register is used to select which of these functions will be
    performed after the keyboard buffer is flushed. With the keyboard buffer
    clear of extraneous characters, function 0CH forces the system to wait for
    new input before it acts on the invoked function.

    Because function 06H is supported, the follow-up service need not be
    keyboard input: It can be display output.

Function 0DH (decimal 13): Flush Disk Buffers

    Function 0DH (decimal 13) flushes (writes to disk) all internal DOS file
    buffers. However, this function does not update directory entries or close
    any open files. To ensure that the proper length of a changed file is
    recorded in the file directory, use the close-file functions 10H or 3EH.

Function 0EH (decimal 14): Select Disk Drive

    Function 0EH (decimal 14) selects a new current default drive. It also
    reports the number of drives installed. The drive is specified in DL, with
    00H indicating drive A, 01H drive B, and so on. The number of drives is
    reported in AL.

    Keep a few things in mind when using this function:

    ■  The drive IDs used by DOS are consecutively numbered.

    ■  If only one physical diskette drive exists, DOS will simulate a second
        drive, drive number 1 (drive B). Thus the first fixed-disk drive is
        always drive number 2, corresponding to drive letter C.

    ■  If you use the value in AL to determine the number of drives in your
        system, beware: In DOS versions 3.0 and later, the minimum value
        returned by this function is 05H.

Function 0FH (decimal 15): Open File

    Function 0FH (decimal 15) opens a file using a file control block (FCB).
    An FCB is a data structure used by DOS to track input and output for a
    particular file. Among other things, an FCB contains a file's name and
    disk drive number. (See page 341 in this chapter for details on the
    contents of FCBs.)

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Function 0FH is one of 15 DOS functions that use an FCB to track file
    input and output. You should avoid the DOS functions that use FCBs.
    These functions were made obsolete by the more powerful handle-based
    file functions introduced in DOS version 2.0. Furthermore, unlike
    handle-based functions, FCB-based functions are not supported in OS/2
    protected mode. Use the FCB-based functions only if compatibility with
    DOS version 1 is important.
    ──────────────────────────────────────────────────────────────────────────

    To use an FCB to open a file, you must reserve memory for the FCB and
    place the file's name and disk drive number in the proper fields in the
    data structure. Then call function 0FH with the segmented address of
    the FCB in the register pair DS:DX. DOS attempts to open the file, using
    the drive and filename you specified in the FCB. If the file is opened, AL
    = 00H; if the file cannot be opened, AL = FFH.

    If the file is opened successfully, DOS initializes several fields in the
    FCB, including the drive number field (with a value of 1 for drive A, 2
    for drive B, and so on), the date and time fields, and the logical
    record-size field (which is set to 128). You can either use this record
    size or change it, depending on your application.

Function 10H (decimal 16): Close File

    Function 10H (decimal 16) closes a file and updates the file's directory
    entry. Call this function with the segmented address of the file's FCB in
    DS:DX. DOS returns AL = 00H if the function successfully closed the file
    or AL = FFH if an error occurred.

    It is good practice to use function 10H to explicitly close all files you
    opened with function 0FH or 16H. This ensures that the file contents are
    updated from DOS internal file buffers and that the corresponding
    directory entries are current.

Function 11H (decimal 17): Find First Matching Directory Entry

    Function 11H (decimal 17) searches the current directory for a specified
    directory entry. The name you specify to function 11H can contain the
    wildcard characters ? and *. The ? character matches any single ASCII
    character (as a wild card in a poker game matches any other card) and the
    * matches any string of characters, so DOS can match a name that contains
    one or more wildcard characters with several different directory entries.
    If more than one directory entry matches, DOS reports only the first
    match. You must then use function 12H to continue the search for
    subsequent matching directory entries.

    Before you call function 11H, store the address of an FCB in DS:DX. The
    filename field of this FCB must contain the name you want DOS to search
    for. DOS reports a successful match by returning AL = 00H; if no directory
    entries match the specified name, DOS returns AL = FFH. When DOS finds a
    matching directory entry, it creates a new FCB in the current disk
    transfer area (DTA) and copies the matching name from the directory entry
    into the new FCB's filename field.

    If the FCB has an FCB extension (see page 344), then you can specify the
    attributes of the file that you wish to search for. If you specify any
    combination of the hidden, system, or directory attribute bits, the search
    matches normal files and also any files with those attributes. If you
    specify the volume-label attribute, this function searches only for a
    directory entry with that attribute. With DOS versions prior to 2.0,
    neither the directory nor the volume-label attributes can be used in the
    file search operation. The archive and read-only attributes cannot be used
    as search criteria in any DOS release.

Function 12H (decimal 18): Find Next Matching Directory Entry

    Function 12H (decimal 18) finds the next of a series of files, following
    the set-up preparation performed by function 11H. As with function 11H,
    you must call function 12H with the address of an FCB in DS:DX. For
    function 12H, the FCB should be the same as the one you used for a
    successful call to function 11H.

    DOS reports a successful match by returning AL = 00H; if no match exists,
    DOS returns AL = FFH. This lets you combine functions 11H and 12H to
    perform a complete directory search by using the following logic:

    initialize FCB
    call function 11H
    WHILE AL = 0
            use current contents of DTA
            call function 12H

Function 13H (decimal 19): Delete File

    Function 13H (decimal 19) deletes all files that match the name specified
    in the FCB pointed to by the register pair DS:DX. The filename in the FCB
    can contain wildcard characters so that multiple files can be deleted with
    a single call to function 13H. The function returns AL = 00H if the
    operation is a success and all matching file directory entries are
    deleted. AL = FFH if the operation is a failure, meaning that no directory
    entries matched.

Function 14H (decimal 20): Sequential Read

    Function 14H (decimal 20) reads records sequentially from a file. To use
    this function, open a file using function 0FH. Then initialize the
    current-record and record-size fields of the FCB. For example, to read the
    first 256-byte record from a file, set the record-size field to 100H
    (decimal 256) and the current-record field to 00H before you call function
    14H.

    After the FCB is initialized, you can call function 14H once for each
    record you want to read. Each time you call function 14H, pass the address
    of the file's FCB in DS:DX. DOS reads the next record from the file and
    stores the data in the current disk transfer area (DTA). At the same time,
    DOS tracks its current position in the file by updating the current-block
    and current-record fields in the FCB.

    AL reports the results of the read. Complete success is signaled when AL =
    00H; AL = 01H signals an end-of-file, indicating that no data was read; AL
    = 02H signals that data could have been read, but wasn't, because
    insufficient memory remained in the DTA segment; AL = 03H signals an
    end-of-file with a partial record read (the record is padded with zero
    bytes).

Function 15H (decimal 21): Sequential Write

    Function 15H (decimal 21) writes a sequential record and is the companion
    to function 14H. As with function 14H, DOS tracks its current position in
    the file by updating the FCB whose address you pass in DS:DX. DOS copies
    the data from the current DTA to the file and reports the status of the
    write operation in AL.

    If AL = 00H, the write operation was a success. If AL = 01H, the disk was
    full and the record was not written. If AL = 02H, the amount of memory
    remaining in the DTA's segment was less than the record size, so DOS
    aborted the write operation.

    It's important to note that data is logically written by this function,
    but not necessarily physically written. DOS buffers output data until it
    has a complete disk sector to write──only then does DOS actually transfer
    the data to the disk.

Function 16H (decimal 22): Create File

    Function 16H (decimal 22) opens an empty file with a specified name. If
    the file exists in the current directory, function 16H truncates it to
    zero length. If the file does not exist, function 16H creates a directory
    entry for the new file. As with the other FCB-based file functions, you
    call function 16H with DS:DX pointing to an FCB containing the name of the
    file. The function returns AL = 00H to indicate successful operation. If
    AL = FFH, the function failed, possibly because the filename you specified
    in the FCB is not valid.

    If you want to avoid inadvertently losing the contents of an existing
    file, you should determine if the file already exists by calling function
    11H before you use function 16H.

Function 17H (decimal 23): Rename File

    Function 17H (decimal 23) renames files or subdirectories in a modified
    FCB pointed to by DS:DX. For the rename operation, the FCB has a special
    format. The drive and original name are located in their usual positions,
    but the new name and extension are placed at offsets 11H through 1BH in
    the FCB.

    AL = 00H signals complete success, and AL = FFH signals that the original
    name wasn't found or the new name is already in use.

    If the new name contains wildcard characters (?), they are interpreted as
    ditto-from-old-name, and the characters in the original name that
    correspond to the positions of the wildcard characters are not changed.

Function 19H (decimal 25): Get Current Disk

    Function 19H (decimal 25) reports the current drive number in AL, using
    the standard numeric code of drive A = 00H, drive B = 01H, and so forth.

Function 1AH (decimal 26): Set Disk Transfer Area

    Function 1AH (decimal 26) establishes the disk transfer area that DOS will
    use for file I/O. The location of the DTA is specified by the register
    pair DS:DX. Normally, you should specify a DTA address before you use any
    of the interrupt 21H functions that access a DTA. If you do not, DOS uses
    the default 128-byte DTA at offset 80H in the program segment prefix.

Function 1BH (decimal 27): Get Default Drive Information

    Function 1BH (decimal 27) returns important information about the disk in
    the current drive. Function 1CH performs the identical service for any
    drive. Function 36H performs a nearly identical service. (See Chapter
    17.)

    The following information is returned through this function call:

    ■  AL contains the number of sectors per cluster.

    ■  CX contains the size, in bytes, of the disk sectors (512 bytes for all
        standard PC formats).

    ■  DX contains the total number of clusters on the disk.

    ■  DS:BX points to a byte in DOS's work area containing the DOS media
        descriptor. Prior to DOS version 2.0, the DS:BX register pair pointed
        to the complete disk FAT (which could be guaranteed to be in memory,
        complete), whose first byte would be the ID byte. In later DOS
        versions, DS:BX points only to the single ID byte.

    Beware: Function 1BH uses the DS register to return the address of the
    media descriptor byte. If your program relies on the DS register to point
    to data──and most high-level and assembly-language programs do──then you
    should be careful to preserve the contents of the DS register while you
    call function 1BH.

    The following example shows how to do this:

    push    ds              ; preserve DS
    mov     ah,1Bh
    int     21h             ; call function 1BH; DS:BX -> media descriptor
    mov     ah,[bx]         ; get a copy of the media descriptor byte
    pop     ds              ; restore DS

Function 1CH (decimal 28): Get Specified Drive Information

    Function 1CH works in the same way as function 1BH except that it reports
    on any drive, not only the current drive. Before calling this function,
    set DL to the drive ID number, where 0 = the current drive, 1 = drive A, 2
    = drive B, and so forth.

Function 21H (decimal 33): Read Random Record

    Function 21H (decimal 33) reads one record from a random location in a
    file. To use this function, open a file with an FCB. Then store the record
    number of the record you want to read in the random-record field of the
    FCB. When you call function 21H with DS:DX pointing to the FCB, DOS reads
    the specified record into the DTA.

    AL is set with the same codes as it is for a sequential read: AL = 00H
    indicates a successful read; AL = 01H indicates end-of-file, with no more
    data available; AL = 02H means that insufficient space exists in the DTA
    segment; and AL = 03H indicates an end-of-file, with a partial data record
    available.

    Contrast this function with function 27H, which can read more than one
    random record at a time, or with function 14H, which reads sequential
    records. See function 24H for more on setting the random-record field.

Function 22H (decimal 34): Write Random Record

    Function 22H (decimal 34) writes one record to a random location in a
    file. As with function 21H, you must initialize the random-record field in
    the file's FCB and then call this function with DS:DX pointing to the FCB.
    DOS then writes data from the DTA to the file at the position specified in
    the FCB.

    AL is set with the same codes used for a sequential write: AL = 00H
    indicates a successful write; AL = 01H means the disk is full; AL = 02H
    indicates insufficient space in the DTA segment.

    Contrast this function with function 28H, which can write more than one
    random record, or with function 15H, which writes sequential records. See
    function 24H for more on setting the random-record field.

Function 23H (decimal 35): Get File Size

    Function 23H (decimal 35) reports the size of a file in terms of the
    number of records in the file. DS:DX points to the FCB of the file you
    want to know about. Before calling the function, the FCB should be left
    unopened and the record-size field in the FCB filled in. If you set the
    record size to 1, the file size is reported in bytes, which is most likely
    what you want.

    If the operation is successful, AL = 00H and the file size is inserted
    into the FCB. If the file is not found, AL = FFH.

Function 24H (decimal 36): Set FCB Random Record Field

    Function 24H (decimal 36) sets the random-record field to correspond to
    the current sequential block and record fields in an FCB. This facilitates
    switching from sequential to random I/O. The DS:DX registers point to the
    FCB of an open file.

Function 25H (decimal 37): Set Interrupt Vector

    Function 25H (decimal 37) sets an interrupt vector. Before you call
    function 25H, place the segmented address of an interrupt handler in DS:DX
    and an interrupt number in AL. DOS stores the segment and offset of your
    interrupt handler in the proper interrupt vector.

    When updating an interrupt vector, you should use function 25H instead of
    simply computing the address of the vector and updating it directly. Not
    only is it simpler to call this function than to do the work yourself, but
    this function gives the operating system the chance to detect when an
    important interrupt vector is modified.

    To examine the contents of an interrupt vector, see function 35H in the
    next chapter.

Function 26H (decimal 38): Create New Program Segment Prefix

    Function 26H is used within a program to prepare for loading and executing
    another subprogram, or overlay. When you call function 26H, DX must
    contain the paragraph address of the start of the memory area where you
    want DOS to build the new PSP. DOS builds a new PSP at the location you
    specify. You can then load an executable program from a file into the
    memory above the new PSP and transfer control to it.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Function 26H is obsolete. You should use function 4BH (Chapter 17) to
    load and execute a new program from within another executing program.
    ──────────────────────────────────────────────────────────────────────────

Function 27H (decimal 39): Read Random Records

    Unlike function 21H, function 27H reads one or more records, starting at a
    random file location. DS:DX points to the FCB for the file to be read and
    the random-record number is then taken from this FCB. CX contains the
    number of records desired, which should be more than 0.

    The return codes are the same as they are for function 21H: AL = 00H means
    the read was successful; AL = 01H indicates end-of-file, with no more data
    (if the records were read, the last record is complete); AL = 02H
    indicates that the DTA segment was too small; and AL = 03H indicates the
    end-of-file, where the last record read is incomplete and padded with
    zeros.

    No matter what the result, CX is set to the number of records read,
    including any partial record, and the random-record field in the FCB is
    set to the next sequential record.

    Contrast this with function 21H, which reads only one record.

Function 28H (decimal 40): Write Random Records

    Unlike function 22H, function 28H (decimal 40) writes one or more records,
    starting at a specified random file location. DS:DX points to the FCB for
    the file to be written, and the random record number is then taken from
    this FCB. CX contains the number of records desired and in this case, CX
    can be 00H. CX = 00H signals DOS to adjust the file's length to the
    position of the specified random record. This adjustment makes it easier
    for a program to manage random files: If you have logically deleted
    records at the end of a file, this service allows you to truncate the file
    at that point by setting the file's length in CX, thereby freeing disk
    space.

    The return codes are the same as they are for function 22H: AL = 00H
    indicates a successful write; AL = 01H means that no more disk space is
    available; and AL = 02H indicates that the DTA segment was too small. No
    matter what the result, CX is always set to the number of records written.

    Contrast this function with function 22H, which writes only one random
    record.

Function 29H (decimal 41): Parse Filename

    Function 29H (decimal 41) parses a string for a filename with the form
    DRIVE:FILENAME.EXT. Call this function with DS:SI pointing to a text
    string and ES:DI pointing to the drive-identifier byte in an unopened FCB.
    Function 29H attempts to extract the drive and filename information from
    the string, and to use it to initialize the drive and name fields of the
    FCB. If the function executes successfully, it returns AL = 00H if the
    string contains no wildcard characters or AL = 01H if the string contains
    at least one * or ? wildcard character. If the drive letter specifies an
    invalid drive, the function returns AL = FFH.

    Function 29H also updates DS:SI to point to the byte after the end of the
    filename in the string. This facilitates processing a string that contains
    multiple filenames. Also, if the parsing was unsuccessful, the FCB
    contains a blank filename.

    Function 29H lets you control four different aspects of the filename
    parsing. When you call the function, the 4 low-order bits of the value in
    AL specify how function 29H parses the string:

    ■  If bit 0 is set, the function scans past separator characters (for
        example, leading blank spaces) to find the file specification. If bit 0
        is 0, the scan operation is not performed, and the file specification
        is expected to start in the first byte of the string.

    ■  If bit 1 is set, then the drive byte in the FCB will be set only if it
        is specified in the file specification being scanned. This allows the
        FCB to specify a default drive.

    ■  If bit 2 is set, the filename in the FCB is changed only if a valid
        filename is found in the string. This lets the FCB specify a default
        filename, which can be overridden by the filename in the string.

    ■  If bit 3 is set, the filename extension in the FCB is changed only if a
        valid extension is found in the file specification. This allows the FCB
        to specify a default extension.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Although this service can be handy, it is intended for use only with
    FCB-based file functions. You don't need this function if you rely on
    the handle-based file functions described in Chapter 17.
    ──────────────────────────────────────────────────────────────────────────

Function 2AH (decimal 42): Get Date

    Function 2AH (decimal 42) reports DOS's record of the current date. The
    date is reported in CX and DX. DH contains the month number (1 through
    12); DL contains the day of the month (1 through 28, 29, 30, or 31, as
    appropriate); and CX contains the year (1980 through 2099).

    This function reports the day of the week by returning a value from 0
    through 6, which signifies Sunday through Saturday, in register AL. This
    day-of-the-week feature is somewhat of an orphan. It has been present in
    DOS since version 1.1, but was not even mentioned until DOS version 2.0.
    In both the 2.0 and 2.1 manuals, it is incorrectly described as a part of
    the get-time function and not as part of the get-date function. Starting
    with DOS 3.0, the manual tells it as it is. Turn to the example on page
    346 to see how this function can be used.

Function 2BH (decimal 43): Set Date

    Function 2BH (decimal 43) sets DOS's record of the current date, using the
    same registers as function 2AH. The date is set in CX and DX. DH contains
    the month number (1 through 12); DL contains the day of the month (1
    through 28, 29, 30, or 31, as appropriate); CX contains the year (1980
    through 2099). This function returns AL = 00H if the date is successfully
    updated, or AL = FFH if you specified an invalid date.

    Starting in DOS version 3.3, this function also updates the real-time
    clock/calendar in the PC/AT and PS/2. In earlier versions, you must still
    use ROM BIOS interrupt 1AH services to change the real-time clock date.

Function 2CH (decimal 44): Get Time

    Function 2CH (decimal 44) reports the time of day. The time is calculated
    from the ROM BIOS timer-tick count. (See page 59.) DOS responds to the
    ROM BIOS's midnight-passed signal and updates the date every 24 hours.

    The timer-tick count is converted into a meaningful time and placed in
    registers CX and DX. CH contains the hour (0 through 23, on a 24-hour
    clock); CL contains the minutes (0 through 59); DH contains the seconds (0
    through 59); and DL contains hundredths of seconds (0 through 99). This
    function returns AL = 00H if the time is successfully updated, or AL = FFH
    if you specified an invalid time.

    The IBM PC timer ticks 18.2 times per second, so the time of day reported
    by DOS is only as accurate as the timer tick──roughly 5.4 hundredths of a
    second. Nevertheless, even with this relatively low accuracy, you can use
    DOS function 2CH to measure time intervals in many applications.

Function 2DH (decimal 45): Set Time

    Function 2DH (decimal 45) sets the time of day. The time is specified in
    registers CX and DX. CH contains the hour (0 through 23, on a 24-hour
    clock); CL contains the minutes (0 through 59); DH contains the seconds (0
    through 59); DL contains hundredths of seconds (0 through 99).

    Starting in DOS version 3.3, this function also updates the real-time
    clock in the PC/AT and PS/2. In earlier versions, you must still use ROM
    BIOS interrupt 1AH services to change the real-time clock time.

Function 2EH (decimal 46): Set Verify Flag

    Function 2EH (decimal 46) controls verification of disk-write operations.
    Call this function with AL = 01H to set DOS's internal verify flag and
    enable verification; call it with AL = 00H to turn off the flag and
    verification. Also, in DOS versions 1 and 2, you must zero DL before you
    call function 2EH.

    The disk-verify operation requires the disk controller to perform a
    cyclical redundancy check (CRC) each time it writes data to the disk. This
    process involves reading the data just written, which significantly
    decreases the speed of disk writes.

    With DOS versions 2.0 and later, function 54H can be used to report the
    current setting of the verify flag. (See page 379.)


The File Control Block

    As mentioned several times in this chapter, file control blocks and the
    DOS functions that use them are obsolete. We recommend that you use the
    handle-based file I/O functions introduced in DOS version 2.0 and
    described in the next chapter. Usually, the only reason to concern
    yourself with FCBs is when compatibility with DOS version 1 is an issue.

    With that in mind, let's take a look at the structure of the FCB. The
    usual FCB is a 37-byte data structure that contains a variety of
    information DOS can use to control file input/output. (See Figure 16-3.)
    A 44-byte, extended FCB is also used in some DOS functions: 7 extra bytes
    are tacked onto the beginning of the usual FCB data structure. (See Figure
    16-4.)

    The situation with the FCB extension is more than a little peculiar. The
    extension is used only when you work with the attribute field in a
    directory entry in which read-only files, hidden files, system files,
    volume labels, and subdirectories are identified. In general, you need to
    use extended FCBs only if you are performing directory searches or
    otherwise working with directory entries rather than the contents of
    files. However, all FCB-based functions recognize the extended FCB format
    if you should choose to use it.

    Offset             Field Width       Description
    ──────────────────────────────────────────────────────────────────────────
    00H                1                 Drive identifier
    01H                8                 Filename
    09H                3                 File extension
    0CH                2                 Current-block number
    0EH                2                 Record size in bytes
    10H                4                 File size in bytes
    14H                2                 Date
    16H                2                 Time
    18H                8                 (Reserved)
    20H                1☼                Current-record number
    21H                4                 Random-record number
    ──────────────────────────────────────────────────────────────────────────

    Figure 16-3.  Structure of a file control block.

    Offset             Field Width       Description
    ──────────────────────────────────────────────────────────────────────────
    00H                1                 Extended FCB flag (always FFH)
    01H                5                 (Reserved)
    06H                1                 Attribute
    07H                1                 Drive identifier
    08H                8                 Filename
    10H                3                 File extension
    13H                2                 Current-block number
    15H                2                 Record size in bytes
    17H                4                 File size in bytes
    1BH                2                 Date
    1DH                2                 Time
    1FH                8                 (Reserved)
    27H                1☼                Current-record number
    28H                4                 Random-record number
    ──────────────────────────────────────────────────────────────────────────

    Figure 16-4.  Structure of an extended file control block. The first three
    fields distinguish this data structure from a normal FCB.

    With two exceptions, all fields in an extended FCB are identical to those
    in a normal FCB. Only the offsets are different: In an extended FCB, the
    offset of a particular field is 7 bytes greater than the offset of the
    same field in a normal FCB.

    The following sections describe the fields in normal extended FCBs.

FCB Fields

    Offset 00H. The first field in a normal (nonextended) FCB is the disk
    drive identifier. Values for the drive identifier start at 1; a value of 1
    indicates drive A, 2 indicates drive B, and so on. If this field contains
    0 at the time an FCB is opened, DOS uses the current default drive and
    updates this field with the corresponding drive identifier.

    Offsets 01H and 09H. The two fields at offsets 01H and 09H contain an
    8-byte name and a 3-byte extension. These fields are left-justified and
    padded on the right with blanks. Following DOS convention, either upper-
    or lowercase letters may be used. If the filename is a device name that
    DOS recognizes, such as CON, AUX, COM1, COM2, LPT1, LPT2, PRN, or NUL, DOS
    will use that device rather than a disk file.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    This is a reasonably good place to point out that the FCB mechanism has
    no provision for working with pathnames. Whenever you use FCBs, they
    always apply to the current directory in any drive. For flexible use of
    paths and subdirectories, see the new, extended functions in Chapter
    17.
    ──────────────────────────────────────────────────────────────────────────

    Offsets 0CH and 20H. For sequential file operations, the current-block and
    current-record fields keep track of the location in the file. The use of
    these fields is rather odd. Instead of using one integrated record number,
    the record number is divided into a high and low portion, referred to as
    the block number and record number. The record number is a 7-bit value, so
    record numbers range from 0 through 127. Thus the first record in a file
    is block 0, record 0; the 128th record is block 1, record 0.

    Before you use the sequential read and write functions 14H and 15H, be
    sure to initialize the current block and record fields to the desired
    starting location in the file.

    Offset 0EH. The record-size field contains a 2-byte value that specifies
    the size, in bytes, of the logical records in the file. When DOS reads or
    writes a record, the logical size of the record is the number of bytes
    transferred between DOS's disk buffers and the DTA.

    The same file data can be worked on using a variety of record sizes. When
    a file is opened through functions 0FH or 16H, DOS sets the record size to
    128 bytes by default. If you want another size, such as 1 for single-byte
    operations, you must change the record-size field after the file is
    opened.

    Offset 10H. The file-size field at offset 10H indicates the file size in
    bytes. The value is taken from a file's directory entry and is placed in
    the FCB when DOS opens the file. For an output file, this field is changed
    by DOS as the file grows. When the file is closed, the value is copied
    from the FCB to the file's directory entry.

    By changing this field, you can gain some last-minute control over the
    size of an output file, but be careful when doing this. You can, for
    example, truncate a file you have updated by decreasing the file-size
    value in this field. Also, be careful not to use function 17H to rename an
    open file: This function requires that you specify the file's new name in
    the same part of the FCB used for the file size.

    Offsets 14H and 16H. The 2-byte fields at offset 14H (date) and offset 16H
    (time) record when a file was last updated. These fields use the same
    format as the corresponding fields in a directory entry. (See Chapter 5.)
    The initial values in these fields are copied from a file's directory
    entry when the file is opened. They are subsequently updated each time you
    write to the file. If the file was updated, DOS copies the values from the
    FCB to the directory entry when the file is closed.

    Offset 21H. The random-record field is used during random read and write
    operations, just as the current record and block numbers are used during
    sequential operations. This field is in the form of a 4-byte, 32-bit
    integer. Records are numbered from 0, which makes it easy to calculate the
    file offset to any record by multiplying the random-record number by the
    record size. You must set this field before any random file operation. DOS
    leaves it undisturbed.

Extended FCB Fields

    An extended FCB has two additional fields not found in a normal FCB:

    ■  The first field of an extended FCB is a flag byte whose contents must
        be FFH. DOS distinguishes between normal and extended FCBs by examining
        this byte. (In a normal FCB, the first field is the disk-drive
        specifier, which should never be FFH.)

    ■  Offset 06H in an extended FCB is a 1-byte field that consists of an
        attribute byte whose bits signify file, volume label, and subdirectory
        attributes. This byte's format is identical to the attribute byte in a
        directory entry. (See Chapter 5.)

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    One rare situation in which you would use FCB-based functions instead of
    handle-based functions is when you work with a disk's volume label. DOS
    versions 2.0 and later do not provide any special services for
    manipulating a volume label. You must use function 16H with an extended
    FCB to create a volume label, function 17H to rename it, and function
    13H to rename it.
    ──────────────────────────────────────────────────────────────────────────


An Example

    For our assembly-language example in this section, we've chosen something
    rather interesting. It's a routine used within the Norton Utility
    programs, so you'll be seeing some actual production code.

    The purpose of this routine is to calculate the day of the week for any
    day within DOS's working range, which is stated to be from Tuesday,
    January 1, 1980, through Thursday, December 31, 2099. Occasionally, it's
    valuable for a program to be able to report the day of the week, either
    for the current date or for any other date that may be in question. For
    example, DOS keeps track of the date and time each file was last changed.
    Because people often use this information to find out when they last
    worked with a file, it can be handy to know the day of the week as well.
    In fact, the day of the week is often more immediately meaningful than the
    actual date.

    Although several interesting and clever algorithms let you calculate the
    day of the week, the actual work of writing a day-of-the-week program is
    usually rather tedious. Beginning with version 1.10, DOS incorporated a
    day-of-the-week calculation, which spared us the chore of writing our own.
    DOS's routine is available only in a form that reports the current day of
    the week, but that is no obstacle: We can temporarily change DOS's date to
    the date we're interested in and then have DOS report the day of the week.
    That is what the following assembly-language routine does for us.

    Besides being slightly foxy, this routine is interesting because it
    illustrates how three DOS function calls operate together to produce one
    result. It also illustrates the minor intricacies involved in saving and
    restoring things on the stack. As we will see here, stack use occasionally
    has to be carefully orchestrated so that different values don't get in
    each others' way.

    This particular subroutine, named Weekday, is set up in the form needed
    for use with the Microsoft C compiler. The routine is called with three
    integer variables, which specify the month, day, and year we are
    interested in. The routine returns the day of the week in the form of an
    integer in the range of 0 through 6 (signifying Sunday through Saturday).
    This conforms to the C language convention for arrays, providing an index
    to an array of strings that give the names of the days. Therefore, we
    could use this subroutine in this way:

    DayName[ Weekday( month, day, year ) ]

    It is important to note that this routine works blindly with the date,
    checking neither for a valid date nor for the range of dates accepted by
    DOS. Here is the subroutine:

    _TEXT           SEGMENT byte public 'CODE'
                    ASSUME  cs:_TEXT

                    PUBLIC  _Weekday
    _Weekday        PROC    near

                    push    bp              ; establish stack addressing ..
                    mov     bp,sp           ; .. through BP

                    mov     ah,2Ah          ; get current date
                    int     21h

                    push    cx              ; save current date on the stack
                    push    dx

                    mov     cx,[bp+8]       ; CX = year
                    mov     dl,[bp+6]       ; DL = day
                    mov     dh,[bp+4]       ; DH = month

                    mov     ah,2Bh          ; set the date specified
                    int     21h

                    mov     ah,2Ah          ; get the date back from DOS
                    int     21h             ; (AL = day of the week)

                    pop     dx              ; restore the current date ..
                    pop     cx              ; .. in CX and DX
                    push    ax              ; save day of week on the stack

                    mov     ah,2Bh          ; set the current date
                    int     21h

                    pop     ax              ; AL = day of week
                    mov     ah,0            ; AX = day of week

                    pop     bp              ; restore BP and return
                    ret

    _Weekday        ENDP

    _TEXT           ENDS



────────────────────────────────────────────────────────────────────────────
Chapter 17  DOS Functions: Versions 2.0 and Later

    Enhancements in DOS Versions 2 and 3
    Consistent Error Codes
    ASCIIZ Strings
    File Handles
    Installable Device Drivers

    Interrupt 21H Functions: DOS Versions 2.0 and Later
    Function 2FH (decimal 47): Get DTA Address
    Function 30H (decimal 48): Get DOS Version Number
    Function 31H (decimal 49): Terminate and Stay Resident
    Function 33H (decimal 51): Get/Set Ctrl-C Flag
    Function 35H (decimal 53): Get Interrupt Vector
    Function 36H (decimal 54): Get Disk Free Space
    Function 38H (decimal 56): Get/Set Country-Dependent Information
    Function 39H (decimal 57): Create Directory
    Function 3AH (decimal 58): Remove Directory
    Function 3BH (decimal 59): Change Current Directory
    Function 3CH (decimal 60): Create File
    Function 3DH (decimal 61): Open Handle
    Function 3EH (decimal 62): Close Handle
    Function 3FH (decimal 63): Read from File or Device
    Function 40H (decimal 64): Write to File or Device
    Function 41H (decimal 65): Delete File
    Function 42H (decimal 66): Move File Pointer
    Function 43H (decimal 67): Get/Set File Attributes
    Function 44H (decimal 68): IOCTL──I/O Control for Devices
    Function 45H (decimal 69): Duplicate Handle
    Function 46H (decimal 70): Force Duplicate Handle
    Function 47H (decimal 71): Get Current Directory
    Function 48H (decimal 72): Allocate Memory Block
    Function 49H (decimal 73): Free Memory Block
    Function 4AH (decimal 74): Resize Memory Block
    Function 4BH (decimal 75): EXEC──Load and Execute a Program
    Function 4CH (decimal 76): Terminate with Return Code
    Function 4DH (decimal 77): Get Return Code
    Function 4EH (decimal 78): Find First Matching Directory Entry
    Function 4FH (decimal 79): Find Next Matching Directory Entry
    Function 54H (decimal 84): Get Verify Flag
    Function 56H (decimal 86): Rename File
    Function 57H (decimal 87): Get/Set File Date and Time
    Function 58H (decimal 88): Get/Set Memory Allocation Strategy
    Function 59H (decimal 89): Get Extended Error Information
    Function 5AH (decimal 90): Create Temporary File
    Function 5BH (decimal 91): Create New File
    Function 5CH (decimal 92): Lock/Unlock File Region
    Function 5EH (decimal 94): Network Machine Name and Printer Setup
    Function 5FH (decimal 95): Network Redirection
    Function 62H (decimal 98): Get PSP Address
    Function 65H (decimal 101): Get Extended Country Information
    Function 66H (decimal 102): Get/Set Global Code Page
    Function 67H (decimal 103): Set Handle Count
    Function 68H (decimal 104): Commit File

    In this chapter we'll discuss the interrupt 21H functions introduced in
    DOS versions 2.0 and later. These functions provide a wide range of
    operating system services within a more sophisticated and flexible
    framework than the original 42 functions we described in Chapter 16.

    Almost every DOS upgrade has increased the number of services provided to
    programmers. DOS 2.0 initiated the most dramatic changes: It added 33 new
    functions to the existing 42; it changed the way you access file
    information as a result of these new functions; and it made it possible to
    adapt DOS to work with almost any hardware device through the use of
    programs called installable device drivers. Before discussing the newer
    DOS functions in detail, we'll briefly cover how some of these
    enhancements can affect your programming practices.


Enhancements in DOS Versions 2 and 3

    The services introduced with DOS versions 2 and 3 have three important new
    features that directly affect the way you use the services:

    ■  Most of the functions return a set of consistent error codes in the AX
        register.

    ■  All functions that use string input require a special string format
        known as the ASCIIZ format──a string of ASCII characters terminated by
        a single zero byte.

    ■  The newer DOS functions use a 16-bit number called a handle, instead of
        an FCB, to identify the files and I/O devices that a program
        communicates with.

    We'll discuss each of these enhancements on the next few pages.

Consistent Error Codes

    When you call an interrupt 21H function in DOS versions 2.0 and later, the
    function returns an error status code in the AX register. These functions
    also set the carry flag to signal that an error has occurred. You should
    generally follow each call to these interrupt 21H functions with a test of
    the carry flag; if the flag is set, the value in AX describes what caused
    the error.

    In DOS versions 3.0 and later, you can also use interrupt 21H, function
    59H, to obtain extended error information from DOS. You can call function
    59H after any interrupt 21H function reports an error; you can also use it
    inside a critical-error (interrupt 24H) handler to determine the nature of
    a DOS critical error. In both situations, function 59H returns an extended
    error code and also suggests possible actions to alleviate the problem.

    For a complete list of extended error codes and how to use them, see the
    discussion of function 59H on page 381.

ASCIIZ Strings

    Many interrupt 21H functions introduced in DOS versions 2 and 3 require
    you to pass file and directory names in the form of ASCIIZ strings. An
    ASCIIZ string is simply a string of ASCII characters terminated by a
    single zero byte that marks the end of the string. For example, the ASCIIZ
    representation of the pathname C:\COMMAND.COM would consist of the
    following 15 hexadecimal bytes:

                                                                    null
                                                                    byte
                                                                    │
                        ┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬▼─┐
    Characters───────────►│C │: │\ │C │O │M │M │A │N │D │. │C │O │M │  │
                        └──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
    ASCII values (hex)───► 43 3A 5C 43 4F 4D 4D 41 4E 44 2E 43 4F 4D 00

    The ASCIIZ string format is commonly used within the UNIX operating system
    and the C programming language; it is only one of many new elements with a
    C/UNIX flavor introduced in DOS version 2.0.

File Handles

    The newer interrupt 21H functions in DOS versions 2.0 and later rely on
    the notion of handles. Handles are 16-bit numbers that DOS uses to
    identify open files. Handles can also identify other sources of input and
    output for a program, including the keyboard and the video display.
    (They're also another example of the UNIX influence: In UNIX, file handles
    are called "file descriptors" but are used in essentially the same way as
    they are in DOS.)

    The use of handles allows DOS to be more flexible in its file management
    services than it was with FCB-based file services. In particular,
    capabilities such as file redirection and support for hierarchical
    directories would have been very difficult to graft onto the fixed-format
    FCB data structure. Furthermore, the use of handles actually simplifies
    file management by making the mechanics of file input/output──parsing
    filenames, keeping track of the current file position, and so on──the
    responsibility of DOS instead of your programs.

    DOS assigns a new handle number whenever you create or open a file. Five
    standard handles, numbered 0 through 4, are automatically available to
    every program. (See Figure 17-1.) Other handles, with higher handle
    numbers, are issued by DOS as needed.

    Handle         Use                                         Default Device
    ──────────────────────────────────────────────────────────────────────────
    0              Standard input (normally keyboard input)    CON
    1              Standard output (normally screen output)    CON
    2              Standard error output (always to the        CON
                    screen)
    3              Standard auxiliary device (AUX device)      AUX
    4              Standard printer (LPT1 or PRN device)       PRN
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-1.  The five standard DOS handles.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Of the five standard DOS handles, only the first three are supported in
    OS/2 protected mode. If you are programming with upward compatibility in
    mind, you should avoid using handles 3 and 4 by default. Instead, open
    the serial port and printer devices explicitly, as you would any other
    file or input/output device.
    ──────────────────────────────────────────────────────────────────────────

    DOS limits the use of handles in regard to how many files or devices your
    program can open at one time:

    ■  DOS maintains an internal data structure that controls I/O for each
        file or other input/output device associated with a handle. The default
        size of this data structure allows for only 8 handles. Fortunately, the
        FILES command in the CONFIG.SYS file lets you increase the number of
        possible handles (99 in DOS versions prior to 3.0; 255 in versions 3.0
        and later).

    ■  DOS uses a reserved area in each program's PSP to maintain a table of
        handles associated with the program. This table has room for a maximum
        of 20 handles. Thus, even if you specify FILES = 30 in your CONFIG.SYS
        file, your programs will still be able to use only 20 handles at a
        time. (DOS 3.3 provides a way around this through interrupt 21H,
        function 67H. See page 392 for details.) Fortunately, few applications
        require more than 20 different files to be open at once, so these
        limitations are not usually important.

Installable Device Drivers

    In DOS versions 2.0 and later, you can write a routine that provides a
    consistent interface between DOS's handle-based I/O functions and almost
    any I/O device that can input or output a stream of data. Such a routine
    is called a device driver. DOS comes with several built-in device drivers
    for the keyboard, video display, printer, communications port, and disks.
    You can also install device drivers for other devices by including their
    names in DEVICE commands in the CONFIG.SYS file.

    DOS I/O device drivers allow handles to be associated not only with disk
    files but with any input/output device. When you use a handle-based DOS
    function to open a device, DOS searches its list of device drivers before
    it searches for a disk filename. Familiar names like "CON", "LPT1", and
    "NUL" are all part of the default list of device drivers. Opening a device
    for input/output thus consists only of passing a name to a DOS function
    and receiving a handle from DOS in return, regardless of whether the
    device is a disk file or is associated with some other type of hardware.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Incidentally, this explains why you can't open a file named "CON" or
    "PRN": DOS searches for device names before it searches for filenames,
    so it always finds a named device before it finds a file with the same
    name.
    ──────────────────────────────────────────────────────────────────────────

    You don't have to know much about the implementation of device drivers to
    use the handle-based DOS functions, so we will save a more detailed
    discussion of device drivers for Appendix A. Keep in mind that by placing
    the discussion of device drivers at the end of the book, we in no way mean
    to diminish their importance. All programmers concerned with the range and
    longevity of their programs should at least be familiar with the use and
    operation of DOS device drivers.


Interrupt 21H Functions: DOS Versions 2.0 and Later

    All DOS function calls described in this chapter are invoked through
    interrupt 21H (decimal 33). The individual functions are selected by
    placing the function number in the AH register. Any program that uses
    these functions should test the DOS version number first to be sure the
    functions are supported. (Function 30H provides this service.)

    The functions can be organized into the groups shown in Figure 17-2. In
    an effort to make the logical groupings of the function calls as clear as
    possible, we organized and described them in a slightly different manner
    than that in IBM's DOS technical reference manuals. You may want to
    compare this organization with IBM's, to be sure you understand. Figure
    17-3 lists the individual function calls.

        Function
    Hex            Dec            Group
    ──────────────────────────────────────────────────────────────────────────
    2FH─38H        47─56          Miscellaneous functions
    39H─3BH        57─59          Directory functions
    3CH─46H        60─70          File-management functions
    47H            71             Directory function
    48H─4BH        72─75          Memory-management functions
    4CH─5BH        76─91          Miscellaneous functions
    5CH─5FH        92─95          Network support
    62H─68H        98─104         Miscellaneous functions
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-2.  The logical groups of extended DOS function calls.

╓┌─┌──────────────┌───────────────────────────────────────────┌──────────────╖
    Function                                                  DOS
    Hex    Dec     Description                                 Version
    ──────────────────────────────────────────────────────────────────────────
    2FH    47      Get DTA Address                            2.0
    30H    48      Get DOS Version Number                     2.0
    Function                                                  DOS
    Hex    Dec     Description                                 Version
    ──────────────────────────────────────────────────────────────────────────
    30H    48      Get DOS Version Number                     2.0
    31H    49      Terminate and Stay Resident                2.0
    33H    51      Get/Set Ctrl-C Flag                        2.0
    35H    53      Get Interrupt Vector                       2.0
    36H    54      Get Disk Free Space                        2.0
    38H    56      Get/Set Country-Dependent Information      2.0
    39H    57      Create Directory                           2.0
    3AH    58      Remove Directory                           2.0
    3BH    59      Change Current Directory                   2.0
    3CH    60      Create File                                2.0
    3DH    61      Open Handle                                2.0
    3EH    62      Close Handle                               2.0
    3FH    63      Read from File or Device                   2.0
    40H    64      Write to File or Device                    2.0
    41H    65      Delete File                                2.0
    42H    66      Move File Pointer                          2.0
    43H    67      Get/Set File Attributes                    2.0
    44H    68      IOCTL──I/O Control for Devices             2.0
    Function                                                  DOS
    Hex    Dec     Description                                 Version
    ──────────────────────────────────────────────────────────────────────────
    44H    68      IOCTL──I/O Control for Devices             2.0
    45H    69      Duplicate File Handle                      2.0
    46H    70      Force Duplicate File Handle                2.0
    47H    71      Get Current Directory                      2.0
    48H    72      Allocate Memory Block                      2.0
    49H    73      Free Memory Block                          2.0
    4AH    74      Resize Memory Block                        2.0
    4BH    75      EXEC──Load and Execute a Program           2.0
    4CH    76      Terminate with Return Code                 2.0
    4DH    77      Get Return Code                            2.0
    4EH    78      Find First Matching Directory Entry        2.0
    4FH    79      Find Next Matching Directory Entry         2.0
    54H    84      Get Verify Flag                            2.0
    56H    86      Rename File                                2.0
    57H    87      Get/Set File Date and Time                 2.0
    58H    88      Get/Set Memory Allocation Strategy         3.0
    59H    89      Get Extended Error Information             3.0
    5AH    90      Create Temporary File                      3.0
    Function                                                  DOS
    Hex    Dec     Description                                 Version
    ──────────────────────────────────────────────────────────────────────────
    5AH    90      Create Temporary File                      3.0
    5BH    91      Create New File                            3.0
    5CH    92      Lock/Unlock File Region                    3.0
    5EH    94      Network Machine Name and Printer Setup     3.1
    5FH    95      Network Redirection                        3.1
    62H    98      Get PSP Address                            3.0
    65H    101     Get Extended Country Information           3.3
    66H    102     Get/Set Global Code Page                   3.3
    67H    103     Set Handle Count                           3.3
    68H    104     Commit File                                3.3
    ──────────────────────────────────────────────────────────────────────────


    Figure 17-3.  Interrupt 21H functions available in DOS versions 2.0 and
    later.

Function 2FH (decimal 47): Get DTA Address

    Function 2FH (decimal 47) returns the address of the disk transfer area
    (DTA) currently used by DOS. The address is returned in the register pair
    ES:BX. Contrast this with function 1AH, discussed on page 335.

Function 30H (decimal 48): Get DOS Version Number

    Function 30H (decimal 48) returns the DOS major and minor version numbers.
    The major version number is in AL, and the minor version number is in AH;
    BX and CX contain a serial number (0 in IBM's versions of DOS; other
    possible values in non-IBM versions). For example, if you execute function
    30H in DOS version 3.3, the function returns AL = 03H (the major version
    number), AH = 1EH (30, the minor version number), BX = 00H, and CX = 00H.
    In the OS/2 compatibility box, function 30H returns AL = 0AH; that is, the
    major version number is 10.

    In DOS version 1, function 30H was unsupported. Nevertheless, you can
    still test for DOS version 1 by executing function 30H; in DOS version 1,
    function 30H is guaranteed to return AL = 00H. Thus, a simple test of the
    value returned in AL is sufficient to distinguish between version 1 and
    later versions:

    mov ah,30h              ; AH = 30H (interrupt 21H function number)
    int 21h                 ; get DOS version number
    cmp al,2
    jl  EarlyVersion        ; jump if DOS version 1

    Any program that uses interrupt 21H functions with numbers above 2EH can
    use function 30H to determine if the appropriate DOS version is being
    used.

Function 31H (decimal 49): Terminate and Stay Resident

    Function 31H (decimal 49) terminates a program and leaves part of the
    program resident in memory. Except for the fact that function 31H lets you
    reserve memory for a memory-resident program, its function is the same as
    that of the program termination function (function 4CH). You call
    function 31H with a return code value in AL and with the number of
    paragraphs of memory to reserve for the program in DX.

    Before you use function 31H, you should generally carry out the following
    steps:

    1.  Call function 30H to verify that the DOS version is 2.0 or later.
        Function 31H isn't supported in DOS version 1.

    2.  Call function 49H to free the memory allocated to the program's
        environment block. (The word at offset 2CH in the program's PSP
        contains the paragraph address of the environment block.)

    3.  Determine the amount of memory to reserve for the resident program.
        This value must include the 16 paragraphs reserved for the program's
        PSP in addition to contiguous memory reserved for the program itself.
        This value does not include memory allocated dynamically by the
        program using function 48H.

    4.  Call function 31H to terminate the program.

    Like function 4CH, function 31H restores the interrupt vectors for
    interrupts 22H (Terminate Address), 23H (Ctrl-C Handler), and 24H
    (Critical Error Handler) to the DOS default values; therefore, you cannot
    use this function to install memory-resident handlers for these
    interrupts.

    Function 31H is much more flexible than the Terminate-and-Stay-Resident
    service supported through interrupt 27H. You should always use function
    31H in your TSR programs unless you are concerned about maintaining
    compatibility with DOS version 1.

Function 33H (decimal 51): Get/Set Ctrl-C Flag

    Function 33H (decimal 51) lets you test or update DOS's internal Ctrl-C
    flag. When you call function 33H with AL = 00H, DOS reports the current
    state of the Ctrl-C flag in DL:

    ■  If the flag is clear (DL = 00H), DOS checks for Ctrl-C keystrokes only
        when transmitting a character to or from a character device (interrupt
        21H functions 00H through 0CH).

    ■  If the flag is set (DL = 01H), DOS also checks for Ctrl-C when it
        responds to other service requests, such as file I/O operators.

    When you call function 33H with AL = 01H, DOS expects DL to contain the
    desired value for the break flag:

    ■  DL = 00H disables the break check.

    ■  DL = 01H enables the break check.

Function 35H (decimal 53): Get Interrupt Vector

    Function 35H (decimal 53) returns the interrupt vector for the interrupt
    number you specify in register AL. The vector is returned in the register
    pair ES:BX.

    Function 35H provides a complementary service to function 25H, which
    updates an interrupt vector. (See Chapter 16.)

Function 36H (decimal 54): Get Disk Free Space

    Function 36H (decimal 54) is similar to function 1CH (which gets disk
    information), but also provides information about unused disk space, which
    function 1CH does not. Before calling this function, select the drive that
    you are interested in with the DL register: DL = 00H indicates the default
    drive, DL = 01H indicates drive A, DL = 02H indicates drive B, and so on.

    If you specify an invalid drive, function 36H returns FFFFH in the AX
    register. Otherwise, AX contains the number of sectors per cluster, CX
    contains the number of bytes per sector, BX contains the number of
    available clusters, and DX contains the total number of clusters.

    From these numbers you can make many interesting calculations, as follows:

    CX * AX = bytes per cluster
    CX * AX * BX = total number of free bytes
    CX * AX * DX = total storage space in bytes
    (BX * 100) / DX = percentage of free space

    If S were the size of a file in bytes, you could calculate the number of
    occupied clusters in this way:

    (S + CX * AX - 1) \ (CX * AX)

    Similar formulas would give you the number of sectors and the amount and
    proportion of space allocated to a file but not used (the slack space).

Function 38H (decimal 56): Get/Set Country-Dependent Information

    Function 38H (decimal 56) allows DOS to adjust to different international
    currency and date format conventions. In DOS version 2, this function
    reports a very small set of country-dependent information. In DOS version
    3, function 38H reports a more detailed list of country-dependent items;
    in this version of DOS, a program can also change the country-dependent
    information with a call to function 38H.

    To get country-dependent information from DOS, call function 38H with
    DS:DX containing the address of a 32-byte buffer. (In DOS versions 3.0 and
    later, the size of the buffer must be 34 bytes.) Register AL must be set
    to 00H to get the current country information. For DOS versions 3.0 and
    later, register AL can also be set to a predefined country code. (The
    country code is the same 3-digit code used as the country's international
    telephone access code.) To specify a country code of 255 or greater, AL
    can be set to FFH (decimal 255), and the country code can be put into
    register BX.

    If the requested country code is invalid, DOS sets the carry flag (CF) and
    places an error code in AX. Otherwise, register BX contains the country
    code, and the buffer at DS:DX is filled in with the country-specific
    information shown in Figures 17-4 and 17-5.

    To set the current country code in DOS version 3, set DX equal to FFFFH
    and call function 38H with AL equal to the country code (or if the code is
    greater than 254, set AL equal to FFH and register BX equal to the country
    code).

    The country-dependent information is used by DOS utilities like DATE and
    TIME. A program can call function 38H to obtain the information DOS uses
    to configure itself for country-dependent conventions.

    The date format is an integer word whose value specifies the display
    format for the date. This word has three predefined values and three
    corresponding date formats. (See Figure 17-6.) Room is reserved so that
    others might be added in the future.

    The currency symbol is the symbol used in displaying an amount of money:
    In the United States, the currency symbol is a dollar sign ($); in the
    United Kingdom, it's the pound symbol (j); in Japan, it's the yen symbol
    (J). In DOS versions 2.0 and 2.1, the currency symbol can only be a single
    character, but in DOS version 3, a string up to four characters in length
    can be used. For example, one of the currency strings that could be used
    in DOS version 3.3 is DKR, which stands for Danish kroner.

    Offset           Size
    Hex      Dec       (bytes)  Description
    ──────────────────────────────────────────────────────────────────────────
    00H      0          2       Date format
    02H      2          2       Currency symbol string (ASCIIZ format)
    04H      4          2       Thousands separator string (ASCIIZ format)
    06H      6          2       Decimal separator string (ASCIIZ format)
    08H      8         24       (Reserved)
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-4.  The country-dependent information reported by function 38H
    in DOS version 2.

    Offset           Size
    Hex      Dec       (bytes)  Description
    ──────────────────────────────────────────────────────────────────────────
    00H       0         2       Date format
    02H       2         5       Currency symbol string (ASCIIZ format)
    07H       7         2       Thousands separator string (ASCIIZ format)
    09H       9         2       Decimal separator string (ASCIIZ format)
    0BH      11         2       Date separator string (ASCIIZ format)
    0DH      13         2       Time separator string (ASCIIZ format)
    0FH      15         1       Currency symbol location
    10H      16         1       Currency decimal places
    11H      17         1       Time format: 1 = 24-hour clock; 0 = 12-hour
    12H      18         4       Extended ASCII map call address
    16H      22         2       List separator string (ASCIIZ format)
    18H      24        10       (Reserved)
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-5.  The country-dependent information returned by function 38H
    in DOS version 3.

    Value              Use               Date
    ──────────────────────────────────────────────────────────────────────────
    00H                American          month day year
    01H                European          day month year
    02H                Japanese          year month day
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-6.  The three predefined date formats returned by function 38H.

    The thousands separator is the symbol used to punctuate the thousands mark
    in numbers. The U.S. uses a comma as a thousands separator, as in the
    number 12,345; other countries use a period or a blank.

    The decimal separator is the symbol used to punctuate decimal places. The
    U.S. uses a period as a decimal separator, as in 3.0; other countries use
    a comma.

    The date separator and time separator are the punctuation used in
    displaying the date (for example, ─ as in 7─4─1988) and in displaying the
    time (for example, : as in 12:34).

    The currency symbol location indicates where the currency symbol should be
    placed. A value of 00H places the currency symbol immediately before the
    amount (J1500); 01H places the symbol immediately after the amount (15¢);
    02H places the symbol before the amount with an intervening space (FFr
    15); 03H places the symbol after the amount with an intervening space (15
    DKR); and 04H replaces the decimal separator with the currency symbol.

    The currency decimal places value specifies how many decimal places are
    used in the currency. For example, the value would be 02H for U.S.
    currency (dollars and cents) and 00H for Italian currency (lire).

    The time format field specifies whether time appears in a 12-hour or
    24-hour format. Only the low-order bit (bit 0) is currently used; if the
    bit is set to 0, a 12-hour clock is used; if it is set to 1, a 24-hour
    clock is used.

    The extended ASCII map call address is the segmented address of a routine
    that maps ASCII characters 80H through FFH to characters in the range 00H
    through 7FH. Not all printers or plotters can display extended ASCII
    characters in the range 80H─FFH, so the routine at this address is called
    when it is necessary to map such characters into the usual range of ASCII
    characters (00H─7FH).

    The list separator indicates the symbol used to separate items in a list,
    such as the commas in the list A, B, C, and D.

Function 39H (decimal 57): Create Directory

    Function 39H (decimal 57) creates a subdirectory, just as the DOS command
    MKDIR does. To invoke this service, create an ASCIIZ string containing the
    pathname of the new directory. The register pair DS:DX contains the
    address of the ASCIIZ string. If an error occurs, function 39H sets the
    carry flag and returns an error code in AX. The possible error codes are
    03H (path not found) and 05H (access denied).

Function 3AH (decimal 58): Remove Directory

    Function 3AH (decimal 58) removes (deletes) a subdirectory exactly as the
    DOS command RMDIR does. To invoke this function, create an ASCIIZ string
    containing the pathname of the directory you want to remove. The register
    pair DS:DX points to the ASCIIZ string. If an error occurs, function 3AH
    sets the carry flag and returns an error code in AX. The possible error
    codes are 03H (path not found), 05H (access denied), and 10H (attempt to
    remove current directory).

Function 3BH (decimal 59): Change Current Directory

    Function 3BH (decimal 59) changes the current directory exactly as the DOS
    command CHDIR does. To invoke this function, create an ASCIIZ string
    containing the pathname of the new directory. DS:DX contains the address
    of the ASCIIZ string. If an error occurs, function 3BH sets the carry flag
    and returns an error code in AX. The one possible error code is 03H (path
    not found).

Function 3CH (decimal 60): Create File

    Function 3CH (decimal 60) opens an empty file using a specified name. If
    the file exists, function 3CH truncates it to zero length. If the file
    does not exist, function 3CH creates a new file. This function parallels
    function 16H (discussed on page 334).

    To invoke this function, create an ASCIIZ string containing the pathname
    and filename. The register pair DS:DX contains the address of the ASCIIZ
    string. CX contains the file attribute. (See page 113 for more on file
    attributes and attribute bit settings.) When function 3CH executes
    successfully, it clears the carry flag and returns a handle in AX.
    Otherwise, this function sets the carry flag and leaves an error code in
    AX. Possible error codes are 03H (path not found), 04H (no handle
    available), and 05H (access denied). Code 05H can indicate either that
    there is no room for a new directory entry or that the existing file is
    marked read-only and can't be opened for output.

    Be aware that by using function 3CH you can accidentally truncate an
    existing file to zero length. The best way to avoid this mistake is simply
    to call function 4EH to search the directory for an existing file before
    you call function 3CH. Or, if you are using DOS 3.0 or later, you have two
    other alternatives: You can call function 5BH, which works like function
    3CH but won't open an existing file, or you can use function 5AH to
    create a temporary file with a unique filename.

Function 3DH (decimal 61): Open Handle

    Function 3DH (decimal 61) opens an existing file or device. You provide
    the pathname and filename in the form of an ASCIIZ string. As with all
    other file I/O functions, DS:DX points to this string. You also indicate
    how you want to use the file by placing a file-access code in register AL.
    The 8 bits of AL are divided into the four fields shown in Figure 17-7 on
    the following page.

        Bit
    7 6 5 4 3 2 1 0          Use
    ──────────────────────────────────────────────────────────────────────────
    I . . . . . . .          Inheritance flag (DOS version 3 only)
    . S S S . . . .          Sharing mode (DOS version 3 only)
    . . . . R . . .          (Reserved)
    . . . . . A A A          Access code
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-7.  File-access and sharing codes for function 3DH.

    The file-access code for DOS version 2 is simple: Only the access bits
    (bits 0─2) are used; all other bits are set to 0. The three access-code
    settings are defined in Figure 17-8.

    Bit
    2 1 0                    Use
    ──────────────────────────────────────────────────────────────────────────
    0 0 0                    Read (only) access
    0 0 1                    Write (only) access
    0 1 0                    Read or write access
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-8.  File-access modes for function 3DH.

    DOS version 3 uses the inheritance and sharing codes as well as the access
    code. The inheritance and sharing codes give you control over how
    different programs access the same file at the same time.

    Bit 7, the inheritance bit, indicates whether or not a child process can
    inherit the use of this file. (For more about parent and child processes,
    see the discussion of function 4BH later in this chapter.) When a child
    process inherits a handle, it inherits the file's access and sharing
    codes: If bit 7 = 0, a child process can use the same handle to access the
    file as the parent process; if bit 7 = 1, the child process must itself
    open the file to obtain a different handle.

    Bits 4 through 6, the sharing-mode bits (SSS in Figure 17-7), define what
    will happen when more than one program tries to open the same file. There
    are five sharing modes: compatibility mode (SSS = 000), deny read/write
    mode (SSS = 001), deny write mode (SSS = 010), deny read mode (SSS = 011),
    and deny none mode (SSS = 100). When a second attempt is made to open the
    file, DOS compares the file's sharing code with the access requested in
    the second open operation. DOS allows the second open operation to succeed
    only if the sharing mode and the requested access mode are compatible.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    DOS performs this file-sharing validation only if it is running on a
    network or if the SHARE utility is installed. See the DOS technical
    reference manual for more details on networking and the SHARE utility.
    ──────────────────────────────────────────────────────────────────────────

    Bit 3, marked as "Reserved" in Figure 17-7, should be set to 0.

    Like function 3CH, function 3DH clears the carry flag and returns a handle
    in AX when it successfully opens a file or device. Otherwise, this
    function sets the carry flag and leaves an error code in AX. The possible
    return codes from function 3DH are 02H (file not found), 03H (path not
    found), 04H (no handles available), 05H (access denied), and 0CH (invalid
    access code).

    If SHARE or network file sharing is in force in DOS version 3, DOS signals
    a sharing violation by executing interrupt 24H.

Function 3EH (decimal 62): Close Handle

    Function 3EH (decimal 62) closes a file or device associated with the
    handle in BX. This function flushes all file buffers and updates the
    directory if necessary. The only error code this function can return is
    06H (invalid handle).

Function 3FH (decimal 63): Read from File or Device

    Function 3FH (decimal 63) reads the file or device associated with the
    handle in BX. The CX register specifies the number of bytes to read; DS:DX
    points to the buffer where data that is read will be placed. If the read
    operation is successful, function 3FH clears the carry flag and returns
    the number of bytes read in AX. If this value is 0, the function has tried
    to read from the end of a file. If the read operation fails, this function
    sets the carry flag and leaves an error code in AX. The possible error
    codes are 05H (access denied) and 06H (invalid handle).

Function 40H (decimal 64): Write to File or Device

    Function 40H (decimal 64) writes to the file or device associated with the
    handle in BX. CX specifies the number of bytes to be written; DS:DX points
    to the address of the data bytes.

    When the write operation is complete, function 40H updates the file
    pointer to point past the data just written.

    You must examine both the carry flag and the value in AX returned by
    function 40H to determine the success of the write operation:

    ■  If the carry flag is clear and AX = CX, the operation completed
        successfully.

    ■  If the carry flag is clear but AX < CX, then the output was written to
        a disk file that had insufficient disk space to complete the write
        operation.

    ■  If the carry flag is set, AX contains an error code of 05H (access
        denied) or 06H (invalid handle).

    The fact that function 40H updates the file pointer has an interesting
    side effect: You can set the size of a file to any arbitrary value by
    executing function 40H with CX = 00H. The usual technique is to call
    function 42H to set the file pointer location and then to immediately call
    function 40H with CX = 00H to update the file size.

Function 41H (decimal 65): Delete File

    Function 41H (decimal 65) deletes the directory entry of a file. The file
    is specified by an ASCIIZ string containing the path and filename. The
    register pair DS:DX points to the string. Unlike function 13H, function
    41H does not support wildcard characters in the file specification: With
    function 41H you can delete only one file at a time.

    You cannot delete read-only files with this function. To delete a
    read-only file, first remove the read-only attribute using function 43H,
    and then use function 41H.

    Function 41H can return three error codes in AX: 02H (file not found), 03H
    (path not found), and 05H (access denied).

Function 42H (decimal 66): Move File Pointer

    Function 42H (decimal 66) changes the logical read/write position in a
    file. To invoke this service, load BX with a handle and then specify the
    new pointer location by placing a reference location in AL and an offset
    relative to the reference location in register pair CX:DX. The byte offset
    in CX:DX is a 32-bit, long integer. CX is the high-order part of the
    offset (which is 0, unless the offset amount is more than 65,535) and DX
    is the low-order part.

    You can specify the reference location in AL in three different ways: If
    AL = 00H, the offset is taken relative to the beginning of the file and
    the file pointer is moved CX:DX bytes from that point; if AL = 01H, the
    offset is taken relative to the current file pointer location; if AL =
    02H, the offset is taken from the current end of file.

    If the function executes successfully, it clears the carry flag and
    returns in the register pair DX:AX the current file pointer location
    relative to the beginning of the file. The pointer is returned as a 32-bit
    long integer, with the high-order part in DX and the low-order part in AX.
    If the function fails, it sets the carry flag and returns an error code in
    AX. Possible error codes are 01H (invalid function number, which means AL
    did not contain 00H, 01H, or 02H) and 06H (invalid handle).

    You can use function 42H in several different ways:

    ■  To place the file pointer at an arbitrary location in the file, call
        function 42H with AL = 00H and CX:DX specifying the desired offset
        relative to the start of the file.

    ■  To position the file pointer at the end of the file, call function 42H
        with AL = 02H and 00H in CX:DX.

    ■  To determine the current location of the file pointer, use AL = 01H and
        00H in CX:DX; the value returned in DX:AX is the current file pointer
        location.

    DOS does not validate the resulting location of the file pointer. In
    particular, you can end with a negative file pointer offset (that is, a
    file pointer at a position before the logical start of the file). However,
    it's not a good idea to use negative file pointers for two reasons: If you
    perform a subsequent read or write operation, you'll be in error; and your
    program will be harder to adapt for OS/2, where an attempt to move a file
    pointer to a negative offset generates an error.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    The operation of moving a logical file pointer to a specified location
    in a file is sometimes called a "seek," but the same word is also used
    in the sense of moving the read/write heads of a disk drive to a
    specified cylinder on a disk. The two operations aren't the same.
    ──────────────────────────────────────────────────────────────────────────

Function 43H (decimal 67): Get/Set File Attributes

    Function 43H (decimal 67) gets or sets the attributes of a file. (See page
    113 for details about file attributes.) DS:DX points to an ASCIIZ string
    that specifies the file in question. (Global filename characters ? and *
    cannot be used.) Calling function 43H with AL = 00H returns the file's
    attributes in CX; AL = 01H sets the attribute values you specify in CX.

    If function 43H fails, the carry flag is set and AX contains one of four
    error codes: 01H (invalid function), 02H (file not found), 03H (path not
    found), and 05H (access denied).

Function 44H (decimal 68): IOCTL──I/O Control for Devices

    Function 44H (decimal 68) performs input/output control operations, mostly
    for devices. (See Figure 17-9.) AL selects one of 16 subfunctions,
    numbered 00H through 0FH; some of these subfunctions have sub-subfunctions
    you specify with a "minor code" in CL.

    The main purpose of the IOCTL function is to provide a consistent
    interface between DOS programs and device drivers. In general, you
    shouldn't use IOCTL calls unless you know something about how device
    drivers are structured──a topic we'll cover in Appendix A. A few IOCTL
    calls, however, are useful even if you don't understand the details of
    device-driver operations. We'll point these out as we summarize the
    various IOCTL calls.

    ──────────────────────────────────────────────────────────────────────────
    NOTE:
    Not all IOCTL subfunctions are supported in earlier versions of DOS.
    Figure 17-9 indicates the DOS versions in which the various IOCTL
    subfunctions were introduced.
    ──────────────────────────────────────────────────────────────────────────

    Subfunction                                                      DOS
    Hex     Dec        Description                                   Version
    ──────────────────────────────────────────────────────────────────────────
    00H      0         Get device data.                             2.0
    01H      1         Set device data.                             2.0
    02H      2         Receive control data from character device.  2.0
    03H      3         Send control data to character device.       2.0
    04H      4         Receive control data from block device.      2.0
    05H      5         Send control data to block device.           2.0
    06H      6         Check input status.                          2.0
    07H      7         Check output status.                         2.0
    08H      8         Check if block device is removable.          3.0
    09H      9         Check if block device is remote.             3.1
    0AH     10         Check if handle is remote.                   3.1
    0BH     11         Change sharing retry count.                  3.0
    0CH     12         Generic I/O control for handles.             3.2
    0DH     13         Generic I/O control for block devices.       3.2
    0EH     14         Get logical drive map.                       3.2
    0FH     15         Set logical drive map.                       3.2
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-9.  Subfunctions available under interrupt 21H, function 44H
    (IOCTL).

    Subfunctions 00H and 01H. These subfunctions get and set device
    information formatted in DX by a complicated set of bit coding. Bit 7 is
    set to 1 for devices and to 0 for disk files. For devices, bits 0 through
    5 are specified as shown in Figure 17-10. For disk files, bits 0 through
    5 provide the disk-drive number: A value of 0 represents drive A, a value
    of 1 represents drive B, and so on. Both subfunctions should be called
    with a file or device handle in BX. Subfunction 00H can be called for both
    disk files and devices; subfunction 01H can be called only for character
    devices.

╓┌─┌──────────────────────────────────────────────────────────────┌──────────►
                        Bit
    15 14 13 12 11 10  9  8   7  6  5  4  3  2  1  0               Use
    ───────────────────────────────────────────────────────────────────────────
    .  .  .  .  .  .  .  .   .  .  .  .  .  .  .  X               1 = standard
    .  .  .  .  .  .  .  .   .  .  .  .  .  .  X  .               1 = standard
                        Bit
    15 14 13 12 11 10  9  8   7  6  5  4  3  2  1  0               Use
    ───────────────────────────────────────────────────────────────────────────
    .  .  .  .  .  .  .  .   .  .  .  .  .  .  X  .               1 = standard
    .  .  .  .  .  .  .  .   .  .  .  .  .  X  .  .               1 = null dev
    .  .  .  .  .  .  X  .   .  .  .  .  X  .  .  .               1 = clock de
    .  .  .  .  .  .  .  .   .  .  .  X  .  .  .  .               (Reserved)
    .  .  .  .  .  .  .  .   .  .  X  .  .  .  .  .               1 = data os
                                                                    control-char
                                                                    = data is "c
                                                                    control-char
    .  .  .  .  .  .  .  .   .  X  .  .  .  .  .  .               0 = end of f
                                                                    file (for in
    .  .  .  .  .  .  .  .   X  .  .  .  .  .  .  .               1 = device;
    .  .  .  .  .  .  .  R   .  .  .  .  .  .  .  .               (Reserved)
    .  .  .  .  .  .  R  .   .  .  .  .  .  .  .  .               (Reserved)
    .  .  .  .  .  R  .  .   .  .  .  .  .  .  .  .               (Reserved)
    .  .  .  .  R  .  .  .   .  .  .  .  .  .  .  .               (Reserved)
    .  .  .  R  .  .  .  .   .  .  .  .  .  .  .  .               (Reserved)
    .  .  R  .  .  .  .  .   .  .  .  .  .  .  .  .               (Reserved)
    .  X  .  .  .  .  .  .   .  .  .  .  .  .  .  .               1 = device c
                        Bit
    15 14 13 12 11 10  9  8   7  6  5  4  3  2  1  0               Use
    ───────────────────────────────────────────────────────────────────────────
    .  X  .  .  .  .  .  .   .  .  .  .  .  .  .  .               1 = device c
                                                                    strings tran
                                                                    subfunctions
    R  .  .  .  .  .  .  .   .  .  .  .  .  .  .  .               (Reserved)
    ───────────────────────────────────────────────────────────────────────────


    Figure 17-10.  The bit settings of the device data word DX for subfunction
    00H or 01H of interrupt 21H, function 44H.

    You can modify how DOS processes I/O for the CON device (the keyboard/
    video display combination) by setting "raw" input/output mode for the
    device. Do this by clearing bit 5 of the device data word in DX and
    calling subfunction 01H:

    mov     ax,4400h        ; AH = 44H (interrupt 21H function number)
                            ; AL = 0 (subfunction number)
    mov     bx,0            ; BX = 0 (handle for CON device)
    int     21h             ; get device data into DX
    or      dx,0020h        ; set bit 5 ("raw" mode)
    and     dx,00FFh        ; zero reserved bits 8─15
    mov     ax,4401h        ; set up for subfunction 1
    mov     bx,0            ; BX = CON device handle
    int     21h             ; set device data for CON

    After you execute this sequence of code, DOS no longer recognizes Ctrl-P
    and Ctrl-S characters, nor does it expand tabs on output.

    Subfunctions 02H through 05H. These subfunctions transfer control data
    between your program and a device driver. Subfunctions 02H and 03H get and
    send control data for character-oriented devices; subfunctions 04H and 05H
    get and send control data for block-oriented devices. In all four
    subfunctions you specify the subfunction number in AL, the address of a
    data buffer in DS:DX, and the number of bytes to transfer in CX. For
    subfunctions 02H and 03H, you must specify a handle in BX; for
    subfunctions 04H and 05H, you must specify a drive number in BL (00H =
    default drive, 01H = drive A, and so on).

    The control data you transfer to or from a device driver is not
    necessarily part of the device's input/output data stream: The control
    data is often used to obtain the device status or to control
    hardware-specific features such as printer font characteristics or tape
    drive rewind.

    These subfunctions can be used only if the device can process control
    strings. This capability is indicated by bit 14 in the device data word
    returned by subfunction 00H.

    Subfunctions 06H and 07H. These subfunctions return the current input or
    output status of a device or file. Call them with a handle in BX:
    Subfunction 06H returns the current input status; subfunction 07H returns
    the current output status.

    Both of these subfunctions use the carry flag to indicate a successful
    call. If the carry flag is clear, AL contains the status: AL = 00H means
    the device is not ready for input or output; AL = FFH means the device is
    ready. (For a file, input status AL = 00H means end-of-file; output status
    is always "ready" regardless of the value in AL.) If the carry flag is
    set, AX contains an error code: 01H (invalid function), 05H (access
    denied), 06H (invalid handle), or 0DH (invalid data).

    Subfunction 08H. This subfunction, supported only in DOS versions 3.0 and
    later, indicates whether a block-oriented device has removable media or
    not. (The floppy diskettes in a diskette drive are removable; the fixed
    disk in a fixed-disk drive is not.) Subfunction 08H can be extremely
    useful because it lets a program know if it has to check for a disk change
    or if it can rely on the same disk always being there. Call subfunction
    08H with a drive number in BL (00H = default drive, 01H = drive A, and so
    on). The subfunction clears the carry flag on a successful return and
    leaves AX = 00H if the storage medium is removable or AX = 01H if the
    storage medium is nonremovable. If the carry flag is set, AX contains an
    error code: 01H (invalid function) or 0FH (invalid drive).

    Subfunction 09H. In a network configuration, this subfunction determines
    whether a particular block device is local (attached to the computer
    running the program) or remote (redirected to a network server). You must
    specify a drive number in BL when you call this subfunction.

    Subfunction 09H clears the carry flag to indicate a successful call. In
    this case, bit 12 of the value in DX indicates whether the device is
    remote (bit 12 = 1) or local (bit 12 = 0). If the carry flag is set, AX
    contains an error code: 01H (invalid function) or 0FH (invalid drive).
    Subfunction 09H is available in DOS 3.1 and later.

    Subfunction 0AH (decimal 10). This subfunction is similar to subfunction
    09H but is used with a device handle instead of a drive number. Specify
    the handle in BX when you call this subfunction.

    Like subfunction 09H, subfunction 0AH clears the carry flag and returns a
    value in DX that indicates whether the device is local or remote. Bit 15
    of DX indicates whether the device is remote (bit 15 = 1) or local (bit 15
    = 0). If an error occurs, the function sets the carry flag and returns an
    error code in AX: 01H (invalid function) or 06H (invalid handle).
    Subfunction 09H is available in DOS 3.1 and later.

    Subfunction 0BH (decimal 11). This subfunction, which is supported only in
    DOS versions 3.0 and later, controls the way DOS attempts to resolve
    file-sharing conflicts. Because some programs lock files only briefly,
    file-sharing conflicts can be very transitory. DOS can try more than once
    to gain access to a shared file before reporting a conflict, in the hope
    that the lock condition goes away in the meantime.

    Subfunction 0BH can help you empirically tune a network in which you
    expect transient file-sharing conflicts to occur. Call this subfunction
    with DX containing the number of times you want DOS to retry access to a
    shared file before it gives up and reports an error. CX should specify the
    delay value between retries. DOS creates a delay by executing an empty
    loop 65,536 times; the value in CX indicates the number of times you want
    DOS to execute the empty delay loop. (The DOS defaults are three retries
    and one delay loop between retries.)

    If the subfunction executes successfully, it clears the carry flag. If the
    carry flag is set, AX contains an error code of 01H (invalid function).

    Subfunction 0CH (decimal 12). This subfunction provides miscellaneous
    control functions for character-oriented devices. Each control function is
    designated by a minor code in CL and a major code (also called a category
    code) in CH. The various major and minor codes are listed in Figure 17-11.

    Hex            Dec            Description
    ──────────────────────────────────────────────────────────────────────────
    Major Code (specified in CH)
    00H            0              Unknown
    01H            1              Serial port (COM1, COM2, COM3, COM4)
    03H            3              Console (CON)
    05H            5              Printer (LPT1, LPT2, LPT3)

    Minor Code (specified in CL)
    45H            69             Set iteration count.
    4AH            74             Select code page.
    4CH            76             Start code page preparation.
    4DH            77             End code page preparation.
    65H            101            Get iteration count.
    6AH            106            Query selected code page.
    6BH            107            Query prepare list.
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-11.  Major and minor codes for IOCTL subfunction 0CH (generic
    I/O control for handles).

    Minor codes 45H and 65H were introduced in DOS version 3.2. They apply
    only to print devices (major code 05H). They deal with the number of times
    DOS attempts to send a character to a printer before it assumes the
    printer is busy. The remaining minor codes were introduced in DOS version
    3.3. They provide detailed support for defining and loading code pages for
    output devices that can use multiple character sets or fonts.

    For details on the use of the services provided in this IOCTL subfunction,
    see the DOS technical reference manual.

    Subfunction 0DH (decimal 13). Subfunction 0DH provides six generic
    services for block-oriented devices. Each service is designated by a major
    code in CH and a minor code in CL. (See Figure 17-12.) In general, these
    services are similar to services provided by the ROM BIOS for diskettes
    and fixed disks, but these IOCTL services provide a consistent interface
    to any block-oriented device with a device driver that supports these
    IOCTL calls.

    Subfunction 0DH is available in DOS 3.2 and later. See the DOS technical
    reference manual for details on subfunction 0DH services.

    Hex            Dec            Description
    ──────────────────────────────────────────────────────────────────────────
    Major Code (specified in CH)
    08H            8              Disk drive

    Minor Code (specified in CL)
    40H            64             Set parameters for block device.
    41H            65             Write track on logical drive.
    42H            66             Format and verify track on logical drive.
    60H            96             Get parameters for block device.
    61H            97             Read track on logical drive.
    62H            98             Verify track on logical drive.
    ──────────────────────────────────────────────────────────────────────────

    Figure 17-12.  Major and minor codes for IOCTL subfunction 0DH (generic
    I/O control for block devices).

    Subfunctions 0EH and 0FH (decimal 14 and 15). These two subfunctions
    relate logical mapping of drive letter assignments to physical drives. For
    example, in systems with only one diskette drive, DOS maps drive letter B
    to physical drive A.

    Call these subfunctions with a logical drive ID in BL (01H represents
    drive A, 02H represents drive B, and so on). Subfunction 0EH returns a
    logical drive ID that is currently mapped to the drive you specified in
    BL. Subfunction 0FH also updates DOS's internal logical map so that the
    drive ID you specified becomes the new logical drive ID. Both subfunctions
    use AL to return the logical drive ID; if AL = 00H, only one logical drive
    is associated with the drive ID you specified in BL. If an error occurs,
    the carry flag is set and AX contains an error code: 01H (invalid
    function) or 0FH (invalid drive).

    For example, if you execute the following instructions on a system with
    only one diskette drive, DOS associates drive B with the diskette drive:

    mov bl,2                ; BL = logical drive number
    mov ax,440Fh            ; set logical drive map
    int 21h                 ; update the logical drive ID
                            ; (DOS returns AL = 02H)

Function 45H (decimal 69): Duplicate Handle

    Function 45H (decimal 69) duplicates an open file handle and returns a new
    handle number that refers to the same file or device. All actions
    performed with one handle will be reflected in the other handle──the new
    handle does not act independently in any way.

    Call function 45H with an open handle in BX. If the function executes
    successfully, it clears the carry flag and leaves a new handle number in
    AX. If an error occurs, the carry flag is set and AX contains an error
    code: 04H (no more handles) or 06H (invalid handle).

    You can use function 45H along with function 46H to implement
    input/output redirection. You can also use it to commit an open file to
    disk by duplicating the open file's handle and then closing the duplicate
    handle. This has the effect of flushing the file's disk buffers and
    updating the directory, without the overhead of closing the file,
    reopening it (which involves a directory search), and repositioning the
    file pointer:

    mov bx,Handle           ; BX = handle of open file
    mov ah,45h
    int 21h                 ; get duplicate handle into AX
    jc  Error
    mov bx,ax               ; BX = duplicate handle
    mov ah,3Eh
    int 21h                 ; close duplicate handle
                            ;   (original handle remains open)

Function 46H (decimal 70): Force Duplicate Handle

    Function 46H (decimal 70) has a somewhat misleading name because it really
    does not create a duplicate handle as does function 45H. Instead, function
    46H associates an existing open handle with a different device. This is
    the key to implementing input/output redirection in DOS.

    Call function 46H with an open handle in BX and a second handle in CX.
    When function 46H returns, the handle in CX is associated with the same
    device as the open handle in BX. If the handle in CX was previously
    associated with an open device, function 46H closes the device (which
    might otherwise be without a handle). If no errors occur, the function
    clears the carry flag. Otherwise, the carry flag is set, and AX contains
    an error code: 04H (no more handles) or 06H (invalid handle).

    To see how function 46H works, consider how you would redirect output from
    the standard output device (the video screen) to a file:

    mov bx,stdout           ; BX = handle of standard output device
    mov ah,45h              ; AH = function number ("Duplicate Handle")
    int 21h                 ; get duplicate handle into AX
    jc  Error               ; (trap errors)
    mov stdoutDup,ax        ; save the duplicate handle in a memory variable

    mov bx,FileHandle       ; BX = handle of open file
    mov cx,stdout           ; CX = handle to be redirected
    mov ah,46h              ; AH = function number ("Force Duplicate Handle")
    int 21h                 ; redirect stdout to the file
    jc  Error
                            ; at this point, all output to stdout
                            ;   goes into the file

    To undo this redirection, associate the standard output device with the
    saved duplicate:

    mov bx,stdoutDup        ; BX = duplicate of previous stdout
    mov cx,stdout           ; CX = handle to be redirected
    mov ah,46h              ; AH = function number ("Force Duplicate Handle")
    int 21h                 ; restore stdout to what it was
    jc  Error

    mov bx,stdoutDup        ; BX = duplicate
    mov ah,3Eh              ; AH = function number ("Close")
    int 21h                 ; discard duplicate handle

Function 47H (decimal 71): Get Current Directory

    Function 47H (decimal 71) reports the current directory in the form of an
    ASCIIZ string. Call function 47H with a drive number in DL (00H = default
    drive, 01H = drive A, and so on) and the address of a 64-byte buffer in
    DS:SI. The function normally clears the carry flag and fills the buffer
    with an ASCIIZ string indicating the path from the root to the current
    directory. If you specify an invalid drive number, the function sets the
    carry flag and returns an error code of 0FH in AX.

    Because the path returned by this function starts at the root directory,
    the string at DS:SI includes neither the drive letter (as in A:) nor the
    start-from-the-root backslash (as in A:\). By these rules, if the current
    directory is the root directory, then this function returns a null string.
    If you want an intelligible display of the current directory, you can
    prefix the information returned by this function with the drive-and-root
    indicators (as in A:\).

Function 48H (decimal 72): Allocate Memory Block

    Function 48H (decimal 72) dynamically allocates memory. You request the
    number of paragraphs (16-byte units) you want allocated in BX. On return,
    AX contains the segment of the allocated memory block.

    If an error occurs, the carry flag is set and AX contains an error code:
    07H (memory control blocks destroyed) or 08H (insufficient memory). If
    there is insufficient memory to satisfy your request, BX contains the
    size, in paragraphs, of the largest available block of memory.

    Memory blocks allocated to a program using function 48H are freed by DOS
    when the program terminates with function 00H or 4CH, but they remain
    allocated to a memory-resident program that terminates with the
    Terminate-and-Stay-Resident function, 31H.

Function 49H (decimal 73): Free Memory Block

    Function 49H (decimal 73) frees a block of memory for subsequent reuse by
    DOS or by other programs. Call function 49H with ES containing the
    paragraph address (segment) of the start of the memory block. If the
    memory is successfully freed, the function clears the carry flag.
    Otherwise, the carry flag is set, and AX contains an error code: 07H
    (memory control blocks destroyed) or 09H (invalid memory-block address).

    Although function 49H is usually used to free memory previously allocated
    through function 48H, it will free any memory block. For example, a
    Terminate-and-Stay-Resident program can free its environment block by
    calling function 49H with ES containing the paragraph address of the
    environment block. (See the discussion of function 31H in this chapter.)

Function 4AH (decimal 74): Resize Memory Block

    Function 4AH (decimal 74) is used to increase or decrease the size of a
    block of memory that was allocated by function 48H. Register ES contains
    the segment address of the block that will be changed. Register BX
    contains the desired size of the block in paragraphs (units of 16 bytes).

    The function clears the carry flag if the memory block can be resized as
    requested. If an error occurs, the carry flag is set, and AX contains an
    error code: 07H (memory control blocks destroyed), 08H (insufficient
    memory), or 09H (invalid memory-block address). If DOS reported that there
    was insufficient memory to increase the size of a memory block, BX
    contains the maximum size, in paragraphs, of the memory block.

Function 4BH (decimal 75): EXEC──Load and Execute a Program

    Function 4BH (decimal 75) lets a parent program load a "child" program
    into memory and execute it. This function can also be used to load
    executable code or data into memory without executing it. In both cases,
    you call function 4BH with DS:DX pointing to an ASCIIZ string with the
    path and filename of the file to be loaded. The register pair ES:BX points
    to a parameter block that contains control information for the load
    operation. AL specifies whether the child program is to be executed after
    it is loaded.

    I