Files
Sepp J Morris 31738079c4 Upload
Digital Research
2020-11-06 18:50:37 +01:00

240 lines
8.1 KiB
TeX

.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