seppdroid/Digital-Research-Source-Code
1
0
Fork 0
mirror of https://github.com/SEPPDROID/Digital-Research-Source-Code.git synced 2025-10-27 02:14:19 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Upload

Browse Source 
Digital Research
This commit is contained in:
Sepp J Morris
2020-11-06 18:50:37 +01:00
parent 621ed8ccaf
commit 31738079c4
8481 changed files with 1888323 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

357
CPM OPERATING SYSTEMS/CPM 8000 (CPM8K)/P-CP M-Z8K SOURCES/sg/sys0.tex Normal file
View File

@@ -0,0 +1,357 @@
.op
.sp 15
.ce 100
.sh
CP/M-8000 \
.sp
.sh
Operating System
.sp
.sh
System Guide
.qs
.cs 5
.sp 10
Copyright \ \ 1983
.sp
Digital Research
P.O. Box 579
167 Central Avenue
Pacific Grove, CA 93950
(408) 649-3896
TWX 910 360 5001
.sp 4
All Rights Reserved
.ce 0
.bp
.po 17
.ll 50
.ce
COPYRIGHT
.sp
Copyright 1983 by Digital Research. All rights reserved.
No part of this publication may be reproduced, transmitted,
transcribed, stored in a retrieval system, or translated
into any language or computer language, in any form or
by any means, electronic, mechanical, magnetic, optical,
chemical, manual or otherwise, without the prior written
permission of Digital Research, Post Office Box 579, Pacific
Grove, California, 93950.
.sp 4
.mb 4
.fm 1
.ce
DISCLAIMER
.sp
Digital Research makes no representations or warranties with
respect to the contents hereof and specifically disclaims
any implied warranties of merchantability or fitness for
any particular purpose. Further, Digital Research reserves the
right to revise this publication and to make changes from
time to time in the content hereof without obligation of
Digital Research to notify any person of such revision or
changes.
.sp 4
.ce
TRADEMARKS
.sp
CP/M and CP/M-86 are registered trademarks of Digital Research. CP/M-80,
CP/M-8000, DDT, and MP/M are trademarks of Digital Research. Z80 and
Z8000 are trademarks of Zilog, Inc. VAX/VMS is
a trademark of Digital Equipment Corporation. UNIX is a trademark of
Bell Laboratories.
.sp 6
The \c
.ul
CP/M-8000 Operating System System Guide \c
.qu
was prepared using the Digital Research TEX Text Formatter and printed
in the United States of America.
.sp 2
.ce 3
********************************
* First Edition: March 1983 *
********************************
.in 0
.bp
.fi
.cs 5
.mt 5
.mb 6
.pl 66
.ll 65
.po 10
.hm 2
.fm 2
.he
.ft iii
.ce
.sh
FOREWORD
.sp 2
.fi
.pp 5
CP/M-8000 \ \ is a single-user general purpose operating system.
It is designed for use with any disk-based computer using a Zilog Z8000 or
compatible processor. CP/M-8000 is modular in design, and can be modified to
suit the needs of a particular installation.
.pp
The hardware interface for a particular hardware environment is supported by
the OEM or CP/M-8000 distributer. Digital Research supports the user
interface to CP/M-8000 as documented in the \c
.ul
CP/M-8000 Operating System User's Guide.\c
.qu
\ Digital Research does not support any additions or modifications made to
CP/M-8000 by the OEM or distributer.
.sp 2
.sh
Purpose and Audience
.pp
This manual is intended to provide the information needed by a
systems programmer in adapting CP/M-8000 to a particular hardware
environment. A substantial degree of programming expertise is
assumed on the part of the reader, and it is not expected that
typical users of CP/M-8000 will need or want to read this manual.
.sp 2
.sh
Prerequisites and Related Publications
.pp
In addition to this manual, the reader should be familiar with the
architecture of the Zilog Z8000 as described in the \c
.ul
Zilog 16-Bit Microprocessor User's Manual
.qu
(third edition), the \c
.ul
CP/M-8000 User's and Programmer's Guides,
.qu
and, of course, the details of the hardware environment where CP/M-8000 is
to be implemented.
.sp 2
.sh
How This Book is Organized
.pp
Section 1 presents an overview of CP/M-8000 and describes its major
components. Section 2 discusses the adaptation of CP/M-8000 for your specific
hardware system. Section 3 discusses bootstrap procedures and related
information. Section 4 describes each BIOS function including entry
parameters and return values. Section 5 describes the process of creating a
BIOS for a custom hardware interface. Section 6 discusses approaches to
debugging your BIOS. Section 7 provides information on using the distributed
version of CP/M-8000 if you have a ===???=== system.
.pp
Appendix A describes the contents of the CP/M-8000 distribution disks.
Appendixes B, C, and D are listings of various BIOSes. Appendix E
contains a listing of the PUTBOOT utility program.
.bp
.ft iv
.sp 50
.bp
.cs 5
.mt 5
.mb 6
.pl 66
.ll 65
.po 10
.hm 2
.fm 2
.he
.ft v
.nf
.bp
.ce
.sh
Table of Contents
.sp 3
.nf
.sh
1 System Overview
.qs
=== PAGE NUMBERS ARE TOTAL GARBAGE ===
1.1 Introduction . . . . . . . . . . . . . . . . . . . . 1
1.2 CP/M-8000 Organization . . . . . . . . . . . . . . . . 3
1.3 Memory Layout . . . . . . . . . . . . . . . . . . . . 3
1.4 Console Command Processor . . . . . . . . . . . . . . 4
1.5 Basic Disk Operating System (BDOS) . . . . . . . . . 5
1.6 Basic I/O System (BIOS) . . . . . . . . . . . . . . . 5
1.7 I/O Devices . . . . . . . . . . . . . . . . . . . . . 5
1.7.1 Character Devices . . . . . . . . . . . . . . 5
1.7.2 Character Devices . . . . . . . . . . . . . . 5
1.8 System Generation and Cold Start Operation . . . . . 6
.sp 2
.sh
2 System Generation
.qs
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Creating CPM.SYS . . . . . . . . . . . . . . . . . . 7
2.3 Relocating Utilities . . . . . . . . . . . . . . . . 8
.sp 2
.sh
3 Bootstrap Procedures
.qs
3.1 Bootstrapping Overview . . . . . . . . . . . . . . . 9
3.2 Creating the Cold Boot Loader . . . . . . . . . . . . 10
3.2.1 Writing a Loader BIOS . . . . . . . . . . . . 10
3.2.2 Building CPMLDR.SYS . . . . . . . . . . . . . 11
.sp 2
.sh
4 BIOS Functions
.qs
4.1 Introduction . . . . . . . . . . . . . . . . . . . . 13
4.2 Memory Management Functions . . . . . . . . . . . . . ??
.bp
.ft vi
.ce 2
.sh
Table of Contents
.sp
.sh
(continued)
.qs
.sp 3
.sh
5 Creating a BIOS
.qs
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Disk Definition Tables . . . . . . . . . . . . . . . 39
5.2.1 Disk Parameter Header . . . . . . . . . . . . 40
5.2.2 Sector Translate Table . . . . . . . . . . . . 41
5.2.3 Disk Parameter Block . . . . . . . . . . . . . 42
5.3 Disk Blocking Guide . . . . . . . . . . . . . . . . . 45
5.3.1 A Simple Approach . . . . . . . . . . . . . . 46
5.3.2 Some Refinements . . . . . . . . . . . . . . . 46
5.3.3 Track Buffering . . . . . . . . . . . . . . . 47
5.3.4 LRU Replacement . . . . . . . . . . . . . . . 47
5.3.5 The New Block Flag . . . . . . . . . . . . . . 48
5.4 Memory Management Guide . . . . . . . . . . . . . . . ??
.sp 2
.sh
6 Installing and Adapting the Distributed BIOS and CP/M-8000
.qs
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Booting on an ===???=== . . . . . . . . . . . . . . . 49
6.3 Bringing up CP/M-8000 Using ===???=== . . . . . . 50
.sp 2
.sh
7 Cold Boot Automatic Command Execution
.qs
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . 51
7.2 Setting up Cold Boot Automatic Command Execution . . 51
.sp 2
.sh
8 The PUTBOOT Utility
.qs
8.1 PUTBOOT Operation . . . . . . . . . . . . . . . . . . 53
8.2 Invoking PUTBOOT . . . . . . . . . . . . . . . . . . 53
.bp
.ft vii
.ce
.sh
Appendixes
.qs
.sp 3
.sh
A \c
.qs
Contents of Distribution Disks . . . . . . . . . . . . . . 55
.sp 2
.sh
B \c
.qs
Sample BIOS Written in C . . . . . . . . . 59
.sp 2
.sh
C \c
.qs
Dual-Processor Z8001 BIOS written in C . . . . . 67
.sp 2
.sh
D \c
.qs
Dual-Processor Z8002 BIOS Written in C . . . . . . . . . . . . . . . . 73
.sp 2
.sh
E \c
.qs
PUTBOOT Utility Assembly Language Source . . . . . . . . . 101
.sp 2
.sh
F \c
.qs
CP/M-8000 Error Messages . . . . . . . . . . . . . . . . . 109
.bp
.ft viii
.ce
.sh
Tables and Figures
.qs
.sp 3
.sh
Tables
.qs
.sp
1-1. CP/M-8000 Terms . . . . . . . . . . . . . . . . . . 1
.sp
4-1. BIOS Register Usage . . . . . . . . . . . . . . . 14
4-2. BIOS Functions . . . . . . . . . . . . . . . . . . 14
4-3. CP/M-8000 Logical Device Characteristics . . . . . 33
4-4. I/O Byte Field Definitions . . . . . . . . . . . . 34
.sp
5-1. Disk Parameter Header Elements . . . . . . . . . . 40
5-2. Disk Parameter Block Fields . . . . . . . . . . . 42
5-3. BSH and BLM Values . . . . . . . . . . . . . . . . 44
5-4. EXM Values . . . . . . . . . . . . . . . . . . . . 45
.sp
A-1. Distribution Disk Contents . . . . . . . . . . . . 55
.sp
F-1. CP/M-8000 Error Messages . . . . . . . . . . . . . 109
.sp 2
.sh
Figures
.qs
.sp
1-1. CP/M-8000 Interfaces . . . . . . . . . . . . . . . 3
1-2. Typical CP/M-8000 Memory Layout . . . . . . . . . . 4
.sp
4-1. Memory Region Table Format . . . . . . . . . . . . 32
4-2. I/O Byte Fields . . . . . . . . . . . . . . . . . 34
.sp
5-1. Disk Parameter Header . . . . . . . . . . . . . . 40
5-2. Sample Sector Translate Table . . . . . . . . . . 42
5-3. Disk Parameter Block . . . . . . . . . . . . . . . 42
.fi
.nx one

390
CPM OPERATING SYSTEMS/CPM 8000 (CPM8K)/P-CP M-Z8K SOURCES/sg/sys1.tex Normal file
View File

@@ -0,0 +1,390 @@
.bp
.pn 1
.cs 5
.mt 5
.mb 6
.pl 66
.ll 65
.po 10
.hm 2
.fm 2
.ft All Information Presented Here is Proprietary to Digital Research
.ce
.tc 1 System Overview
.sh
Section 1
.ce
.sp
.sh
System Overview
.sp 2
.he CP/M-8000 Operating System System Guide 1.1 Introduction
.tc 1.1 Introduction
.sh
1.1 Introduction
.qs
.pp
CP/M-8000 is a single-user, general purpose operating system for
microcomputers based on the Zilog Z8000 or equivalent microprocessor
chip. It is designed to be adaptable to almost any hardware environment, and
can be readily customized for particular hardware systems.
.ix Zilog Z8000
.pp
CP/M-8000 is equivalent to other CP/M \ \ systems with changes
dictated by the Z8000 architecture. In particular, CP/M-8000 supports the
very large segmented address space of the Z8000 family.
The CP/M-8000 file system
is upwardly compatible with CP/M-80 \ \ version 2.2 and CP/M-86 \ \ Version
1.1. The CP/M-8000 file structure allows files of up to 32 megabytes per
file. CP/M-8000 supports from one to sixteen disk drives with as many as
512 megabytes per drive.
.ix address space
.ix CP/M-8000 file structure
.pp
The entire CP/M-8000 operating system resides in memory at all times,
and is not reloaded at a warm start. CP/M-8000 can be configured to reside in
any portion of memory.
The remainder of the address space is available for applications programs,
and is called the transient program area, TPA.
The TPA is assumed to consist of one or more complete (64 Kbyte)
memory segments.
CP/M-8000 supports both segmented and non-segmented user programs, and
supports the splitting of user program and data into separate addressing
spaces.
.ix TPA
.pp
Several terms used throughout this manual are defined in Table 1-1.
.sp 2
.ce
.sh
Table 1-1. CP/M-8000 Terms
.sp
.nf
Term Meaning
.sp
.fi
.ll 60
.in 25
.ti -20
nibble 4-bit half-byte
.sp
.ti -20
byte 8-bit value
.sp
.ti -20
word 16-bit value
.sp
.ti -20
longword 32-bit value
.sp
.ti -20
address 32-bit identifier of a storage location
.sp
.ti -20
physical address address of a location in real memory
.sp
.ti -20
logical address address as issued by a program, possibly requiring
translation into a physical address.
.sp
.ti -20
offset a value defining an address in storage; a fixed
displacement from some other address
.ix nibble
.ix byte
.ix word
.ix longword
.ix address
.ix physical address
.ix logical address
.ix offset
.sp
.ti -20
.bp
.ll 60
.ce
.in 0
.sh
Table 1-1. (continued)
.sp 2
Term Meaning
.sp
.in 25
.ti -20
text segment program section containing machine instructions
.sp
.ti -20
data segment program section containing initialized data
.sp
.ti -20
block storage program section containing uninitialized data
.ti -20
segment (bss)
.sp
.ti -20
absolute describes a program which must reside at a fixed memory
address.
.sp
.ti -20
relocatable describes a program which includes relocation information
so it can be loaded into memory at any address
.ix text segment
.ix data segment
.ix block storage
.ix absolute
.ix relocatable
.ix CP/M-8000 programming model
.ix bss
.ix transient program
.ix base page
.in 0
.ll 65
.sp
.pp
The CP/M-8000 programming model is described in detail in the \c
.ul
CP/M-8000 Operating System Programmer's Guide.
.qu
\ To summarize that model briefly, CP/M-8000 supports four segments within
a program: text, data, block storage segment (bss), and stack. When a
program is loaded, CP/M-8000 allocates space for all four segments in the TPA,
and loads the text and data segments. A transient program may manage free
memory using values stored by CP/M-8000 in its base page.
.pp
If the program is to run in segmented mode,
the allocation of program segments to logical address segments must
have been done at link time. If the program is to run in non-segmented
mode, however, information in the Memory Region Table is used to
decide which physical segments to run the program in. If the program
is to run with split program and data spaces, two physical segments
are required (with the data, bss, and stack in the same physical
segment), otherwise only a single physical segment is used.
=== THIS LEAVES SOMETHING TO BE DESIRED ===
=== CLARITY, FOR EXAMPLE ===
.bp
.nf
.ll 60
USER
User Interface
(CCP)
Programming
Interface
(BDOS)
Hardware
Interface
(BIOS)
HARDWARE ENVIRONMENT
.sp
.ce
.sh
Figure 1-1. CP/M-8000 Interfaces
.qs
.ll 65
.in 0
.ce 0
.fi
.he CP/M-8000 Operating System System Guide 1.2 CP/M 8000 Organization
.cp 6
.sp 2
.tc 1.2. CP/M-8000 Organization
.sh
1.2 CP/M-8000 Organization
.pp
CP/M-8000 comprises three system modules: the Console Command Processor (CCP)
the Basic Disk Operating System (BDOS) and the Basic Input/Output System
(BIOS). These modules are linked together to form the operating system.
They are discussed individually in this section.
.ix CCP
.ix BDOS
.ix BIOS
.ix CP/M-8000 , system modules
.ix interrupt vector area
.he CP/M-8000 System Guide 1.3 Memory Layout
.sp 2
.sh
.tc 1.3 Memory Layout
1.3 Memory Layout
.pp
The CP/M-8000 operating system can reside anywhere in memory.
The location of CP/M-8000 is defined
during system generation. Typically the system occupies a
segment which is logically separated from the TPA.
.pp
The TPA for non-segmented programs consists of one or two 64 Kbyte
segments, one for program and one for data. (Some programs
expect program and data to be mixed in one segment. The segment
in which such programs are run may be the same as or different
from the segments for separated program and data.) The TPA for
segmented programs consists of up to 128 segments.
The mapping from logical addresses (which consist of a 7-bit segment
number and a 16-bit offset) into physical addresses is done by
system-specific hardware, and the BIOS contains memory management
operations to map addresses and copy blocks of memory.
=== GRAB DISCUSSION FROM ARTICLE??? ===
.nf
.sp 2
.in 10
=== NEED MEMORY FIGURE FROM ARTICLE ===
.sp
.sh
Figure 1-2. Typical CP/M-8000 Memory Layout
.in 0
.sp 2
.fi
.tc 1.4 Console Command Processor
.sh
1.4 Console Command Processor (CCP)
.qs
.he CP/M 8000 System Guide 1.4 Console Command Processor
.ix CCP
.pp
The Console Command Processor, (CCP) provides the user interface to
CP/M-8000. It uses the BDOS to read user commands and load programs,
and provides several built-in user commands. It also provides
parsing of command lines entered at the console.
.ix user interface
.ix built-in user commands
.ix parsing, command lines
.bp
.tc Basic Disk Operating System (BDOS)
.sh
1.5 Basic Disk Operating System (BDOS)
.he CP/M 8000-System Guide 1.5 Basic Disk Operating System
.pp
The Basic Disk Operating System (BDOS) provides operating system services to
applications programs and to the CCP. These include character I/O,
disk file I/O (the BDOS disk I/O operations comprise the CP/M-8000 file
system), program loading, and others.
.ix BDOS
.ix applications programs
.ix I/O character
.ix I/O, disk file
.ix BIOS
.ix interface, hardware
.sp 2
.tc Basic I/O System (BIOS)
.sh
1.6 Basic I/O System (BIOS)
.he CP/M 8000 Operating System 1.6 Basic I/O System (BIOS)
.pp
The Basic Input Output System (BIOS) is the interface between CP/M-8000 and its
hardware environment. All physical input and output is done by the
BIOS. It includes all physical device drivers, tables defining disk
characteristics, and other hardware specific functions and tables. The
CCP and BDOS do not change for different hardware environments because
all hardware dependencies have been concentrated in the BIOS. Each hardware
configuration needs its own BIOS. Section 4 describes the BIOS functions in
detail. Section 5 discusses how to write a custom BIOS. Sample BIOSes are
presented in the appendixes.
.sp 2
.tc I/O Devices
.sh
1.7 I/O Devices
.he CP/M 8000 Operating System 1.7 I/O Devices
.pp
CP/M-8000 recognizes two basic types of I/O devices:
character devices and disk drives. Character devices are serial devices that
handle one character at a time. Disk devices handle data in units of 128
bytes, called sectors, and provide a large number of sectors which can be
accessed in random, nonsequential, order. In fact, real systems might have
devices with characteristics different from these. It is the BIOS's
responsibility to resolve differences between the logical device models and
the actual physical devices.
.ix I/O devices, character
.ix I/O divices, disk drives
.ix sector
.ix divice models, logical
.sp 2
.tc 1.7.1 Character Devices
.sh
1.7.1 Character Devices
.pp
Character devices are input output devices which accept or supply
streams of ASCII characters to the computer. Typical character devices are
consoles, printers, and modems. In CP/M-8000 operations on character devices
are done one character at a time. A character input device sends ASCII
CTRL-Z (1AH) to indicate end-of-file.
.ix character devices
.ix ASCII character
.ix CTRL-Z (1AH)
.ix end-of-file
.ix sectors, 128-byte
.sp 2
.tc 1.7.2 Character Devices
.sh
1.7.2 Character Devices
.qs
.pp
Disk devices are used for file storage. They are organized into sectors and
tracks. Each sector contains 128 bytes of data. (If sector sizes other than
128 bytes are used on the actual disk, then the BIOS must do a
logical-to-physical mapping to simulate 128-byte sectors to the rest of the
system.)
All disk I/O in CP/M-8000 is done in one-sector units. A track is a group of
sectors. The number of sectors on a track is a constant depending on the
particular device. (The characteristics of a disk device are specified in
the Disk Parameter Block for that device. See Section 5.)
To locate a particular sector, the disk, track number,
and sector number must all be specified.
.ix disk devices
.ix file storage
.ix mopping, logical-to-physical
.ix track
.sp 2
.tc 1.8 System Generation and Cold Start Operation
.sh
1.8 System Generation and Cold Start Operation
.pp
Generating a CP/M-8000 system is done by linking together the CCP, BDOS, and
BIOS to create a file called CPM.SYS, which is the operating system.
Section 2 discusses how to create CPM.SYS. CPM.SYS is brought into memory
by a bootstrap loader which will typically reside on the first two tracks
of a system disk. (The term system disk as used here simply means a disk
with the file CPM.SYS and a bootstrap loader.) Creation of a bootstrap loader
is discussed in Section 3.
=== WORRY ABOUT THIS ===
.ix track
.ix CCP
.ix BDOS
.ix BIOS
.ix disk
.ix bootstrap loader
.ix system disk
.ix CPM.SYS
.ix system generation
.ix cold start
.sp 2
.ce
End of Section 1
.nx two

82
CPM OPERATING SYSTEMS/CPM 8000 (CPM8K)/P-CP M-Z8K SOURCES/sg/sys2.tex Normal file
View File

@@ -0,0 +1,82 @@
.he
.bp odd
.mt 5
.mb 6
.pl 66
.ll 65
.pn 7
.po 10
.hm 2
.fm 2
.ft All Information Presented Here is Proprietary to Digital Research
.ce 2
.sh
Section 2
.sp
.sh
System Generation
.sp 3
.tc 2.1 Overview
.sh
2.1 Overview
.pp
This section describes how to build a custom version of CP/M-8000 by combining
your BIOS with the CCP and BDOS supplied by Digital Research to obtain a
CP/M-8000 operating system suitable for your specific hardware system.
Section 5 describes how to create a BIOS.
.pp
In this section, we assume that you have access to an already configured and
executable CP/M-8000 system. If you do not, you should first read
Section 6, which discusses how you can make your first CP/M-8000 system
work. === ACTUALLY, IT MAY BE SIMPLY IMPOSSIBLE ===
.pp
A CP/M-8000 operating system is generated by using the linker, LD8K, to
link together the system modules (CCP, BDOS, and BIOS) and
bind the system to an absolute memory location.
The resulting file is the configured operating system. It is named CPM.SYS.
.ix CP/M-8000, customizing
.ix CP/M-8000, generating
.ix RELOC utility
.ix CPM.SYS, creating
.ix memory location, absolute
.sp 2
.tc 2.2 Creating CPM.SYS
.sh
2.2 Creating CPM.SYS
.he CP/M-8000 System Guide 2.2 Creating CPM.SYS
.pp
The CCP and BDOS for CP/M-8000 are distributed in a library file named
CPMLIB. You must link your BIOS with CPMLIB using the following command:
.ix CCP
.ix BDOS
.ix CPMLIB
.ix LD8K command
.sp
.in 8
A>\c
.sh
=== NEED COMMANDS ===
LO68 -R -UCPM -O CPM.REL CPMLIB BIOS.O
.in 0
.ix BIOS, compiled
.ix CPM.REL
.ix cold boot loader
.sp
where BIOS.O is the compiled or assembled BIOS. This creates CPM.SYS, which
is an absolute version of your system.
.sp 2
.tc 2.3 Relocating Utilities
.sh
2.3 Relocating Utilities
.pp
Since the utilities all run in non-segmented mode, they do not need to
be relocated: they will run in whatever segments you have assigned
for the TPA. Note that the compiler and linker require separate
code and data segments; all other utilities supplied with the system
run in a single segment.
.sp 2
.ce
End of Section 2
.nx three

239
CPM OPERATING SYSTEMS/CPM 8000 (CPM8K)/P-CP M-Z8K SOURCES/sg/sys3.tex Normal file
View File

@@ -0,0 +1,239 @@
.bp odd
.he
.cs 5
.mt 5
.mb 6
.pl 66
.ll 65
.po 10
.hm 2
.fm 2
.ft All Information Presented Here is Proprietary to Digital Research
.ce 2
.sh
Section 3
.sp
.sh
Bootstrap Procedures
.qs
.sp 3
.tc 3.1 Bootstrapping Overview
.sh
3.1 Bootstrapping Overview
.qs
.he CP/M-8000 System Guide 3.1 Bootstrapping Overview
.pp 5
Bootstrap loading is the process of bringing the CP/M-8000 operating system
into memory and passing control to it. Bootstrap loading is necessarily
hardware dependent, and it is not possible to discuss all possible variations
in this manual. However, the manual presents a model of bootstrapping that is
applicable to most systems.
=== MASSIVE RE-WRITE NEEDED. ===
=== There are three bootstrap models:
=== The one presented here,
=== The Olivetti version, with the whole system on the boot tracks,
=== And the TRS-80 version, with the loader running on a Z80.
.ix Bootstrapping loading
.pp
The model of bootstrapping which we present assumes that the CP/M-8000
operating system is to be loaded into memory from a disk in which the first
few tracks (typically the first two) are reserved for the operating system
and bootstrap routines, while the remainder of the disk contains the file
structure, consisting of a directory and disk files. (The topic of disk
organization and parameters is discussed in Section 5.) In our model,
the CP/M-8000 operating system resides in a disk file named CPM.SYS (described
in Section 2), and the system tracks contain a bootstrap loader program
(CPMLDR.SYS) which knows how to read CPM.SYS into memory and transfer
control to it.
.ix CPM.SYS
.ix bootstrap procedure
.pp
Most systems have a boot procedure similar to the following:
.sp 2
.in 8
.ti -3
1) When you press reset, or execute a boot command from a monitor ROM,
the hardware loads one or more sectors beginning at track 0, sector 1, into
memory at a predetermined address, and then jumps to that address.
.sp
.ti -3
2) The code that came from track 0, sector 1, and is now executing, is
typically a small bootstrap routine that loads the rest of the sectors on the
system tracks (containing CPMLDR) into another predetermined address in
memory, and then jumps to that address. Note that if your hardware is
smart enough, steps 1 and 2 can be combined into one step.
.sp
.ti -3
3) The code loaded in step 2, which is now executing, is the CP/M Cold Boot
Loader, CPMLDR, which is an abbreviated version of CP/M-8000 itself. CPMLDR
now finds the file CPM.SYS, loads it, and jumps to it. A copy of CPM.SYS is
now in memory, executing. This completes the bootstrapping process.
.mb 4
.fm 1
.sp
.in 0
.pp
In order to create a CP/M-8000 diskette that can be booted, you need to know
how to create CPM.SYS (see Section 2.2), how to create the Cold Boot Loader,
CPMLDR, and how to put CPMLDR onto your system tracks. You must also
understand your hardware enough to be able to design a method for bringing
CPMLDR into memory and executing it.
.ix CPMLDR
.sp 2
.tc 3.2 Creating the Cold Boot Loader
.sh
3.2 Creating the Cold Boot Loader
.he CP/M-8000 System Guide 3.2 Creating the Cold Boot Loader
.pp
CPMLDR is a miniature version of CP/M-8000. It contains stripped versions of
the BDOS and BIOS, with only those functions which are needed to open the
CPM.SYS file and read it into memory. CPMLDR will exist in at least two forms;
one form is the information in the system tracks, the other is a file named
CPMLDR.SYS which is created by the linker. The term CPMLDR is used to
refer to either of these forms, but CPMLDR.SYS only refers to the file.
.mb 6
.fm 2
.ix Cold Boot Loader, creating
.ix CPMLDR.SYS
.ix loader system library
.ix LDRLIB
.ix PUTBOOT utility
.pp
CPMLDR.SYS is generated using a procedure similar to that used in generating
CPM.SYS. That is, a loader BIOS is linked with a loader system library, named
LDRLIB, to produce CPMLDR.SYS. Additional modules may be linked in as required
by your hardware. The resulting file is then loaded onto the system tracks
using a utility program named PUTBOOT.
.sp 2
.tc 3.2.1 Writing a Loader BIOS
.sh
3.2.1 Writing a Loader BIOS
.qs
.ix Loader BIOS, writing
.pp
The loader BIOS is very similar to your ordinary BIOS; it just has fewer
functions, and the entry convention is slightly different. The differences
are itemized below.
.sp 2
.in 8
.ti -3
1) Only one disk needs to be supported. The loader system selects only
drive A. If you want to boot from a drive other than A, your loader BIOS
should be written to select that other drive when it receives a request to
select drive A.
.sp
.ti -3
2) The loader BIOS is not called through a trap; the loader BDOS calls an entry
point named _bios instead. The parameters are still passed in registers, just
as in the normal BIOS. Thus, your Function 0 does not need to
initialize a trap, the code that in a normal BIOS would be the Trap 3
handler should have the label _bios, and you exit from your loader BIOS with
an RTS instruction instead of an RTE.
.ix Function 0
.ix Trap 3 handler
.ix BIOS
.ix RTE
.ix trap initialization
.sp
.ti -3
3) Only the following BIOS functions need to be implemented:
.sp
0 (Init) Called just once, should initialize hardware as necessary, no return value necessary. Note that Function 0 is called via _bios with the
function number equal to 0. You do not need a separate _init entry point.
.sp
4 (Conout) Used to print error messages during boot. If you do not want
error messages, this function should just be an rts.
.sp
9 (Seldsk) Called just once, to select drive A.
.ix Init
.ix Conout
.ix Seldsk
.sp
10 (Settrk)
.sp
11 (Setsec)
.sp
12 (Setdma)
.sp
13 (Read)
.sp
16 (Sectran)
.sp
18 (Get MRT) Not used now, but may be used in future releases.
.sp
22 (Set exception)
.ix Settrk
.ix Setsec
.ix Setdma
.ix Read
.ix Sectran
.ix Get MRT
.ix Set exception
.sp
.ti -3
4) You do not need to include an allocation vector or a check vector, and the
Disk Parameter Header values that point to these can be anything. However,
you still need a Disk Parameter Header, Disk Parameter Block, and directory
buffer.
.ix allocation vector
.ix Disk Parameter Header
.ix Disk Parameter Block
.ix directory buffer
.in 0
.sp
.pp
It is possible to use the same source code for both your normal BIOS and
your loader BIOS if you use conditional compilation or assembly to
distinguish the two.
We have done this in our example BIOS for the EXORmacs.
.sp 2
.tc 3.2.2 Building CPMLDR.SYS
.sh
3.2.2 Building CPMLDR.SYS
.qs
.ix CPMLDR.SYS, building
.pp
Once you have written and compiled (or assembled) a loader BIOS, you can build
CPMLDR.SYS in a manner very similar to building CPM.SYS. There is one
additional complication here: the result of this step is
placed on the system tracks. So, if you need a small prebooter to bring
in the bulk of CPMLDR, the prebooter must also be included in the link
you are about to do. The details of what must be done are hardware dependent,
but the following example should help to clarify the concepts involved.
.pp
Suppose that your hardware reads track 0, sector 1, into memory at location
400H when reset is pressed, then jump to 400H. Then your boot disk must
have a small program in that sector that can load the rest of the system
tracks into memory and execute the code that they contain. Suppose that you
have written such a program, assembled it, and the assembler output is in
BOOT.O. Also assume that your loader BIOS object code is in the file
LDRBIOS.O. Then the following command links together the code that must
go on the system tracks.
.ix boot disk
.ix PUTBOOT utility
.ti 8
.sp
A>\c
.sh
lo68 -s -T400 -uldr -o cpmldr.sys boot.o ldrlib ldrbios.o
.pp
Once you have created CPMLDR.SYS in this way, you can use the PUTBOOT utility
to place it on the system tracks. PUTBOOT is described in Section 8.
The command to place CPMLDR on the system tracks of drive A is:
.sp
.ti 8
A>\c
.sh
putboot cpmldr.sys a
.pp
PUTBOOT reads the file CPMLDR.SYS, strips off the 28-byte command file
header, and puts the result on the specified drive. You can now boot from
this disk, assuming that CPM.SYS is on the disk.
.sp 2
.ce
End of Section 3
.nx four

1160
CPM OPERATING SYSTEMS/CPM 8000 (CPM8K)/P-CP M-Z8K SOURCES/sg/sys4.tex Normal file
View File

File diff suppressed because it is too large Load Diff

596
CPM OPERATING SYSTEMS/CPM 8000 (CPM8K)/P-CP M-Z8K SOURCES/sg/sys5.tex Normal file
View File

@@ -0,0 +1,596 @@
.he
.bp odd
.mt 5
.mb 6
.pl 66
.ll 65
.po 10
.hm 2
.fm 2
.ft All Information Presented Here is Proprietary to Digital Research
.sp 3
.sh
.ce 2
.tc 5 Creating a BIOS
Section 5
.SP
.sh
Creating a BIOS
.sp 3
.sh
5.1 Overview
.tc 5.1 Overview
.pp
The BIOS provides a standard interface to the physical input/output devices
in your system. The BIOS interface is defined by the functions
described in Section 4. Those functions, taken together, constitute a model
of the hardware environment. Each BIOS is responsible for mapping that
model onto the real hardware.
.ix BIOS, creating
.ix BIOS interface
.pp
In addition, the BIOS contains disk definition tables which define
the characteristics of the
disk devices which are present, and provides some storage for use by the BDOS
in maintaining disk directory information.
.pp
Section 4 describes the functions which must be performed by the BIOS, and the
external interface to those functions. This Section contains additional
information describing the structure and significance of the disk definition
tables and information about sector blocking and deblocking. Careful choices
of disk parameters and disk buffering methods are necessary if you are to
achieve the best possible performance from CP/M-8000. Therefore, this section
should be read thoroughly before writing a custom BIOS.
.sp 2
.sh
5.2 Disk Definition Tables
.he CP/M-8000 System Guide 5.2 Disk Definition Tables
.tc 5.2 Disk Definition Tables
.ix disk definition tables
.ix CP/M-8000 configuration
.pp
As in other CP/M systems, CP/M-8000 uses a set of tables to define disk
device characteristics. This section describes each of these tables
and discusses choices of certain parameters.
.bp
.sh
5.2.1 Disk Parameter Header
.tc 5.2.1 Disk Parameter Header
.ix Disk Parameter Header (DPH)
.ix scratchpad area
.pp
Each disk drive has an associated 26-byte Disk Parameter Header (DPH)
which both contains information about the disk drive and
provides a scratchpad area for certain BDOS operations. Each drive must
have its own unique DPH. The format of a Disk Parameter Header is shown in
Figure 5-1.
.sp 3
.ce 100
.nf
XLT 0000 0000 0000 DIRBUF DPB CSV ALV
.sp
32b 16b 16b 16b 32b 32b 32b 32b
.sp
.sh
Figure 5-1. Disk Parameter Header
.sp 2
.ce 0
.fi
.ix word (16-bit) value
.ix longword (32-bit) value
.pp
Each element of the DPH is either a word (16-bit) or longword (32-bit)
value. The meanings of the Disk Parameter Header (DPH) elements are given
in Table 5-1.
.sp 2
.ce
.sh
Table 5-1. Disk Parameter Header Elements
.qs
.ix Disk Parameter Header elements
.sp
.nf
Element Description
.sp
.fi
.ll 62
.in 15
.ti -10
XLT Address of the logical-to-physical sector translation table, if used
for this particular drive, or the value 0 if there is no translation table
for this drive (i.e, the physical and logical sector numbers are the same).
Disk drives with identical sector translation may share the same translate
table. The sector translation table is described in Section 5.2.2.
.ix XLT
.sp
.ti -10
0000 Three scratchpad words for use within the BDOS.
.sp
.ix scratchpad words
.ix 0000
.ti -10
DIRBUF Address of a 128-byte scratchpad area for directory operations
within BDOS. All DPHs address the same scratchpad area.
.ix DIRBUF
.sp
.ti -10
DPB Address of a disk parameter block for this drive. Drives with
identical disk characteristics may address the same disk parameter block.
.ix DPB
.bp
.ll 65
.in 0
.ce
.sh
Table 5-1. (continued)
.sp
.nf
Element Description
.fi
.sp
.ll 62
.in 15
.ti -10
CSV Address of a checksum vector. The BDOS uses this area to maintain
a vector of directory checksums for the disk. These checksums are used in
detecting when the disk in a drive has been changed. If the disk is not
removable, then it is not necessary to have a checksum vector. Each DPH must
point to a unique checksum vector. The checksum vector should contain 1 byte
for every four directory entries (or 128 bytes of directory). In other words:
length (CSV) = (DRM+1) / 4. (DRM is discussed in Section 5.2.3.)
.ix CSV
.ix checksum vector
.sp
.ti -10
ALV Address of a scratchpad area used by the BDOS to keep disk storage
allocation information. The area must be different for each DPH. There must
be 1 bit for each allocation block on the drive, requiring the following:
length (ALV) = (DSM/8) + 1. (DSM is discussed below.)
.ix ALV
.ix Disk Parameter Header elements
.in 0
.ll 65
.sp 3
.sh
5.2.2 Sector Translate Table
.tc 5.2.2 Sector Translate Table
.pp
Sector translation in CP/M-8000 is a method of logically renumbering
the sectors on each disk track to improve disk I/O performance. A frequent
situation is that a program needs to access disk sectors
sequentially. However, in reading sectors sequentially, most programs
lose a full disk revolution between sectors because there is not
enough time between adjacent sectors to begin a new disk operation. To
alleviate this problem, the traditional CP/M solution is to create a logical
sector numbering scheme in which logically sequential sectors are physically
separated. Thus, between two logically contiguous sectors, there is a
several sector rotational delay. The sector translate table defines
the logical-to-physical mapping in use for a particular drive, if a
mapping is used.
.ix logical sector numbering
.ix mapping, logical to physical
.ix rotational latency
.pp
Sector translate tables are used only within the BIOS. Thus the table
may have any convenient format. (Although the BDOS is aware of the
sector translate table, its only interaction with the table is to get the
address of the sector translate table from the DPH and to pass that address
to the Sector Translate Function of the BIOS.) The most common form for a
sector translate table is an n-byte (or n-word) array of physical sector
numbers, where n is the number of sectors per disk track. Indexing into
the table with the logical sector number yields the corresponding physical
sector number.
.ix sector translate table
.pp
Although you may choose any convenient logical-to-physical mapping, there is
a nearly universal mapping used in the CP/M community for single-sided,
single-density, 8-inch diskettes. That mapping is shown in Figure 5-2.
Because your choice of mapping affects diskette compatibility between
different systems, the mapping of Figure 5-2 is strongly recommended.
.sp 3
.nf
.sp
Logical Sector 0 1 2 3 4 5 6 7 8 9 10 11 12
Physical Sector 1 7 13 19 25 5 11 17 23 3 9 15 21
.sp
Logical Sector 13 14 15 16 17 18 19 20 21 22 23 24 25
Physical Sector 2 8 14 20 26 6 12 18 24 4 10 16 22
.sp 2
.ce
.sh
Figure 5-2. Sample Sector Translate Table
.fi
.sp 2
.sh
5.2.3 Disk Parameter Block
.tc 5.2.3 Disk Parameter Block
.pp
A Disk Parameter Block (DPB) defines several characteristics associated
with a particular disk drive. Among them are the size of the drive, the
number of sectors per track, the amount of directory space, and others.
.ix Disk Parameter Block (DPB)
.pp
A Disk Parameter Block can be used in one or more DPH's if the disks are
identical in definition. A discussion of the fields of the DPB follows the
format description. The format of the DPB is shown in Figure 5-3.
.cp 6
.sp 2
.nf
.sp
SPT BSH BLM EXM 0 DSM DRM Reserved CKS OFF
.sp
16b 8b 8b 8b 8b 16b 16b 16b 16b 16b
.sp
.ce
.sh
Figure 5-3. Disk Parameter Block
.sp 2
.fi
.sp
Each field is a word (16 bit) or a byte (8 bit) value. The description of
each field is given in Table 5-2.
.ix byte (8 bit) value
.ix word (16 bit) value
.sp 2
.ix Disk Parameter Block fields
.ce
.sh
Table 5-2. Disk Parameter Block Fields
.sp
.nf
Field Definition
.fi
.ll 62
.in 15
.sp
.ti -10
SPT Number of 128-byte logical sectors per track.
.ix SPT
.sp
.ti -10
BSH The block shift factor, determined by the data block allocation
size, as shown in Table 5-3.
.ix BSH
.ix Block Shift Factor
.bp
.ce
.ll 65
.in 0
.sh
Table 5-2. (continued)
.sp
.nf
Field Definition
.sp
.fi
.in 15
.ll 62
.ti -10
BLM The block mask which is determined by the data block allocation
size, as shown in Table 5-3.
.ix BLM
.ix Block Mask
.sp
.ti -10
EXM The extent mask, determined by the data block allocation
size and the number of disk blocks, as shown in Table 5-4.
.ix BLM
.ix Extent Mask
.sp
.ti -10
0 Reserved byte.
.sp
.ti -10
DSM Determines the total storage capacity of the disk drive and
is the number of the last block, counting from 0. That is,
the disk contains DSM+1 blocks.
.ix DSM
.ix disk drive, total storage capacity
.sp
.ti -10
DRM Determines the total number of directory entries which can be
stored on this drive. DRM is the number of the last directory entry,
counting from 0. That is, the disk contains DRM+1 directory entries.
Each directory entry requires 32 bytes, and for maximum efficiency, the
value of DRM should be chosen so that the directory entries exactly fill
an integral number of allocation units.
.ix DRM
.sp
.ti -10
CKS The size of the directory check vector, which is zero if the disk
is permanently mounted, or length (CSV) = (DRM) / 4 + 1 for removable
media.
.ix CKS
.ix directory check vector
.sp
.ti -10
OFF The number of reserved tracks at the beginning of a logical
disk. This is the number of the track on which the directory begins.
.ix OFF
.ix reserved tracks, number of
.ll 65
.in 0
.sp
.pp
To choose appropriate values for the Disk Parameter Block elements, you must
understand how disk space is organized in CP/M-8000. A CP/M-8000
disk has two major areas: the boot or system tracks, and the file system
tracks. The boot tracks are usually used to hold a machine-dependent
bootstrap loader for the operating system. They consist of tracks 0 to OFF-1.
Zero is a legal value for OFF, and in that case, there are no boot tracks. The
usual value of OFF for 8-inch floppy disks is two.
.ix file system tracks
.ix boot tracks
.ix Disk Parameter Blocks
.ix bootstrap loader, machine dependent
.pp
The tracks after the boot tracks (beginning with track number OFF)
are used for the disk directory and disk files. Disk space in this area
is grouped into units called allocation units or blocks. The block size
for a particular disk is a constant, called BLS. BLS may take on any
one of these values: 1024, 2048, 4096, 8192, or 16384 bytes. No other
values for BLS are allowed. (Note that BLS does not appear explicitly in
any BIOS table. However, it determines the values of a number of other
parameters.) The DSM field in the Disk Parameter Block is one less than
the number of blocks on the disk. Space is allocated to a file
or to the directory in
whole blocks. No fraction of a block can be allocated.
block size
.ix BLS
.ix DSM
.pp
The choice of BLS is very important, because it effects the efficiency of
disk space utilization, and because for any disk size there is a minimum
value of BLS that allows the entire disk to be used.
Each block on the disk has a block number ranging from 0 to DSM. The largest
block number allowed is 32767. Therefore, the largest number of bytes that
can be addressed in the file system space is 32768 * BLS. Because the largest
allowable value for BLS is 16384, the biggest disk that can be accessed by
CP/M-8000 is 16384*32768 = 512 Mbytes.
.ix block number, largest allowed
.pp
Each directory entry may contain either 8 block numbers (if DSM >= 256)
or 16 block
numbers (if DSM < 256). Each file needs enough directory entries to hold
the block numbers of all blocks allocated to the file. Thus a large value
for BLS implies that fewer directory entries are needed. Since fewer
directory entries are used, the directory search time is decreased.
.pp
The disadvantage of a large value for BLS is that since files are allocated
BLS bytes at a time, there is potentially a large unused portion of a block
at the end of the file. If there are many small files on a disk, the waste
can be very significant.
.pp
The BSH and BLM parameters in the DPB are functions of BLS. Once you have
chosen BLS, you should use Table 5-3 to determine BSH and BLM. The EXM
parameter of the DPB is a function of BLS and DSM. You should use Table 5-4
to find the value of EXM for your disk.
.ix ESM
.sp 3
.nf
.sh
Table 5-3. BSH and BLM Values
.sp
BLS BSH BLM
1024 3 7
2048 4 15
4096 5 31
8192 6 63
16384 7 127
.in 0
.fi
.bp
.sh
Table 5-4. EXM Values
.sp
.nf
BLS DSM <= 255 DSM > 255
.sp
1024 0 N/A
2048 1 0
4096 3 1
8192 7 3
16384 15 7
.in 0
.fi
.ll 65
.sp
.pp
The DRM entry in the DPB is one less than the total number of directory
entries. DRM should be chosen large enough so that you do not run
out of directory entries before running out of disk space. It is not
possible to give an exact rule for determining DRM, since the number
of directory entries needed will depend on the number and sizes of the
files present on the disk.
.pp
The CKS entry in the DPB is the number of bytes in the CSV (checksum vector)
which was pointed to by the DPH. If the disk is not removable, a checksum
vector is not needed, and this value may be zero.
.sp 2
.sh
5.3 Disk Blocking System Guide
.tc 5.3 Disk Blocking Guide
.he CP/M-8000 System Guide 5.3 Disk Blocking
.ix sector, 128-byte
.pp
When the BDOS does a disk read or write operation using the BIOS, the unit
of information read or written is a 128-byte sector. This may or may not
correspond to the actual physical sector size of the disk. If not, the BIOS
must implement a method of representing the 128-byte sectors used by CP/M-8000
on the actual device. Usually if the physical sectors are not 128 bytes long,
they will be some multiple of 128 bytes. Thus, one physical sector can hold
some integer number of 128-byte CP/M sectors. In this case, any disk I/O
will actually consist of transferring several CP/M sectors at once.
.pp
It might also be desirable to do disk I/O in units of several 128-byte sectors
in order to increase disk throughput by decreasing rotational latency.
(Rotational latency is the average time it takes for the desired position on
a disk to rotate around to the read/write head. Generally this averages 1/2
disk revolution per transfer.) Since a great deal of disk I/O is sequential,
rotational latency can be greatly reduced by reading several sectors at a
time, and saving them for future use.
.ix rotational latency
.ix read/write head
.pp
In both the cases above, the point of interest is that physical I/O
occurs in units larger than the expected sector size of 128 bytes.
Some of the problems in doing disk I/O in this manner are discussed below.
.bp
.sh
5.3.1 A Simple Approach
.pp
This section presents a simple approach to handling a physical sector size
larger than the logical sector size. The method discussed in this section
is not recommended for use in a real BIOS. Rather, it is given as a
starting point for refinements discussed in the following sections.
Its simplicity also makes it a logical choice for a first BIOS on new
hardware. However, the disk throughput that you can achieve with this method
is poor, and the refinements discussed later give dramatic improvements.
.ix disk throughput
.pp
Probably the easiest method for handling a physical sector size which
is a multiple of 128 bytes is to have a single buffer the size of the
physical sector internal to the BIOS. Then, when a disk read is to be
done, the physical sector containing the desired 128-byte logical sector
is read into the buffer, and the appropriate 128 bytes are copied to the
DMA address. Writing is a little more complicated. You only want to
put data into a 128-byte portion of the physical sector, but you can
only write a whole physical sector. Therefore, you must first read the
physical sector into the BIOS's buffer; copy the 128 bytes of output data
into the proper 128-byte piece of the physical sector in the buffer; and
finally write the entire physical sector back to disk.
.sp
.sh
Note: \c
.qs
this operation involves two rotational latency delays in addition to the time
needed to copy the 128 bytes of data. In fact, the second rotational wait
is probably nearly a full disk revolution, since the copying is usually
much faster than a disk revolution.
.sp 2
.sh
5.3.2 Some Refinements
.tc 5.3.2 Some Refinements
.ix disk access, sequential
.pp
There are some easy things that can be done to the algorithm of Section 5.2.1
to improve its performance. The first is based on the fact that disk
accesses are usually done sequentially. Thus, if data from a certain physical
sector is needed, it is likely that another piece of that sector will be
needed on the next disk operation. To take advantage of this fact, the BIOS
can keep information with its physical sector buffer as to which disk,
track, and physical sector (if any) is represented in the buffer. Then, when
reading, the BIOS need only do physical disk reads when the information needed
is not in the buffer.
.pp
On writes, the BIOS still needs to preread the physical sector for the same
reasons discussed in Section 5.2.1, but once the physical sector is in the
buffer, subsequent writes into that physical sector do not require additional
prereads. An additional saving of disk accesses can be gained by not
writing the sector to the disk until absolutely necessary. The conditions
under which the physical sector must be written are discussed in
Section 5.3.4.
.ix physical sector
.bp
.sh
5.3.3 Track Buffering
.tc 5.3.3 Track Buffering
.pp
Track buffering is a special case of disk buffering where the I/O is done
a full track at a time. When sufficient memory for several full track
buffers is available, this method is quite good. The method is essentially
the same as discussed in Section 5.3.2, but there are some interesting
features. First, transferring an entire track is much more efficient than
transferring a single sector. The rotational latency is incurred only once
for the entire track, whereas if the track is transferred one sector at a
time, the rotational latency occurs once per sector. On a typical diskette
with 26 sectors per track, rotating at 6 revolutions per second, the difference
in rotational latency per track is about 2 seconds versus a twelfth of a
second. Of course, in applications where the disk is accessed purely
randomly, there is no advantage because there is a low probability that
more than one sector will be used from a given track. However, such
applications are extremely rare.
.ix rotational latency
.sp 2
.sh
5.3.4 LRU Replacement
.tc 5.3.4 LRU Replacement
.pp
With any method of disk buffering using more than one buffer, it is necessary
to have some algorithm for managing the buffers. That is, when should buffers
be filled, and when should they be written back to disk. The first question
is simple, a buffer should be filled when there is a request for a disk sector
that is not presently in memory. The second issue, when to write a buffer
back to disk, is more complicated.
.ix buffer, writing to disk
.pp
Generally, it is desirable to defer writing a buffer until it becomes
necessary. Thus, several transfers can be done to a buffer for the cost of
only one disk access, two accesses if the buffer had to be preread.
However, there are several reasons why buffers must be written. The following
list describes the reasons:
.sp 2
.in 8
.ti -3
1) A BIOS Write operation with mode=1 (write to directory sector). To maintain
the integrity of CP/M-8000's file system, it is very important that directory
information on the disk is kept up to date. Therefore, all directory writes
should be performed immediately.
.ix BIOS write operation
.sp
.ti -3
2) A BIOS Flush Buffers operation. This BIOS function is explicitly intended
to force all disk buffers to be written. After performing a Flush Buffers,
it is safe to remove a disk from its drive.
.ix BIOS flush buffers operation
.sp
.ti -3
3) A disk buffer is needed, but all buffers are full. Therefore some
buffer must be emptied to make it available for reuse.
.sp
.ti -3
4) A Warm Boot occurs. This is similar to number 2 above.
.ix warm boot
.ix boot, warm
.sp
.in 0
.pp
Case three above is the only one in which the BIOS writer has any discretion
as to which buffer should be written. Probably the best strategy is to
write out the buffer which has been least recently used. The fact that
an area of disk has not been accessed for some time is a fairly good
indication that it will not be needed again soon.
.ix LRU buffers
.sp 2
.sh
5.3.5 The New Block Flag
.tc The New Block Flag
.pp
As explained in Section 5.2.2, the BDOS allocates disk space to files
in blocks of BLS bytes. When such a block is first allocated to a file,
the information previously in that block need not be preserved. To
enable the BIOS to take advantage of this fact, the BDOS uses a special
parameter in calling the BIOS Write Function. If register D1.W contains
the value 2 on a BIOS Write call, then the write being done is to the
first sector of a newly allocated disk block. Therefore, the BIOS need
not preread any sector of that block. If the BIOS does disk buffering
in units of BLS bytes, it can simply mark any free buffer as corresponding
to the disk address specified in this write, because the contents of the
newly allocated block are not important. If the BIOS uses a buffer size
other than BLS, then the algorithm for taking full advantage of this
information is more complicated.
.ix BLS bytes
.pp
This information is extremely valuable in reducing disk delays. Consider
the case where one file is read sequentially and copied to a newly created
file. Without the information about newly allocated disk blocks, every
physical write would require a preread. With the information,
no physical write requires a preread. Thus, the number of physical disk
operations is reduced by one third.
.sp 2
.ce
End of Section 5
.nx six

165
CPM OPERATING SYSTEMS/CPM 8000 (CPM8K)/P-CP M-Z8K SOURCES/sg/sys6.tex Normal file
View File

@@ -0,0 +1,165 @@
.he
.bp odd
.mt 5
.mb 6
.pl 66
.ll 65
.po 10
.hm 2
.fm 2
.ft All Information Presented Here is Proprietary to Digital Research
.sp 3
.ce 2
.sh
Section 6
.sp
.sh
Installing and Adapting the Distributed BIOS and CP/M-8000
.tc 6 Installing and Adapting the Distributed BIOS and CP/M-8000
.sp 2
============ THIS ENTIRE SECTION NEEDS TO BE RE-WRITTEN ============
============ FIRST WE NEED TO KNOW HOW CP/M IS DISTRIBUTED =========
.sh
6.1 Overview
.he CP/M-8000 system Guide 6.1 Overview
.tc 6.1 Overview
.ix CP/M-8000, installing
.pp 5
The process of bringing up your first running CP/M-8000 system is
either trivial or involved, depending on your hardware environment.
Digital Research supplies CP/M-8000 in a form suitable for booting
on a Zilog EXORmacs development system. If you have an EXORmacs,
you can read Section 6.1 which tells how to load the distributed system.
Similarly, you can buy or lease some other machine which already runs
CP/M-8000.
.pp
If you do not have an EXORmacs, you can use the S-record files supplied
with your distribution disks to bring up your first CP/M-8000 system.
This process is discussed in Section 6.2.
.ix EXORmacs
.ix S-record files
.sp 2
.sh
6.2 Booting on an EXORmacs
.he CP/M-8000 System Guide 6.2 Booting on an EXORmacs
.tc 6.2 Booting on an EXORmacs
.ix boot disk
.pp 5
The CP/M-8000 disk set distributed by Digital Research includes disks
boot and run CP/M-8000 on the Zilog EXORmacs. You can use the distribution
system boot disk without modification if you have a Zilog EXORmacs system
and the following configuration:
.ix configuration requirements
.sp 2
.in 8
.ti -3
1) 128K memory (minimum)
.sp
.ti -3
2) a Universal Disk Controller (UDC) or Floppy Disk Controller (FDC)
.sp
.ti -3
3) a single-density, IBM 3740 compatible floppy disk drive
.sp
.ti -3
4) an EXORterm
.in 0
.sp 2
To load CP/M-8000, do the following:
.ix CP/M-8000, loading
.sp 2
.in 8
.ti -3
1) Place the disk in the first floppy drive (#FD04 with the UDC or #FD00
with the FDC).
.ix MACSbug
.ix UDC
.ix FDC
.sp
.ti -3
2) Press SYSTEM RESET (front panel) and RETURN (this brings in MACSbug).
.sp
.ti -3
3) Type "BO 4" if you are using the UDC, "BO 0" if you are using the
FDC, and RETURN. CP/M-8000 boots and begins running.
.sp 2
.in 0
.sh
6.3 Bringing Up CP/M-8000 Using the S-record Files
.he CP/M-8000 System Guide 6.3 CP/M-8000 with S-record Files
.tc 6.3 Bringing up CP/M-8000 Using S-record Files
.pp
The CP/M-8000 distribution disks contain two copies of the CP/M-8000 operating
system in Zilog S-record form, for use in getting your first CP/M-8000
system running. S-records (described in detail in Appendix F) are a simple
ASCII representation for absolute programs. The two S-record
systems contain the CCP and BDOS, but no BIOS. One of the S-record systems
resides at locations 400H and up, the other is configured to occupy the top
of a 128K memory space. (The exact bounds of the S-record systems may vary
from release to release. There will be release notes and/or a file named
README describing the exact characteristics of the S-record systems
distributed on your disks.) To bring up CP/M-8000 using the S-record files,
you need:
.ix S-records, bringing up CP/M-8000
.ix S-record systems
.ix CCP
.IX BDOS
.ix README file
.sp 2
.in 8
.ti -3
1) some method of down-loading absolute data into your target system
.ix absolute data, down-loading
.sp
.ti -3
2) a computer capable of reading the distribution disks (a CP/M-based
computer that supports standard CP/M 8-inch diskettes)
.sp
.ti -3
3) a BIOS for your target computer
.sp
.in 0
.pp
Given the above items, you can use the following procedure to bring a working
version of CP/M-8000 into your target system:
.in 8
.ix _init entry point
.sp
.ti -3
1) You must patch one location in the S-record system to link it to your BIOS's
_init entry point. This location will be specified in release notes and/or
in a README file on your distribution disks. The patch simply consists of
inserting the address of the _init entry in your BIOS at one long word
location in the S-record system. This patching can be done either before
or after down-loading the system, whichever is more convenient.
.ix S-record, long word location
.ix _ccp entry point
.sp
.ti -3
2) Your BIOS needs the address of the _ccp entry point in the S-record
system. This can be obtained from the release notes and/or the README file.
.sp
.ti -3
3) Down-load the S-record system into the memory of your target computer.
.mb 4
.fm 1
.sp
.ti -3
4) Down-load your BIOS into the memory of your target computer.
.sp
.ti -3
5) Begin executing instructions at the first location of the down-loaded
S-record system.
.sp
.in 0
.pp
Now that you have a working version of CP/M-8000, you can use the tools
provided with the distribution system for further development.
.sp
.ce
End of Section 6
.nx seven

68
CPM OPERATING SYSTEMS/CPM 8000 (CPM8K)/P-CP M-Z8K SOURCES/sg/sys7.tex Normal file
View File

@@ -0,0 +1,68 @@
.bp odd
.he
.cs 5
.mt 5
.mb 6
.pl 66
.ll 65
.po 10
.hm 2
.fm 2
.ft All Information Presented Here is Proprietary to Digital Research
.ce 2
.sh
Section 7
.sp
.sh
Cold Boot Automatic Command Execution
.tc 7 Cold Boot Automatic Command Execution
.ix Cold Boot Automatic Command Execution
.sp 3
.fi
.sh
7.1 Overview
.tc 7.1 Overview
.pp
The Cold Boot Automatic Command Execution feature of CP/M-8000 allows you to
configure CP/M-8000 so that the CCP will automatically execute a predetermined
command line on cold boot. This feature can be used to start up turn-key
systems, or to perform other desired operations.
.ix turn-key systems
.sp
.sh
7.2 Setting up Cold Boot Automatic Command Execution
.ix CBACE feature
.pp
The CBACE feature uses two global symbols: _autost, and _usercmd. These are
both defined in the CCP, which uses them on cold boot
to determine whether this feature is enabled. If you want to have a CCP
command automatically executed on cold boot, you should include code in your
BIOS's _init routine (which is called at cold boot) to do the following:
.ix _autost
.ix _usercmd
.ix _init routine
.sp 2
.in 8
.ti -3
1) The byte at _autost must be set to the value 01H.
.sp
.ti -3
2) The command line to be executed must be placed in memory at _usercmd and
subsequent locations. The command must be terminated with a NULL (00H) byte,
and may not exceed 128 bytes in length. All alphabetic characters in the
command line should be upper-case.
.sp
.in 0
.pp
Once you write a BIOS that performs these two functions, you can
build it into a CPM.SYS file as described in Section 2. This system, when
booted, will execute the command you have built into it.
.ix CPM.SYS file
.sp 2
.ce
End of Section 7
.bp
.he CP/M-8000 System Guide End of Section 7
.sp 30
.bp
.nx eight

88
CPM OPERATING SYSTEMS/CPM 8000 (CPM8K)/P-CP M-Z8K SOURCES/sg/sys8.tex Normal file
View File

@@ -0,0 +1,88 @@
.bp odd
.he
.cs 5
.mt 5
.mb 6
.pl 66
.ll 65
.po 10
.hm 2
.fm 2
.ft All Information Presented Here is Proprietary to Digital Research
.ce 2
.sh
Section 8
.sp
.sh
The PUTBOOT Utility
.tc 8 The PUTBOOT Utility
.sp 3
=============== WE OR SOMEBODY NEEDS TO WRITE THIS UTILITY =============
.fi
.sh
8.1 PUTBOOT Operation
.tc PUTBOOT Operation
.ix PUTBOOT utility
.pp 5
The PUTBOOT utility is used to copy information (usually a bootstrap loader
system) onto the system tracks of a disk. Although PUTBOOT can copy any
file to the system tracks, usually the file being written is a program
(the bootstrap system).
.sp 2
.sh
8.2 Invoking PUTBOOT
.tc 8.2 Invoking PUTBOOT
.he CP/M-8000 System Guide Invoking PUTBOOT
.pp
Invoke PUTBOOT with a command of the form:
.sp
.in 8
PUTBOOT [-H] <filename> <drive>
.fi
.sp
.in 0
where
.sp
.in 5
.ti -2
o -H is an optional flag discussed below;
.sp
.ti -2
o <filename> is the name of the file to be written to the system tracks;
.sp
.ti -2
o <drive> is the drive specifier for the drive to which <filename> is to be
written (letter in the range A-P.)
.sp
.in 0
.pp
PUTBOOT writes the specified file to the system tracks of the specified
drive. Sector skewing is not used; the file is written to the system tracks
in physical sector number order.
.ix sector skewing
.pp
Because the file that is written is normally in command file format,
PUTBOOT contains special logic to strip off the first 28 bytes of the file
whenever the file begins with the number 601AH, the magic number used in
command files. If, by chance, the file to be written begins with 601AH, but
should not have its first 28 bytes discarded, the -H flag should be specified
in the PUTBOOT command line. This flag tells PUTBOOT to write the file
verbatim to the system tracks.
.ix -H flag
.pp
PUTBOOT uses BDOS calls to read <filename>, and used BIOS calls to
write <filename> to the system tracks. It refers to the OFF and SPT
parameters in the Disk Parameter Block to determine how large the system
track space is. The source and command files for PUTBOOT are supplied
on the distribution disks for CP/M-8000.
.ix OFF parameter
.ix SPT parameter
.sp 2
.ce
End of Section 8
.bp
.he CP/M-8000 System Guide End of Section 8
.sp 23
.bp
.nx appa