EXT ENT
INTRODUCTION TO MACHINE LANGUAGE I/O
7.2 BUFFERED I/O EXAMPLE
The A/Q channel prohibits the execution of other instructions while data is being trans-ferred. The reason is obvious: the Q register and A register, which are used for I/O, are also the arithmetic registers. A direct storage access (DSA) channel may be con-nected to the 1704. The DSA transfers data di re c tly to memory, bypassing the A and Q registers. Therefore, apr 0 g ram may be executing while data is being transferred.
The direct storage of data is ref err e d to as BUFFERING. The A/Q channel is used to send functions and receive status, but the data is transferred via the DSA. The disk is an example of a buffered device.
A/Q 1704
DSA
1
7-11
7.2
SIDE VIEW:
850 DISK PACK (6 DISKS)
,1.-_ _ _ _ _ _ _ _ _ _ _
DISK SURFACE 0 DISK SURFACE 1---i---..s..c-- - - - - - -
DISK SURFACE 9 TOP VIEW:DISK SURFACE
r----~
CYLINDER 00...1
CYLINDER 99£
-DIRECTION OF ROTATION
853 contains 100 cylinders; 854 contains 200 cylinders.
Figure 14. Side and Top Views of 850 Disk Pack 7. 2. 1 Disk Functions
SECTOR 14 SECTOR 15 SECTOR 0 SECTOR 1
The program s e 1 e c t s the disk by setting the Q register with the e qui pm e n t number and the desired director bits. Throughout this discussion the disk shall be considered equipment number 8.
7-12
\._.-
.C)
'i/)
\ ... 1
7.2.1
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
o
Q
I
0o o o o I
1 0 0 0I o o o o
D\\... __ ---.. _---J'
VEQUIP 8
The setting of the director bits will define the operation and the information to be sent from or received in the A register.
A (A) depends upon D field of Q
Q
I
DI
DISK FUNCTION CODES Value Set in Q
(Bits 02-00) Output from A Input to A
001 Director function Director status
010 Load address Address register status
011 Write
100 Read
101 Compare
110 Checkword check
111 Write address
7-13
7.2.1.1
7.2.1.1 Director Function
A
D = 001 , OUT
LDQ LDA*
NOP OUT
=N$0401 FUNC -1
UNIT SELECT RELEASE
DISK FOR FUNC FUNC IN A
FUNC TO CONTROLLER
ALARM INTERRUPT END OF OPERATION INTERRUPT
READY & NOT BUSY INTERRUPT CLEAR INTERRUPT The clear interrupt fun c t ion will clear all selected in t err u p t s, allowing the
pro g ram mer to select the in t err up t s hde desires. Threedinlterrupts may be
C
selected: next ready and not busy status, en of operation, an a arm. The next ready and not busy in t err u p t occurs when the 1738 becomes not busy but still holds its ready status.
The end of 0 per a t ion interrupt allows the controller to inform the 1700 when it has completed an 0 per at ion such as a data transfer. The alarm interrupt will notify the 1700 that an alarm condition has arisen. There are eight possible alarm conditions: not ready, checkword error, lost data, seek error, add res s error, defective track, storage parity error, and protect fault.
The release function allows an unprotected pro g ram to use the disk even though the protect switch on the disk is still set. A protected pro g ram must issue the release function. The next time a protected program accesses the disk, the disk will become protected and must again be released before it will become accessible to an unprotected program.
The unit select and unit select code will al way s be zero unl e s s two disks are connected to the con t roll e r. Bit 8 is the unit select bit. It informs the con-troller that the pro g ram will select unit 0 or unit 1. Bit 9 indicates which unit bit 8 wishes to select. If 9 bit is a 0, unit 0 is s e 1 e c ted; if it is a 1, unit 1 is selected. The controller ignores bit 9 unless bit 8 is set.
7-14
c
7. 2. 1. 2 Load Address Ftmction record address) is placed in the A register (Figure 14).LDQ
The controller will position the Read/Write heads on the requested address. The' heads will be moved directly to the address forward or backward, depending on the cu rr en t location of the Read/Write heads. The address held in the A register will be in the following format.
15 8 7 4 3 0
AI L ___________________ c_Y_L_I_ND ___ E_R ____________ - L _________ H_E_A_D ______
~
_______ SE_C ___ T_O_R ___~I
The disk has been functioned and g i v e n the desired disk address. The next step will be to initiate one of three operations.
7. 2.1. 3 Write Ftmction
WRITE OPERATION INITIATED The controller expects to find the first word address minus 1 (FWA-1) of the transferred from memory.
7-15
7. 2.1~ 3
DATA BUFFER FOR DISK
, - - - - . - - - - I
I LWA + 1 I
I I
FWA---DATA
LWA-'~---~,
FWA - 1 MUST CONTAIN LWA + 1 OF BUFFER
Prior to issuing the write operation, the interrupts must be selected, the sector record add re s s must be sent to the controller and the LWA+1 of the buffer area must be at the FWA-1.
LDQ =N$0401 DISK FOR FUNC
LDA* FUNC SELECTED INT IN A
NOP
OUT -1 INT SELECTED
LDQ =N$0402 DISK FOR DISK ADDR
LDA =XDISKAD ADDR IN A
NOP
OUT -1 HEADS POSITIONED
LDA =XLWAP1 LWA+1 IN A
STA FWAMI LWA+1 AT FWA-1
LDQ =N$0403 DISK TO WRITE
LDA =XFWAM1 FWA-1 IN A
NOP
OUT -1 OPERATION INITIATED
The 1704 continues executing ins tructions while the disk t ran s fer s data. When the data has all been transferred or an alarm condition has arisen, the 1704 will be notified.
7-16
o
data into memory rather than writing data on the disk.7. 2. 1. 5 Compare Function D
=
101 ; OUTThe compare function code follow s the same pro g ram min g procedure as the read and write function codes. The compare function causes the con t roll e r to read data from the computer's memory and compare it with the data stored on the disk. If at any time during the compare, one word does not compare, the no compare status bit will be set. This fun c t ion provides an extra c he c k on the validity of the data transferred.
The checkword check (D=110) and write address (D=lll) functions are used by the customer engineers.
7.2.2 Disk Status 7. 2. 2. 1 Director Status
D = 001 , INP
Status may be t a ken to m 0 nit 0 r the operation of the disk. Once the disk erates an interrupt, status must be taken to determine which interrupt was gen-erated. This is a c com p lis he d by loading the Q register with the D portion set to 001 and by issuing an INP instruction.
15 14 A
PRODUCT FAULT STORAGE PARITY ERROR
LDQ
7.2.2.1
The ready status in d i cat e s that the unit is available. The busy bit indicates ( ' that the controller and/or the drive unit is presently involved in the performance _/
of an operation. This bit is set with the acceptance of a load address, write, read, compare, checkword check, or write address function. At the completion of the function which set the busy status, the status will be cleared and the disk will become not busy. Once the disk is not busy, a new function may be issued.
The interrupt bit a c k now 1 e d g e s that an interrupt has occurred. Further ex-amination of A will determine which of the three selected in t err u p t s was gen-erated: bit 4 (EOP) and bit 5 (ALARM).
If neither bit 4 nor bit 5 is set, the pro g ram mer should check bits 0 and 1 for ready and not busy. If the alarm bit is set, the pro g ram mer mus t determine which of the eight alarm conditions caused the interrupt.
The on cylinder status bit 3 is set when the Read/Write heads have reached the sector record address initially sent to the controller via the A/Q channel.
7. 2. 2. 2 Address Register Status D = 010 ; INP
The programmer may request the disk to return the current position of the Read/
Write heads at any time by selecting the disk as above but issuing an INP instruc-tion.
LDQ NOP INP
=N$0402 -1
DISK FOR DISK ADDR CURRENT ADDR IN A
The address will be in the same format used to send the address to the controller.
7. 2. 3 Summary, Buffered 1/0
The DSA provides the 1704 with a means of storing data directly in memory; this permits the execution of instructions while transferring data. The program sends the function word, the sector record address, and stores the LWA+1 of the buffer area at the FWA-1 prior to initiating an operation. The operation is indicated by the D portion of Q, with the A register containing the FWA-1 of the buffe-r area.
The con t roll e r interrupts the 1704 when a selected interrupt condition arises.
The program takes status to determine which of the selected interrupts was gen-erated.
7-18
CHAPTER VIII
SYSTEM REQUESTS
II
o
CHAPTER VIII - System Requests
G
TOPIC PAGE8.1 Operating Systems 8-1
8.1.1 utility 8-1
8.1.2 MSOS 8-1
8.2 Request Processing 8-1
8.2.1 Summary of Request Processing 8-3
8.3 Requests 8-4
8.3.1 Exit Request 8-7
•
8.3.2 Read/Write Reques ts 8-88.3.2.1 Format of the Read/write Request 8-9
8.3.2.2 Request Code 8-10
8.3.2.2.1 Format of Records 8-10
8. 3.2. 2. 1. 1 Teletype 8-11
8.3.2.2.1.2 Paper Tape Reader and Paper Tape Punch 8-11
C)
8. 3. 2. 2. 1. 3 Mass Storage Addressing 8-158.3.2.3 X Bit 8-15
8.3.2.4 Request Priority 8-16
8. 3.2. 5 Completion Priority 8-16
8. 3. 2. 6 Completion Address 8-16
8.3.2.7 Thread Word 8-19
8.3.2.8 Error Code 8-19
8.3.2.9 Mode 8-19
8.3.2.10 A Field 8-19
8.3.2.11 Logical Unit 8-19
8.3.2.12 Number of Words 8-24
8.3.2.13 Starting Address of Buffer 8-24
8.3.2.14 Setting Up RW Requests in Background 8-28·
8.3.2.14.1 Looping on the Thread Word 8-28
(1
'-../'CHAPTER VIII - System Requests (Cont) ". .. ~
\, •... /
TOPIC PAGE
8.3.2.14.2 Looping on a Flag 8-28
8.3.2.14.3 Scheduling Out of the Completion Routine 8-29
8.3.2.15 Examples of Programs Using
Ilo
Requests 8-30•
8.3.3 Schedule Reques t 8-368.3.3.1 Format of Schedule Request 8-36
8.3.3.2 Request Code 8-37
8.3.3.3 X Bit 8-37
8.3.3.4 Priority 8-37
8.3.3. 5 Address 8-37
8. 3. 3. 6 Example of Schedule Request 8-38
•
8.3.4 Timer Request 8...;408.3.4.1 The Format for the Timer Request 8-40
8.3.4.2 Request Code 8-41
8.3.4.3 X Bit 8-41
(-~
\
8. 3.4.4 Units 8-41
8.3.4.5 Priority 8-41
8.3.4.6 Address 8-41
8.3.4.7 . Q Parameter 8-41
8.3.4.8 Example of Timer Reques t 8-42
•
8.3.5 Status Request 8-428.3.5.1 Format of the Status Request 8-42
8.3.5.2 Request Code 8-43
8.3.5.3 X Bit 8-43
8.3.5.4 A Field 8-43
8.3.5.5 Logical Unit 8-43
8.3.5.6 Address of Parameter List 8-43
8.3.5.7 Reply to Status Reques t 8-44
8.3.5.7.1 Hardware Status 8-45
( '
\.,.
Chapter VIII - System Requests (Cont)
/' .. ,.
~) TOPIC PAGE
8. 3. 5.7. 2 Word 8 of PDT 8-45
8. 3. 5.7.3 Current Buffer Address 8-47
8. 3. 5. 8 Example of Status Reques t 8-47
•
8.3.6 GTFILE Request 8-478. 3. 6.1 Format of GTFILE Reques t 8-48
8. 3. 6. 2 Request Code 8-49
8. 3.6. 3 X Bit 8-49
8.3.6.4 Request Priority 8-49
8. 3. 6. 5 Completion Priority 8-49
8. 3.6. 6 Completion Address 8-49
8.3.6.7 Mode 8-49
8. 3.6. 8 A Field 8-49
8. 3. 6. 9 Logical Unit 8-49
0
8.3.6.10 Word Addresses: wI, w2 8-508.3.6.11 Starting Core Addres s 8-50
8.3.6.12 File Name Address 8-50
8.3.6.13 Example of a GTFILE Request 8-51
•
8.3.7 Loader Request 8-548. 3.7. 1 Format of the Loader Request 8-55
•
8.3.8 Core Reques t 8-558. 3. 8. 1 Format of Core Reques t 8-56
8.3.8.2 Example of Core Request 8-56
•
8.3.9 INDIR Request 8-598. 3.9. 1 Format of the INDIR Request 8-59
8. 3. 9. 2 Example of the INDIR Request 8-59
8.4 Problem 8-60
c)
8.1 OPERATING SYSTEMS 8.1o
o
The 1700 computer system has two commonly used operating systems: the utility system and the mass storage operating system (MSOS). MSOS is a disk or drum oriented sys-tem and all 0 cat e s the resources of the computer according to a priority system. The utility system is a much smaller system. It provides for assembly, loading, and execu-tion of programs in a batch mode.
8. 1.1 utility
The 1700 utility system provides the 1700 computer with a means of loading and executing programs in configurations smaller than the minimum required for the 1700 operating system. The utility system requires 8K of core but no disk or drum. I/O is by way of the paper tape rea d e r and paper tape punch, and lis ting and operator control is t h r 0 ugh the teletype. * Ex e cut ion of jobs through the utility system can make use of the standard drivers provided by utility. The standard drivers provided are for the teletype, paper tape input, and paper tape output. It is possible, then, to operate these devices in one's own pro g ram by simply using a standard calling sequence.
8.1.2 MSOS
Under MSOS core is divided into two areas: foreground and background. The foreground is for s y s tern and process programs. System programs are those programs that make up the operating system, such as the job processor and drivers. Pro c e s s programs are those application programs that are most im-portant to the particular installation. For example, if the system is controlling a chemical plant operation, those programs monitoring the chemical pro c e s s are the pro c e s s programs. The pro c e s s programs and system programs usually have the highest priority and have access to the resources of the computer first.
Foreground is protected; this means the on-line process programs cannot be de-stroyed by programs in the background and they cannot be inadvertently brought into execution by background programs. However, b a c kg r 0 u n d programs may make use of protected routines such as I/O drivers.
Backgr ound programs are run in a batch mode (serially) and run at the lowest priorities in the system. Programs in the background are called jobs. Assem-bling, compiling, and loading are examples of such jobs.
8. 2 REQUEST PROCESSING
Three basic functions of the 0 per at in g system are to: (1) allocate core space to those pro g ram s that want to use it, (2) communicate with the outside world, i. e., supervise I/O operations, and (3) allocate CPU time between the various programs. When a pro-gram wants one of these functions done, a request is made to the operating system.
*There are other options available.
8-1
8.2
Are que s t takes the form of a transfer of control to the module of the operating system that processes requests (the request entry processor, entry point name MONI) followed by words containing the necessary parameters for the particular request.
The entry ad d res s for MONI is always located in core location F4 so every request is initiated by an indirect return jump through F4. The return jump will provide the link-age necessary. The parameter string length is different for different requests:
54F4 RTJ ($F4) TO MONI
=1
Reques t codeand other parameters
In the first parameter word, bit positions 9 through 14 will be the request code. This is for all requests.
MON! saves the registers of the requesting program in a special core area called volatile storage and gives control to a request processor denoted by the request code in the para-meter list. This processor must return control to the request exit processor which re-turns control to the requesting program.
,r---.,
( ,
'----/
The 1700 ope ra ting system provides the user with up to 30 monitor requests; 20 are reserved for the operating system. However, they may be replaced by user-written pro-cessors when the system is initiated. The other 10 requests may be added at initialization by including in the resident load the necessary programs with the required entry points.
The number of possible request processors can be extended from 30 to 63 by reassembly.
C
Each request processor is a separate submodule and has a coded entry point with one of the following names:
T1
. : \,---.----
~- reserved for system use T20T21
:
~r--
_ _ _ _ available to usersT3J
The numerical part of each name is the request code. It corresponds to the value of an index to a table of request processor addresses contained in MONI.
MONI has these entry points as externals providing linkage with each appropriate request processor.
Since the numeric part of the entry point name for each request processor must corres-pond to its request code, a request code of 5 will provide entry through MON! to module T5.
8-2
c~
G
o
o
User
Requests
..
Request Entry Processor
...
...
::
I
T1I
c;J
I I~ I
8.2 Request Submodules
Users can asselnble an added request processor, as sign a request code to it, and affix the entry point with T followed by the number for the request code and incorporate it as part of the sys tem.
8. 2.1 Summary of Request Processing
Note that all requests begin with the return jump toMONIand that MONIdetermines which type of request it is by examining the request code in the first word of the parameter string. Each type of r e que s t has a request processor to which MONI g i v e s control, depending on the request code. When control is given to the request processor, several functions take place before control is returned to the requesting program.
It is important for the programmer to understand that a request only initiates action de-sired of the operating system. It does not do anything. In most cases, a request causes the des ire d action only to be put on a queue; control is returned i m me d i ate 1 y to the requestor at the next instruction beneath the parameter string.
For example, it is desired to write a message on logical unit 4:
REQ
RET
RTJ-
~
($F4) (Parameters for a write request on logical unit 4)~
Control is passed to MONI. MONI passes control to the Read/Write request processor which puts the request on a queue of other messages waiting to be printed on logical unit 4. Control then passes to the request exit routine which returns control to the requestor at RET. The message has not yet been written but it will be done in due time.
8-3
8.2.1
8. 3 REQUESTS
RTJ- ($F4)
/
request~;propriat~
~ TO MONI - - processor; R t
~ ~ "'Reque~s~
processor equesBack to
program
TOREQXT
gets on a exits queue
Figure 15. Flow of Requests
The following requests are included in the standard operating system:
READ * WRITE * FREAD*
FWRITE*
SCHEDULE TIMER EXIT * CORE LOADER GTFILE STATUS*
SPACE
RELEASE
)
Available to both foreground and background programs.
Available only to background programs.
Request processor modules for these requests must have the same residency as the job processor.
Available only to foreground programs.
INDIR is an indirect version of any of the listed requests.
The job processor can make any request.
*These requests are included in the utility system.
8-4
c)
o
o
8.3 System macro calls are available to generate the code for the requests under the macro ass em b 1 e r, which runs under MSOS. Codes for the requests under the utility system must be coded by the programmer.
In this chapter those requests that are available to b a c kg r 0 u n d programs will be dis-cussed. Those requests available only to for e g r 0 un d programs will be discussed in
Chapter 11.
Any of the allowable requests for background programs will be accepted by the operating system and put on the desired queue. They will not be rejected.
8-5
8.3
c completion address
s starting address of data block n number of words
m mode
rp request priority cp completion priority
ap address of parameter list p priority
u units f index
x mode of addressing indicator for c, s, n, f, and ap in STATUS a mode of addressing indicator for logical unit
RC
*For mass storage devices theprogrammer sets up two words following the request to contain the mass storage address.
8-6
r-.,
(
,'-_/
c
C)
8.3.1 8.3.1 EXIT Request - Request Code 5
The EXIT request is available only to background programs.
When control is to be given back to the job processor, the EXIT request is used.
This may be when the program has rea c he d a point where it has com pIe tel y finished its goal and wants to terminate itself or when it wants to give up control while waiting for an I/O operation to take place.
The EXIT assembles into two words in the follOwing manner:
I
0I
0001011 000000000~
RC = 5 54F4
OAOO macro call:
EXIT coded call:
RTJ- ($F4)
NUM $OAOO
Most of the examples in this chapter have at least one EXIT request; check them for" its use and assembly.
If this request were executed in a completion routine, normal processing of a job would resume at the 10 cat ion where it was interrupted. If this request was not
executed in a completion routine, the job is considered complete.
The EXIT request simply causes a jump to the dispatcher which could be accom-plished by:
EQU
JMP-ADISP($EA) (ADISP)
8-7
8.3.1
This would be abe t t e r way to code exits since it saves time and since protected programs cannot make EXIT requests.
In the background, the jump to the dispatcher can be used only under MSOS 2.0;
under 1. 0 it can only be used in the foreground.
8. 3. 2 Read/Write Requests - Request Code 1,2,4, 6
For peripheral equipment that more than one program may use, a standard driver for each is written and incorporated into the operating system. The programmer makes use of the driver when he makes a Read/Write request to the 0 per a tin g system. Read/Write r e que s t s are available to both foreground and background programs.
When the programmer wants to communicate with a peripheral device, he makes a READ, WRITE, FREAD, or FWRITE request. Reads are used when informa-tion is to be b r 0 ugh t into core and writes when information is to be transferred from core to the device.
When a Read/Write request is made, the transfer of data is only initiated. If the driver is busy working on another request, the new request is placed in a list of
When a Read/Write request is made, the transfer of data is only initiated. If the driver is busy working on another request, the new request is placed in a list of