Chapter 5
Random Block File Manager
The random block file manager (RBF manager) supports
disk
storage.
It is a re-entrant subroutine package called by the I/O
manager for I/O system calls to random-access devices. It main
tains the logical and physical file structures.
During normal operation, the RBF manager requests allocation
and deallocation of 256-byte data buffers. Usually, one buffer is
required for each open file. When physical I/O functions are nec
essary, the RBF manager directly calls the subroutines in the
associated device drivers. All data transfers are performed using
256-byte data blocks (pages).
The RBF manager does not deal directly with physical addresses
such as tracks and cylinders. Instead, it passes to the device
drivers address parameters, using a standard address called a
logical sector number,
or
LSN.
LSNs are integers from 0 to
n-1,
where
n is
the maximum number of sectors on the media. The
driver translates the logical sector number to actual cylinder/
track/sector values.
Because the RBF manager supports many devices that have dif
ferent performance and storage capacities, it is highly parame
ter-driven. The physical parameters it uses are stored on the
media itself.
On disk systems, the parameters are written on the first few
sectors of Track 0. The device drivers also use the information,
particularly the physical parameters stored on Sector 0. These
parameters are written by the FORMAT program that initial
izes and tests the disk.
Logical and Physical Disk Organization
All disks used by OS-9 store basic identification, file structure,
and storage allocation information on these first few sectors.
LSN 0 is the
identification sector.
LSN 1 is the
disk allocation
map sector.
LSN 2 marks the beginning of the disk's ROOT
directory. The following section tells more about LSN 0 and LSN
1.
5-1
OS-9 Technical Reference
Identification Sector (LSN 0)
LSN 0 contains a description of the physical and logical charac-
teristics of the disk. These characteristics are set by the FOR-
MAT command program when the disk is initialized.
The following table gives the OS-9 mnemonic name, byte
address, size, and description of each value stored in this LSN 0.
Relative Size
Name Address (Bytes)
Use
DD.TOT $00 3 Number of sectors on disk
DD.TKS $03 1 Track size (in sectors)
DD.MAP $04 2 Number of bytes in the alloca
tion bit map
DD.BIT $06 2 Number of sectors per cluster
DD.DIR $08 3 Starting sector of the ROOT
directory
DD.OWN $OB 2 Owner's user number
DD.ATT $OD 1 Disk attributes
DD.DSK $OE 2 Disk identification (for internal
use)
DDYMT $10 1 Disk format, density, number
;-/ of sides
DD. SPT $11 2 Number of sectors per track
DD.RES $13 2 Reserved for future use
DD.BT $15 3 Starting sector of the boot
strap file
DD.BSZ $18 2 Size of the bootstrap file (in
bytes)
DD.DAT $lA 5 Time of creation (Y:M:D:H:M)
DD.NAM $1F 32 Volume name in which the last
character has the most signifi
DD.OPT $3F Path descriptor options
5-2
Random Block File Manager / 5
Disk Allocation Map Sector (LSN 1)
LSN 1 contains the
disk allocation map,
which is created by
FORMAT. This map shows which sectors are allocated to the
files and which are free for future use.
Each bit in the allocation map represents a sector or cluster of
sectors on the disk. If the bit is set, the sector is considered to be
in use, defective, or non-existent. If the bit is cleared, the corre
sponding cluster is available. The allocation map usually starts
at LSN1. The number of sectors it requires varies according to
how many bits are needed for the map. DD.MAP specifies the
actual number of bytes used in the map.
Multiple sector allocation maps allow the number of sectors/clus
ter to be as small as possible for high volume media.
The FORMAT utility bases the size of the allocation map on the
size and number of sectors per cluster.
The DD.MAP value in LSN 0 specifies the number of bytes (in
LSN 1) that are used in the map.
Each bit on the disk allocation map corresponds to one sector
cluster on the disk. The DD.BIT value in LSN 0 specifies the
number of sectors per cluster. The number is an integral power
of 2 (1, 2, 4, 8, 16, and so on).
If a cluster is available, the corresponding bit is cleared. If it is
allocated, non-existent, or physically defective, the corresponding
bit is set.
ROOT Directory
This file is the parent directory of all other files and directories
on the disk. It is the directory accessed using the physical device
name (such as /D1). Usually, it immediately follows the Alloca
tion Map. The location of the ROOT directory file descriptor is
specified in DD.DIR. The ROOT directory contains an entry -for
each file that resides in the directory, including other
directories.
File Descriptor Sector
The first sector of every file is the
file
descriptor. It contains the
logical and physical description of the file.
5-3
OS-9 Technical Reference
The following table describes the contents of the file descriptor.
Relative Size
Name Address (Bytes)Use
FD.ATT $00 1 File attributes: D S PE PW PR
E W R (see next chart)
FD.OWN $01 2 Owner's user ID
FD.DAT $03 5 Date last modified: (Y M D H
M)
FD.LNK $08 1 Link count
FD.SIZ $09 4 File size (number of bytes)
FD.CREAT $OD 3 Date created (Y M D)
FD.SEG $10 240 Segment list (see next chart)
FD.ATT. (The attribute byte) contains the file permission bits.
When set the bits indicate the following:
Bit 7 Directory
Bit 6 Single user
Bit 5 Public execute
Bit 3 Public read
Bit 2 Execute
Bit 1 Write
Bit 0 Read
FD.SEG (the segment list) consists of a maximum of 48 5-byte
entries that have the size and address of each file block in logical
order. Each entry has the block's 3-byte LSN and 2-byte size (in
sectors). The entry following the last segment is zero.
After creation, a file has no data segments allocated to it until
the first write. (Write operations past the current end-of-file
cause sectors to be added to the file. The first write is always
past the end-of-file.)
If the file has no segments, it is given an initial segment. Usu
ally, this segment has the number of sectors specified by the
minimum allocation entry in the device descriptor. If, however,
the number of sectors requested is more than the minimum, the
initial segment has the requested number.
5-4
Random Block File Manager l 5
Later expansions of the file usually are also made in minimum
allocation increments. Whenever possible, OS-9 expands the last
segment, instead of adding a segment. When the file is closed,
OS-9 truncates unused sectors in the last segment.
OS-9 tries to minimize the number of storage segments used in
a file. In fact, many files have only one segment. In such cases,
no extra Read operations are needed to randomly access any byte
in the file.
If a file is repeatedly closed, opened, and expanded, it can
become fragmented so that it has many segments. You can avoid
this fragmentation by writing a byte at the highest address you
want to be used on a file. Do this before writing any other data.
Directories
Disk directories
are files that have the D attribute set. A direc
tory contains an integral number of entries, each of which can
hold the name and LSN of a file or another directory.
Each directory entry contains 29 bytes for the filename, followed
by the three bytes for the LSN of the file's descriptor sector. The
filename is left justified in the field, with the most significant bit
of the last character set. Unused entries have a zero byte in the
first filename character position.
Every disk has a master directory called the ROOT directory.
The DD.DIR value in LSN 0 (identification sector) specifies the
starting sector of the ROOT directory.
The RBF Manager Definitions of the Path
Descriptor
As stated earlier in this chapter, the PD.FST section of the path
descriptor is reserved for and defined by the file manager. The
following table describes the use of this section by the RBF man
ager. For your convenience, it also includes the other sections of
the PD.
5-5
OS-9 Technical Reference
Relative Size
Name Address (Bytes) Use
Universal Section (Same for all file managers and device drivers)
PD.PD $00 1 Path number
PD.MOD $01 1 Access mode
1 = read,
2 = write,
3 = update
PD.CNT $02 1 Number of open images (paths
using this PD)
PD.DEV $03 2 Address of the associated
device table entry
PD.CPR $05 1 Current process ID
PD.RGS $06 2 Address of the caller's 6809
register stack
PD.BUF $08 2 Address of the 256-byte data
buffer (if used)
Relative Size
Name Address (Bytes) Use
The RBF manager Path Descriptor Definitions (PD.FST Section)
PD.SMF $OA 1 State flag:
Bit 0 = current buffer is
altered
Bit 1 = current sector is in
the buffer
Bit 2 = descriptor sector is
in the buffer
PD.CP $OB 4 Current logical file position
(byte address)
PD.SIZ $OF 4 File size
PD. SBL $13 3 Segment beginning logical sec
tor number (LSN)
PD.SBP $16 3 Segment beginning physical
sector number (PSN)
5-6
Random Block File Manager / 5
Relative Size
Name Address (Bytes) Use
PD . SSZ $19 3 Segment size
PD.DSK $1C 2
Disk ID (for internal use only)
PD.DTB $lE
2
Address of drive table
Relative Size
Name Address (Bytes) Use
The RBF manager Option Section Definitions (PD.OPT Section)
(Copied from the device descriptor)
PD.DTP
$20 1
Device class:
0=SCF
1 = RBF
2 = PIPE
3=SBF
PD.DRV
$21 1
Drive number (On)
PD.STP
$22 1
Step rate
PD.TYP $23 1 Device type
PD.DNS $24 1 Density capability
PD.CYL $25 2 Number of cylinders (tracks)
PD.SID $27 1 Number of sides (surfaces)
PD.VFY $28 1 0 = verify disk writes
PD.SCT $29 2 Default number of sectors per
track
PD.TOS $2B 2 Default number of sectors per
track (Track 0)
PD.ILV $2D 1 Sector interleave factor
PD.SAS $2E 1 Segment allocation size
PD.TFM $2F 1 DMA transfer mode
PD.EXTEN $30 2 Path extension for record
locking
PD.STOFF $32 1 Sector/track offsets
5-7
OS-9 Technical Reference
Relative Size
Name Address (Bytes) Use
(Not copied from the device descriptor):
PD.ATT $33 1 File attributes
(DSPEPWPREWR)
PD.FD $34 3 File descriptor PSN
PD.DFD $37 3 Directory file descriptor PSN
PD.DCP $3A 4 File's directory entry pointer
PS.DVT $3E 2 Address of the device table
entry
Any values not determined by this table default to zero.
RBF-Type Device Descriptor Modules
This section describes the use of the initialization table con
tained in the device descriptor modules for RBF-type devices.
The following values are those the I/0 manager copies from the
device descriptor to the path descriptor.
5-8
Random Block File Manager / 5
Relative Size
Name Address (Bytes) Use
r~1$0-$11 Standard device descriptor
module header
IT.DTP $12 1
Device type:
0=SCF
1 = RBF
2 = PIPE
3 = SBF
IT. DRV $13 1 Drive number
IT. STP $14 1 Step rate
IT.TYP $15 1 Device type (see RBF path
descriptor)
IT.DNS $16 1 Media density:
Always 1 (double)
(see following information)
IT. CYL $17 2
Number of cylinders (tracks)
IT. SID $19 1 Number of sides
IT.VFY $lA 1 0 = Verify disk writes
1 = no verify
IT.SCT $1B 2
Default number of sectors per
track
IT. TOS $1 D
2
Default number of sectors per
track (Track 0)
IT.ILV $1 F 1 Sector interleave factor
IT.SAS $20 1
Minimum size of segment allo
cation (number of sectors to be
allocated at one time)
IT.DRV is used to associate a 1-byte integer with each drive
-- that a controller handles. Number the drives for each controller
as 0 to
n-1,
where
n is
the maximum number of drives the con
troller can handle.
5-9
OS-9 Technical Reference
IT.TYP specifies the device type (all types).
Bit 0 0 = 5-inch floppy diskette
Bit 5 0
1
Bit 6 0
1
Bit 7 0
1
Non-Color Computer format
Color Computer format
Standard OS-9 format
Non-standard format
Floppy diskette
Hard disk
IT.DNS specifies the density capabilities (floppy diskette only).
Bit 0 0
Single-bit density (FM)
Double-bit density (MFM)
Bit 1 0 = Single-track density (5-inch, 48 tracks per
1 = Double-track density (5-inch, 96 tracks per
IT.SAS specifies the minimum number of sectors allowed at one
time.
RBF Record Locking
Record locking is a general term that refers to methods designed
to preserve the integrity of files that can be accessed by more
than one user or process. The OS-9 implementation of record
locking is designed to be as invisible as possible. This means
that existing programs do not have to be rewritten to take
advantage of record locking facilities. You can usually write new
programs without special concern for multi-user activity.
Record locking involves detecting and preventing conflicts during
record access. Whenever a process modifies a record, the system
locks out other procedures from accessing the file. It defers
access to other procedures until it is safe for them to write to the
record. The system does not lock records during reads; so, multi
ple processes can read the record at the same time.
5-10
Random
Block File Manager / 5
Record Locking and Unlocking
To detect conflicts, OS-9 must recognize when a record is being
updated. The RBF manager provides true record locking on a
byte basis. A typical record update sequence
is:
OS9 I$Read
OS9 I$Seek
OS9 I$Write
program reads record
RECORD IS LOCKED
program updates record
reposition to record
record is rewritten
RECORD IS RELEASED
When a file is opened in update mode, any read causes locking
of the record being accessed. This happens because the RBF
manager cannot determine in advance if the record is to be
updated. The record stays locked out until the next read, write,
or close.
However, when a file is opened in the read or execute modes, the
system does not lock accessed records because the records cannot
be updated in these two modes.
A subtle but important problem exists for programs that interro
gate a data base and occasionally update its data. If you neglect
to release a record after accessing it, the record might be locked
up indefinitely. This problem is characteristic of record locking
systems and you can avoid it with careful programming.
Only one portion of a file can be locked out at a time. If an
application requires more than one record to be locked out, open
multiple paths to the same file and lock the record accessed by
each path. RBF notices that the same process owns both paths
and keeps them from locking each other out.
5-11
OS-9 Technical Reference
Non-Shareable Files
Sometimes (although rarely), you must create a file that can
never be accessed by more than one user at a time. To lock the
file, you set the single-user (s) bit in the file's attribute byte. You
can do this by using the proper option when the file is created,
or later using the OS-9 ATTR command. Once the single-user
bit is set, only one user can open the file at a time. If other users
attempt to open the file, Error 253 is returned. Note however,
that non-shareable means only one path can be opened to a file
at one time. Do not allow two processes to concurrently access a
non-shareable file through the same path.
More commonly, you need to declare a file as single-user only
during the execution of a specific program. You can do this by
opening the file with the single-user bit set. For example, sup
pose a process is sorting a file. With the file's single-user bit set,
OS-9 treats the file exactly as though it had a single-user attrib
ute. If another process attempts to open the file, OS-9 returns
Error 253.
You can duplicate non-shareable files by using the I$Dup system
call. This means that it can be inherited, and therefore accessi
ble to more than one process at a time. Single-user means only
that the file can be opened only once.
End-of-File Lock
A special case of record locking occurs when a user reads or
writes data at the end of a file, creating an
EOF Lock.
An EOF
Lock keeps the end of the file locked out until a process performs
a READ or WRITE that is not at the end of the file. It prevents
problems that might otherwise occur when two users want to
simultaneously extend a file. The EOF Lock is the only case in
which a WRITE call automatically causes portions of a file to be
locked out. An interesting and useful side effect of the EOF Lock
function occurs if a program creates a file for sequential output.
As soon as the program creates the file, E OF Lock is set and no
other process can pass the writer in processing the file. For
example, if an assembler redirects a listing to a disk file, and a
spooler utility tries to print a line from the file before it is writ
ten, record locking makes the spooler wait and stay at least one
step behind the assembler.
5-12
Random Block File Manager / 5
Deadlock Detection
A deadly embrace,
or deadlock, typically occurs when two pro
cesses attempt to gain control of two or more disk areas at the
same time. If each process gets one area (locking out the other
process), both processes become permanently stuck. Each waits
for a segment that can never become free. This situation is is not
restricted to any particular record locking scheme or operating
system.
When a deadly embrace occurs, RBF returns a deadlock error
(Error 254) to the process that caused OS-9 to detect the dead
lock. To avoid deadlocks, make sure that processes always access
records of shared files in the same sequence.
When a deadlock error occurs, it is not sufficient for a program
to retry the operation that caused the error. If all processes use
this strategy, none can ever succeed. For any process to proceed,
at least one must cancel operation to release its control over a
requesting segment.
RBF-Type Device Driver Modules
An RBF-type device driver module contains a package of subrou
tines that perform sector-oriented I/O to or from a specific hard
ware controller. Such a module is usually re-entrant. Because of
this, one copy of one device driver module can simultaneously
run several devices that use identical I/O controllers.
The I/O manager allocates a permanent memory area for each
device driver. The size of the memory area is given in the device
driver module header. The I/O manager and the RBF manager
use some of this area. The device driver can use the rest in any
manner. This area is used as follows:
The RBF Device Memory Area Definitions
Relative Size
Name Address (Bytes)Use
V.PAGE $00 1 Port extended address bits
A20-A16
V.PORT $01 2 Device base address (defined
by the I/O manager)
5-13
OS-9 Technical Reference
Relative Size
Name Address (Bytes)
Use
V.LPRC $03 1 ID of the last active process
(not used by RBF device
drivers)
V.BUSY $04 1 ID of the current process using
driver (defined by RBF)
0 = no current process
V.WAKE $05 1 ID of the process waiting for
I/O completion (defined by the
device driver)
V.USER $06 0 Beginning of file manager spe
cific storage
V.NDRV $06 1 Maximum number of drives
the controller can use (defined
by the device driver)
$07 8 Reserved
DRVBEG $OF 0 Beginning of the drive tables
TABLES $OF DAN*N Space for number of tables
reserved (n)
FREE 0 Beginning of space available
for driver
These values are defined in files in the DEFS directory on the
Development Package disk.
TABLES.
This area contains one table for each drive that the
controller handles. (The RBF manager assumes that there are as
many tables as indicated by V.NDRV.) Some time after the
driver Init routine is called, the RBF manager issues a request
for the driver to read LSN 0 from a drive table by copying the
first part of LSN 0 (up to DD.SIZ) into the table. Following is
the format of each drive table:
,--~.
5-14
Random Block File Manager / 5
Relative Size
Name Address (Bytes)Use
DD.TOT $00 3 Number of sectors.
DD.TKS $03 1 Track size (in sectors).
DD.MAP $04 2 Number of bytes in the alloca
tion bit map.
DD.BIT $06 2 Number of sectors per bit
(cluster size).
DD.DIR $08 3 Address (LSN) of the ROOT
directory.
DD.OWN $OB 2 Owner's user number.
DD.ATT $OD 1 Disk access attributes
(DSPEPWPREWR).
DD.DSK $OE 2 Disk ID (a pseudo-random
number used to detect diskette
swaps).
DDYMT $10 1 Media format.
DD.SPT $11 2 Number of sectors per track.
(Track 0 can use a different
value specified by IT.TOS in
the device descriptor.)
DD.RES $13 2 Reserved for future use.
DD.SIZ $15 0 Minimum size of device
descriptor.
V.TRAK $15 2 Number of the current track
(the track that the head is on,
and the track updated by the
driver).
V.BMB $17 1 Bit-map use flag:
0 = Bit map is not in use.
(Disk driver routines
must not alter V.BMB.)
V.FILEHD $18 2 Open file list for this drive.
5-15
OS-9 Technical Reference
Relative Size
Name Address (Bytes) Use
V.DISKID $lA 2 Disk ID.
V.BMAPSZ $1C
V.MAPSCT $1D
V.RESBIT $ lE
Size of bitmap.
Lowest reasonable bitmap
sector.
Reserved bitmap sector.
V.SCTKOF $1F 1 Sector/track byte.
V.SCOFST $20 1 Sector offset split from byte
above.
V.TKOFST $22 4 Reserved for future use.
DRVMEN $26 Size of each drive table.
The format attributes (DD.FMT) are these:
Bit BO
Bit B 1
Bit B2
Number of sides
Single-sided
Double-sided
Density
Single-density
Double-density
Track density
Single (48 tracks per inch)
Double (96 tracks per inch)
RBF Device Driver Subroutines
Like all device driver modules, RBF device drivers use a stan
dard executable memory module format.
The execution offset address in the module header points to a
branch table that has six 3-byte entries. Each entry is typically
a long branch (LBRA) to the corresponding subroutine. The
branch table is defined as follows:
5-16
Random Block File Manager / 5
ENTRY LBRA INIT Initialize drive
LBRA READ Read sector
,~. LBRA WRITE Write sector
LBRA GETSTA Get status
LBRA SETSTA Set status
LBRA TERM Terminate device
Ensure that each subroutine exists with the C bit of the condi
tion code register cleared if no error occurred. If an error occurs,
set the C bit and return an appropriate error code Register B.
The rest of this chapter describes the RFB device driver subrou
tines and their entry and exit conditions.
5-17
OS-9 Technical Reference
Init
Initializes a device and the device's memory
area.
Entry Conditions:
Y = address of the device descriptor
U = address of the device memory area
Exit Conditions:
CC = carry set on error
B = error code
(if any)
Additional Information:
0
If you want OS-9 to verify disk writes, use the Request
Memory system call (F$SRqMem) to allocate a 256-byte
buffer area in which a sector can be read back and verified
You must initialize the device memory area. For floppy
diskette controllers, initialization typically consists of:
1. Initializing V.NDRV to the number of drives with which
2. Initializing DD.TOT (in the drive table) to a non-zero
value so that Sector 0 can be read or written
3. Initializing V.TRAK to $FF so that the first seek finds
4. Placing the IRQ service routine on the IRQ polling list,
using the Set IRQ system call (F$IRQ)
5. Initializing the device control registers (enabling inter
· Prior to being called, the device memory area is cleared (set
to zero), except for V.PAGE and V.PORT. (These areas con
tain the 24- bit device address.) Ensure the driver initial
izes each drive table appropriately for the type of diskette
that the driver expects to be used on the corresponding
5-18
Random Block File Manager l 5
Read
Reads a 256-byte sector from a disk and
,,~ places it in a 256-byte sector buffer.
Entry Conditions:
B = M
SB of
the disk's LSN
X = LSB
of
the disk's LSN
Y = address of the path descriptor
U = address
of
the device memory area
Exit Conditions:
CC = carry set on error
B
= error code
(if any)
Additional Information:
· The following is a typical routine for using Read:
1. Get the sector buffer address from PD.BUF in the path
2. Get the drive number from PD.DRV in the path
3. Compute the physical disk address from the logical sec
4. Initiate the Read operation.
5. Copy V.BUSY
to VMAKE. The driver goes to sleep and
waits for the I/O to complete. (The IRQ service routine is
responsible for sending a wakeup signal.) After awaken
ing, the driver tests VMAKE to see if it is clear. If it
isn't clear, the driver goes back to sleep.
· Whenever you read LSN 0, you must copy the first part of
this sector into the proper drive table. (Get the drive num
ber from PD. DRV in the path descriptor.) The number of
bytes to copy is in DD.SIZ. Use the drive number (PD.DRV)
to compute the offset for the corresponding drive table as
5-19
OS'-9
Technical Reference
LDA PD.DRV,Y Get the drive number
LDH #DRVMEN Get the Size of a
drive table
MUL
LEAX DRVHEG,U Get the address of
the f ir5t table
LEAX D,X Compute the address
of the table
5-20
Random Block File Manager l 5
Write
Writes a 256-byte sector buffer to a disk.
Entry Conditions:
B
= MSB of the disk LSN
X = LSB
of
the disk LSN
Y = address
of
the path descriptor
U = address
of
the device memory area
Exit Conditions:
CC = carry set on error
B
= error code
Additional Information:
0
Following is a typical routine for using Write:
1. Get the sector buffer address from PD.BUF in the path
r ,
descriptor.
2. Get the drive number from PD.DRV in the path descriptor.
3. Compute the physical disk address from the logical sector
4. Initiate the Write operation.
5. Copy V.BUSY to VMAKE. The driver then goes to sleep
and waits for the I/O to complete. (The IRQ service routine
sends the wakeup signal.) After awakening, the driver tests
VMAKE to see if it is clear. If it is not, the driver goes
back to sleep. If the disk controller cannot be interrupt-dri
ven, it is necessary to perform a programmed I/O transfer.
6. If PF.VFY in the path descriptor is equal to zero, read the
sector back in and verify that it is written correctly. Verifi
cation usually does not involve a comparison of all of the
If disk writes are to be verified, the Init routine must
request the buffer in which to place the sector when it is
read back. Do not copy LSN 0 into the drive table when
reading it back for verification.
5-21
OS-9 Technical Reference
0
Use the drive number (PD.DRU) to compute the offset to
the corresponding drive table as shown for the Read
routine.
5-22
Random Block File Manager l 5
Getstats and Setstats
Reads or changes device's operating parameters.
Entry Conditions:
U = address
of
the device memory area
Y = address
of
the path descriptor
A = status code
Exit Conditions:
B = error code
(if any)
CC = carry set on error
Additional Information:
Get/set the device's operating parameters (status) as speci
fied for the Get Status and Set Status system calls. Getsta
and Setsta are wild card calls.
0
It might be necessary to examine or change the register
stack that contains the values of the 6809 register at the
time of the call. The address of the register stack is in
PD.RGS, which is located in the path descriptor. You can
use the following offsets to access any value in the register
stack:
Relative
Reg. Addr. Size 6809 Reg.
R$CC $00 1 Condition
Code Reg.
R$D $01 2 Register D
R$A $Ol 1 Register A
R$B $02 1 Register B
R$DP $03 1 Register DP
R$X $04 2 Register X
R$Y $06 2 Register Y
R$U $08 2 Register U
R$PC $OA 2 Program Counter
0
Register D overlays Registers A and B.
5-23
OS-9 Technical Reference
TerM
Terminate a device.
Entry Conditions:
U = address of the device memory area
Exit Conditions:
CC = carry set on error
B = error code (if
any)
Additional Information:
0
This routine is called when a device is no longer in use in
the system (when the link count
of
its device descriptor
module becomes zero).
0
Following is a typical routine for using Term:
1. Wait until any pending I/O is completed.
2. Disable the device interrupts.
3. Remove the device from the IRQ polling list.
4. If the Init routine reserved a 256-byte buffer for verify
ing disk writes, return the memory with the Return
Sysmem system call (F$SRtMem).
5-24
Random Block File Manager / 5
IRQ Service Routine
Services device interrupts.
Additional Information:
The IRQ Service routine sends a wakeup signal to the pro
cess indicated by the process ID in VMAKE when the I/O
is complete. It then clears VMAKE as a flag to indicate to
the main program that the IRQ has indeed occurred.
When the IRQ service routine finishes servicing an inter
rupt it must clear the carry and exit with an RTS
instruction.
Although this routine is not included in the device driver
module branch table and is not called directly by the RBF
manager, it is a key routine in interrupt-driven drivers. Its
function is to:
1. Service the device interrupts (receive data from device or
send data to it). The IRQ service routine puts its data
into and get its data from buffers that are defined in the
device memory area.
2. Wake up a process that is waiting for I/O to be com
pleted. To do this, the routine checks to see if there is a
process ID in VMAKE (if the bit is non-zero); if so, it
sends a wakeup signal to that process.
3. If the device is ready to send more data, and the output
buffer is empty, disable the device's
ready to transmit
interrupts.
5-25
OS-9 Technical Reference
Boot (Bootstra~ Module)
Loads the boot
ale
into AM.
Entry Conditions:
None
Exit Conditions:
D = size
of the boot file
(in bytes)
X = address at which the boot file was loaded into memory
CC = carry set on error
B
= error code
(if any)
Additional Information:
· The Boot module is not part of the disk driver. It is a sepa
rate module that is stored on the boot track of the system
The bootstrap module contains one subroutine that loads
the bootstrap file and related information into memory. It
uses the standard executable module format with a module
type of $C. The execution offset in the module header con
tains the offset to the entry point of this subroutine.
· The module gets the starting sector number and size of the
OS9Boot file from LSN 0. OS-9 allocates a memory area
large enough for the Boot file. Then, it loads the Boot file
· Following is a typical routine for using Boot:
1. Read LSN 0 from the disk into a buffer area. The Boot
module must pick its own buffer area. LSN 0 contains
the values for DD.BT (the 24-bit LSN of the bootstrap
file), and DD.BSZ (the size of the bootstrap file in bytes).
2. Get the 24-bit LSN of the bootstrap file from DD.BT.
3. Get the size of the bootstrap file from DD.BSZ. The Boot
module is contained in one logically contiguous block
beginning at the logical sector specified in DD.BT and
extending for DD.BSZ/256 + 1 sectors.
5-26
Random Block File Manager / 5
4. Use the OS-9 Request Sysmem system call (F$SRqMem)
to request the memory area in which the Boot file is
,-- loaded.
5. Read the Boot file into this memory area.
6. Return the size of the Boot file and its location. Boot file
5-27