2.0 The Pascal Level


p.4 As mentioned above, all Pascal level I/O requests are eventually mapped by the compiler and operating system into calls on a group of UCSD pre-declared procedures known as the unit I/O procedures. The Pascal programmer may call the Unit I/O procedures directly or he may use standard Pascal I/O procedures such as READ, WRITE, GET and PUT. The exact details of how this mapping is accomplished do not concern us here. The Unit I/O procedures are not written in Pascal but, in facts are the native code procedures comprising the I/O section of the Run-Time Support Package. The mechanism by which they are called is described next.

2.1 Calling the Next Level Down: RSP/IO

All native code routines in RSP are called using the CSP (Call Standard Procedure) opcode, followed in the P-code stream by an unsigned byte containing the procedure number. To the Pascal user making direct calls to Unit I/O routines, they look like any other pre-declared procedure. If they actually were declared in Pascal, the declarations would have the following format (allowing a few illegitimate constructs such as optional parameters and variable length arrays). 
PROCEDURE UNITREAD(UNITNUMBER: INTEGER;
                   VAR DATAAREA: PACKED ARRAY [0..BYTESTOTRANSFER-1]
                     OF 0..255;
                   BYTESTOTRANSFER: INTEGERS;
                   [ LOGICALELOCK: INTEGER;
                   [ CONTROL: INTEGER ]] );

PROCEDURE UNITWRITE(UNITNUMBER: INTEGER;
                   VAR DATAAREA: PACKED ARRAY [0..BYTESTOTRANSFER-1]
                     OF 0..255;
                   BYTESTOTRANSFER: INTEGERS;
                   [ LOGICALELOCK: INTEGER;
                   [ CONTROL: INTEGER ]] );

FUNCTION UNITBUSY(UNITNUMBER: INTEGER): BOOLEAN;

PROCEDURE UNITWAIT(UNITNUMBER: INTEGER);

PROCEDURE UNITCLEAR(UNITNUMBER: INTEGER; UINITPTR: ^UIR);

(Note that UINITPTR is being introduced for the level 2 release.)

p.5 Remember that no such declarations actually exist in the system. They are intended to model the parameters passed and returned by the native code RSP/IO routines. Some of these routines are useful only in an asynchronous environment; under the synchronous system described here they are mere dummies.

2.1.1 Units and UNITNUMBERS

The various physical devices of the UCSD Pascal System are numbered, a fixed number being assigned to each device which the system is designed to handle. The formal parameter UNITNUMBER in the declarations above determines which of the Pascal physical units the operation is intended for. Thus the Unit I/O procedures are device-transparent to the Pascal programmer — the same procedure will deal with any of the physical units. Figure 2.0 is a list of the unit numbers associated with each physical unit. The meaning of the other parameters is discussed in section 3 of this document, the section dealing specifically with RSP/IO.

Unit NumberVolume Name
0(must not be used)
1CONSOLE:
2SYSTERM:
3(no current assignment)
4disk O
5disk 1
6PRINTER:
7(no current assignment)
8REMOTE:
9disk 2
10disk 3
11disk 4
12disk 5

Figure 2.0 — Unit Numbers

2.1.2 CONTROL Parameter

The CONTROL parameter to UNITREAD and UNITWRITE is a word used to pass special information to RSP/IO and BIOS regarding the handling of the I/O request. The format of the CONTROL word is shown in Figure 2.1.

p.6 

  15          4           3          2          1          0
+---------------+----------+----------+----------+----------+
| (un-assigned) |   CRLF   |  NOSPEC  | PHYSSECT |   ASYNC  |
+---------------+----------+----------+----------+----------+
  MSB                                                   LSB
Unassigned(3..15)  The contents of bits 4..15 are ignored.
CRLF(bit 2)  If set, do not do CR LF mapping.
NOSPEC(bit 2)  If set, implies “no special character handling”, i.e. no DLE expansion or LFs appended to CRs.
PHYSSECT(bit 1) If set, implies “Physical Sector Mode” for disk I/O.
ASYNC(bit 0) Ignored in this implementation.

Figure 2. — CONTROL word format

2.2 IORESULT and Completion Codes

At times, an I/O request will terminate abnormally. To detect such occurrences, UCSD Pascal offers the predefined function IORESULT. IORESULT returns an integer value describing the status of the last I/O request. The value of IORESULT is set as follows: Each call to UNITREAD, UNITWRITE or UNITCLEAR will cause a “completion code” to be set in the SYSCOM data area [SYSCOM (for SYStem COMmunication area) is the one and only data space directly accessible by both the Pascal Operating System and the Interpreter]. Programmers may test the completion code by using IORESULT.

The standard completion codes for release level 2.0 of the UCSD Pascal System are given in figure 2.2.

p.7

CodeMeaning
0 No error
1 CRC error
2 Illegal unit number
3 Illegal operation on unit
4 (no longer used)
5 Lost unit; unit no longer on line
6 Lost file; file name no longer in directory
7 Illegal file name
8 No room; insufficient space on disk
9 Unit not on line; no such volume on line
10 No file; no such file name in directory
11 Duplicate file
12 Not closed; attempt to open an open file
13 Not open; attempt to access a closed file
14 Bad format; error reading real or integer
15 Ring Buffer Overflow
16 Write protect; write attempt to protected disk
17 Illegal block number
18 Non-zero byte count (in physical sector mode)
19 Invalid UIR settings
100..199 Codes 100 through 199 are reserved for non-predefined device-dependent errors.
Figure 2.2 — I/O Completion Codes (Level 2.0)

2.3 Logical Disk Structure

The UCSD Pascal system views the disk as a zero-based linear array of 512 byte logical blocks. All UCSD Pascal disks have this logical structure, regardless of their physical format. The physical allocation units of a disk are commonly known as sectors and vary widely in size depending on the hardware. The BIOS is responsible for mapping the logical structure of a Pascal disk onto the physical structure of the device, i.e. mapping logical blocks onto physical sectors (see section 4.5.3.1).

2.3.1 Physical Sector Mode

p.8 To provide enhanced flexibility for systems programming at a machine-specific level, a mechanism has been provided for directly accessing the physical sectors of the disk. When the PHYSSECT bit of the CONTROL word is set on a call to UNITREAD or UNITWRITE involving a disk unit. the I/O is performed in physical sector mode. This has the following effects:

  1. The parameter LOGICALBLOCK is interpreted by the BIOS as physical sector number (PSN).
  2. The parameter BYTESTOTRANSFER must be zero or an error will be flagged. The actual number of bytes transferred is equal to the physical sector size.

2.3.1.1 Physical Sector Numbers

Typically, the physical sectors of a disk are addressed by specifying both track and sector numbers. That is, the disk is viewed as an array of tracks where each track is an array of sectors. If this data structure were declared in Pascal. it would look like this: 
type
     BYTE = 0..255;
     SECTOR = array [0..(BYTES_PER_SECTOR-1)] of BYTE;
     TRACK = array [1..SECTORS_PER_TRACK] of SECTOR;
     DISK = array [O..(TRACKS_PER_DISK-1)] of TRACK;

(Note that we are using the convention that track numbers are zero-based but sector numbers start from one. )

We can convert the type DISK into a linear array of SECTOR as follows: 

type
     DISK = array [0..(TRACKS_PER_DISK*SECTORS_PERTRACK)-1] of
       SECTOR;

p.9 We use this linear representation for addressing the disk by physical sector number (PSN). The relations between the PSN and track and sector numbers are: 

PSN = (TRACK_NUM * sectors_per_track) + SECTOR_NUM - 1;
TRACK_NUM = PSN div sectors_per_track;
SECTOR_NUM = (PSN mod sectors_per_track) + 1;

2.3.1.2 Physical Sector Size

Any physical sector size may be accommodated. An I/O request in physical sector made simply causes a full sector to be transferred. The Pascal programmer is responsible for ensuring that the data area is at least large enough for one physical sector.

Programs written using physical sector mode are not expected to be portable to different disk hardware without some modification.

This page last regenerated Sun Jul 25 13:37:38 2010.