M.J.Karas, 00-00-00
SYSTEM FUNCTIONS THAT CONTROL THE DISKS
The data storage files for applications programs are stored
upon the disk drives attached to the CP/M computer. The BDOS
supports a number of functions that allow the state and selection
status of the drives to be controlled.
SELECT DISK: Function 14.
The simplest control function is to select the current disk
with which to refer to as the logged or default disk. The
function is equivalent to the console CCP command:
A>B:<cr>
B>
Which changed the currently logged disk to drive B:. A BDOS
program to affect the same thing is given in the example program
of the next section below. Drive numbers correspond to the
console displayed drive designators as follows:
A: = Drive # 0
B: = Drive # 1
***
P: = Drive # 15
Once a drive has been selected it has its directory "activated"
and is maintained in a logged in status until the next warm boot,
cold boot, or disk reset BDOS function.
DETERMINE LOGGED DISK: Function 25.
An applications program can determine which disk drive is
the currently logged or default drive through use of this
function. The BDOS will return in the (A) register the number of
the currently selected drive according to the table given above.
The program segment below shows a sequence of BDOS interface
code that first determines if drive B: is selected, and if not
then does a BDOS call to change it.
;SELECT AND POLL LOGGED DISK DRIVE EXAMPLE
;
SELECT EQU 0EH ; FUNCTION 14
ASKDRV EQU 19H ; FUNCTION 25
BDOS EQU 0005H ; SYSTEM ENTRY POINT
ORG 0100H ; PROG START
LD C,ASKDRV ; FIND OUT IF B: IS SELECTED
CALL BDOS
CP 'B'-'A'
RET Z ; DONT SELECT IF ALREADY
; ..LOGGED
LD E,'B'-'A' ; SET TO LOG AND SELECT B:
LD C,SELECT
CALL BDOS
RET ; FINISHED WITH ANOTHER PROG
;
END
DRIVE STATUS SET AND RESET: Functions 28 & 37.
Drive status may be individually controlled by these
functions. Operation 28 allows a the currently selected drive to
be write protected (set to read/only). The process is simply:
WPDSK EQU 01CH
BDOS EQU 0005H
LD C,WPDSK ;WRITE PROTECT DISK
CALL BDOS
The write protect status of a specific disk may be removed by
function 37 which deactivates the directories of each drive
specified at call time. Each drive by default then becomes
read/write again but requires reactivation through reselection.
The reset drive vector is a 16-bit value passed to the BDOS with
a "1" bit in each bit position for a drive that equires
resetting. The most significant bit of the 16 bit quanity
corresponds to drive P: and the LSB to drive A:. The code
sequence to reset drive B: would be:
RESDSK EQU 025H
BDOS EQU 0005H
LD C,RESDSK ;FUNCTION CODE
LD DE,0000$0000$0000$0010B ;DRIVE B: BIT SET
CALL BDOS
GET DRIVE LOGIN AND READ?ONLY VECTORS: Function 24 & 29.
The BDOS keeps track of all drives that have been selected
since the last boot or disk reset functions. These drives are
considered in a online status in that the system knows
immediately what the space allocation map of the drive is and
whether the drive is in read/only status or not. Function 24
allows the application program to determine what subset of the
current drive complement are in this online logged status. The
vector returned in the (HL) register pair is a bit map like above
where a "1" bit means the drive is active. The most significant
bit of the 16-bit number corresponds to drive P:. The code below
fetches the vector and saves it in a local data area.
;LOGIN VECTOR EXAMPLE
;
LOGIN EQU 018H ; FUNCTION 24
BDOS EQU 0005H ; SYSTEM ENTRY POINT
ORG 0100H
LD C,LOGIN ; FUNCTION
CALL BDOS
LD (LOCLOG),HL ; SAVE VECTOR HERE
RET ; TO CCP
;
LOCLOG:
DEFS 2
END
In a similar manner the BDOS allows determination of which
drives are in the write protected read/only status. A "1" bit in
the returned vector indicates read/only status for a specific
drive. The code here shows how to fetch it.
;READ/ONLY VECTOR EXAMPLE
;
ROVEC EQU 01DH ; FUNCTION 29
BDOS EQU 0005H ; SYSTEM ENTRY POINT
ORG 0100H
LD C,ROVEC ; FUNCTION
CALL BDOS
LD (LOCROV),HL ; SAVE VECTOR HERE
RET ; TO CCP
;
LOCROV:
DEFS 2
END
GET ALLOCATION VECTOR AND DISK PARM POINTER: Function 27 & 31.
Two more miscellaneous disk drive interface functions are
provided that permit several special types of functions to be
performed. The first, function 27 returns an address in the (HL)
registers that points to a bit string in memory that corresponds
to the data block allocation map of the currently selected drive.
The map contains one bits in each position where a block
allocated, starting with the MSB of the forst byte in the string.
The length of the bit string depends upon the total capacity of
the drive in allocatable blocks. Function 31 permits an
application to determine the characteristics of the currently
selected drive. The BDOS returns an address in the (HL) registers
that points to a table of 33 bytes that describe the current
drive. Data in the table includes such data as number of
possible directory entries on the disk, number of allocatable
blocks on the disk, and, indirectly, the size of each disk block.
The program below is a comprehensive example of how these
functions can be used to determine the remaining space left on a
the selected drive. The program stores the available space of the
drive specified in the first byte of the default FCB into memory
location "KPDISK" and then exits to the CCP. The reader can adapt
the code as desired.
;
;CP/M BDOS INTERFACE EQUATES
;
BASE EQU 0000H ;BASE OF CP/M SYSTEM
LOGDRIV EQU 0004H+BASE ;LOCATION OF CURRENTLY LOGGED DRIVE
BDOS EQU 0005H+BASE ;THE BDOS I/O VECTOR
SLCTDSK EQU 14 ;SELECT DISK DRIVE
GALVEC EQU 27 ;GET ADDRESS ALLOCATION VECTOR
GDSKP EQU 31 ;GET ADDRESS OF DISK PARAMETER TABLE
;
;
ORG 0100H
;
;
;PROGRAM TO FETCH REMAINING DISK SPACE IN KBYTES
;
SPCGET:
LD A,(LOGDRIV) ; GET CURRENTLY LOGGED DRIVE AND SAVE
AND 0FH ; STRIP OUT USER NUMBER
LD (SAVDRIV),A ; SAVE CODE
;
LD A,(FCB) ; CHECK IF SAME AS SELECT
DEC A ; ADJUST FCB DRIVE TO MATCH SELECT DRIVE
LD E,A ; ..SELECT IN BDOS
LD C,SLCTDSK ; SELECT DISK FUNCTION
CALL BDOS
;
LD C,GDSKP ; FIND ADDRESS OF DISK PARAMETER HEADER
CALL BDOS
LD BC,0002H ; INDEX TO BLOCK SHIFT FACTOR
ADD HL,BC
LD B,(HL) ; (B) = BYTE BLOCK SHIFT FACTOR
INC HL
INC HL
INC HL
LD E,(HL) ; (DE) = WORD DISK BLOCK COUNT
INC HL
LD D,(HL)
INC DE
;
LD A,B ; ADJUST SHIFT FOR KBYTE SIZE
SUB 03H
LD HL,0001H ; CALCULATE BLOCK SIZE
SPCCAL:
OR A ; KNOW KBYTES PER BLOCK?
JP Z,SPCKNW
ADD HL,HL ; DOUBLE # SECTORS PER TRACK
DEC A ; DECREMENT BLOCK SHIFT
JP SPCCAL
;
SPCKNW:
LD C,L ; (BC)=KBYTES PER BLOCK
LD B,H
LD HL,0 ; INITIALIZE KPDISK
LD (KPDISK),HL
PUSH BC ; SAVE KBYTES/BLOCK
PUSH DE ; SAVE NUMBER OF BLOCKS
LD C,GALVEC ; NOW POINT TO THE ALLOCATION VECTOR
CALL BDOS ; (HL)=ALLOCATION VECTOR ADDRESS
POP DE
POP BC
;
LD (ALLSAVE),HL ; SAVE ALLOCATION POINTER
LD H,1 ; SET MINIMUM START BIT COUNT
;
UALLOC:
DEC H ; DEC BIT COUNT
JP NZ,STACT ; STILL ACTIVE BYTE
;
LD HL,(ALLSAVE) ; GET POINTER
LD A,(HL)
INC HL
LD (ALLSAVE),HL ; SAVE NEW POINTER
LD H,08H ; SET BIT COUNTER TO MAX
;
STACT:
RLCA ; GET ALLOCATION BIT TO CARRY
JP C,ALLOC ; DONT COUNT ALLOCATED BLOCKS
PUSH HL
LD HL,(KPDISK) ; GET KBYTES LEFT COUNT
ADD HL,BC ; ADD IN ONE MORE BLOCK COUNT
LD (KPDISK),HL
POP HL
;
ALLOC:
DEC DE ; DEC TOTAL BLOCK COUNT
LD L,A
LD A,D
OR E ; ALL BLOCKS SCANNED YET
LD A,L ; RESTORE ALLOC BIT PATTERN
JP NZ,UALLOC ; MORE TO COUNT
;
LD A,(SAVDRIV) ; RETURN DISK SELECT TO PREVIOUS
LD E,A ; ..SELECT IN BDOS
LD C,SLCTDSK ; SELECT DISK FUNCTION
CALL BDOS
RET ; BACK TO THE CCP
;
;
;PROGRAM DATA STORAGE ALLOCATIONS
;
BLKSIZ:
DEFS 2 ; STORAGE FOR ALLOCATION BLOCK SIZE
ALLSAVE:
DEFS 2 ; STORAGE FOR ALLOCATION PNT SAVE
SAVDRIV:
DEFS 1 ; SAVE CURRENT DISK SELECT DURING RELOG
KPDISK:
DEFS 2 ; STORAGE FOR KBYTES PER DRIVE LEFT
;
END
The next part in this series will present the the CP/M file
system as viewed from the BDOS interface aspect. The FILE CONTROL
BLOCK (FCB) will be presented. In addition the procedures to
prepare files for I/O and then the actual I/O procedures will be
presented. The series will round out to a conclusion with a
comprehensive programming example that presents a sequential file
I/O set of subroutines that permit character by character I/O
with a file to be done.
-----
What is this thing everybody is talking about called BDOS?
This series will attempt to answer this question in some detail
but first we need a little basis to understand WHY in the first
place. Digital Research CP/M is an operating system for smaller
type micro processor computer systems that is designed to remove
much of the normal computer operation drudgery experienced by the
computer operator. The operating system software embodies a
"system philosophy" that structures and generalizes upon the
operating environment of a piece of electronics hardware. The
environment presented actually allows that piece of quiet,
transistorized machinery to be used at a much higher level. The
full impact of what this operating system provides to a computer
is most probably felt by the typical micro computer hacker that
worked the hard way to get a computer system up and running.
While building, debugging, and integrating the pieces, the
computer was just a whole bunch of parts interfaced together in
an organized manner. However, when the thing is finally a
"computer" how does it get used. The low level process of poking
data into memory from a front panel or even filling, dumping, or
block moving memory data with an EPROM based "monitor program"
hardly makes this computer "useful". The process of putting on
disks and bringing up CP/M lights the torch for computer
usability. In this case the hacker experiences an elated feeling
now "NOW I CAN DO SOMETHING!"
Buried inside of the total operating system presentation is
the concept of generalization brought up in the previous
paragraph. One of the major requirements in order to make a
computer useful is that there has to be applications software
that performs the jobs intended for the computer. Jobs like
accounting, word processing, spread sheet data analysis, or
inventory control. Unfortunately the process of producing
applications software is very, very expensive. A good package may
take anywhere from one to ten man years of development effort to
make. If the process of making an applications package had to be
custom taylored to a specific hardware environment, then there
would not be affordable software available for use upon a given
XYZ computer. Generalization in the operation of a computer
environment solves this problem however. With the understanding
that at a certain level "all microprocessor computer systems are
alike" it is possible, with minimum constraints, to define a set
of logical type operations that make a computer useful.
This logical set of operations, for the Digital Research
CP/M operating system, is defined within the BDOS portion of the
operating system. Here in about 3 1/2 K bytes of tightly written
assembly language is the "generalization converter" that takes
I/O requests for hardware independant applications programs and
turns them into a lower level set of simplistic hardware oriented
functions that are then processed through the BIOS. This
conversion process is beneficial in the light that CP/M Ver 2.2
can be setup to run on a typical brand XYZ computer for about one
half of the effort needed to convert even one of the simplest
application packages had that application been written in a
hardware dependant manner. Conclusion; software developers can
make better, more sophisticated applications available for lower
cost and computer users find a competitive software market place
where there are many times multiple packages available that
perform similar functions.
The thrust of this presentation is to show the prospective
applications programmer how to use most of the generalized set
of "BDOS System Calls" within Digital Researches CP/M Ver 2.2.
The presentation scheme will be to describe all of the functions
and use simple examples. The reader is assumed to be modistly
familiar with 8080 Assembly Language Programming as all of the
examples will be given in machine language. Likewise, in this
environment it is assumed by default that the prospective
programmer is planning to code in assembly language. If a CP/M
compatible high level language is used for programming, such as
Digital Research PL/I-80 or Microsoft BASIC-80, then of course
the program interface at the "System Call" level becomes
transparent to the programmer. Run time subroutines make the high
level coded application get converted through yet another step.
(One major reason applications code in a high level language runs
slower than the equivalent function written in assembly
language).
|
