BASIC-DOS

Architecture

Components

BASIC-DOS consists of a boot sector and three files, which must be in the root directory of the startup diskette:

The startup diskette may also contain CONFIG.SYS (see Configuring BASIC-DOS) and HELP.TXT (used by the HELP command).

Unlike PC DOS, there is no separate BIOS-level file (IO.SYS or IBMBIO.COM); BASIC-DOS relies on the ROM BIOS for low-level services, and its device drivers fill the role of IBMBIO.COM. The initialization code at the end of BASDEV.COM and BASDOS.COM is discarded once it’s done, and its memory is reused.

Boot Process

The boot sector runs in three parts:

1. Part 1 copies the BIOS diskette parameter table (DPT) to low memory (522h) so its values can be tuned, and moves the boot sector to low memory (550h). If a hard disk is present, it displays “Press a key to start…” and waits; Esc boots from the hard disk instead. The key pressed is saved in BOOT_KEY (52Dh). It then finds BASDEV.COM, BASDOS.COM, and CONFIG.SYS in the root directory.
2. Part 2 loads BASDEV.COM at BIOS_END (960h), hops over its driver headers to find the devinit code that follows them, and calls it. Devinit reads CONFIG.SYS (to honor any SKIP= line), chains the driver headers together, and sends each driver a DDC_INIT request; each driver reports how much memory it needs, so the drivers end up packed together, and skipped drivers take no memory.
3. Part 3 loads BASDOS.COM above the drivers and jumps to sysinit, passing it the CONFIG.SYS data.

Sysinit then:

• Processes SWITCHAR= and MEMSIZE=, and records the boot key (or BOOTKEY=)
• Allocates the Session Control Block table (SESSIONS=) and the System File Block table (FILES=), along with the BPBs and disk buffers
• Opens a CON context for each CONSOLE= line (or a single default context), and opens AUX and PRN
• Opens the DEBUG= device, if any, and obtains the FPU$ function table (FPUTBL), if the FPU$ driver is present
• Revectors the DDINT_ENTER, DDINT_LEAVE, and DDINT_UTIL entry points (530h-53Fh) used by driver interrupt handlers
• Prints the startup banner, and for each SHELL= line (or the default, COMMAND.COM), loads the program into the next session with DOS_UTL_LOAD and starts it with DOS_UTL_START

Successive loads of the same program (eg, COMMAND.COM in several sessions) are served from a cached copy of the file, so the disk is read only once.

Memory Layout

The memory arena is a chain of Memory Control Blocks (see MCB), as in PC DOS. DOS_MEM_ALLOC normally allocates from the bottom of the first free block that’s big enough, but with MCBTYPE_HIGH (80h) set in AL, it allocates from the top of the last one. COMMAND.COM allocates its code, text, variable, and string blocks from the top, so that the memory it frees before running a program stays contiguous.

Unlike PC DOS, BASIC-DOS doesn’t give a program all available memory: a COM program gets its file size plus a heap (at least MINHEAP, or 1K, or more if the program requests it; see COMDATA), and an EXE program gets its image size plus the minimum its header requests (EXE_PARASMIN), rather than the maximum (EXE_PARASMAX). This leaves memory available for other sessions.

Sessions

Each session is described by a Session Control Block (see SCB), which records the session’s console context, standard file handles, current PSP, stack, DTA, CTRL-C and exit handlers, and wait state.

Sessions are scheduled preemptively: hardware interrupt handlers (eg, the CLOCK$ driver’s timer handler) exit through DDINT_LEAVE, which can switch to another runnable session. A session that’s waiting for something (eg, keyboard input or a timer) calls DOS_UTL_WAIT with a wait ID, which makes it non-runnable until a driver calls DOS_UTL_ENDWAIT with the same ID.

Code that must not be interrupted by a session switch can use DOS_UTL_LOCK and DOS_UTL_UNLOCK; a switch requested while the session is locked is deferred until it’s unlocked.

Each session has its own console context (if it was given one by a CONSOLE= line), and keyboard input goes to the context with focus (Shift-Tab switches the focus). Sessions without a console of their own (eg, the sessions that run the commands of a pipeline) use the handles supplied in their Session Parameter Block (see SPB).

Interrupt Vectors

Programs should use DOS_MSC_SETVEC (25h) to set vectors 22h, 23h, and 24h, which BASIC-DOS stores in the current session’s SCB, rather than writing the vector table directly.

« ContentsDOS Functions »