CA1306310C - Distributed computer system - Google Patents

Abstract

ABSTRACT OF THE DISCLOSURE

A distributed computer system comprising a plurality of digital computers is disclosed. Unique bus means are provided within each digital computer and for interconnecting them into a distributed network. The CPU's of the digital computers are off-loaded by auxiliary seats of intelligence distributed in each computer, including a novel and flexible video display controller. An operating system is disclosed which cooperates with the computers in a manner which enhances distributed computing.

Description

`` ~306310 Application of Epstein et al . .:
~ . ~
~` l o Background of the Invention 1.1 Field Or the Invention -~ Thig invention relates to digital computers, and particularly to dig~tal computers adapted for use in a distributed data processlng system compri~ing andsharing load among a plurality of indlvidual digital computers.

1.2 Des~riptlon Or the E'rlor Art Digit~l computers in general are well known in the prlor art. Digital computerR have been employed ln "distributed computing networks" in which a plurality of computers are interconnected and are progra~med to cooperate on an overall data processing task lnvolving a related body of data and a related body.7 Or tasks to be performed thereon, with some computer3 doing some Or the ~rocessing and then passing results or status information to other of the computers which perform other Or the processlng.
~91 Using traditlonal general purpose computers in distributed computing networks has required that each computer perform a portion Or the networking runotlons (intercommunication, coordination, priority arbitration, etc.) in addition to its direct data processing work. With such traditional computers, it ~, has generally been neces~any to interconnect them by means Or their input/output 1 buses so that each views the others as I/0 devices and i8 thus responsible for r~, detailed contro} over all transmissions to and from them.

r ' .`

1.3 Su nary Or the IDventlon ~!
~ ~ .
j The computers of the present invention overcome the overhead-prone i drawbacks Or the prior art by provlding an architecture in which additional i -11- ,, `l 1306.~0 Application Or Epstein et al intelligence is provided at junction points Or the computer network, this intelligence being surficient to perform the networking overhead functions.
bus is provided for data transrers between each computer' 3 CPU and an intelligent I/0 controller; another bus is provided for memory transfers; another bus is provided for interconnecting the computers; an intelligent bus controller is provided to tranQfer from any to any Or the the three buses. Flow Or data and status information around the network is thuQ expedlted, and the CP~ Or each computer is rreed to devote its attention to direct data processing tasks. An ., .
intelligent controller i9 provided ahead Or the video RAMs to free the CPU Or detailed bitmap manipulation in support Or graphic dislays.

;~1 It i9 thus a general ob~ect Or the present invention to provide improved digital oomputers.
.'~
It is a particular ob~ect Or the present invention to provide digital computers that may be interconnected to form a highly efricient distributed computlng system.

Additlonal obJects and advantages will be apparent to one skilled in the art, arter referrlng to the descrlptlon or the preferred embodiment and the ~, appended drawings.

Brle~ Descrlptlon or the Dra~lngs ~'~

For olarlty, the rigure numbers are based on the number Or the section re~errlng to the rlgure. For example, rigures rirst rererred to in Section 1 are numbered in the "100" series, figures rirst rererred to in Section 2 in the "200"
Qeries, and so on.
~ i .
Flgure numbers 1 - 100 are not used.
.
Figure 101 (prlor art) i3 a block diagram Or a typlcal prior art general purposecomputer employed ln a dlstributed computer network.

~ ~ 130fi3~0 ~ Application Or Epsteln et al :, ~ ~ Figure 102 is a block diagram of the computer of the present invention employed ; in a distributed computer network.

Figure 103 i8 a block diagram of CPU 101 Figure 104 iQ a block diagram of IOC 202 Figure 105 is a block diagram of MC~ 201 Flgure numbers 106 through 200 are not used.
,, I Figures 201 through 235 pertain to MCU 201 and I-Bus 204:
.~, , .
Figure 201 depicts the flow of an even double-word 32 bit trangfer.

1 Figure 202 depicts the flow of an odd double-word 32 bit transfer.
l -i- Figure 203 depicts the flow Or justified 16-bit transrers.
,. ..
"~! Figure 204 depicts the ~low the un~ustified 16-bit transfers.

~i Figure 205 depicts the flow of justified 8-bit transfers ~, Figure 206 depicts the flow of un~ustified 8-bit transfers.
~.j ~ Figure 207 depicts the flow Or a block transfer.
,:
Figure 208 show~ the logical organization of glob~1 memory.

Figure 209 shows the makeup of a control word.

Flgure 210 is an overview of bus arbitrat~on ti~ing.

Figures 211a-211e schematlcally depict the bus arbltration priority ' ~' scheme.

; .

~ 1306310 Appllcation Or Epstein et al .~., '.:
Figure 212 is a schematlc diagram Or the bus arbitration priority wiring.
'.,, . . -', Figure 213 depicts an example of bus priority arbitration.

,~' Figure 214 iR a timing dia~ram of bus priority arbitration.

Figure 215 depicts a data format.

j Figures 216 through 223 are timing charts pertaining to bus arbitration and bus data transmission.

Figure 224 is a table of command encodings.

Figure 225 illui~trates the timing of the Bus Clock signal Flgures 226 through-234 illustrate the timing of var~ous bus control signals in relation to the Bus CLock signal.
':~
O Figure 235 shows the timing of various control signials relative to the ,`
power-up condition.
`:~
t Figure numbers 236 throu p 300 are not used.

Figures 301 through 315 pertain to the IOC 202 and LMB bus 203:

~I Figure 301 depicts data and address transmission rormats.

Flgure 302 depicts 32-bit memory storage formats.
. .j, Figure 303 depicts ~ustified bus transmission formats.

Figures 304 throu p 315 are detalled timing charts of various esamples of bus transmissions.
, ~ Figure numbers 316 throu p 400 are not used.

: ``

. ~ .

~306310 Appllcation Or Epstein et al , :- :
~ Figures 401 through 419 pertain to MBus 205:
, , Figure 401 depicts the addressing breakdown Or Memory 102.
, ! I j . , Figures 402 through 419 are detailed timing charts pertalning to Mbus t''~ 102.
:,, Figure numbers 420 through 500 are not used.

Figures 501 through 557 pertain to Video Control Unit 206:

~'. .
~ Figure 501 is a functional overview.
: I
Figure 502 depicts pixel data flow.

Figure 503 depicts character data rlOw.

-l Figure 504 depicts an embodiment utilizing a single Graphics Data ll Processor.

,~l Figure 505 illustrates tbe connections of multiple Graphics Data Processors.

~¦ Figure 506 illustrates the internal~ or a Graphic3 Data Proces~or.
:,,"j Figure 507 shows the skewing Or MBus llnes to Graphics Data Processors.

Pigure 508 illustrates the pin layout Or a Graphic3 Data Processor gate array.

Figure 509 lists the signals assigned to the pins Or Graphics Data ;`~ Processor gate array.
.1 .

'~! Figure 510 illustrates Graphics Data Proce ~or control of MBus lines.

, : ' ~ -15-' , Application o~ Ep~te~n et al Figure 511 list~ the Boolean functions that may be performed in the Graphics Data Processor.

Figure 512 llsts the functions that may be performed in the Graphics Data Processor.

Flgure 513 illu~trates decoding of the Plane Enable Register Or the Graphics Data Processor.

Figure 514 references the Plane Enable Register to planes controlled.
~1 .
Figures 515 through 525 illustrate various functions:

Fig. 515 EXTernal Read Fig. 516 EXTernal Write ``I Fig. 517 EXTern~l PLANE Read Fig. 518 EXTernal PLANE Write Fig. 519 INTernal Read Fig. 520 INTernal Write Fig. 521 INTernal PLANE Read Fig. 522 INTernal PLANE Write Fig. 523 Character Write Fig. 524 Character Write (1 bit/pixel) Flg. 525 Character XOR
:, :
Figures 526 through 531 are timing chart~ for the Video COntrol ~nit.

Flgure 532 i~ an overview of video memory co~figuration.

Figures 533A, 533B, 533C, ard 533D illustrate Screen Addre3s to Memory Address mapping.

Figure 534 illustrates CAS phases in ~ideo Memory.

Figures 535 to 554 illustrate the decoding of various functions:

:.~
..1 ' ,~, ~ ~ Applicatlon Or Epstein et al , , .
Fig. 535 LAR to MBus address mapping Fig. 536 "OTHER space" decoding Fig. 537 LALU Register Fig. 538 PLANE ENABLE Register Fig. 539 Foreground Register Fig. 540 Background Register Fig. 541 Mouse~Table* Double Word Fig. 542 Host Wrlte COM DATA Register Fig. 543 MOUSE COM~AND
Fig. 544 PALETTE LOAD COMMAND
, Fig. 545 NMI ENABLE/DISABLE
Fig. 546 BLINE ENABLE/DISABLE
Fig. 547 Mouse double click delay Fig. 548 Echo Mode Fig. 549 Manufacturing Test Mode Fig. 550 COM STATUS Register Fig. 551 ~EYBOARD Register Fig. 552 LED Register Fig. 553 PI~EL ENABLE Register Fig. 554 "NORMAL spoace" decoding ;'~
~i~ Figure 555 depicts the Pixel Address Path.
~ .
Figure 556 depicts the Rerre~h/Transfer Address Path.
"
Flgure 557 illustrates data alignment.

Figure numbers 558 through 600 are not used.
`.1 .
Flgures 601 through 617 pertain to Operating System 501: ~
,~ .
Figure 601 depicts the operating ervironment.

Figures 602A, 602B, and 602C expand on the operating environment.
~ ''~ ' .
~ Figure 603 depicts the tree-structuring of proces~es.
,~ .

~ 17-"`'`1 ~ ~

:: ~

~ Application Or Epsteln et ~1 "~
.,., .~.
Figure 604 depicts the form Or the Argument Block Figure 605 illustrates a Deflection Call Sequence Figure 606 illustrate~ a call recelving sequence.
, Figure 607 deplcts the Entity Environment.

;~ Figure 608 is an overview o~ the Transaction Service.
- i ~ ~ Figure 609 shows the structure Or the Transport Service Task.
-. ' Figure 610 shows outgoing data flow.
,:' Flgure 611 shows incoming data ~low.

Figure 612 illustrates the form Or mesisage burfers.

, Figure 613 shows the flow involved in a transaction.
.;
Figure 614 illustrates a Receive Flcw.

Figure 615 illustrates a Send~Reply Flow.

Flgures 616 and 617 are state diagrEms for examples Or typical use Or Operating Syistem 501.

1.5 Over~iew Or Detailed Description .

, :
1.5.1 Prior art: -Rererring to Figure 101, which is a bloc~ diagra~ Or a typical prior-art ~`~ computer employed in a dlstributed computer networ~, Central Processing Unit j ~

~ 18-,~b ~. ~3063~0 Applioatlon of Epsteln et al (CP~) 101 is the baslo ~eat o~ intelligence in the computer and, as is indlcatedby its being deplcted at the hub of all the other elements, i9 called upon to control all informatlon transfers between those other elements.
"
CPU 101 is connected to memory 102 by memory bus 103, and must control all transfers over memory bus 103. System console 104 connects directly into CPU101, which must control all transfers to system console 104. CPU 101 ls connected to the extern 1 world by I/O bu~ 105, which connects to I/O controller~
108, through which transfers may be made to I/O devloes 109; commurications controller 106, through which transfers may be made to communication lines 107;
and intercomputer controller 110, through which transfers may be made to other computers 111 compri~ing the distributed computer network. The controllers 106, 108, and 110 may be provided with some limited intelligence to control low-leveldetails of trans~ers e~fected through them, but CPU 101 must provide all high-level control, ~etting up the controllers and overseeing returns of status informatlon from them.
, Alternatively, intercomputer bu~ 112 may be provided to interface with :!
other computers 111; this may relieve some of the load on I/O bus l05, but does O nothing to eliminate the problem of overhead on CPU 101.

Vldeo RAMs 113 may be provided to contain "bit maps" of screen lnformation for user terminal~. CPU 101 provides bit map data and stores it in ~1 the RAMs i~ a form in whlch it may be displayed on u^~er terminals.
:'1 '~1 1.5.2 Over~ ot the Fe~ent in~ention:

Referring to Figure 102, an overview block diagram of computers of the pre~ent invention employed in a distributed computing network, it i9 seen that CP~ 101 is no longer configured at the hub of all the other elements. Over LocalMemory Bus (LMB) 203, CPU 101 can communicate with integrated I/O controller (IOC) 202, and memory control and I-Bus lnterface (MCU) 20f, both of whlch contain sufficlent intelligence to oversee their respective functions without close supervislon by CP~ 101. MC~ 201 can establlsh connection between LMB Bus 203, IBus 204, and MBus 205, passing data from any one to any of the other two.

., : i :

1306~310 Application of Epstein et al ~ .
Communication between computers of the present invention configured as a dlstributed system, is effected by memory references. All memory locations within the distributed system are accessible to any CPU-- a CPU may read from awrite to a memory location associated with another CPU on the distributed systemwlth the same facility with which it may access any of the memory locations as~oclated with itself. All memory access requests from a CPU 201 are passed over LMB bus 203 to MCU 201, which determine3 from the memory address whether the desired location is associated with the local computer (the computer containing the CPU and MCU) or one of the other computers comprising the nstwork. If the former, MC~ 201 accesses the local memory 102 tor video RAM 113, a~ appropriate)over memory bus 205 performing the requested read or write and obtaining data from CPU 101 over LMB bus 203 (if a write) or passing data to CPU 101 over LMB
bus 203 (if a read). If the latter, MCU 201 passes the request over I-~u3 204 whence the MCU 201'8 of all other computers on the system examine the memory address; the computer having that address within its local memory performs the ~-` memory access, the data being passed over I-Bus 204 between the ~CU 201 of the oomputer having the memory address and the MCU 201 of the requesting computer.
This feature (re~erring briefly to Figure 101) eliminatcs the prior-art need to have an interoomputer bus (112) connected to and overset~n by the CPU.

An arbltration scheme is provided to ensure that no computer can monopolize the I-Bus and that no computer can be deprived of the use of the I^Bu~. This scheme is based on a rotating priority, wherein the computer that has Just used the bus ls eivsn lowest priority and must wait till other requesting computers have used the bus before it can-use the bus again.

Inte8rated I/O controller (IOC) 202 contains a microprocessor and is provided to relieve CPU 101 o~ detail-level 07ersight of data transfers between the computer and I/O devices 109, and communication lines 107. System Console ; 104 i8 grouped with other user terminals, and is does not occupy the special role it had in prior-art machines.

LMB bus 203 is provided so that communication between CPU 101, IOC 202, ~ and MCU 201 can take place without contention from any of the memory devices 102 2`~ or 113. Rererences to memory 102 or VRAMs 113 are "passed through" MCU 201 from ~i ~, .
~i -20-,- 1 ~ ` {

~: ~306310 Applicatlon Or Epstein et al .
LMB Bus 203-to M-Bus 205. Rererences to memory locations of another computer ofthe distributed computer network are "passed through" MC~ 201 to I-~us 204.

Video Control Unit (VCU) 206 is provided ahead of the video RAMs 113 to relieve CPU 101 of much Or the detailed work Or modifying bitmaps for controlling displays on user terminals.

Video Expans$on Unit (VEU) 207 may optionally be provided to expand the pixel size from 8 to 24 bits. VEU 207 includes additional V~AM chlps, but does not result in the creatlon Or more VRAM locations-- it merely expands the slze of the existing locations.
~' .
An operating system (not shown on Figure 102, to be discussed in detail in Section 6) ls provided to facilitate user access to the features provided.

In ~ummaryt the computer Or the present invention is well suited to distributed processing applications, from two standpoints: one, MCU 201'9 ability to resolve memory requests and honor them regardless Or whether the desired memory location exists in the requesting computer or some other computer1 Or a network racilitates interconnection and load sharing by a group Or several Il computers; and two, organization within each computer orrloads functioLs traditionally perrormed by the CPU and distributes them to other areas Or the 1 computer (IOC 202 to control I/O devices, MCU 201 to handle the details Or memory -` acoesses and intercomputer communication, VCU 206 to manipulate video bitmaps).

1.5.3 O-errie~ Or the Prererred Eobodiment In the present embodiment, each computer is a 32-bit computer and is embodied on a singie 15nx15" printed circuit board. Each board contains its ownLNB Bus 203 which does not leave the board. Each board has a connection to I-Bus 204. Each board h~ a Memory Bus 205 which may leave the board and connect to , optional expansion memory and video memory boards; up to 2 MBytes Or memory may ' t be accommodated on the computer board and are connected to Memory Bus 205;

~306310 ` Application o~ Epstein et al ~;, ' , addltional memory and video memory boards may be connected to the computer board's Memory Bus 205 to expand each computer's memory capacity.
;
Up to sixteen such computers teach wlth associated memory and video memory boards) may be accommodated in a single cabinet, the cabinet including a nbackplane" comprising sockets into which all the boards are plugged, and permanent wiring interconnecting the sockets. I-Bus 204 is made up Or backplanewiring and interconnects all the computer3 plugged into the cabinet to form a distributed computer network.

The sixteen computers may share a tot~l memory space Or 512 M~ytes. A~
described above, any Or the computers may access any location Or the 512 MBytes,which may thus be regarded as a "global address spacen.
~.
Figures 103, 104, and 105 together comprise a block diagram Or one computer board, with CPU 101 depicted on Figure 103, IOC 202 depicted on Figure 104, and MCU 201 depicted on Figure 105.

Rererring to Figure 103, the CPU portion (CPU 101) 's a 32 bit computer which execute3 microinstructions at a 160ns ma~or cycle speed. It is controlledby a 64 bit microinstruction and uses pipelining techniques for enhanced perrormance. All data paths, registers and standard accumulators are 32 bits l wide~ while the FPU registers and runctional units are a full 64 bits wide.
~1 `~1 CPU 101 uses two lnternal non-archltectural buses, A BUS 358 and B BUS 359.
`I These buses conneot the rour maJor subsections Or the computer: MIP
~ ~Microsequencer) 366; ATU (Address Tran~lation Unit) 353; ALU (Arlthmetlc and ;~ Logic Unit) 352; and FPU (Floating Polnt Unit) 351. The B BUS is mainly used for transrerrlng logical addresses rrom the ALU to the ATU after address calculations ~I have been made. The B Bus also provldes a path to the hardware Referenced and ~l Modified Bit logic 356. The A BUS is primarily used to move data rrom me~ory 102 i;~ (obtained over L~B bus 203, to be disoussed below) through the MIP 366 to the ALU -352. The A BUS is additionally used ror loading and storing the Floating Point Accumulators (FPACs) reslding ln FPU 351.
i~' ~, ~`-r, - 22-3063~
Application of Epstein et al :
The CPU communicates wi$h other sections Or the board via the LM8 Bus 203, RD bus 362, and EA Bu~ 361. All memory requests are directed through LM8 203 to MCU 201 where the request is either granted locally (if the memory locations are in the local space), or are redirected to the glob~1 memory bus (an I-Bus request). A "Read Bus" and "Write Bus" mode is provided on the LM8 which allcws the CPU and the IOC to communicate without any memory response or interference. The I-Bus type request provideQ the path to attached computers and intelligent I/O servers.

The XD and EA bu~es allow IOC 202 to initialize CPU 101 by dlagnosing, loading and verifying CPU Microcode Control Store 369. These are non-architectural buses; that is, they support internal, underlying functions and do not directly bear upon the execution of any user-invoked runctions. The XD is a bi-directional data path which multiplexes its 16 bits onto and Orr or the 64 bit u~ord bus. The EA path is the address path for the Control Store 369 RAMs.
'I
CP~ 8lock Diagram Summary ALU- ALU 352 is a full 32 bit ALU inoluding 13 GP registers, a shlrt reglster and a self incrementing PC. Most operations are co~pleted in a 160ns cycle with the remainder Or operations requiring 240ns. It is j implemented in a 135 pln PGA package.
`" MIP Microlnstruction Processor (MIP) 366 is a 15-blt ~ pipellned microsequencer along with an instruction `~l prefetch unit (enqueues, cracks and dispatches on macro instruction~), the MY Architectural Clock, the Real ~- Time Clock (RTC), and a memory data unit whlch accepts i~ data from the local memory bus. The MIP contains : ~ selrtest logic and provides a test-OK pin which is checked on power-up. It is implemented ln a 179 pln PGA
package.
AT~- Address Translation Unit (AT3) 353 contains address translation and memory address logic (including address protection support) in addition to a 16 entry ATU cache.
¦ FPU- Floating Point Unlt (FPU) 351 is a 64 blt floating point ! computer chlp lncluding the 4 Floating Point Accumulators (FPACs~, a full double precision data adder with rounding, truncation, prescaling, exponent and normalization support. Thls chip rits lnto a small 64 pln PGA package. `
~.,. :
~3 ~ i ~ ~, , uStore (Micro~tore) 369 -a 16~ x 64 bit RAM eontrol store, including a parlty bit whleh is loaded 16 blts at a time. It eomprises 70ns 8Kx8 SRAMs.
loek Generation -a multiphased elock based on 80ns basie system cloek whieh generates a 160ns microcycle. A mieroprogra~mable stretch to 240ns i8 used for longer oPerations.
eratehpad 365 a 2Kx32 RAM area used rOr mieroeode temporary.ar,d oonstant ~torage area. It eompri~es 45n~ 2Kx8 SRAMs.
oeal Mem Bu~ Control (latches 354, 355, 364) Interraoe logic to ~atch the ATU and MIP memory eontrol si~nal3 to the LMB protocol. This interrace also lncludes hardware eontrolled refereneed and modified bits whieh ~upport up to 16 MBytes of loeal memory without ~ieroeode support.
uStore De-mux 370 Memory Portion Logle for loading the eontrol store via the XD Bu3.

The Memory portion Or the board eontains the main memory control unit (MCU 201) and 2 Megabytes of main memory 102 itselr. The MCU also provides the eontrol Or the MBus and the eontrol for the global I-Bus (to be deseribed below). The MBu~ is A1so the conneetion for blt mapped video sereens that are attaohed to the main memory addre~s spaee (~ee seotlon 5). The only eommunication path between CPU 101 or IOC 202 and MCU 201 is the LNB, deseribed ln detail in seotlon 3.

The Memory portion ls entirely eontrolled by two 8ate arrays: CMOS-MEM
gate array 561 and Bipolar-MEM gate array 562. Since the rormats and protocols on the varlou~ buses are eontrived to facilitate pas3lnt rrom one to the other, these two gate arrayq are basieally trar~ie directors and error cheeking devieeswhlch control l l the lnteractionq that take place among the LMB, and I-Bus and the MBus.

13063~0 Application Or Epstein et al The LMB and the I-Bus are the two busses that can initiate memory operations. The LMB initiates all local memory accesses while the I-Bus initlates all accesses Or this particular node from other global nodes. The MBus is essentially an lnternal bus to this memory portion which carries the actual address and data Or the local RAM's themselves. This bus is "rawn, unallgned, uncorrected data which is stored in the RAMs themselves. This MBus has expansion capablllty 80 that up to 16 Mbytes can be addressed by this MCU (the two gate arrays) without adding more control. Thus, the MBus goes ofr-board 90 that additional memory can be added either in the form Or standard DRAHs or in the form of memory mapped sraphics.
.
To illustrate the flow Or a memory aQcess~ consider a CPU reference. The rererence is initiated by ~he CPU via the LMB. The MCU (combination Or CMOS andBipolar MEM gate arrays~ recognizes the start Or the memory operation. It then makes a determination Or whether the rererence was a local reference - i.e. to this node - or a global reference. Assuming it was local, the M W generates the-~` proper RAS and CAS (row address and column address) llnes to acce~s the required data. (The RAS and CAS llnes are part Or the MBus, and will be discussed in detail in Section 4.j Elther the memory array cn the board ltself (2 Hbytes) oran external expansion memory on the MBus will respond with the data. The MCU now dlrects that data back onto the LMB and signals the oomputer that the data ls available. Ir the data required allgning or correcting, the MCU would have taken the data lnto the gate arrays themselves, manipulated it as required, and rebroadoast the data baok onto the LMB prior to signaling the computer.

~ ad the rererenoe been global - i.e. not for this node, then the MCU
would not have issued the rererence on the MBus. Rather, the MCU would have begun arbitrating and re-initlatlng the reference onto the I-B w . The responding ' I-Bua node will return aligned, corrected data back vla the I-Bus at which tlme - the MC~ will direct the data back onto the LMB, bufrering the data as necessary.
., :~

Memory Blook Diagram Summary The memory portion Or a computer board is deslgned around MCU 201 which comprises two 8ate arrays:
-, ~ ~ .

~ -25-., ~ . - - :

:
~ ~ ~ 1306310 ,~. .
Application Or Epstein et al This Fu~itsu CMOS C8000VH series gate array is implemented in a 179 pin PGA package. Its main runctiOns include: Error Detection and correction circuitry tcorrect all single bit errors and any touble bit errors that contain at least one hard bit failure); Refresh and - snipr control; Read-Mod~fy-~rite control; data alignment; interrupt and special function control.~
~ . .
~ipolar-MEM 562 This Motorola 2800ALS series gate array is an ECL
internal gate array. This primary MCU control chip is necessary for high speed response to memory requests.
The ma~or functions of this array is: Address recognition; Data flow direction; Bus arbitration (both i Bus and LMB); initial Address generation; and Error detection (correctlon is done in the CMOS array).
MBus 205 The Memor~ Data Bu~ is the common data path for transmitting data to and from all syste~ memories 102 (including the 2 Megabyte~ that can be on-board) and VRAM~ 113.
`1, LMB 203 ~`1 The Local Memory Bus is the communication path from the looal comput;er (CPU portion) and from the local I/O
portion. T~is is a specified bus interface which is - I recognized ~r the MCU and is described in detail in section 3.
~-' IBus 204 ~i This I-Bus is a global memory bus which connects computer ~ nodes vla a common memory space. Section 2 describes ,~ ' this bus in detail.
Main Memory 102 The Main Hemory block repre~ents 2 Mbytes of 256R DRAMs ~; organized into 512~ x 39 blts. The 32 bit data words and 7 ERCC blts implement a portion of the memory address space. It i9 two way interleaved to enhance consecutive ~ccess performa~ce. Additional off-board memory may be connected to MBU8 205; this may addition 1 main memory i 102, or YRAMs 113 for storing screen bit maps (see section 5).
~- Integrated I~O Portion i IOC 202 (Figure 104) i8 designed to 3upport the base system I/O devices as well as SCP tsYstcm console proce~sor~ functions. This subsystem, run by a . . .

.~, ~` 4 ;~, -26-~1 .

` 1306~0 ~:
Appllcation Or Ep~tein et al :.
microprooessor, i8 the only lntelllgent part Or the board upon power-up. Its SCP
functions include: booting the rest Or the system (including CP~ microcode load); acting as a system console computer during normal run time; and ; diagnosing the system on railures. The I/O function provides the board with device support for the basic integrated I/O derices. This includes:
- an SCSI (small computer standard interface) Bus Host-Adapter Interface 468 - an SA400 Floppy Diskette Controller 467 - an Ethernet IEEE802.3 LAN Controller 480 - Four RS232C Asynch Channels 459 (1 w/modem support) , :
- a parallel Printer Port 460 - a battery-backed-up Time-or-Boot Clock/Calendar 457 :,~ ,.. .
~t3i The Local Me~ory 8us Inter~ace is the primary communications ch~nnel between CPU 101, IOC 202, and MCU 201.
~j The integrated I/O subsystem is centered around the 80186 microprocessor 451 and its associated 16 bit uPAD (microprocessor Address/Data) Bus 465. The microprocessor co~trols the power up sequence by holding the CPU portion and i Memory portion or the board in Reset state. (This microprocessor is the sole `~ controller Or the system RESET signal whlch resets all IBus nodes as well as this oomputer node.) Uslng mlcroprocessor rirmware stored ln the power up PROMs 452, lt does a selr-check, verlrylng enough Or this section to read more ~ mloroproce sor rlnmware Orr o~ a disk into the ucomputer RAN Nemory. Any railure ~ ~-c to thls point will be displayed on the front panel LED 458 which is under control ~ Or the 80186.
:.y -.:
`;~ Once the uP Memory i8 loaded with a full complement Or firmware, a more ~i complete power-up diagnostic is run, including the MIP gate array selrte~t pin (see CPU seotlon), other CPU testing, memory testing and vldeo dl~play lndlcatlons. The microprocessor then boots ln host mlcrocode rrom the boot devlce (Floppy or SCSI Winchester) into the CPU control store using the XD and EA Busses. It then rinishes the power up diagnostic testing and starts the CPU.
:

~306310 Appllcatlon o~ Epsteln et al ' Durlng normal run tlme, IOC 202 serviceq devlces connected to it. All communication with CPU 101 takes place through buffer 484. CP~ 101 rorwards requests over LMB 203 u~ing the ~RITE BUS function to be explained below, which does not involve MCU 201 or memory 102 but which results in writing into buffer 484. The microprocessor does the interpreting, scheduling and device control Or these request3 in parallel to normal cPn execution. To aid in thi function, the IOC includes a DMA channel 476 directly connected to the LHB for non-host-assisted main memory accesses. In this way, the Integrated I/O
subsystem is acting as an independent I/O computer to the host. Data for outputare likewise placed by CPU 101 into buffer 484. Input data are placed in buffer 484, from which CiU 101 may read them over LHB 203 using the READ BUS function (explained further below) which does not involve MCU 201 or memory 102. The WRITE BUS and READ 8US runctions of LMB 203 eliminate the prior-art need ~re~erring briefly to Figure 101) to have an I/O bus and a memory bu3 both connected to and overseen by the CPU.

Integrated I/O Block Diagram Summary 80186 microprocessor 451 All the integrated I/O device~ are managed using the Intel 80186 microprocessor. The main purpose Or he ' microproce3sor is to rield I/O requests, supervise I/Odata trarric ~ provide I/O status on completion of a data ~i~ transrer. The microprocessor also Eives the systempower-up ~ diagnostic intelligen¢e with which to load/verify Control Store RAMs.
The 80186 microprocessor ~eatures include: a 16 bit data bus; 2 integrated DMA controllers and interrupt support.
It ha~ a 1 Mbyte address space which allows all the I/O
' `~ controller~ to be memory mapped as well as the CPU; Control Store. The 80186 will be run at 8 MHz in order ``3I to maximize its perrormance.
Power-up PROM 451 and N W RAM 453 The Integrated I/O portion contains two 2KX8 PROMs and a non-volatile RAM (32x8). The PRONs are used for power-up diagnostics and a Floppy/SCSI loader to complete the power-up procedure. The N W RAMs (non-volatile RAMs) are used to store configuration informatlon, serial numbers and LAN adtress information to reduce hardware ~umpers i ant repetltious user lnput.
uP Memory and Buffer 484 ~ ~ .
. ~, ` ' - 28 -.

-: 1306~,10 Appllcatlon Or Epstein et al .:, .
Thls 18 a 32 KByte shared memory area. Approximately two third~ of thls space i9 used for 801 code to control -j the LAN, I/O devlces, Host Interface, and SCP
functlonality. The remainder of the space i9 used for data buffering to lnsure high bandwidth burst data movement support.
The RAM consists of four 8Kx8 CMOS statlc RAMs with access times of 70ns. The bufrer 18 conrigured to be a 16Rx16 bit ~pace frcm the 80186JLAN side and 8Kx32 bit space from the Loc~l Memory interface side.
~; The buffer memory system will bs shared by LAN, Local Memory and 80186 DMA vla tlme slot allocation. Data is packed into the buffer ln DG format. (lower addressed bytes are leftmost). A byteswap/wordswap is performed at a 3et Or transceivers between these RAMs & the UPAD bus.
~ This allows the LAN & the 80186 to access the contents of 3 the buffer witbout having to perform software byteswapping.
~ LMB DMA Control 476 -~ Communication to the Local Memory Bus (LMB) is controlled by this part of IOC 202. The LMB provides a path both to main memor~ and to CPU 101. :
For oommunication to main memory, this section provides a direct memory aocess state maohine which does not require 80186 firmware control. A 9-bit DNA Double Word Counter 1 and an address pointer/counter is provided to facilltate the transfer. Eaoh memory access i~ either a double word (32 bits) read or double word Nrlte. By loading the DMA
Double Word Counter with a number between O and 511, up -to 1 page t2Kb) of data can be transferred at one time. ~ ~
This interface will support a transfer rate of 7.6 ~ -~2'; Mbytes/second.
Integrated I/O to CPU communication is handled by Special Read and Special Wrlte commands on the LMB (RX and WX).
(See Section 3.) (Nemory residing on the LNB will not ï respond to R~/WX commands which allow non-memory operations.) The I/O to CPU communication is acoomplished by the CP~ reading and writing to the uP
Memory and Buffer (see above) via RX and WX commands on the LMB. Blooks of data are loaded into or read from that buffer by the CPU which then signals the 80186 via ~ an interrupt line. The 80186 then processes that data ;~ block in an appropriate manner (specified by the data bloo~ itself), and, in turn, the 80186 will signal tbe acoeptance or completion of that block via a dedicated signal to the CPU which causes a micro level trap (microcode visible but not macrocode visible).

~ L
'~
, ~ .

.

:~ ~306310 Applicatlon Or Epstein et al Flop W Disk Controller 467 Support is provided ror two 5.25" Floppy Diskette drives. The target drives record data at 96 TPI and have a 737.28 KByte capacity. -The dri~es will be controlled by the Fu~itsu MB8877 Floppy Disk Controller chip, pac~aged in a 40-pin DIP.
The microproce3sor initiates all floppy disk operation3 while the MB8877 chip itselr perrorms DMA transrers between Floppy disk ~ the Buffer RAM area utilizing one the microprocessor's DMA ports. The Floppy controller has priority over the SCSI DMA Channel since the SCSI
tranfers can be held orf indefinitely.
,, The SMC FDC9229BT Floppy Interrace Chip, which performs the runctions o~ write-precompensation, digital data separatlon ~ head-load delay i9 u~ed in con~unction with the MB8877 chip.
`/ :
SCSI Bus Controller 468 The SCSI Bu~ Controller provides access to SCSI
compatible devices, particularly Winchester type disk ~i drlves and magnetic tape drives. The SCSI ~u~ Inter~ae, ~i5i acting in a Host-Adapter mode, allows up to 7 SCSI
Formatter cards (Controllers, CPU's, etc.O to be ~ connected together on the SCSI Bu~. This bu~ is 8 bit3 d wlde (plus parity) and trans~er~ data at a an ~! Asynchronous rate ~r 1.5 MBytes/sec. Drivers and i! receivers are slngle-ended.
¦ ` The controller chip i-~ the NCR SCSI Protocol controller.
¦ This controller per~orms DMA transrers between SCSI and the RAM Bufrer area by using one Or the 80186 DMA
¦ channels.

LAN Controller 480 The IEEE 802.3 CSMA/CD Loc~l Area Networking protocol is ¦ - supported. This communications protocol ls rated at 10 ; - MBit per second utilizing coaxial cable. ~p to 100 ¦ statlons may be connected together using a miximum cable length of 500 meters. It i8 lmplemented using the Intel 82586 LAN Controller ~ the SEEQ 8023 Manchester Encoder~Decoder.
.
The Intel 82586 LAN controller chip fully implements the IEEE 802.3/Ethernet Data Llnk speci~ication. On-chlp ~ control includes DMA ~emory management and microprocessor j hold-ofr control allowlng it to operate as a cocomputer on the UPAD bus and using the same RAM Buffer as the i 80186. The SEEQ 8023 Manche~ter Encoder/Decoder completes the Ethernet interrace by connecting directly ¦ to the Intel 82586 on one slde and to the Ethernet transcelver box on the other 3ide.
~ j .

' -30-'`~` ' :, .

;~
i306310 ~ .
Applioation Or Epstein et al , ,~ . .
. ..
Ethernet node~ are identified by a distlnct 48-blt address. The high 24 bits are fixed for Data General Corporatlon at 08001B (~EX). The low 24 b1ts are set indiYidually with the board's serial number during the manuracturing prucess. This number is stored ln NOVRA~s The integrated I/O portlon supports 4 R æ 32C Asynchronousport~ 459 uslng two Signetics 2681 DUARTs. Each DUART
provides programmable reatures which include:
Independent baud rates; Data format seleotion (bits/char, stop bits and parity selection); duplex selectlon; and overrun detection.
Of the four ports, one is full-reatured, including modem control, a second 3upports hardware Busy, and the remaining two are simple, requiring ~ortware Busy control.
:
IOC 202 supports an 8-bit parallel printer port. Either Centronics type or Data Products type parallel devlces can be connected to this port.

Th Ricoh RP5C15 Clock/Calendar chip is used to provide ~-the system with the current time ~ date during the boot ~ -procedure. The l2V at 15uA required to keep this chip backed up while standard power is not applied must be 8upplled to the board via a backpanel pin. This will be provided by 2 AA cells found iD a user-accessible location. The Time of Day and Date will be accessed once during power up. The time is then kept track Or by ths ho8t ltselr Thi~ chip can be read only via the SCP once the 8ystem is up, but can be written under bost software or SCP control.

The 80186 directly controls the display Or a 7 segment LED located on the front panel 461. The decim2l point of the LED is a POWER-OK indicator and will be lit when the 80186 detects POWER-O~ as signalled by the power supply. Tbe 80186 firmware directly controls each Or the 7 segments Or the display which will be used to signal railures detected during the microprocessor~s diagnostic procedures.
. ~
Operating Systems :
, ~ -31-Appllcatlon Or Epstein et al . ~
Operating Syste~ (OS) 501 and the AOS/VS operating sy~tem (a prior-art operating system marketed by Data General Corporation) will both run on the system. OS 501, however, i8 the target system and thu~ will be designed to takeadvantage of certain reatures not currently supported in AOS/VS. The major sOrtware reatures include: ~ ~
- All 8it Mapped Graphic displays - ~NICORN lnterraces ror integrated Printers, Disks and Tape~
- Auto-Power-~p with automatic system generation, sizing, configurations and date/time I - I-Bu~ support Or attached computers and foreign operating system enviroDments - Extensive Windowing support ~;1 - LAN based transparent file and computer sharing ~33 - Hhltiple OP~S computer support AOS/VS will require some modirication in I/O device handlers. There will, however be a device code 10 and 11 emulator built into the hardware for compatlbillty. this emulator is neither efricient nor expected to be permanent,but rather, included to help in the transition away rrom the 10 and 11 !~` dependenoy.
., ;~ All standard sortware languages and higher level program applications will run unmodirled.

.
f ' ' ,' ~ 1 .
:: .
:

~-3 ``.`.i ~ 33~
`, -32-':"

130fi310 ~ Appllcation Or Epsteln et al ; 2. Det~led De~cription Or NCU 201 . .
The I-~US, or Interface Bus, is a 32-bit interconnection system for processors and memory. The I-BUS allows nodes (such as proces~ors and memory controllers) on different P.C. cards to talk to each other.
Physically, the I-BUS is a set Or wires connecting two or more P.C. boards in a single chassis. The nodes talk to each other (that is, send or receive data) over these wires. Each node has its own MCU 201, which forms the lnterface to the I-BUS.
This interface takes the data and data requests from the node and translates them into the proper protocol to send on the I-BUS. The protocol determines what can be sent, when and where it can be sent, who can send it, and how it can be sent.
'`'`1 :
This protocol is what make~ the I-BUS conceptually unique from any other data bus or set of Ju~per cables. It ', i9 intended to achieve the following:

+ One common backpanel syste~ for all processors + Transfer capabillty for 8 bits, 16 bits, 32 bits, and 256 (8x32) bits + Plpelining of priority arbitration + ~quality in bus access for all nodes + Able to support up to 16 nodes + High transfer rate + Multiproces~or and attached processor support Fault detection + Simple to reconfigure + Designed to work as extended memory bus in MV arohitectural environment 2.1 Sectional Overview ~' ~306310 Application Or Epstein et al Definitions ''", To aid in understanding the following information, a li~t of oommon terms and their definitions is given below.
;, Node An entity conneoted to the bus that drives and/or ~> monitors signals on the bus llnes.
Baokpanel ~¦ A p.c. board that runs parallel to the back of the card -~'l cage. It contain~ the interconnections between the ~;~i indlvldual cards as well as the sockets into which the edge ;~ oonnectors on the cards are inserted.
Slot ~ A location on the backpanel into which a p.c. card is ; lnserted. A node can occupy more than one slot, but each slot `1 ¢an belong to only one node.
Arbitration sing a priority system to determine which node will be allowed to use the bus next when two or more nodes request ~l the bus at the same time.
-'i Master ~; The node that has gained control of the bus.
~ ~l j Slave The node responding to a command from a Master.
Requester A node that 18 requestlng use o~ the bus.
,. i ` ~ Transactlon One complete operation on the I-~US, usually involving trans~lsslon Or data ~rom one node to another.
Phase Several phases c~mprlse a transactlon. Each phase represents a specl~lc event durlng the transactlon, such as ~l an Arbltratlon Phase.
:`1 Perlod One full cyole of the bus clock slgnal.
~l Inter~ace The physical part of a node that 18 directly attached to the bus and i~ responsible ~or sending and receiving bus slgnals. The inter~ace usually acts as an intermedlary -. . .
" -34-". ..
,, r ~ _ 13063~0 Appllcatlon Or Epsteln et al `c - between the bus and a local processor or memory, ~-~ translating local commands lnto the necessary bus protocol.
;..
~,~;, .
~ 2.1.1 Purpose .
, ., - ' ' The primary purpose of the I-~US is to allow fast communication between indivldual processor nodes and distributed global memory in a 32-bit system. AD explanation of those partic~-lar goals stated in the introduction is li~ted belcw~
.~ - , .
:`'j ' ~ " ~, ~:
One common backpanel system for 1l processors:
; The one set Or interconnections on the backpanel will ; bandle all processors.
; I Transfer capability for ô bits, 16 bits, 32 bits, and 256 3 (ôx32) bits:
Bus instructionq will be available to transmit data in ~ the previously listed sizes.
;~ + Pipelining of priority arbitration:
Determination of which node will get the bus next can be done before completion o~ the current bus operation.
+ Equality in bu~ acee~s for all nodes:
No node can monopolize the bus;
No node can be deprived of the bus:
~sing a dynamic prlority system (instead of fixed priority, Every node is guaranteed periodic acoess to the bus.
j .
Able to support up to 16 nodes:
This is the ab~olute maximum for a single cha~sis system. Typical ~ystems will have fewer than 16 nodes.
+ High transfer rate:
~` The bus clock frequency is ôO ns. The maximNm transfer rate for single transfers is 25Mbytes~s and for block transfers is 44.4Mbytes/s.
+ Multiprocessor support:
The bu~q protocol supports multiple co-equal independent prooessing nodes.
r + Fault detection:
Byte parity will be provided with all data transmission.

, .
:
,'i, ```1 306;~10 ~ Applicatlon Or Epstein et al ~, . . .
Simple to reconfigure: -No ~umpers are required ln slots tbat are not filled.
Also special lnstructlons wlll make lt easy to determlne upon lnitlallzatlon the properties and capabillties Or each node on the bus.
De~igned to work as an extended memory bus ln prlor-art MV
architectural environment:
~' The I-BUS addresslng scheme is compatlble wlth the i~ physlcal addressing mode ln MV archltecture.
''I .' ~
.j -~i An efrlclent use of the I-BVS i9 ln a system where each node executes out Or its own local memory. Ir one or more processors requires an I-BUS acces~ for each operation, system ~;~l perrormance can be severely degraded. As will be discussed ln 8eotion 6, the operating system racllltates allo¢atlng data to the local memory Or the node where the programs accesslng that data most frequently are executing.
!~, i;, , 2.1.2 Signals .
~, .
2.1.2.1 Signal Groups ' :
Physloall1, the I-BUS conslsts or 61 lines. These are dlvlded Into three groups: data/address llnes, bus arbitration ~; llnes, and utillty lines. Below i9 a breakdown Or the three groups. (The ^ symbol appearlng before a slgnal name means that the signal is "low-truen.) .~ I
.j ~

`~i -36- ~:
.
,, :

- Application Or Epstein et al .
, .~, ~ Data/Address:
, .
32 ^DA<0-31> data~address llnes 4 ^PDAC0-3> byte parlty Or data/address lines 1 ^AV/^MM address valld~Master wait 1 ^SWAIT Slave wait 1 ^XV transaction valid ; Bus Arbltration:
16 ^BREQ<0-15> bus request lines ~ -1 ^B8SY bus busy ~tlllty:
1 ^ARBRST arbltration reset 1 ^BUSCLK bus clock 1 ^CACHE encache 1 ^PWRFAIL power fail 1 ^PWRUPRST power up reset total 61 ~:, 2.1.2.2 Data~Address signals There are 39 slgnal lines in the data/address group. They are as ' rOllOW8:

DA<0-31~ - Data/Address These are used for the aotual transmission Or the address and data.

PDA<0-3> - Parity These contain the byte parity 8enerated during data and address transmisslon.
`' ; AV/MW - Address Valid/Master Wait Thls is used by the Master to tell the Slave that an address is ~- present on the Data/Address lines.. !
: :.
SWAIT - Slave Wait This 19 used by the Slave to tell the ~aster that it is not ready for the next transmlssion Or data yet.
~.~
r ~
: ~
~ -37-:1306310 ; Appllcation of Epsteln et al ~ XV - Transaction Valid ,`' ;?J~ The Slave uses this to let the Master know that no error has , been encountered ln the processing Or the current reque3t.
i`~ Errors can include: bus parity error, illegal request, or multiple bit errors in memory.

~j 2.1.2.3 Bus Arbitration Signals `f, There are 17 lines in the Bus Arbitration group. They are as follows:
,t: ~ .
BREQ<0-15> - Bus Request - These are used to request the bu3 and to determine who will be granted access to the bus next.
i, - BBSY - Bus Busy ~; This i9 used to indicate that a node is currently using the bu~.
It is driven by a Master.
. .1 .
.,~ . .
~, 2.1.2.4 Utility Signals ~.
! There are ~ive utility signals on the I-BUS. They are a~ follows:
.~1 `^l ARBRST - Arbitration reset ~;~ This causes all nodes to reset their priority to the lnitlal value after startup.

BUSCLK - Bus clock ~, This signal is generated by only one node and ls sent to all ~`¦ nodes. It is used to synchronize and clock all actlons on the I-BUS.

~ CACHE - Encaohe .,~
. .
.,.

-38- ~

.. 1 .

` ~

:~;
` i~06~0 Application Or Epstein et al .... .
This is used to tag data as belng encachable for processors with local caches. ~

PWRFAIL - Power railed -This slgnal is asserted by the power supply when it i8 determined that a power 1099 has occurred that ls sufricisnt to arfect the bus.

PWRUPRST - Power up reset This is provided by the power supply to lnform the nodes that the system has ~ust powered up.

2.1.2.5 Signal States All slgnals on the I-~US use "low-true" implementatlon. That is, a slgnal is consldered activated, asserted, or representing a "logic 1" when there is a voltage pre~ent corresponding to a low TTL voltage level. A signal 19 considered released, de-asserted, or representing a "loglc 0" when there is a voltage present corresponding to a hi8h TTL voltage level. ~hen rererring to the actual electrical content Or the signal line, the ^ ~ymbol will appear berore the signal name indicating its low-true status. When describing the logical contents Or the signal line (1'8 and 0'9) the ^ will not appear with the slgnal name.

2.1.3 Address/Data 2.1.3.1 Normal Address Space As will be described in section 2.5, "Commandsn, command encodings are provided to access "normal spacen, and "specl~l spacen. All system memory is part Or normal space.

~- 1306310 ,,~ .
r Application of Epstein et al ;~ The I-BUS operates in an addressing mode corresponding to that Or the physical addressing mode Or 32-bit prior-art ~ECLIPSEn*systems manuracturedby Data General Corporation. Physical addresses generated by ECLIPSE
address translators correspond to the addresses that appear on the I-BUS.

The I-BUS has a limit Or 512M bytes Or normal addressing range. This is typically organized in double word format; that is, each memory location can be thought of as being 32 bits wide (two t6-bit words). Individual bytes and single words can be accessed as well as double words and blocks Or 8 double words.

The 512M bytes Or addre3slng range is divided lnto 4096 segments Or 128K bytes each. Each node on the I-~US will be assi8ned one or more Or these se8ments ror its own address ran8e. Ir a node has less than 128K bytes Or physical memory available, lt wlll be assigned more than it actually needs. In that case, it will be up to the requestlng node to kncw the correct range.

Asslgnment 19 done by a slngle de~lgnated Master node called a System Conflgurator Node. Asslgnment 19 done a~ter a node has po~-ered up and performedall necessary looal lnitlallzatlons. m e lnitial memory assi8nment usually remains with a node unless there i8 a power railure or a system reset.

It is not necessary that all 4096 segments get asslgned somewhere.
~owever, Master nodes must take responsiblllty ror generatlng valld destinatlon addresses.

.
All addresses are aocompanled by parity blts. m e data~address lines are dlvlded into 4 groups o~ 8 llnes wlth eaoh group havlng lts own oorrespondlng parlty llne. Parity llnes generate odd parlty for both address and data trans~lsslon.

2.1.3.2 Speolal Space Whlle system memory is, as descrlbed lmmedlately above, addressed as normal spaoe, the primary rea~on ror speolal space is to allow acoess to things * Registered trade-mark ~ -40-`:
~306~310 -` Application of Epstein et al i: .
s' .
.,,~ . ,.
such as proCeSQor registers, PROM, or static RAMs by assigning addresses to them. Special Space access wlll be handled through special commands. ~ata can only be read or written to Special Space in 32-bit even double-word format.

Each node's special space is addressed by a combination of the node ID
number and a 23-bit offset. Thus, each node has 8M (32-bit wide) Special Space addresses available, regardless of how much normal memory space addressing range has been assigned to it.

The upper 16 locations of each node's special space are reserved for certain interface registers used during I-BUS operation.

2.1.3.3 Data transmission Data can be sent across the bus 8 bits, 16 bits, or 32 bits at a time.
For 8 or 16 bits, the contents of the remaining data lines will be undefined.
The four parity lines generate odd byte-parity for data transl~ission in thesame manner as for address transmission. For 8 and 16-bit transmission, correct parity will be generated for all 4 bytes.

~ ach data transmisslon can take as long as needed. One control line is used to hold up the bus until the sender can place the entire data on the bus.
Another oontrol line is used by the receiver to hold up the bus until it is ready to receive the data.

2.1.4 Bus Arbitration Priority arbitration follows these rules:
1) When two or more node3 wish to use the bus at the same time, the node with the highest priority is granted access ririst. If only one node is requesting the bus, it is granted access regardless of its current priority.
2) The last node to access the bus becomes the lowest priority node. The node following lt becomes the highest priority node.

.
~ ~` 1306310 ;;~.
Applicatlon of Epsteln et al * 3) PrioritieQ are assigned from highest to lowest with the same - progression order as that of the slot numbers ~0,1,2.. 15). Slot O
always follows slot 15 on wraparounds (e.g. 5,6..15,0,1..4).
4) Each access can conslst of one of the following:
A single 8, 16, Or 32-blt transfer A single block (8x32) transfer A bus locking operation (such as a combination read-wrlte) Below ls an example of a sequence Or requests and the res~lting arbltrations.

2~ode(s) requesting Current prlority Node granted access idle 6,7.. 15,0,1.. 5 ---3 6,7.. 15,0,1.. 5 3 3,5,6 4,5.. 15,0,1.. 3 5 3,6 6,7.. 15,0,1.. 5 6 3 7,8.. 15,0,1.. 6 3 idle 4,5.. 15,0,1.. 3 ---0,1 4,5.. 15,0,1.. 3 1,2.. 15,0 2,3.. 15,0,1 ldle 2,3.. 15,0,1 ---Immedlately after initialization, the node in slot O will be the lowest prlority node. It is not necessary to have all slots filled ln order to arbitrate properly. Any unused slots will be ignored during priority arbitration.

Priorlties do not change when the bus is idle.

2.1.5 I-PUS Operation .

' ', ' ~. ' "'...... ~ `' : ' `~:

~306310 Application Or Epstein et al 2.1.5.1 Node Register Requirements ,..
; Each Or the nodes on the I-BUS are required to have several reglsters available for access by other nodes on the bus. m ese registers are used to ~tore I-BU$ specific lnformatlon. m e registers are asslgned address locations in speclal space. They are then acce~sed through normal special space commands. Since most of these registers are less than 32 blts wlde, they are returned ln the low order DA lines with the upper lines ignored.

Many of these are control registers and not true memory locations.
Some have restrlction~ on global acceqs and some perform special functions when written to. m ese special characteristics are summarized in the following register descriptlons: `

Memory Base Regi ter (Location 7FFFFD) This contains a 12-blt number that corresponds to the starting segment Or addressing range for that node. m is is read/write ~ccessible to any Ma~ter.

ID register (Location 7FFFFF) This oontains a 16-blt code for the type Or board that the node represents, for example: processor, memory, etc. Thi3 is read aooessable to ary Master (writ are undefined).

Node Number Register (Locatlon 7FFFFC) This contains the 4-bit node number assigned to the interrace when it powered up. All special commands are addressed to a node by its node number. This is read accessible by any Master (writes are undefined).

Memory Size reglster (Locatior. 7FFFFE) A 12-bit register containing the local memory size in 128K-byte blocks. This is read/write accessable to any Master.

Interrupt register (Location 7FFFF8) 1306;~10 `: .
~ Application Or Ep~teln et al :
-~ A 16-bit register for interrupt requests from other nodes. Each bit can represent an interrupt request from a node with the corresponding slot ID. This is read/write acce~sable to any Master.
Writing a "1" to any bit will set that bit, whereas writing a "0" will bave no effect.

Mask-out register (Location 7FFFF7) A 16-bit register for bits to mask out those Or the Interrupt register. Thls is read/write accessable to any Master.

Status register (Locatlon 7FFFF9) A 16-bit register conta~ning status bits for things such as initl~1izatlon, hardware resets, and errors in transmission or commands. Thi~ is read/write accessable to any node. Writing a n1" to a bit will clear that bit, whereas writing a "0" will have no effect.

Data Latch (Not accessible in Special Space) A 32-bit register containing the last 32-bit double-word written to that node. This is read accessable to the local node only. It is written to impllcitly on every memory write to that node.

InterPaoe Status register (Location 7FFFFB) A 1-bit register indlcatlng whether or not the lnterface is fully funotlonal. This is read/wrlte accessable to the local node only.

Loopback Control Register (Location 7FFFF6) Any write to this 1-blt register will inltiate the Loopback dlagnostic sequence. This is used for testing the data path of the node. The next command to that node will use the data latch, that is, any data stored or read will be to or from this register. The node's data latching and address deooding cirouitry can be tested without disturbing any internal memory locations. This is read/write aooessible to any Master, however any command will reset the sequence, ; so there is no point in readlng the status of the loopback control register.

, .
:
~: ., - .~ ~-- ~ 13063~0 ` Appllcation o~ Epstein et al :
Global Access Enabled Register (Location 7FFFFA) This 1-bit register controls a node's acceQs to remote memory locations through the I-BUS. If this regi~ter contains O, the node is prevented from making any memory references on the I-BUS. If this reglster contains 1, the node ls allowed to make memory references.
This register does not prevent special space accesses. This register is read/write accessible to any ~aster.

2.1.5.2 Power-up The power supply determines when the individual nodes may begin bus initialization. A single node, determined by system configuration, begins sending the bus clock. Bus clock frequency is set at 80ns. ~hen the bus clock appears on the line, each node undergoes a self-test. If the self-test i~
complete, the node can place itself o~rline.
At ~his polnt, the system configurator node will begin issuing commands to the other nodes in the system. The system coDfigurator node will run a dlagnostic test to make sure that all nodes are operational. It then determines the memory requirements of each node and assigns the appropriate address ranga. It will also issue an arbitration reset that initializes the priorities o~ all the nodes (giving itselr the lowest priority).

The system coDrigurator node does not necessarily have to generate the bus clook signal.

2.1.5.3 Normal Operation Bus operation is divided into rour phases. They are as follows:

Arbitration phase Each node inspects the arbitration lines. The node granted access will proceed throu p the other three phases. This can overlap with the pre~ious Data phase.
Address phase The address ror the data (source or destination) is sent to the 1306;3~0 Application Or Epstein et al appropriate node.
Data phase The receiving node waits until the sender announces the presence o~
data on the bus.

Transaction validation phase The receiving node sends a signal to the sender acknowledging correct completion of the transaction.
Once initialization and memory assignment are complete, the I-BUS
becomes idle until requested. In idle state, the only sign 1 active i8 the bus olock.

Normal oPeration begins wlth one or more nodes requesting to use the bus. This initiates the bus arbitration phase, during which the highest priority node ls granted access. Bus operation then proceeds to the address phase. After the address ha~ been placed on the bus, ea~h node inspects it to see ir the address is within lts own assigned address range. Following the address phase come~ the data phase. This oan be as long as nece~sary to get the data on the bus and latched into the receiving node. Once this occurs, transaction valldation begins. If everything has gone correctly, a transaction va;id signal is sent and the bus operation is complete. If no other node has requested the bus, the bus returns to idle state.

The bus arbitration phase, address phase, and transaction validation phase must be accomplished in one bus olock period each. The data phase can take as many clock periods as necessary.

Three sequences Or events occur in typical operation Or the I-B~S:
single transrers, blook transrers, and bus locking operations. A single transrer involves sending one byte, word, or double-word from one node to another. A block transfer involves sending a blook Or 8 double words to/from a node from/to oonsecutive locations in another node. A bus looking operation oonsists of holdlng the bus to complete more than one transaotion without using additional arbitration.

A single transrer starts with an arbitration phase followed by an , :

13063~0 ~ Application Or Epsteln et al , address phase, data phase, and finally, a validation phase. A block transfer has the same arbitration phase and address phase but has a much longer data phase during which data is sent out 8 times, oDce for each 32-bit portion of the block transfer. Only one transaction validation accompanie3 the entire block transfer. Thu3, no attempt is made to point out which of the 8 double words contained the error.

A bu~ locking operation also lock3 the Slave processor out of its looal memory to prevent memory contention. The memory is not relea~ed until the transaction is completed. Only the node addressed at the start of the operation will be locked out. It 19 therefore important to restrict all transactions to the same node during a bus locking operation.

The transaction validation phase only indicates that an error has occurred in the preceeding transaction. It does not indicate the nature or location of the error.

2.1.5.4 Power Down/Powerfail The power supply provides to the bus a signal called PWRFAIL. When this signal is asserted (low), it indicates that the A.C. power has been interrupted for a signiricant period Or time. The handling Or this signal i8 striotly up to the individual nodes and configurations.

2.1.6 Commands 2.1.6.1 Data Transfer Commands The data transrer commands have been designed to support both processors that require ~ustiried data and prooessors that require unJustiried data. "Justifying" means that the data always comes from or ends up ~n the low order bits Or the DA lines. For example, a proces30r requiring Justiried ô-bit Applioation of Epsteln et al data would expect to see the data in bits 24-31 of the DA lines, regardless of which byte Or a memory location was the source or destination. A processor requiring an unjustified 8-bit data would expect the byte to maintain the same posltion (relative to the other three bytes) as in the 32-bit memory location.

For 32-bit transactions, there is no dlfference between Justified and unJu3tJfied. ~owever, there are two options. Data can be transferred in even double-word format or in odd double-word format. In even double-word format, the contents of an entire 32-bit memory location are transferred to or from the bus (see Figure 201). In odd double-word rormat, each memory location is effectively shifted by 16 bits (see Figure 202). The low order bits Or the address specified become the high order bits, and the high order bits of the next address become the low order bits. The other words of each memory looation remain unchanged.

For 16-bit transactions, there is a difference between Justified and unJustiried data. For ~ustified data, each half of a memory location must be transferred to and from the low order half of the DA lines (see Figure 203).
Only half of each memory location will be affected; the other half will remain unchanged. The high order half of the DA lines will be undefined ror these instructions; however, byte parity will be maintained for all bytes.

For unJustifled data, each half of a memory location must be tran~ferred to and ~rom the corresponding half of the DA lines (see Flgure 204). Again, only half of the memory location will be affected, the other halfOr the DA llnes will be undefined, and byte parity will be maintained for all bytes for each transaction.

For Justified 8-bit transactions, data from each of the four bytes of a memory location must be transferred to and from the low order byte of the data bu~ (see Figure 205). The remaining three bytes of the memory location areunchanged. The three unused bytes on the DA lines are undefined but byte parityis maintained for all bytes.

For unJustified 8-bit transactions, each byte must be transferred to , . " ~ ... .

1306;310 Appllcatlon Or Epstein et al ' :
and from the corresponding byte of the memory location (see Figure 206). The other tbree bytes Or the memory location are unchanged. The unused bytes onthe DA lines are underined but all must maintain correct byte parity.

Block transfers can also be accomplished. These have some restrictions. Block transrers move ei p t 32-bit double words to or from eightconsecutive memory locations starting with the location sent during the address phase. Only one address i8 sent out. The receiving node i8 then resporsible for incrementing the address internally. All transrers are 32-blt double-word aligned. All eight memory locations must be addressed to the same node. (See Figure 207.) 2.1.6.2 Special Space Acces~es Speclal commands are provided to allow node~ to access th~ngs other than normal memory space. These have the same data format as even double-Hord transrers. Each location in special space is addressed by a combination Or 4-bit node number and 23-bit node orrset. The Speclal Space commands are as -~
rOllOW8:

Read Speci~l Space The contents of the special space location or the node speciried are placed on the bus.

Wrlte Spec~al Space The value on the bus is loaded into the approprlate speclal space location Or the speciried node.

2.2 Addressing ~306310 Appllcatlon of Epstein et al 2.2.1 Memory Organizatlon The physlcal addresses sent out on the I-BUS Data/address lines have an addresslng range Or 128M double words (512M bytes). This ~pace ls (logically) organized and asslgned ln segments of 32X double words each. Thu~ there ls a total Or 4096 t32~ double-word) segments available ln normal addres?~ablephyslcal memory space. (See Flgure 208.) 2.2.2 Memory Assignment Each node on the I-BUS must be asslgned one or more of these segments.
Asslgnment for all nodes i8 done durlng bus int?tialization, by a single nodedesignated the sy~tem config;rator node. It i9 the ~ob of this node to determine the memory sizes and requirements of each node and to assign approprlate amount~ Or address space. It is usually only done once, but it is possible to change memory assignments at any time.

Assignment is done through the Memory Base register present on each node. Thls reglster can be rram 1 to 12 bits wide. The value loaded ln this reglster represents the upper blts Or the addresslng range for that node. The wldth determines how much memory addresslng range will be assigned. If the node has a l-bit memory base register, it will be assigned half Or the available memory addresslng range (64M double words). If the node has a 12-bit memory base register, it will be assigned 32K double words Or addressing range.
This reglster is accessed by the system configurator through special space. If the node has a memory base register Or less than 12 bits, all unused bits will return a value Or 0 when read.

Whenever an address is sent out on the I-BUS, each node compares its memory base register contents to the corresponding upper address bits. Only one node will rlnd a match. That node wlll combine that value with the remair~ng address bits to point to a specific 32-bit wide memory location. The complete address is sent out during the address phase on DA lines 4-30. rne remaining bits 0, 1, 2, 3, and 31 are decoded to determine what action is to be -5o-Appllcation Or Epsteln et al taken. (For further lnformatlon on lnstruction decodlng, see sectlon 2.5, nCommand9 n . ) Although bit 31 i9 used to decode instruction types, for memory reference commands it always represents a word pointer within tbe particular 32-bit memory location. In mo3t cases, it is used directly with the other address bits to form a word address instead Or Ju~t a double word address.
Thi3 feature enhances MV compatability by allowing more direct usage Or physical addresses generated by MV address translators.

Figure 209 shows the contents and use Or the 32 D/A lines when an address 18 ~ent out.

The l~emory Base Registe is loaded and examined with special commands found in the "Commands" :~ection (section 2.5). The value3 loaded lnto it are subJect to the followlng restrictions: -~
- If multiple 32R-word segments are required for a node, the assignment must be a power Or 2 (i.e. 2, 4, 8, 16, 32, etc.3. Thus, if a node bas 6M bytes Or physical memory, it would be assigned 8M bytes Or addressing range. The upper 2M byte3 would be wasted space.
- Any assignment must be done on the corresponding boundary. For example, if you asslgned 8M bytes o2` of addressing range, you could only assign it on an 8M-byte boundary (ô, 16, 24, 32, etc.).
- No signments can overlap; no two node~ can have the same segment(s) assigned to each.
- The ~inimum assignment for any node on the I-BUS is 1 (32R double-word) segment.
Other hints and guidelines in assienment Or memory space:
- Speclflc nodes are not required to have specific segment numbers. Segment3 can be asslgned ln any order as lon~;5 a~ they don't violate the previous restriction~.
- It i9 not necessary tbat all segments be assigned.
- It is advisable to assign the addressing range requirements starting with the largest requlrements in the lowest addresses followed by consecutively smaller requlrements ln following addresses.

130fi;3~
Appllcatlon Or Epstein et al '.

When a node generates an address outslde its assigned range, that node's I-~US interface will request to use the I-BUS. To prevent memory rererences across the I-BUS berore memory assignment is complete, each node contains a l-blt Global Access Enabled register. If this register contains a 0, the node cannot make any memory rererences across the I-BUS. If thls reglster contalns a 1, the node 19 allowed to make I-BUS memory rererences.
Any node can make speci~l space accesses across the I-BUS regardless Or the status Or thls reglster. The global access enabled reglster is initially set to 0. When the system conrigurator node determines that a given node can access the I-BUS, it will set that node's reglster to 1.

This feature also allows for a node to be taken "ofr-line" during normal operatlon Or the I-BUS, ir it is determlned that the node ls not fun~tioning properly.

Example Or memory assigoment:

Suppose a system with the following elements:
4 small processor nodes with 4M bytes Or local memory each 1 large prooessor node with 64H bytes Or memory 2 graphlcs controller nodes with 1M bytes of memory each Asslgnment begins by determining how much space each needs. For this example, eaoh node has a memory size ln a power of 2. Each node also requlres more than one 32R double-word segment. This means that the asslgned addressing range will exactly rlt the available physical memory. The large processor node has a memory size that requires 512 segments. The sm~ll processor nodes requlre 32 segments each, and the graphics controller nodes require 8 segments each.

Since the large processor requires 512 segments or 1/8th Or the total memory space, there are 8 asslgnments lt can be giveD. ~ois also means that the large processor will only have a 3-bit wide memory base register ~corresponding to the upper three bits Or the address). Similarly~ the small ~306310 Appllcatlon of Epsteln et al ; processors each requlre 1/128th Or the memory space and have ~-blt memory base registers, and the graphics processor requires 1/512th of the memory space and hss a 9-blt memory base register.

The large processor node can be assigned the first 512 segments ln memory, followed by the smaller processor nodes, and finally, the graphics controller nodes.

Node DescriptionMemory Base Register _____________________ _______________________ ~
0large prOQeSsor 000 1small processor 0010000 2small processor 0010001 3small processor 0010010 4small processor 0010011 5graphics controller 001010000 6graphics controller 00101000~
The system configurator node must know both the physical memory size and the memory base reglster size to determine both the valid addressing rangs and the memory assignment for each node. The sy3tem configurator node can reai the physical memory size directly from the memory size register ln specia~
space. In order to determlne the memory base register slze, it must first write "1'9" to all 12 bits of the memory base register. When it then reads that reglster, no's" will appear ln all unused blts.

2.2.3 Special Space Each node has 8M addresses available for Special Space assignment Each address can be a 32-bit wide location. Special Space is designed primarlly to enable the I-BUS interface to access different types of memory, or registers and memory locations not accesslble through norm~l addresslng.

For example, most Or the locsl memory ~pace will probably be ln the form Or dynsmlc RAMs ~DRAM3), and thus require that each address be broken up into a row and column address. For static RAM, PRoM, and processor register addresses, all bits are required at the same time.

~ ~306310 Appllcatlon Or Ep3teln et al '~ :

It was declded that the vast ma~ority of accesse3 to Speclal Space location~ will be single 32-blt lert-word-aligned transrers. By limiting our~elves to these only, we need ~u~t two commands ror Special Space; one command ror reads and one for writes:

~Read Special Space~ - takes the contents Or a 32-blt location ln Special Space and places it on the D/A llnes.

~Wrlte Special Space~ - takes the contents Or the D~A llnes and places it ln the specified Speclal Space location.

For further information, see the ~Commands" section (sectlon Z.5).

3ince Special Space is accessed by ~pecial command, lt dirrers from normal address space in that it 18 addressed by node number rather than ~ust an address. In addit$on, it requires the extra 4-bits Or command encodlng.

The I-BUS enables you to wrlte to any Special Space location. Ir that location happens to be ROM, lt will be up to the Slave to deal with the problem. There are no speclric error codes provlded for illegal accesses.

The upper 16 locations (7FFFFO-7FFFFF) ln each node~s special space are reserved for I-BUS interface register3. These registers, some Or whlch have speclal conditions on read~ and wrltes, are described in the ~I-BUS Operation"
section tsectlon 2.4) 2.2.4 MV Compatabllity The I-~US is deslgned to operate in the ~NV" series Or computers manuractured by Data General Corporation and to be compatible with their 32-bit archltectural environment. The pbysical addresses generated rrom an MV
Address Translator can correspond to the addresses that appear on the I-EUS. However, NV architecture ~llows ror 29 bits Or physical addressing range, whereas the I-~US yields only 28.

_~4-. ~
~ ~: 1306310 Appllcation Or Epsteln et al "

2.3 Arbltration Arbltration 19 determlning whlch node wlll be granted control Or tbe bus. A potentlal Master node rlrst requests to use the bus, tben arbltratlon occurs. Ba~ed on the srbltration scheme, the node may or may not be granted acces~ at that tlme. If the node ls not granted access, lt must re-submit its request at the next opportunity.

Arbitratlon lmplles that more than one node wlll request the bus at the same tlme. The system mnst choo~e which of the requeQters will receive control next. I~ only one requester ls present durlng an arbltration phase, it will be grantsd u~e Or the bu~.

2.3.1 Goals of I-BUS arbitration:

To gi~e unlrormly falr access to all nodes ln the system. A node should not be allowed to monopollze the system or repeatedly prevent any other node rrom gaining access to the bus.

Only one node at a tl~e wlll drive the bus; no slmultaneous access.

Arbitration can occur while the bus is being used so that arbltratlon overhead ls mlnimal.

There should be no ~umpers or reco~figuration required to accommodate empty slots in a system.

2.3.2 Arbitration Bus Structure 1306;3~0 - Appllcatlon Or Epsteln et al r~,~ The followlng slgnals are used durlng bus arbltratlon:
B~EQ<0-15> BUR Request Lines 0-15 AV/MW Address Yalld/Master Wait SWAIT Slave Walt BBSY Bus Bu~y BUSCLK Bus Clock Relatlonship Or the slgn~ls to arbltration:

Bus Request llnes 0-15:

A low-true signal on one or more Or theRe llnes lndicates to all Dodes that use o~ the bus is requested. The numbers Or the activated llnes are used in determining priority.

AddreRs Valid/Master Wait:
This is used to hold the bus ror a Master durlng data transmission.
Arbltration cannot start until this is released.

Slave Wait:
This ls used by a Slave to sus~end operation~ o~ the bus during data transmission. Arbitration cannot occur until thls i8 released.

Bus Busy:
This signal is used during bus operations that require more than one data transrer. It suspends a~y rurther arbitration cycles ~ithout afrecting any data or address transmissions. Arbitration cannot occur until this 19 released.

Bus Clock:
This is used to clock all actions on the bus. One clock perlod is equal t~ 80 ns. All clock periods start with the falling edge Or the bus clock. All actions on the bus take place uith respect to this ralling edge.

2.3.3 Initiation Or an Arbitration cycle ` 1306310 Appllcatlon Or Epsteln et al , Arbltration can only occur on a falling clock edge when all of the rollowlng are true:
^AV/^MW 19 high ^SWAIT is hlgh ^BBSY is high - -One or more bus request llnes ls low Arbltratlon starts wlth one or more nodes requestlng the bus. A node does thls by taklng the approprlate bus request llne low. Thls can be done at any tlme except during-the clock perlod immedlately following an arbltratlon cycle. At the beginning Or a clock perlod, if all the above oondltlons are fulrilled, arbltration wlll occur. ~ur~ng this same perlod, each requestlng node will oheck to see ir it is the highest prlority requester. Ir lt ls not the hlghest priorlty, it will take lts request line hlgh before the next ralllng edge Or the clock. After that, lt may again request use Or the bus.

If the node determines that lt ls the highest prlority requester, it keeps lts bus request llne down untll the next clock perlod tuntll the address is sent out~. It wlll then release the BREQ llne unless lt requires another use or the bus.

The olock period ~ollowlng an arbitratlon cycle 1B used to send out the address. Only the node granted acoess should be asserting its BREQ llne at thi~ time. I~ re than one BREQ line is asserted, an arbitratlon error ooours. Approprlate actlon must then be taken to prevent damage to the bus by oontention between node drivers (see the ~Arbltratlon Error~ sectlon).

A sample arbltratlon cycle ls shown ln Flgure 210. In thls example, there are two nodes requesting the bu3 (nodes m and n). Node m has the hlgher prlority and both nodes arbltrate correctly.

Note: The node granted access to the bus ls always the highest prlority requester, but not necessarily the highest priorlty Or all the nodes.

2.3.4 Prlorlty ~,i .
o Appllcation Or Epstein et al , ~ , .
2.3.4.1 Priorlty Assignment Referrlng to Flgure 211a, prlority order can be thought Or as a circular chain wlth a moving head and 16 links (corresponding to the 16 possible nodeq).
The chain head has the hlghest prlorlty and the chain tail has the lowest prlority. When the prlorlty changes, the entire chain rotates. Thu~, the relatlonshlp Or one node with respect to another remains constant, yet a node can be at any location in the priority order.

The order in which this (logical) priority chain is scanned correqponds to the order Or the node (slot) numbers. Node 15 will follow node 14 which will follow node 13, and so on, down to node O which will follow node 15. For exa~ple, ir node 3 had the highest priority, the chain would look as depicted inFigure 211b.

I~ the priority changes 80 that node 15 i8 the highest, the chain would look as depicted in Figure 211c.

2.3.4.2 Changing Priority Order WheneYer a node gains control Or the bu3, lt become~ the lowest prlorlty node. Priority changes ror all other nodes to maintain ordering. For exa~ple, ir node 7 used the bus la~st, the new prlority order would look as deplcted ln Flgure 211d.

I~ node 12 then was granted access to the bus, the order would change to that depicted in Flgure 211e.

2.3.5 Arbitration Logic .
Arbitration logic is distributed among all potential Master nodes in a system. The logic in each node is responsible only for that node. Its purpose is to tell the node when it has control Or the bus. ~o do this, it needs to 3063~0 .
- ~ Appllcatlon Or Epstein et al ~ ~ .
know the current statu~ Or the bus request llne~ as well as who acces~ed the bus last.

The organizatlon Or the bus request lines ls lmportant because lt slmpllfle arbltratlon. The bus request llnes are connected o~ the backpanel ln a clrcular manner slmllar to the priorlty ordering. Thls 18 shown below ln tabular form, and ls depicted schematically in Figure 212.
Node 15 Node 14 Node 13 ................. ....Node 1 Node O
^BREQO C-> ^BRE41 <-> ^BREQ2 <-~ ........ <-> ^BREQ14 <-> ^BREQ15 ^BREQ1 <-> ^BREQ2 <-> ^BREQ3 <-> ........ <-> ^BREQ15 <-> ^BREQO
^BREQ2 <-> ~BREQ3 <-> ^BREQ4 <-> ........ <-> ^BREQO <-> ^BREQ1 ^BREQ3 <-> ^BREQ4 <-> ^BREQ5 <-> ........ <-> ^BREQ1 <-> ^BREQ2 n n n n n n n n n n n ~1 \
^BREQ14 <-> ^BREQ15 <-> ^BREQO <-> ...... <-> ^BREQ12 <-> ^BREQ13 ^BREQ15 <-> ^BREQO <-> ^BREQ1 <-> ....... <-> ^BREQ13 <-> ^BREQ14 Note that for priority arbltration purposes, all node~ are of themselves ldentlcal; each node's place in the arbltratlon scheme is determined by the wirlng Or the socket into whlch lt ls inserted. Missing nodes (empty ~ockets) slmply appear as nodes that never assert thelr BREQO slgnals, and thus have no effect on prlority arbltratlon.

The arbitratlon loglc wlthin each node consists Or a set of 16 equations. These equatlons compare the current bus request status ~ith the prlority order. The current bus request status is taken directly fro~ the 16 bus request (NBREQ) llnes. The current priority order is taken fro~ a register ln each node in whlch ls stored the state or the bus request lines immediately followlng the last arbltratlon (OBREQ<0-15>). Any or all Or the current bus request llnes can be asserted. Only one Or the llnes ln each node'sprlorlty order register (OBREQ<0-15>) will be asserted (correspondlng to the current lowest prlority node, the last node that was granted use o~ the bus).

Each Or the 16 loglc equatlons represents a posslble prlorlty for that node (ex. hlghest, second hlghest, thlrd highest,....lowest). For each posltlon, the loglc checks to see lf any hlgher prlorlty nodes are also requestlng. If not, the node gets the bus.

.~
..
., 13063~0 Appllcation Or Epstein et al r The current bus request status llnes are shown as NBREQ<0-15>. The current priority order values (information on which node last had control Orthe bus) are stored in OBREQ<0-15>. Due to the interconnection Or the bus reguest lines, each node sees itselr on BREQO that is, ir ths node i~
reguesting the bus, it will see NBREQ0 a~serted; if the node u~ed the bus last, it will see OBREQ0 asserted.

The rirst equation is as follows (n- 1" means "gets the busn) 1) OBREQ15~NBREQ0 = 1 (~ = Boolean AND) It states that i~ the node on BREQ15 used the bu~ la3t, the current node (BREQ0) is granted access.

The ~ccond eguatlon looks like this:
2) OBREQ14~NBREQ15~NBREQ0 = 1 It states that if the node on BREQ14 used the bus last AND the node 04 BREQ15 is not ^equesting, the current node (BREQ0) is granted access.

The other equations are as rollows:

3) OBREQ13'NBREQ14~NBREQ15~NBREQO = 1 -4) OBREQ12~NBREQ13'NBREQ14~NBREQ15~NBREQO = 1 5) OBREQ11~NBREQ12-NBREQ13-NBREQ14~NBREQ15~NBREQO = 1 , .. . ..

6) OBREQ10~NBREQ11~NBREQ12-NBREQ13~NBREQ14~NBREQ15~NBREQ0 = 1 7) O~REQ9~NBREQ10~NBREQ11~NBREQ12~NBREQ13~NBREQ14'NBREQ15~N3REQ0 = 1 8) OBREQ8~NBREQ9~NBREQ10~NBREQ11~NBREQ12~NBREQ13~NBREQ14~NBREQ15~NBREQO = 1 9) OBREQ7~NBREQ8~NBREQ9~NBRE~10-NBREQ11'NBREQ12~NBREQ13-NBREQ14{NBREQ15~ -NBREQO = 1 13063~0 Appllcatlon Or Epsteln et al ~:.

NBREQ15~NBREQ0 ~ 1 .
11) OBREQ5~NBREQ6*NBREQ7~NBREQ8~NBREQ9~NBREQ10~NBREQ11~NBREQ12~NBREQ13-NBREQ14*
NBREQ15*NBREQO = 1 12) OBREQ4~NBREQ5~NBREQ6~NBREQ7~NBREQ8*NBREQ9~NBREQ10*NBREQ11~NBREQ12~NBREQ13-NBREQ14~NBREQ15~NBREQO = 1 13) OBRE~3~NBREQ4*NBREQ5~NBREQ6~NBREQ7~NBREQ8~NBREQ9~NBREQ10~NBREQ11*NBRE412 NBREQ13-NBREQ14*NBREQ15JN8REQ0 = 1 __ 14) OBREQ2~NBREQ3*NBREQ4~NBREQ5fNBREQ6~NBREQ7~NBREQ8~NBREQ9~NBREQ10~NBREQ11 NBREQ12~NBREQ13~NBREQ14~NBREQ15~NBREQ0 = 1 15) OBREQ1~NBREQ2~NBREQ3~NBRE4~NBREQ5~NBREQ6~NBREQ7~NBREQ8~NBREQ9~NBREQ10 . . .. _ NBREQ11~NBREQ12~NBREQ13~NBBEQ14-NBREQ15~NBREQO = 1 _ _ 16) OBREQ0~NBREQ1~NBREQ2-NBREQ3-NBREQ4~NBREQ5~NBREQ6~NBREQ7~NBREQ8~NBREQ9~
. . .
NBREQ10~NBREQ11~NBREQ12~NBREQ13~NBREQ14~NBREQ15~NBREQ0 = 1 Each node use~ the same ~et of equations.

An example ls shown ln Flgure 213. The example supposes that node 1 and node 3 both request the bus slmultaneously.

It will rirst be supposed that node O had used the bus last, and therefore has lowest prlorlty. This would mean that node 1 has OBREQ15 set (because BREQ0 of node 0 connects to BREQ15 of node 1), and that node 3 has OBREQ13 set (because BREQ0 Or node 0 connects BREQ13 of node 3).

~.~06310 Appllcation of Epstein et al ;' + Node 1 signals that it wants the bus by asserting its BREQO llne, denotedby the cross-hatching on Figure 213; the signal i8 applied (inter alia) to the BR3~Q14 terminal of node 3;
+ Node 3 signals that it wants the bus by asserting lts BR3~Q0 line, denoted by the "sawtooth" overlay on Figure 213; the signal is applied (inter alia) to the BREQ2 terminal of node 1.
+ In node 3, none Or the 16 equations above are satisfied. Particular attentlon is called to equation 3, which appears to be a candidate for satisfaction at this time because OBRE~213 i8 true in node 3. However, equation 3 i~ not satisried because BREQ14 i8 true in node 3. Node 3 is thus not awarded use of the bus at thls time.
In node 1, equation 1) (above~ is seen to be satisfied. Thus node 1 in this case is awarded use Or the bus.

Again supposing that nodes 1 and 3 request the bu~ simultaneously. we now suppose that node 2 has used the bus last. This would result in setting OBREQ1 in node 1 (because BREQO o~ node 2 connects to BREQ1 of node 1) and OBREQ15 in node 3 (because BREQO of node 2 connects BREQ15 Or node 3).

+ Node 1 again asserts its BR~QO line, meaning that node 3 again sees BREQ14.
+ Node 3 again asserts its BREQO line, meaning that node 1 again sees BREQ2.
+ In node 1, none o~ the 16 equations above is satisried at this time.
- Attention is called to equation 15), which looks likely because OBREQ1 is set; however, NBRE42 i9 also true which disqualified equation 15). Thus, node 1 is not awarded the bus.
+ In node 3, equation 1) is seen to be satisried. Thus node 3 is awarded use Or the bus.
2.3.6 Arbitration Reset 2.3.6.1 Reset at Power Up At power up (PWRUPRST is asserted), BRE~20 at slot 0 will be asserted by the power supply. This will allow each node to determine its slot ID, and node O will be the lowest priority node during the next bus arbitration.

. . . . . . . ..

.

~306~10 Appllcatlon Or Epstein et al ,., ; 2.3.6.2 Arbitratlon Error :-Two cases of àrbitration error can occur: multiple nodes attempt totake control Or the bus, or no nodes take control Or the bus. Both cases are detected at the start Or the address phase. At this tlme, tbe requester that thinks it has the highest priority will be asserting its bus request line. One and only one bus request line should be asserted. If multiple lines are asserted, or ir no lines are as~erted, an arbitration error has occurred. Any node that detects this should actiYate ARBRST and resynchronization will occur.

All potential Master nodes are required to check to see that at least one node has taken control Or ~he bus. Only a current Master (one who thinks it has control of the bus) is required to check ror multiple nodes attempting to control the bus.

The node with the clock generator is reQponsible for resetting the bus priority chains in the case Or an arbitration error. When ARBRST is asserted, thls node must also assert its BREQO line 80 that all nodes can reset their chains by registering the bus request lines. Hence the node with the clock generator will be the lowest priority node after every arbitration reset.

Arbitration error and reset are shown in Figure 214. In this example, nodes m, n, and p all request use Or the bus. Nodes m and n each think they have galned control Or the bus, thus causlng an arbitration error.

Note that there can be contention on the DA lines durlng the addre~s phase, since arbitration reset does not occur until after the address is sent out.

All nodes that detect an arbitration error are required to set the Arbitration Error flag in their own status registers before the start Or the ~ -next transaction. This rlag indicates only that an error has occurred. It does not indicate what type Or error occurred or which node was "at faultn.
This rlag can be read or cleared by other ma~ters with the special commands RSTAT and CSTAT. For rurther lnformation, see the "Commands" section (section 2.5).

: 1306310 Application Or Epstein et al :

2.4 I-BUS Operation 2.4.1 Hardware Requirements - -.
Each node on the I-BUS must satisfy certain hardware requirements.

2.4.1.1 Memory There is no set amount Or local memory required for an I-BUS node.
Local memory to a processor is accessible to the looal processor and any global Master durin~ norm~l operation. During local initl~llzatlon, however, local memory 19 accesslble only to the local processor.

2.4.1.Z Registers Each node on the I-BUS must have a set o~ hardware reglsters for control of various functions such as initi~llzation, addre~slng, and dlagnostlcs. Most of these registers have addresses in special space and are accessible to other nodes through the commands "Read Special Space" and "Wrlte Speclal Spacen. The function and organizatlon of the registers are described below:
::
Node Number Reglster Thl8 reglster 18 used by the node to determine when a special command i8 addressed to it. The 4-blt register i8 loaded during the `
power-up sequence with a value based on the pbysical slot of the node's interrace. The Node Number register is located in blts 28-31 of speclal spPce address 7FFFFC. It can be read by any Master through the "Read Speclal Space" command. Atte~pts to write to this locatlon after it has been lnitially loaded will produce urdeflned results.

Appllcation Or Epsteln et al ~, .

Memory Base Register This register derines the upper bits of the starting addreqs Or the memory range assignment rOr that node. That is, a comparison i9 done between the upper bits Or each address on the I-BUS and this register. If they match, the address is within that node. Thus, the rirst address in a given nodes memory space would be that number in the upper bits followed by all "o~sn. This register ls 12 bits wide, however, if a node has greater than 128K bytei~ Or memory, it will use less than 12 bits ~or comparison. In that case, only the bits used will be in the actual base register. Any remaining bits will hardware wired to "on. The Memory Base register is located in bits 20-31 Or special space address 7FFFFD.

On power up, the entire Memory Base Register is initi~1ized to "O's" until it is re-assigned by a system configurator node.

ID Reg~ster The ID register contains lnformation as to what board it ls (processor, me~ory, ...) (see Flgure 215). The ID register is located in bits 16-31 of special space address 7FFFFF. This location can be read by any Master, however, it is hardware configured on power-up and any attempt to write to it will produce underined results.

Memory Slze Register The Memory Size Register tells how much lo¢al memory i~
contained by this node. It is a 12-blt register located in bits 20-31 of speclal space location 7FFFFE.

.
Memory Size:
~umber Or 128K-byte blocks minus one ~3063~0 ~ Application Or Ep~teln et al . . .
Typical memory ~izes: (other sizes possible) DA<20-31> Memory Size (bytes) OoOoOOOOOOOO 128E

000000000111 1.OM
000000001111 2.0X
000000011111 4.0M
000000101111 6.0M
000000111111 8.0M
000111111111 64.0M
111111111111 512.0M (entire address space) Interrupt Register Each node that can receive interrupt request~ must have a 16-bit register with bits that can be set individually accordlng to the node number Or the Master requesting the interrupt. The Interrupt register is located in bits 16-31 in special space location 7FFFF8. A Master requesting an interrupt must write to the interrupt register location of the requested node. The Master must send a ~1" in the bit correspondiDg to lts own node number and "O's" in all remaining bits. Writing a "1"
will set the corre~ponding bit and writlng a "on will be ignored. It is the responsibility Or each node to clear lts own interrupt request re~lster looally; no interrupt requests can be cleared over the I-~US.

,.~,'.'.

1306~10 Applloation o~ Epsteln et al . ~ :
Node Numbervalues sent onBlt set in Or requesterDA 16 - 31Interrupt Register 0000 =>1000000000000000 => bit 0 0001 0100000000000000 bit 1 0010 0010000000000000 bit 2 0011 0001000000000000 bit 3 0100 0000100000000000 bit 4 0101 00000100000000~0 bit 5 0110 0000001000000000 blt 6 0111 0000000100000000 bit 7 1000 0000000010000000 bit 8 1001 0000000001000000 bit 9 1010 0000000000100000 bit 10 1011 0000000000010000 bit 11 1100 0000000000001000 bit 12 1101 0000000000000100 bit 13 1110 0000000000000010 bit 14 1111 OOOOQ00000000001 bit 15 Mask Out Register .

Each node that can receive interrupt requests must hsve a 16-bit Mask Out Register for masking interrupt bits. Note that MS~O is performed locally on the node receiving the interrupt request. The Mask Out Register is not a priority interrupt mask register any more.

The Mask Out regiæter is located in bits 16-31 Or speclal space address 7FFFF7. This register hss global write capability, thererore if a Master wishes to set or clear a bit over the I-~US, it must perrorm a read-modify-write operstion to ensure that the status Or the other bits remains unchsnged.

Global Access Enabled Register This 1-bit register controls a node's memory accesses on the I-~US. npOn power-up, this register is initialized to 0. The node cannot make sny memory accesses on the I-~US until this register is set to a "1n. This does not prevent a node from accessing special space.
The Global Access Enabled register is located in bit 31 Or specisl space addresc 7FFFFA.

~3063~0 Applicatlon of Epstein et al Status Register Each node on the I-BUS muAt contain one 16-blt Status Register.
Several bits in the Status Register are de~lned for all nodes while other_ are node specific. One Or the defined bits tells whether the local processor haA finished looal initialization. Another bit allow~ a global Master to issue a hardware node clear to the local processor.
Parity, arbitration and invalid command error~ are also reported in the Status Register. Thi~ register is located in bits 16-31 Or special space address 7FFFF9. Only bits 24-31 are write accessible on the I-BUS, and for all writes, a "1" will clear the corresponding bit whereas a "O"
will not afrect the bit's status.

Reads:
DA16 Node Ready - gignifies that the node has completed all of its local initialization and i3 ready to be placed on the I-BUS.
DA<17-23> Board specific status bits DA24 Reserved DA<25-28> Board speciric error status bits DA29 Bw parity error DA30 Bw arbitration error DA31 Invalid command error Wrltes:
DA24 Clear Node ~ardware --DA<25-28> Clear Board specirlc error status bits DA29 Clear Bus parity error bit DA30 Clear Bus arbitration error bit DA31 Clear Invalid command error bit Data Latch Each node on the I-BUS must contain one 32-bit Data Latch register. It is used by the diagnostic LOOPBACR command for testing the data path. It will alway~ contain the last wide word Or the laQt memory access rrom that node. It is not affected by any special space accesses. This register has no corresponding address in special Apace.

~ ~ : 1306;~10 Appllcat$on Or Epstein et al Interface Status Register Each node on the I-BUS must contain a 1-bit Interface Status Register. This bit when hi p indicates that the I-~US interrace logic has passed all internal selr-test~. When asserted, it indicates that the inter~ace is not functional. Tbis bit is not accessible directly.
Each node is required to report the state Or this blt on the XV line during the time ARBRST is asserted. If this bit iJ set, X~ should be asserted when ARBRST is present. Each potential SYSTEM CONFIGURATOR
NODE must implement a mechanism by which it can cau~e ARBRST to be asserted under sortware control and recei~e the combined Interface Status Or the system from XV. Ir XV i8 asserted, the System Configurator will know that at least one Or the nodes is not functional. The Interrace Status register is located in bit 31 Or special space address 7FFFFB. Since only the lo¢al hardware can determine the lnter~ace status, this register ls not write accessible to any Master. Any attempt to write to thls special space locatlon will produce undefined results.

Loopback Control Register Hhen wrltten to, this 1-blt register lnitlates the loopback dlagnostio sequence durlng whlch all memory accesses are disabled and all data comes directly rrom (or goes to) the Data Latch. The command ~-i~mediately following a write to Loopback wlll reset the Loopback Control reglster and end the loopback sequence. Thus, each loopback 18 good ror only one data transrer command. The Loopback Control regl~ter is located in bit 31 Or special space location 7FFFF6.

2.4.1.3 Address Space A processor does not occupy any address space. Only the local memory it has occupies some address space. Some registers that it has may occupy some Or Special Space.

~306310 Appllcation Or Epstein et al After global initialization, all local memory will be accessible on the I-BUS.

2.4.1.4 Mlscellaneous A board may occupy a slot and not connect to the I-BUS.
, . . --2.4.2 Special Node Deslgnations Certain nodes are required to perform special runctions that affect all nodes in the system. These nodes do not have to be in any particular slot.

2.4.2.1 Clock Generator All nodes derive their time bases ~rom ^BUSCLg. There must be one and orly one clock generator in the system which generates ^BUSCLK. It i~ the responsibility Or the clock generator node to drive its ^BREQ0 line low during arbitration reset.
' ~
The period of BUSCLK i8 rixed at 80 ns.

The clock subsyste~ uses the following signals:

BUSCLK bus clock ARBRST arbitration reset BREQ~0-15> bus request line 0 to 15 2.4.2.2 Sy~tem Configurator The System Configurator node is responsible for asslgning the appropriate amounts Or addressing range to each node in a system. It also has the responsibility for performing initial bus diagnostics test3.

-7o-1306:310 Appll¢atlon o~ Epsteln et al ; - The protoool ~or determining the System Configurator node must be a software protocol, such as reading the ID Registers to determine which nodes are potential Syi3tem Configurator nodes and each determining the true System Conrigurator node based on some pre-derined SLOTID-based priority. Reading a node's ID Register is a spe¢ial co,~and.

- Potential System Conrigurator nodes deslgned arter the original implementatlon must oonform to the old standard.

2.4.3 Power-up State Flow The following sequence of events describeQ the procedure required on the I-BUS to prepare all nodes for normal operation.

Note Identification Each node ~ill have a unique ID number that is derived rrom the bus request lines during power up. The node identiriers are as rollows:

Node ID Bus Request line asQerted during power-up NODE 7 0111 BRiEQ7 At power up, when PWR~PRST is asserted, the po~er supply will .~
Application of Epsteln et al assert BREQO at slot 0. Due to the connection of the bus request lines (see 3.5), BREQl at slot 1 will also be as3erted, ... Hence, each node will be able to generate its unique ID from the bus request lines.
Special commands that are pas~ed between nodes use the node ID number as the destination address. --Power-up ~PWRUPRST asserted) When the power is turned on, the power supply keeps PWRUPRST
asserted until at least 10 m~ec a~ter all DC voltages are stable.

- All nodes read ln the bus request lines and decode their Slot IDs.

- All nodes per~orm hardware reQet at this point. All components are cleared to their re~et state.
~:
,.,:: ~.
Bus Clock Generation BUSCLK will be stable on the bus when PWRUPRST is released.

Selr Test Once DUSCLK is on the bus, all nodes will use BUSCLK rOr their sel~ test. Thus ~or some time after PWRUPRST is released, Dodes will triokle onto the bus.

- This test will check out 100~ o~ the internals of the node, except ~or the I/O drivers, which are disabled during the self test. The3e will remain disabled until (unless) the node successfully passes its self test.

- Since nodes in the process Or selr test are not on the bus, no system sizing can occur until enou p time has elapsed to guarantee Application Or Epsteln et al completion Or selr test.

Inltiallzation Limits Each node will set lts own memory base register to 0. Each node's global access enabled register should also contain a 0. This will allow each node to use its own loc~l memory without having to make I-BUS re~erences, and prevent non-local references rrom going out across the bu~. The local processor can determine its own local memory size and load that value in its memory size register for use by the system con~igurator node.

Software issued ARBRST

Sortware ARBRST is now issued 80 that tbe Interface Status Re B sters Or all tbe nodes in the system can be checked. If any node's interface hardware rails its internal diagnostic~, it will be reported here.

At this point, eacb node that successrully completes all previous steps should set the Node Ready blt lr. lts Interrace Status Register.

System Conrigurator Node Determination The System Configurator node must now be determined. This must be done with special commands only since no global addresses may be used yet.

- A substantial delay may have to be added before any node should issue special commands to any other node to insure that all working node~ are present on the bus. To do this, the System Configurator node must check the Node Ready n ag Or each node's Status Begister.

1306;~0 .
~ Application o~ Epstein et al ....
....
System Sizing by System Con~igurator Node The System Configurator node must slze the system and define the Base Memory register value Por each node. To do this, the~ system configurator needs to know the size of each memory base register. It can determine this by writlng all H1l9" to lt then reading the results.
Any unused bits always return "o'sn. Memory base register assignment i8 not part of I-B~S protocol and will be left up to lndividual system -configurators.
' ~
~ ,. .
Rus Diagnostic Test The System Con~igurator node performs bus test using diagnostic commands, since any bad node can crash the bus.

- Guarantees that all bus signals are operational.

- Guarantees that all node interconnects are operat~on 1.

- Sinoe the Interface Status Registers have been checked, this verifies that the bus is operational and that no node has a rault that could crash the bus.

Operating Systec Start Once the memory assignment is complete and all diagnostics are passed, the system configurator can enable global access for all nodes by setting each node's glob~] acces~ enabled register to 1. The Operating System then must communicate to all potential Masters the address space Or each node in the system. For example, attached processors need to know the address locations of each system resource such as RAM, Video, etc. Local address space limits are provided by :~ . ` 1306310 Appllcation Or Epstein et al each node through the memory size register. Locating and assigning specific resources will be left up to the operating srstem.

2.4.4 Operation Phases Normal operation ls divided into four phases: arbitration, address, data, and transaction validation. A complete transaction comprises all four.

2.4.4.1 Arbitration Phase -~

An arbitration pha~e is requlred to start each transaction on the I-BUS. This decides whlch node will receive control of the bus.

2.4.4.2 Address Phase Immediately following the arbitration phase is the address phase.
During the address phase, the address is se~t out across the bus. The entire addres~ must be stable on the DA llnes during the falllng edge Or BUSCLR
immediately ~ollcwing the arbitration phase. The AV~MW Qignal must also be asserted by the Naster at this tlme. The address phase can take only 1 clock oycle to complete. An example Or an address phase ls shown in Figure 216.

During bus locking operations, an address phase occurs without a preceeding arbitration phase. For further information, see the "Bus Locking"
section.

2.4.4.3 Data Phase Immediately rollowing the address phase is the data phase. Data is placed on the DA lines by the sending node. I~ the sender does not have the data ready, it must have asserted its wait line (AV/MW or S~AIT) before the ~ ~ ' -75- ~

,;:' . , ~ ~

:` :
` ~30~10 Appllcatlon o~ Epsteln et al ~` falllng edge of BUSCL~ of the data phase. By asserting its ~ait line, the sender can hold the bu3 any number of clock cycles until it can prepare the appropriate data for tran~mission. On the rirst ralline clock edge after the sender releases its wait line, the receiver must take the data from the bus.
Ir the receiver is not ready to take the data, lt must have asserted its wait llne before that clock transltion. Data on the bus must remain there as long as the receiver asserts lt~ wait line.

An example Or a data phase lq shown ln Flgure 217.

2.4.4.4 Transaction Validatlon Phase The last phase ln each transactlon ls the tran~action validation phase.
This must always occur on the flrst falling clock edge aM er the data has been recelved. Ir the transaction has completed successrully, the Slave wlll assert the XV llne at this tlme. Ir something has gone wrong with the transaction, the slave will not assert the XV llne. Causes for unsuccessrul transactions are: address or data parlty e-rors detected by the slave, improper command used, or multlple-blt errors ln ~emory.

Transactlon valldation can overlap the arbitration or address phase Or the next transaction.

An example Or a transactlon validation phase ls shown ln Flgure 218.

2.4.5 NormPl Operatlon Three sequences Or the prevlous phases occur durlng normal operation.
These are single transrers, block transrers, and bus locking operations. Any Or these memory rererence operations locks out the referenced node's processor untll the operation is complete.

:::
~ ~ 1306310 Application of Epstein et al 2.4.5.1 Single Transfers A single transfer is a read or write of one memory location. The data involved can be ô bits, 16 bits, or 32 bits wide. A single transfer consists Or an arbitration phase, an address phase, a data phase, and a traDsaction validation phase. The sequence of events for a single transrer ls shown in Figure 219, which depicts a ~minimum oase" transfer; no wait lines were used.
For this, both the sender and the receiver must be ready to move the data.
If, during a read operation, the sender (Slave) cannot produce the data in onecycle, it would have to use its wait llne as lllustrated in Figure 220.

If, during a read operatlon, the recelver (~laster) cannot accept the data in one cycle, it would have to use its wait llne as shown in Figure 221.

2.4.5.2 Block Transfers A block transfer is a read or write of 8 consecutive locations in memory. The data involved are all 32 bits wlde and aligned on address boundaries. Each block transrer consists Or an Arbitration cycle, an address cycle, 8 data cycles, and a transaction validation cycle. A block transfer with no wait perlods is shown ln Figure 222.

Note that there is only one transaction validation phase. If an error occurs in one or more of the 8 data transmissions, the transaction validation can only indicate that an error has occurred somewhere, but it can't distinguish between the 8 traDsmissions~

2.4.5.3 Bus Locking Bus locking enables a node to retain control of the bus for more than one transaction. If a node knows that it will need uninterrupted transactions (for example a read and write to the same memory location), It mu~t assert BBSY

Application of Epsteln et al as soon as it galns control of the bus and release lt just before the last data , .
phase o~ the last transaction. As long as BBSY is asserted, no arbltration phases can occur.

For example, suppose a Master needed to increment a count stored in a remote memory location. The Master could request the bus twice, one to read the count and one to write the count back into the memory locatlon. Instead, it can do both tranQactions with only one request. When lt first receives control of the bus, lt asserts BBSY. It completes the rirst address, dat~, and transaction validation phases ln the normal manner. It now has read the count from the memory location. As lông as it maintains BBSY asserted, it can take as long as it needs to increment the count and prepare it to be sent out.
Anytlme after tbe first transaction, the Ma~ter can send the address back out.
If the Master sends the address before it has incremented the count, it must use Master Wait until the data is ready. It can also choose to not send the address until the data is prepared. When the address is ready, the Master as3erts AV/MM. In this case, the address is the same for both transactions. If the Master does not need the bus further, it can release the BBSY line at this time. If no wait signals are asserted, the Master sends the data across and receives the transaction validation. TLis sequence Or events is illustrated ln Flgure 223.

Technically, once a Master has gained control of the bus, it can retain control for as long as it wants by merely keeping BBSY low. Since this can defeat arbitration goals, it is recommended that bus locking operations be limited to quick double operations such as the previously described Read-Write.
.

Since any bus locking operation also locks the Slave's processor from its local memory, it is necessary to restrict bus locking operations to a single node. Thus, the node addressed when you first lock the bus must be the same node for all other transrers until you release the bus. This is the only bus locking restriction.

2.4.6 Bus Parity Errors ::

. . ~ :- , ~ . . . . ..

06~310 Application Or Epstein et al , . . .
~ Ea¢h node must monitor the parity Or all incoming data and addresses.
i~ If one or more parity errors is round, the node must set the Bus Parity Error flag in its status register special space location before the beginning Or the next transaction (in addition to releasing the XV line). This flag can then be read and cleared by any Master.

2.5 COMMANDS

2.5.1 Command Summary Functionally, there are two types of operations that can be performed:
data transrer commands and speclal space accesses. Data tran~fer commands deal speclrloally with memory rererences, tran~ferring data 8, 16, 32, or 256 bits per command directly to or from the speciried memory location(s). Special space accesses address a particular node ratber than a memory location. They are used to initialize and retrieve status from a node's lnter~ace registers and to access other types of memory by assigning special space addresses to them. Special spaoe accesses only transrer data 32 bits at a time.

The command encodlngs use 5 blts to determine the operation to be performed. Tbese blts are blts O, 1, 2, 3, and 31 whlch are sent out durlng the address phase. m e type of operatlons performed ls summarlzed ln Figure 224. All writes are rrom the D/A lines to memory locations.

2.5.2 Data Transrer Commands 2.5.2.1 8-bit Transrers In all 8-bit transrers, the unused 24 source blts are undefined and the unused 24 destlnation blts are unchanged~

Flow diagrams ror the varlous posslbillties Or 8-bit transrers are given in Appendix A.

13063~0 Appllcatlon o~ Epsteln et al 2.5.2.2 16-blt Transfers In all 16-bit transrers, the unafrected 16 source bits are undefined while the unarfected 16 destination blt~ are unchanged.

Flow diagra~s for the various possibilitles Or 16-bit transrers are given in Appendix A.

2.5.2.3 32-blt Transrers Flow diagrams ror 32-bit transrers are given in Appendix A.

2.5.2.4 Block Transrers Flow dlagrams for block transrers are given ln Appendix A.

2.5.3 ~pecial Space Accesse3 Special commands are provided to control the operation Or the I-BUS
inter~aoe logic, and to cbeck their status. They are encoded in the address Or the rererence. In addition, tbe destination slot ID i9 also speciried in the addres~.

Read Special Space .

Co~mand Data Size Description RSP 32 bits "Read Special Space~ will read rrom the Special Space location specified by the address to DA lines 0-31.
' ~ ~
' ~ Appllcation Or Epstein et al .
:., ~, The following ls sent out during the address phase:
!; -0 1 2 3 4 . . . . . 7 8 . . . . . . . . . 30 31 t 1 0 1 0 1 1 ¦ 0 ¦ destination node ~ I speclal space address I x _l_l_ The ~ollowlng ls the result during the data phase:

Speci l Space 1 32-blt Wide Word I .
Lo¢ation I . I . . : .
` v I .:
Data Lines , 0 . . . . . . . . . . . . 31 Write Spe¢ial Spa¢e Command Data Size Description WSP 32 bits nWrite Special Space" will write the ¢ontents Or DA
lines 0-31 to the Spe¢ial Space location speciried by the address.

The following is sent out during the address phase:
0 1 2 3 4 . . . . . 7 8 . . . . . . . . . 30 31 :
.

t 0 1 0 1 1 1 0 I destlnation node ~ I Speclal Spa¢e address I x I_I I . I_I

The rollowlng is the result during the data phase: ;~

-81- .

. . ~ : . ~

`
;` ` 13063~0 ~ Applloatlon o~ Epstein et al ,,~ .
,?~
~ ~ 0 ............ 31 ;
, I
Data Lines 1 32-blt Wide Word :'.; I I
, I
Special Space Location The upper 16 addreQses (7FFFF0 - 7FFFFF) in each nodes special space are reserved ror certain required $rterrace registers. These are summarized ln the following table.
Each register address begin~ with all H1's" in bits 8-26. Bits 27-30 and their oontents are shown below:

______I ______________________~ ______~ _______~ __________________________.
I bits ¦ I I global I i ¦ 27-30¦ register I width I access I spe¢ial conditions l_________ __________________~ ______~ _______~ __________________________l 1 0000 ¦ reserved 1 0001 I reserved 1 0010 I reserved 0011 I reserved ¦ 0100 I reserved 1 0101 ¦ reserved ¦ 0110 I Loopba~k Control 1 1 I R/W
1 0111 I Mask Out 116 I R/W
1 1000 1 Interrupt 116 I R/W I wrltes: 1=set 0=ignored 1 1001 ¦ Status ¦16 I R/W I writes: 1=clear 0=ignored 1 1010 ¦ Global Access Enabled ¦ 1 ¦ R/W
¦ 1011 ¦ Interrace Status 1 1 I R
1 1100 I Node Number 1 4 I R
1 1101 I Memory Base 112 I R/W
1 1110 I Memory Size ¦12 I R/W
1 1111 ¦ ID I16 I R
______~______________________~ _ _ _~ _ ____ ~ ________ _________________~ ~

2.5.4 Invalid Command Errors Issuing any combination Or control and address bits that is not currently derined constitutes an invalld command error. l~ese include any command encodings not listed in the command summaIy in Figure 224.

--ô2--Appllcatlon Or Epsteln et al If a Slave determlnes that it has recelved an invalid command, it will release the XV line during the transaction v~idation phase and ~ill activate (low) the Invalid Command Error flag in its status register. This flag can be read or cleared by any Master through the special space access commands. The error ~lag remains set until specifically cleared by a Haster.

2.7 ELECTRICAL CHARACTERISTICS

2.7.1 Signal States A signal may be in one Or two levels or in transitlon between these levels. The term "high" refers to a high TTL voltage level ( >= l2.~V ). The term "low" refers to a low m voltage level ( <= l0.8V ). A signal is ln transitlon when its voltage level is changing between ~0.8V and l2.0V. A
"rising edge" rerers to a tranqition from a low level to a hi p level. A
"ralling edge" referq to a transition from a high level to a low level. All signals are terminated on the backpanel such that all undriven signals "floatn to the high level.

2.7.2 Signal Types The rollowing signals are as speciried at the bus interrace~

^XV I/O Open collector ^AV/^MW I/O Open collector ^SWhIT I/O Open collector ^DA<0-31> I/O Open collector ^PDA<0-3> I/O Open collector ^BBSY I/O Open collector ^BREQO O Open collector ^BREQ<1-15> I Input ^ARBRST I/O Open collector ^BUSCLK I/O Open collector ^CACHE I/O - Open collector ^PWR~PRST I Input , .. ~ ' :.......... :. : ., . ' : ~ ,":
- : . :. . .: .. , .: . :- .:
: ~ : :
. .

Application of Ep~tein et al .
2.7.3 Maximum Loading Each node shall add no more than 15 pF of capacitance to any signal line.
Each node sh~ll place no more than 1 TTL load on any signal line.

2.7.4 Timing Figures 225 through 234 depict the timing coDstraints that certain signals must have in relation to ^BUSCLR; Figure 235 depicts the timing constraints that certain signals must have in relation to ~tabilization of the ~5 volt power ~upply.

130~;310 Appllcation Or Epsteln et al 3. Detntled Description Or LHB 203: -3.1 Functional Cverview The Local Memory Bus (LMB 201) 18 the bus used by Central Prooessing Unit (CPU 101) to ¢ommunicate to all memory and I/O.
It is the only architectural bus connected to the CPU. Main Memory, and Loc~1 peripherals are nodes on the LMB, wh~1e Attached Processors, Remote Peripherals, and other I-Bus nodes are accessible via the LNB through a Eateway to the I-B w .

The Local Memory Bus (LMB) is a 32 bit multiplexed data/address bus which will support multiple requestors. The CPU (central processor unit) is the master of the bus. Other requestors, such as SCI 202 and MCU 201, are allowed, but they must request use Or the bus prior to uslng it ~ia request line3.

The LMB is a 16-bit word addressed bus, with support for byte, double word and even-aligned 16 word block transfers.
The addres3 space supported is 28 blts Or word address - or 512 Me~abytes.

MC~ 201 is the one architectur~1 memory node on the LMB which is lnter~aced to the I-Bus and occupies at least one I-Bus node address space. This is the LMB's only connection to the I-Bus, which handles all I-Bus-LMB traffic. This interface will recognize all read~ and writes to the 28 bit address spaoe that occur on the LMB and either respond directly tif the re~erence is to its local memory) or relay the request to the I-Bus. From the reque~tor's point of view, all references appear the same except rOr the access time.

:; ~ . . . -,. . . :
: . . . .
.

Application Or Epstein et al ; The I-Bus is accessible through the LMB but not vice versa.
While LMB accesses may be re-transmitted onto thb I-Bus, which ; facilitates "passing throu~h" references to a memory on another computer, there is no way that an I-Bus command would ever be re-transmitted onto the LMB. The I-Bus node controller on the LMB will field all I-Bus requests. This means that an I-Bus operation can access any location in the local memory space, but it cannot access any other node on the LMB. Local peripherals are not accessible dlrectly by way Or a bus transrer, with the sxception Or memory mapped devlces. In that case, those periperals can be accessed only by reads and wrltes to the designated architectural memory locations. An I-Bus initiated special read and speci l write command can be used to access I-Bus nodal inrormation.

The video connection is a bit mapped memory whlch is part Or the architectural memory space. The memory/I-Bus interrace recognizes this space as part Or its own local space and responds as if it were standard read/write memory.

Non-architectural memory elements exist both on IOC 202 and in MC~ 201 itself. These elements are accessible by way Or Special Read and Special Write commands and will include such things as configuration information, status registers and diagnostic hooks. IOC 201 memory, or other non-memory connections on the LMB will respond to the Read Bus and Write Bus commands which allow non-me~ory use Or the buY. "~

An lnterrupt mechanism 18 provlded for slave connectlons whlch requlre service from a master. ~ses Or the interrupt mechanism include IOC 201 lnterrupts as an operation completed lndlcator, I-Bus interrupts, ERCC fault reporting ~rom a memory board and keyboard/mouse lnterrupts rrOm a video board. Two types Or interrupts are supported: maskable and non-maskable.
Non-maskable types will not be disabled by system software.

- : , ................... : . . , -- ., : . -.

~ ~ ~3063~0 Application of Epsteln et al ':
3.1.1 Architectural Considerations:

3.1.1.1 Overview The L~ is designed to operate in a 32-bit architectural environment. The LMB i9 to be treated ~ an extended memory bus operating with up to 512 Megabytes of physically addressable memory. The L~B gives acces~ to all 28 bits o~ addre~s through the local memory board by re-transmitting global I-Bus references as needed. (See MCU 201 description.) The architecture allows for 29 bits Or address; however, the LMB/I-Bus 28 bit lim~tation aids in implementation of logical and physical addressing logic due to the overlap Or the 29th bit (Bit 3) with tbe ring bits Or a logical address. Therefore, the Bit 13 of both the SBR's and the PTE's ~hoult al~ay-~ be zero when using an LMB/I-Bus based ystem.
. -~3.1.1.2 Memory Protection~

The LMB/I-Bus system provides a distributed physical memory with various pieces being "owned" by local processors. By definitlon, however, any node can address any other node'Y memory sinoe all LMB~I-Bus addresses are part Or one, contiguous "global"
memory space. Thererore, protection Or this physioal memory mu~t be a cooperative errort among all the processors in the system.

Tbe CPU is the true bus master which controls the power up Or the entire system and loads up all Or the memory base registers contained in each Or tbe node3. A~ described in conneotion wlth MCU 201, this is accomplished by having that processor identlfy all the nodes that exist, determine their respective sizes and types, then assigning each one a posltion ln the global, contiguous memorY space. This i~ sortware controlled.

, ~306310 Application Or Epsteln et al ;
. -That master could ~urther take on the responsibility Or global memory management by giving privileees to the dlfferent processors on the system. This does require cooperative processors and proces~es on each Or the nodes.

3.2LMB Signals:

The signals appearing on the LMB bus are as follows:
1 Bus Clock ^BCLR Totem Pole-32 Data/Address Lines ^LMB<0:3i> Open Collector 4 Byte Parity ^LBP<0:3> Open Collector 1 Bus Busy ^BUSY Open Collector 1 Bus Wait ^WAIT Open Collector 1 Interrupt ^INTR Open Collector 1 Non Haskable Interrupt ^NHI - Open Collector 2 Bus Request Signals ^REQ_IN Totem Pole ^RE Q W T Totem Pole ~
1 Abort Reference ^ABORT Open Collector ~ ~N
1 Bus Error ^ERROR Open Collector 1 Bus/System Reset ^RESET Open Collector 46 Total Pin Count ~-3.2.1 Signal Descriptions ^BCLK Bus Clook. This 80ns Clock which synchronizes ~1l me~ory ~-transrers. Only the active (ralling) edge is used. All other slgnal~ are rererenced to this clock.
, ^LMB<0:31> LMB Data and Address Lines. Data, address and commands are transrerred on this bus.
See Figure 301 for the transmission rOrmat.
See Section 3.3 ror the formats Or data, addresses, commands and Special commands.

^LBP<0:3> Local Byte Parlty Bits are asserted by the driver o~
the LMB in the cycle rollowing that ~alld data or address. Each LBP bit represents odd byte parity ror Appllcation Or Ep~teln et al :
each of the rour bytes which were driven. This is used for ¢hecking the integrity Or the buq transfer. The Pollowing table describes the meaning oP each Or these slgnals:
Sign~ eaning _______ ________________________________________ ^LBP0 zero (hlgh) iP the sum Or LM~<0:7> mod 2 z 1; one ~low) iP that sum mod 2 = 0 ^LBP1 zero (high) iP the ~um Or LMB<ô:15> mod 2 = l; one ~low) iP that sum mod 2 = O
^LBP2 zero thigh) ir the sum Or LMB<16:23> mod 2 = 1; one (low) lr that sum mod 2 = 0 ^LBP3 zero thigh) lr the sum oP LMB<24:31> mod 2 = 1; one (low) lr that sum mod 2 = O

^WAIT WAIT iq driven by either the drlver or the receiver Or the LMB. It i8 a low active, open collector signal. The receiver asserts WAIT when it 1S not yet ready to receive the data, while the sender asserts WAIT when there is not yet good data on the bus. In the receiver's case, WAIT is the way oP telling the sender that it i~ not yet ready to receive the next transPer oP data. Anytime WAIT is asserted, the current operation i8 pended by the driver Or the bus, no matter who asserted WAIT, and the receiver Or the buq must ignore the data on the LMB lines. (Note that the "driver~ Or the bus switches between requestor and requestee Por a read operation.) WAIT can be driven by any node on the LMB which is not prepared to accept or deliver any data transPer. It may be asserted at anytlme (glven proper set up and hold requirement-q. ) . ' '~
Note that WAIT cannot be asqerted in response to an address being driven on the LMB as an attempt to hold that address valid. It must have been asserted at the same time ai~ the address (valid at the same clock edge) to successPully stretch the address phase. TherePore, ~1l nodes are assumed to be able to accept an address tor data) immediately, a9 long as WAIT ~as not asserted last cycle.
The Requestor ~3ender), however, may assert HAIT and BUSY at the same time during the address phase to ePfectively stretch that phase. In this case, the Requestor is expected to hold BUSY down as long as it is asserting WAIT. Additionally, the Receiver must ignore the address o~ the bus until WAIT was not asserted.
Only then does it know that the addreQs was valid at the last clock edge. The operation will then proceed as us~

Appllcation of Epsteln et al ^BUSY BUSY ls an open collector signal which indicates that the LMB i~
in use even though WAIT may not bs as~erted. It is asserted only by the requestor. Generally, it ls asserted during the addr~s phase Or a memory operation, but may be asserted longer to perform either a lock operation (two or more consecutive memory operations that must be indlvisible) or a Block Transfer (see bel w). It is as3erted low, by the requestor of the bus at the same time as the address is driven and held until WAIT was not asserted in the previous cycle. In the case of a lock, BUSY 18 asserted as before, but held throughout all locked operations. It is released at the end Or the address phase of the last memory operation in the locked set.
Block Transrers require the use Or BUSY to keep other requestors ofr the bus. In this case, the requestor must assert BUSY in the rirst address cycle as usual, then holds it until the 7th 32-bit data transrer was valid on the LMB and ~AIT was not asserted last cycle.
The reque~tor then releases BUSY and completes the read or write transrer using the WAIT signal as usual. The 810ck Transfer operation appears to all others as a locked bus transrer.

^INTR INTR i~ an open collector signal used to request the service of the CP~ for a pending interrupt. INTR can be asserted (low) anytime (with the proper set up and hold restrictions), and wili be serviced by the CPU by way Or a Read Special (RSP) or Read Bu~
(RX) command. The CPU will decide which requestor to service rirst. When the appropriate RSP or RX command is received, the acknowledged node must release INTR. Once INTR is asserted, it must be held until tbe appropriate RSP command is received.
This signal may be ignored by the CPU if all interrupts have been masked out by the operating system. It is expected that he signal will remain a~serted until interrupts are re-enabled and the CPU recognized this line by way o~ a proper RSP or RX command. For an interrupt condition that cannot be ignored, the NMI line should be used (see below).

^NMI NMI is an open collector signal, asserted low, which behaves identical b to the INTR line (above~ except that it cannot be masked by system sortware. NMI has a higher priority than INTR and is ~sed for such things as the operator "8REAK" key and IOC-to-CPU non device related communication.

^REQ_IN The REQUEST signals all w access to the LMB. It is a Application Or Epsteln et al ^RE Q W T

^~RROR

^ABORT
totem pole, active low, dalsy chain which connects all requestors except the CPU which is not required to drive REQUE~T.
RE Q OUT is asserted low either when REQ~IN is asserted (which is the daisy chain relay case) or when the requestor requires a memory transfer. The requestor is granted th0 bus when REQ_IN, BUSY and HAIT were not a~serted and it wa3 asserting RE Q OUT. Ir BUSY, WAIT or REQ_IN was asserted, the requestor must continue to assert RE Q W T until all three become not asserted at a clock edge. The requestor then asserts BUSY and begins the bus operation.
The priority 1B determined by the physical interconnect order of the REQUEST llnes. A higher priorlty requestor is asserting the signal ir REQ_IN is asserted tlow).

This open collector signal is asserted by any Or the connections on the LMB to lndicate some type of fault. The signal follows the raulty data transfer or the faulty parlty tran3~er by one cycle. The requestor and/or the master (CPU) must sense thi slgnal and take appropriate action.
Generally, these are ratal, hard fault~ such as bus parity error or multiple bit, non-correctible memory failure Once asserted, the ERROR signal mu~-t remain asserted until either the proper RSP command i8 received, or a bu~ RESET i~ asserted. Any operatior in progress must be, or appear to be, completed. The result of the operation will be undefined. Specifically, WRITES with a byte parity error on the data, ~or instance, may destroy the addres~ed location.
NOTE: Correctible errors must be corrected on the fly, holding the bus (if necessary) via the ~AIT line and must not assert the ERROR signal. At a later time, the node which corrected the error should irterrupt to explain the soft failure.

ABORT is an open collector, low active signal asserted by a requestor which wishes to abort its memory operation.
It must be asserted for one BUS_CLR cycle during the address phase or the cycle immediately following the address phase.
All signals pertaining to this operation must cease by the next clock edge. This applies to both the requestor and the slave node. Note that WAIT does not effect how long this signal lasts. It is, by definition, only one BUS_ U R ln duration.
If it is asserted during a read operation, the slave will abort its operation and stop driving all bus signals im~ediately (except, perhaps WAIT, if necessary ~306310 Applloation of Epsteln et al for state integrity). In the case Or writes, the WRITE
will not occur, and the operation will be aborted as with reads.
If the B ORT signal i~ asserted at a tlme other than during or immediately following the address pha~e, the results are undefined. Particularly, a WRITE operation - may be aborted but the state of the memory location - (and possibly the word above andJor below it) will be undefined.
An ABORT ends the memory operation. Another may start only after WAIT has gone away - Just as with any other address phase.
ABORT can only be used to abort Read, ~rite or Block type memory operations. It i3 not valld on any Read -Special, Write Special, Read Bus or Write Bus command. -~

^RESET This open collector master RESET signal 18 used exclu~ively ror globally resetting the system. Pulling down on this signal AT ANY TIME causes a global reset of all state machines in the CP~, Memory, Vldeo Board(s) and I-Bus. (This RESET will cause an T Bus RESET as well). Normally, it will be used for power up reset, rront pdnel reset and diagnostic~, and will be under control Or IOG 201.

3.3 Commands 3.3.1 Word~Double Word Formats 32-blt memory storag formats are depicted in Figure 302.

BuJ-~ustiried formats are shoNn in Figure 303.

3.3.2 Command Encodings 3.3.2.1 Summary o~ Enoodings:

(As shown in Figure 301, commands are transmltted in bit positions 0-3 o~
the address word.) -92^

: 1306~10 :
Application of Epstein et al :
Hex Command Mnemonic Description : .
Reads:
F 1111 RDJ Read Double Word and Justify D 1101 RMJ Read Word and Justify 5 0101 RLBJ Read Left Byte and JustiPy 4 0100 RBK Read Block C 1100 RSP Read Special E 1110 RX Read Bu~ - No Memory Response Writes:
B 1011 WDJ Write Double Word from Justified Data 3 0011 WWJ Write Word from Justlfied Data 7 0111 WM Write Hord direct O 0000 ~LB Write Left Byte from Left Byte ô 1000 WRB Write Right Byte from Right Byte 1 0001 WLBJ Write Left Byte ~rom Ju~tified Byte (3) 9 1001 WRBJ Write Rigbt Byte from Justiried Byte (3) 6 0110 ~Bg Write Block 2 0010 WSP Write Special A 1010 WX Write Bus - No Memory Response 3.3.2.2 Characteristics of encodings:
1) For Write Byte and Ju~tified Read Byte operations, blt 0 of the command 19 a byte pointer. (RWJ and RLBJ for reads and WLB, WRB, WLBJ, WRBJ
for write~) 2) RSP is a RWJ (read single word) with bit 3 cleared.
3) RX i3 a RDJ (read double) with bit 3 cleared.
4) WSP 18 a WWJ (write single) witb bit 3 cleared.
5) WX is a WDJ (write double) witb blt 3 cleared.
6) Justified Byte, Word and Double Word Reads have bit 1 set.
7) Justifled Byte, Word and Double Word Writes have bit 1 cleared.
ô) Where Possible, Reads and Writes differ by 1 bit as do adJacent word and byte operations.

3.3.2.3 Expansion Or above encodings:

, .

1306~0 : Appllcation Or Epstein et al : ~it Encoding 31 result:
~: ------------______________________________ F RDJ O Read Double even F RDJ 1 Read Double odd F RDJ O Read Word O to Word O
D RWJ 1 Read Word 1 to Word 1 (Justiried) D RWJ O Read tlord O to Word 1 (Ju~tified) F RDJ . O Read Byte O to Byte O
F RDJ O Read Byte 1 to Byte 1 D ~WJ 1 Read Byte 2 to Byte 2 D RWJ 1 Read Byte 3 to Byte 3 (Justiried) 5 RL8J O Read Byte O to Byte 3 (Justiried) D RWJ O Read Byte 1 to Byte 3 (JuRtified) 5 RLBJ 1 Read Byte 2 to Byte 3 (Justi~ied) 4 RBK tO) Read Block C RSP x Read Special E RX x Read Bus (No memory response) B WDJ O Write Double even B WDJ 1 Write Double odd 7 WW O Write Word O ~ro~ Word O
3 WWJ 1 \ Write Word 1 from Word 1 (Justified) or 7 WW 1 /
3 WHJ O Write Hord O from Hord 1 (Justiried) O WLB O Write Byte O from 8yte O
8 H B O Write Byte 1 from Byte 1 O WL8 1 Write Byte 2 from Byte 2 8 WB 1 \ Write Byte 3 from Byte 3 (Justiried) or 9 W BJ 1 /
1 WL8J O Write Byte O from Byte 3 (Justiried) 9 W B J O Write Byte 1 from Byte 3 (Justlfied) 1 WLBJ 1 Write Byte 2 from Byte 3 (Justiried) 6 W8~ (O) Write Blook 2 WSP x Write Special A W% x Wrlte Bus (No memory response) 3.4 3us Operation 3.4.1 General Rule3:

3.4.1.1 13063~0 Applicatlon Or Epstein et al :
Data is valid on the LMB when a bu~ operation is in progress and WAIT i8 not asserted. A bus operation is in progre~s ir either BUSY or WAIT was asserted last cycle. Since all signals are oDly v3lid on the clock edge, the implicatlon ls that when WAIT was not as~erted, then the LHB was valid (assumlng a bus operatlon was in progress~.

Therefore, all nodes on thls bus must be ready to accept a 32 bit data or address word unless B~SY or WAIT is asserted. A node may assert WAIT untilit is ready to accept a new transfer, if no B~SY or WAIT was asserted last cycle. For exa~ple, a memory with which is completlng a read and needs its address ;atches for a snifr operation. In this case, WAIT is de-a serted ln Cycle N slgni~ylng good data on the LMB in cycle Nl1. WAIT i9 the re-asserted by the memory in Cycle Nl2 which will pend the bus until WAIT is released whenit's ready to accept a ne~ address ln the next cycle. Thi~, ln errect, will stretch the address phase Or the next transrer.

.4.1.2 When a cycle is pended by the WAIT slgnal, the 32 LMB lines are marked as undefined. Although a node can stretch either pha~e by asserting WAIT, lt CANNOT asAume data i8 vPlid throughout the stretched phase. The LMB i~ OI~LY
valid durlng the last cycle of that phass, when WAIT gets de-asserted (see 4.1.1) 3.4.1.3 The parity lines (L3PO-3) are always valid in the cycle following the valid (last) cycle Or the address or data phase. They are not affectedby the WAIT slgnal except a~ to how WAIT determlnes when a v~1id data or address cycle has occurred.

3.4.1.4 . ` ~306310 j Applicatlon of Epstein et al , ~
i,. .
Bits 4-31 must ¢ontain a valid physical word address during the address ~` phase of a memory reference.

3.4.1.5 For all Byte writes and reads, the upper 24 bits of the LMB during the data phase are undefined with the requirement that ood parity i8 maintalned.

3.4.1.6 .
For all Word wrltes and reads, the upper 16 bits of the LMB during the data phase are undefined with the require~ent that good parity is maintained.

3.4.1.7 Each node on the LMB must be able to recognize an address phase in order to check fc~ lts address. This is accomplished by starting at RESET and expectlng an address phase to begin with BUSY and ^WAIT
asserted. Data phases ~1ways ~ollow address phases except, possibly, in tbe cases o~ ABO M 8, and RESETs. Either of those conditions should reset the memory state machines so that an address phase is expected next.

ABORTs happen for one BUS_CLK cycle, and there~ore must immediately reset state machines to expect an address phase. Thi~ address may come as soon as the BUS_CLK edge immedlately following the edge ln which ABORT was asserted. This would be lndicated by BUSY being asserted with no WAIT, as usual.

RESETs may be as~erted for many cycles and must keep all nodes in a benign, reset state, i.e. in one which does not drive nor corrupt any of the Bus signals. ~hen RESET does go away, ary node is expected to be able to take an address immediately when BUSY becomes asserted, unless WAIT is beinB
driven.

06~10 ~ Appllcatlon Or Epstein et al j, . ~
3.4.1.8 The ERROR si~nal is a special case in which the CPU (or the main processor node) must respond with a read special. When the EBROR signal is asserted by a node, it must keep pertinent information ~see the READ
SPECIAL command for ERRORs ir the appendix) but continue with bus operations a~ usual. The CPU must recognize the error condition and handle it as is deemedproper.

Care must be taken, however, not to upset the Bus protocols in any manner whatsoever when ERROR i9 asserted. In most systems, the ERROR line is expected to oause a high priority interruption of proce~sing, resulting in an immediate READ SPECIAL of the reporting node~ In order for this to correctly occur, the 3equences of Data always rollows Address mu~t be preserved. mis will lnsure that all state machines will ~tay synchronized. mis must be true whether the error occurs on the address or data.

Very importantly, if a ~ystem was t~ ignore the ERROR signal, everything must continue to function in a protocol-proper manner whether or not the datahas been corrupted. In this case, once an ERROfi has occurred, the ERRORsignal would remain asserted indefinitely.

In the case Or multiple ERRORs, any one reporting node would be expected to save the pertlnent information only for its most recent error.

,:
3.4.1.9 Block Reads and ~rites MUST be on even words - that is, Bit 31 must be zero.

.4.1.10 .. . ..

,", ~ ,",~ " ~ ~ 's'`` .' ;:' ' '' ` ' ''~ ''' - '" ~''~' ~ Appllcatlon Or Epsteln et al .
-~ Interrupts (elther the IN~R line or the NMI line) may occur at any time. The interruptlng node must continue to assert that line until a Read Special is issued to lt. However, lt is a requirement that the lnterrupt not impede any other transaction - including one that may be addressing thelnterrupting node itself.

The INTR is a maskable interrupt and may last many cycles before being serviced. For that matter, it may never be serviced. Response to an NMI may, as well, take many cycles. The node that i9 lnterrupting must continue to operate as lf there was no interrupt pendlng at all.

If a second interruptible event occur~ on any one node, it may continue to assert INTR or NMI even ~hile the rirst one is being handled in order to receive multiple interrupt ~ervice~. In that case it will appearJust as though there were multiple nodes interrupting. The sequence of service is determined by the master node.

.4.2 Page and Node boundaries:

Prior-art page boundaries (1~ words, or 2KB) have no meaning on the LMB. Reading or writing data that crosses one Or these boundaries will appear Just as any other read or write. It 18 up to the CP~ (or other pro¢essor) to lnsure that accesses correctly cross ~or don't cross) logical pages. Node boundaries, on the other hand, have the rollowine characteristics and restrictions:

Double word read requests that straddle a node boundary will result in only the rirst word being read. It will be properly allgned on the 16 MSB's Or the LMB, with good parity. The second word (16 LSB's Or the LMB) will be underined, with good parity.

~ 1306310 ~ Applloatlon Or Spsteln et al ,~ , Wrlte requests that 3traddle a node boundary are not allowed.
Executing such an operation may cause a le88 Or memory data, and may degrade memory bu~ integrity.

Block Transfers (either Reads or ~rltes) that cross a node boundary are not allowed.
.

3.4.3 Detalled Descrlptions:

The following descriptionQ of various bus operatlons are accompanied by timing diagra~s. CPU 101, MCU 201, and IOC 202 are assumed to be the only requestors but repre~ent any processor, local peripheral controller and local memory node respectively. For lines such as BUSY, WAIT
and INTR/NMI, the legends CPU, IOC or MEM indicate the driver Or tbat line at that point in time. Tbe letters A and D are used on the LMB line to indicatewhether the LUB is in an address or data phase. The letter X is used to indicate an undefined period on the signalts). Nodes must ignore any ~ignal which is marked an X at that time.

The desoription will refer to the diagram by referencing the BCLK cycle number (top line Or each exa~ple). BCLK cycles are all 80ns between active edges.

3.4.3.1 Reads Reads are initiated by a requestor in the cycle following a clock edge in which BUSY and WAIT were not as~erted and, i~ the requestor is not the CPU, when REQ_OUT and not REQ_IN conditions are true. The initiations _99~

:

0~10 ~ Appllcatlon Or Epstein et al :
conslsts o~ an address being placed on the LMB and the assertion Or BUSY, both done by the requestor.
~. .

RXAMPLE ~1:

In the first example, "Example ~1n, the ra~Qtest memory operation is described. A timlng chart of the example ls shown in Figure 304, and i8 explained below.

It ls likely that a Read Special (RSP) will look llke this example since the location read is, as described ln connection with MCU 201, actually an internal register in the memory interrace.

Cycle Description 1 Bus Idle 2 The CPU places an address on the LNB concurrently ~ith agserting BUSY. This can be done since neither BUSY nor WAIT was asserted in cycle 1.
3 The memory sees that BUSY is asserted with no WAIT, which indicates that the address that was on the LMB in cyc1e 2 was valid and that a reference can begin.
Assuming a very rast memory system, the valid data can be driven onto the LMB during cycle 3 as shown. The CPU
drives correct parity for the address onto the LBP
lines.
4 The CPU kn~s that there was good data on the LMB in cycle 3 since WAIT was not driven during that that same cycle. The parity bits are checked by memory ror correctness.
The bus is ready to begin another operation in cycle 4 since neither BUSY nor WAIT was asserted in cycle 3.
The CPU checks data parity durine this cycle which completes the reference.
6 Bus Idle.

Application o~ Epstein et al The next three examples (Example ~ 2,3 and 4) show various read type ~; operations. A cycle by cycle description will accompany each Example.

EXAMPLE t2:

, .
Example 2 (timing chart shown in Figure 305) agaln assumes a very rast memory and shows what the rastest read from a non processor LMB node would look llke from the bus standpolnt:

Cycle Descrlption , ._~.. ... ,_ ,, . .. - - .. .
1 Bus Idle 2 IOC has noted that nelther BUSY nor WAIT was asserted last cycle and wants to use the bus. IOC 202, then, asserts lts RE Q OUT llne.
3 IOC has noted (agaln) that nelther BUSY nor HAIT was asserted last cycle whlch means it can begln its read operatlon. IOC 202 asserts lts address on the LMB and asserts BUSY.
4 Slnce WAIT was not asserted last cycle, IOC 202 knows that the address has been taken and the Read has begun.
The MEM, belng very rast, drlves the data onto the LMB
for IOC 202. IOC 202 19 drl~rlng the LBP parlty llnes pertaining to the address rrom cycle 3.
IOC 202 has latched ln good data at the end Or cycle 4 as lndlcated by no NAIT was drlven last cycle. The parlty ~or the data is belng drlven by the MEM, while the address parlty is belng checked by IOC 20~.
6 The data parlty 19 checked by IOC 202. Tran9rer 19 complete.
7 Bus Idle.

EXANPLE ~3:

Example #3 (tlming chart in Flgure 306) 18 a reallstlc read Or memory by the CP~. The only dlfrerence between this and Example ~1 19 the ~AIT slgnal:
: ~' 130~ 10 Applioation Or Epsteln et al :
, . .
Cycle Description 1 Bus Idle 2 The CPU begin~ driving an address on the LMB, and the BUSY signal after noting that neither BUSY nor WAIT was asserted last cycle and that it needed to make a reference.
3 m e memory begins the access and pulls WAIT since the access will not be complete during this cycle. The CPU
drives address parity. The CPU is ready to receive data this oycle.
4 m e CPU sees that the memory was busy last cycle and that good data was not received. The memory is ~till not ready and continues to drive WAIT. Parity is checked by the memory.
The CPU still sees WAIT so the input latches still do not close. The memory now has good data and begins driving it onto the L~B along with releasing WAIT.
6 m e CPU now realizes that good data 1Jas on the LMB in cycle 5 and takes the data. The memory drives out the parity for the data.
7 Parity is checked by the CPU, transfer is complete.
8 Bus Idle.

EXAMPLE ~4:
:
Example ~4 (ti~ing chart shown in Figure 307) shows 3 back-to-back reads on the LMB. Interaction between data, BUSY and WAIT is shown.

Cycle Description 1 The CPU has begun a read transfer by p~1ling BUSY and driving the address onto LMB.
2 me memory drive~ WAIT, CPU drives address parity. IOC
202 has decided to be8in a transfer and drives RE Q OUT.
It is the orly non-CPU node reque~ting the bus.

13~63~0 Applloation o~ Epstein et al 3 Both the CPU and IOC sees that WAIT was down and knows that the bus was pended last cycle. Memory cbecks addre3s parity.
4 Again the CPU and IOC see that WAIT was do~n. The memory lets go of WAIT and begins driving good data.
The CPU takes the good data since WAIT was not asserted la~t cycle. The Memory drives data parity. IOC 202 sees that WAIT was not asserted and thererore beBins to drive the LMB with an address and BUSY for one cycle.
IOC 202, in addition, releases REQOUT. Meanwhile, the memory is not ready to accept another transrer, and thererore, drives WAIT.
6 The CPU checks data parity. IOC 202 sees that WAIT was asserted last cycle and therefore repeats itself by driving the address onto the bus along with driving BUSY
for another cycle. Memory is done holding aff the tran9rer, 80 it releases WAIT.
7 IOC 2û2 sees WAIT go away (as well as memory) which indicates that the address was taken. IOC 202 drives addreQs parity, lets go of BUSY and prepares to receive data. The memory pulls WAIT ~or access time.
8 Address parity is checked by the memory. IOC 202 sees that WAIT was down la~t cycle and waits another cycle for data. Memory lets go Or WAIT and drives the data onto the LMB.
IOC 202 takes the data since WAIT was not down. The memory drives parlty for IQC 202 to check in cycle 10.
The CPU sees that nelther HAIT nor BUSY were down last cycle 90 it begins a transrer by placlng an address on the LMB and drives BUSY. The memory drives WAIT tmaybe ~or a re~resh) which pends the address phase. The CPU
will complete the read as usual.

3.4.3.2 Writes Writes are initiated in the same manner as reads by a requestor after neither BUSY nor WAIT was asserted last cycle. Arter the address is aocepted, however, the requestor must drive the data (or drive WAIT until it can drive data) for the write. If the memory needs data recovery time (and cannot overlap this wlth the acceptance Or a new address) then it must drive WAIT
a~ter the data is accepted, until it is able to accept an address Or a new -~
request `

. . ': ` . , -........... .: .

::

~ 1306310 ~. ~
~ - Application Or Epstein et al ,~
, ~
Examples 5 and 6 show simple Write example~ ote that a non-CPU wriSe would simply be preceded by a RE Q OUT signal a3 already exemplified by the IOC
reads aboYe.

Example ~5: Fastest CPU Write to Memory:
Example ~5 (timing chart depicted on Figure 308) depicts the rastest CPU
write to memory:
Cycle Description 1 Bus Idle.
2 CP5 drives BUSY and address for WD to memory 3 Nemory accepts address and is ready for data. The CPU
drives data in addition to the address parity.
4 Memory accepti3 data and does write. Memory ~lso checks address parity from CPU. CP~ drivea data parity.
Memory checks data parity. Operation is complete.
6 Bus Idle.

Esample ~6:

Expected Double Word Write from CPU to Memory (depicted in Figure 309).
Note that a non-CPU write would look identical except that RE Q OUT would be asserted before the transrer as shown for Reads above.

Cycle Desoription t Bus Idle, 2 CPU drives Address and BUSY since neither BUSY nor WAIT
was asserted la~t cycle.
3 CPU drives WAIT because it is not yet ready to transmlt data to the memory. (Memory may drive WAIT here, as wellj for its latching mechanism. Since the CPU is drlving WAIT al~o, this is hidden.) CPU drives address parity.

f ~06310 Applicatlon of Epstein et al 4 Memory notes WAIT was asserted so does not write.
Memory checks address parity. CPU drlves good data onto L~B.
Data is accepted by Memory and Hrite is started. Data Parity is driven by CPU. Memory drives WAIT for one or two cycles here to hold Orr any more addre~ses until the Write is completed.
6 Data parity is checked by the memory. In this case, Memory is still asserting WAIT 90 that no address ¢an be driven next cycle.
7 Bus beoomes idle.

3.4.3.3 Locked Operation~

When a requestor wishes to execute an indivi~ible memory operation, it may use the Locking mechanism on the LMB. This will insure that a memory location will not be seen or changed by any other requestor for the duration Or the locked operation. The most common use of this Locked operation is a Read-Modify-Write semaphore type reference.

Locked operations on the LMB take place simply by asserting the BUSY
slgnal for the duration Or the desired locked operations. All other signals work as defined rOr all other operations. Since BUSY is asserted, no other requestor will be able to use the bus while it i9 locked. Any node, however,wlll still have the power to pend the bus by asserting WAIT for internal ;~
operations such as rerresh.

As this does prevent others rrOm using the bus, Locked operations should be used ror short periods Or time and only when necessary. ~ ;~

To perform the Lock, B~SY is asserted by the requestor at the beginning Or the rirst operation during the address phase. It ~ as~erted at the same time as with any address phase. BUSY must be held, however, throughoutthis memory operation and subsequently held untll the end Or the addressphase of the last memory operation ln the locked set Or references. Note that the WAIT signal derines the valldity Or address and data phase~. In -10~

130~
Appllcation Or Epsteln et al the locked situation, WAIT must be used between memory operations ~between the data phase on one and the address phase Or the next operation) if the locking requestor is not able to begln that addre~s phaQe ~mmediately (l.e. 80 ns after the end of the la~t data phase).

.. . .

~xample ~7:

~ xample 7 (tlming chart depicted in Figure 310) shows the most common Locked operatlon. The CPU is doing a read operation and a write operation without allowing any other requestor to divide those operations.

Cycle Description 1 The CPU has begun a RD operation by driving BUSY and the L~B with the address of the read.
2 The memory prlls WAIT, as usual, ror the Read access.
The CPU dri"es BUSY ror the locked operatlon and will contlnue to hold lt. Address parity is driven by the CPU.
Mem continues to drlve WAIT while waiting ~or access time. Mem checks address parity. CP~ continues to Lock by driving BUSY.
4 Mem completes the read and drives the data onto the LMB
while releasing WAIT. CPU continues Lock via BUSY.
CP~ takes data si~ce it sees that WAIT has gone away.
The CPU is not yet ready to write back the data 80 it drives WAIT. Note that this is requlred in the Lock operation because BUSY is asserted. The Memory drives data parity. ;~
6 The CPU is now ready to begin its second re~erence Or the locked set. It thererore drives the LMB with the address while releasing WAIT. BUSY still remains asserted and will ncw act like tha beBinning o~ any normal transrer. The CPU checks data pari~y.
7 The Memory accepts the address and, ln this case, drives WAIT to hold or~ the data phase. Address parity is Applicatlon Or Epsteln et al :
driven by the CPU. BUSY is finally released by the CPU
since the last re~erence of the locked set is in progress.
8 Mem now releases WAIT and, sinoe the CPU is not asserting WAIT, the LMB is driven with data. Mem checks address parity.
A normal Write transrer ls in progress here - data is accepted by the memory; WAIT i8 driven by the Mem to hold off the next address phase; and data parity is driven by the CPU.
Data parity is checked by Mem. The memory holds WAIT
for one more cycle.

11 WAIT i8 released and Bu~ becomes idle.

3.4.3.4 Aborted Memory Operations A referenoe may be aborted by using the ABORT signal. This allows requestors to begin memory rererences before it has been validated.
That is, berore it has been determined that the reference should indeed tako place.

ABORTs must be done directly ~ollowing or during an address phase by asserting the ABORT signal for one BUS_CLK cycle. The memory which is esecuting the read or write operation will cease all ~ork on that operation and stop dri~ing the data lines by the next cycle. It may choose, however, tooontlnue drl~ing WAIT to insure that the state macbine is ready ~or the next ;~
address transmission. -~
~, Example ~ô~
Example ~8 ~tlming chart depicted in Figure 311) descusses an aborted memory rererence rollowed by a non-CPU write.

Cycle Description 1 Bus Idle.
2 CPC has begun a memory operation as usual. IOC 202 haq pulled REQ ror its own memory operation.
Mem pu119 WAIT to begin the address access. The CP~

30~i3~0 Applioation oP Epsteln et al `- drives Address Parity. IOC 202 sees BUSY asserted which indicates that it does not have the Bus and must continue to drive REQ. The CP~ re~lizes that this operation should not have been ~tarted and pulls ABORT.
4 The Memory sees A80RT and stops driving WAIT. Further, it aborts the accesC and expects to see an address phase next. The Memory checks address parity as u ual. IOC
202 sees WAIT and continues to request the bus via REQ.
The CPU stops driving A80RT (it lasts only one cycle).
IOC 202 gets the bus since neither BUSY nor HAIT was asserted and drives the LMB with an address along with BUSY. IOC 202 releases RE Q OUT.
6,etc IOC 202 completes a normal Write operation.

3.4.3.5 Block Operations To increase memory bandwidth for higher speed device transrers, an LNB
node may choose to use Block mode tranQfers. Block transfers will trans~er 8 double words (32 bytes) in one operation. One address is transmitted in the usual manner, followed by 8 consecutive data phases without any additional addresses. The memory receiver Or the data will read or write all ô double word-to/from consecutive locations by automatically incrementing theaddress. The transrer must begin on an even address.

Block transPers appear sim~lar to locked operations in that B~SY is asserted durlng the ~ntire transPer - through to the 7th data tran3fer. At that tlme it 18 de-asserted (unless the bus is being locked by that requestor) and the eighth data transrer occurs. All nodes on the bus must recognize the Block transrer command ln order to remain in synchronization wlth address phases. Other than the multiple data phases and different command, block transrers follow all the rules already set rorth ror other operations.

Examples 9 and 10 exemplify the Block Read and Block Write operatlons respectively. They are both shown as non-CPU slnce, at thls time, the CPU does not make Block rererences.

~306310 Application Or Epstein et al Example ~9:

Example ~9 (timing chart in Figure 312) depicts a block read by IOC 202 from memory.
,~ .

Cycle Description Bus Idle.
2 IOC 202 drives REQOUT to begin operation.
3 IOC finds neither BUSY nor WAIT down and thererore begin~
driving address and BUSY. Command 1~ a Block Read.
4 IOC notes that address was taken since WAIT was not driven. Memory drives WAIT for read access. IOC drives addre~s parity. IOC continues to dri~e BUSY for the Block Transfer operation.
Address parity is accepted and checked by memory. I~em continue~ to drive WAIT for access time. IOC continues to drive 8VSY.
6 Memory has completed the ac¢ess rOr the rirst double word and begins driving that data onto the LMB lines.
Mem releases WAIT. IOC 202 continues BIJSY.

Cyole Descrlption 7 Mem 18 ready ror the next transrer and sees that WAIT
was not asserted last cycle. Mem, thererore, drives the next 4 bytes Or data. IOC 202 is rast enough to accept the data and thus does not drive WAIT. The memory drivss data parity ror the rirst word. IOC 202 oontinues BUSY.
8 Once again, IOC 202 takes the data (no WAIT was asserted). The Memory pulls WAIT thls time, which allows it to ac¢ess the next couple o~ data words which are to be sent. IOC 202 ¢hecks parity on the rirst transfer Or data. IOC 202 ¢ontinues BUSY.
9-12 The memory continues to drive Data and Parity out, while IOC 202 is collectlng the data and ohecking parity for the next 2 4-Byte transrers. In cy¢le 12, Mem drives 13063~0 Applloation Or Epstein et al WAIT to give it time to access the next few data words.
IOC 202 still drlves BUSY.
13-14 IOC 202, here, is not ready to accept the data and, to indicate such, drives WAIT. The memory responds by drivig the data (again) in cycle 14. (The data in cycle 13 is X'd out since, by definition, it i~ not valid because WAIT i~ asserted.) IOC 202 continues BUSY.
5-17 The next two double words (fifth and sixth transrer) have been driven and received. Mem pulls WAIT down in cycle 16 to pend once agaln waiting on access time. The memory drives the ~eventh data word out onto the LMB in cycle 17 and releases WAIT. IOC 202 continues BUSY.
18 IOC 202 accepts the seventh data transfer and, since WAIT wa~ not asserted, releases BUSY. This is ln accordance with the defined protocol. One more data word is then expected. Memory drives WAIT to indicate that it is not yet ready to return data. Mem is also driving data parity for the seventh data transfer.
9-21 The final data transrer is completed as with any other read type operation with data parity rollowing right behind it. The operation is complete and bus idle at cycle 21.
xample J10:

The example (timirg chart depicted ln Figure 313) ~hows a very fast 8lock rite operatlon ~rom IOC 202 to memory. IOC 202 i~ shown as being able to ransrer all 8 double words ln apparently 8 consecutive BUS_CLK cycles. The emory i8 shown as being able to accept all Or them wlth only one WAIT inserted rter the 2nd double word transfer.

ycle Description 1 IOC has already made a request and begins driving Addres3 and BUSY 9ince neither BUSY nor WAIT was asserted last cycle.
2 IOC 202 drives Data ~1, Address parity, and BUSY.
3 IOC drives Data ~2, parity for Data ~1 and BUSY. Memory checks parity on address.
4 IOC drives Data $3, parity for Data ~2 and BUSY. Memory . ~

~ 13063:10 . , .
Applicatlon Or Epstein et al ,, checks parity on Data ff1. Memory is not ready to accept another data transfer, it thus drives WAIT.
IOC drives Data ~3 again. since WAIT was down last cycle. IOC continues BUSY. Memory chec~s parity on Data ~2. Memory releases WAIT because it is ready to accept more data.
6 IOC 202 drives Data ~4, parity for Data ~3 and BUSY.
7 IOC drives Data #5, parity for Data t4 and BUSY. Memory checks parity on Data #3.
8 IOC driveR Data ~6, parity for Data ~5 and BUSY. Memory checks parity on Data ~4.
9 IOC drives Data ~7, parity for Data ~6 and BUSY. Memory checks parity on Data t5.
IOC notes that the 7th word has been accepted and thus releaseB BUSY. IOC drives Data ~8 and parity for Data ~7. Memory checks parity on Data t6.
11 (not shown) - IOC drlves parlty ror Data tô. Hemory checks parity on Data ~7. Any LMB node could begin driving an ~;
address on the bus since neither BUSY nor HAIT was asserted last cycle.

12 tnot shown) - Memory checks parity on Data ~8. Block transfer is complete.

3.4.3.6 Interrupt Operations Any node on the L~B may communicate with the bus master (main processlng node such as the CP~) vla one Or the two interrupt lines. The INTR signal and the NMI signal rollow the same protocol and cause the master to respond by issuing a Read Special to the node wishing to report some interrupt condition. If multiple condltions are to be reported, INTR
andtor NMI may be held asserted until all interrupt conditionas are acknowledged by the master vis indlvidual speclal reads.

~xample ~

Application Or Epstein et al Example ~11 (timing chart depicted in Figure 314) shows an interrupt line being asserted during a Read Word operaion from the CPU. Note that even after the bus becomes free, the interrupt is not i~mediately acknowledged.
The acknowledgement will not necessarily come quickly, nor will it alway4 be the next transfer request (to that, or any other node) on the bus.

Cycle Description 1 CPU begins a single word read by driving BUSY and the address.
2 Mem wants to report an NY.I for the video board due to Break key interrupt. Mem also begins to drive WAIT for its normal read data access time. CPU drives address parity.
3 Mem now will hold NMI until it becomes acknowledged.
Mem is driving HAIT one more cycle and cheoking address parity for the read in proBress.
4 Data is now driven by tbe memory and WAIT is released.
Mem is waiting for NMI acknowledgement.
Data 18 received by the CPU, Parity is driven by the Mem. ~us is available for other transaction?3. NMI still not acknowledged. Note that another Read could occur and would complete even though an interrupt is pending.
6 Bus Idle. Data parity being checked by CPU.
7 The CPU i~ no~? ready to acknowledge the interrupt and thus does a Read Special to the memory node interrupt register. The CPU drive~ Busy as usual.
8 The addres?s was taken as is evidenced by the fact that WAIT was not asserted. It can be seen that the Memory had only one interrupt pending since neither INTR or NYI
is a~serted anymore. The CPU is not able to receive the data word back from the memory (the results of the RSP
command) even though the memory i8 ready to return the interrupt register data. The CPU drives address parity.
9 The data is repeated by the memory since WAIT wa~
asserted last cycle. The CPU is now ready to receive it and 90 it releases HAIT. Address parity is checked by the memory.

.: ? , , ~ ~ :

1306;~:10 .
Appllcation of Epsteln et al 10, etc. The data word ls accepted by the CPU, ~ollowed by parity and checking of parity, a~ usual. The CPU will now inform the software Or the interrupt condition though a series Or microcode and macrocode routines. Proper action will be initiated as a result.

3.4.3.7 Error Operation Error conditions are generally fatal errors such as multiple, unoorrectable b~t error,a in memory, or bus parity errors. U3ually, an att~mpt will be made, by the master processor (e.g. CPU) to retry the transfer that caused the error. In ,30me systems, however, this ERROR signal llne will simply be ignored. In either case the bus protocol ~ust remain intact.

The actual protocol i~ almost identical to that of interrupts. The ma~or difrerence is the efrect ond severity of the interrupt. Also, any node is only expected to keep track Or ths la~t error, should more than one error occur be~ore a servicing transrer has takenplace. In the interrupt case, however, no interrupt can be lost.

Example ~12:

Example ~12 (Or which the timing chart is depicted in Figure 315) discusses the timing Or an ERROR which happens because Or an address parity error and closely parallels the above INTR case. The CPU will handle the error a while arter it is not~fied.

Cycle Description 1 CPU begins a read double by driving BUSY and the address. , 2 Mem begins to drive WAIT rOr its normal read data acce,3s time. CPU drives address parlty.
3 Mem checks the address and rinds a parity error. It, therefore, drives ERROR. Since it is a Read, it ~3063~0 Appllcation Or Epsteln et al ~ completes the Read, even though it i9 probably the wrong i data. If this were a Hrlte, the memory may choose not to write, although this is neither required nor necessary.
4 Data is ncw driven by the memory and WAIT is released.
Mem will continue to drive ERROR in anticipation of acknowledgement.
Data is received by the CPU, Parity i8 drlven by the Mem. Bus is available for other tran3actions. ERROR
still not acknowledged. Note that another Read could o¢cur and would ¢omplete even though the ERROR is pend~ng.
6 Bus Idle. Data parity belng checked by CPU.
7 The CPU is now ready to a¢knowledge the ERROR and thus does a Read Specl?I to the memory node error register.
The CPU dri~es Busy as usual. -~
8 The address was taken as is evidenced by the fact that WAIT was not asserted. Memory releases ERROR as a result Or its error register being read. The CPU is not able to re¢eive the data word back from the memory (the results of the RSP command) even though the memory i3 ready to return the error register data. The CPU drives address parity.
9 The data is repeated by the memory ~ince WAIT was asserted last cycle. The CPU is now ready to receive it and so it releases WAIT. Address parity i9 che¢ked by the memory.
10, eto. The data word is accepted by the CPU, ~ollowed by parity and checking o~ parity, as usual. The CPU will now take appropriate action a~ a result Or the ERROR.

3.5 Electrical Characteristics or the LMB:

3.5.1 Timings:

All timings are in relation to BCLK on the ba¢kpanel:

Set-Up Time: 15 ns all signals except RE Q W T

Set-Up Time 55 ns REQ_OUT
.

Applicatlon Or Epsteln et al Max Prop delay10ns REQ_IN to RE Q W T

Hold Time: 10 ns all signals Margin Reqd: 4 n3 5% Or 80 ns cycle Bus Prop Delay: 10 ns LNB across backpanel Connector Delay: 1 ns per conneotor ror all slgnals '',~
3.5.2 Loading:

No more than 5 boards are allowed on the LMB- all on one continuous backpanel.

The Bus 19 rated at 50pf max. All nodes must drive that amount wlthin the given tlming constraints.

Each node must load the bus with not more than 8 pf capacitance on any signal except BUs CLK.

Each node must load the bus wlth not more than 16 pf capacitance on BUS CLK.

The bus is rated at 64 ma IOL max. All nodes must be able to sink that much current on all signals driven.

Each node must load the bu3 with not more than 10 ma o~ required low level supply on all slgnals except BU~_CL~.

Each node mu~t load the bus with not more than 5 ma Or reguired 10H
level supply on B~S_CLK.

~ ~ :

~ ` 13063~0 Application Or Epstein et al 3.5.3 Termination:

Only the backpanel will terminate the 43 LMB lines (not including BCLK, RE Q IN and RE Q OUT.) Each will be up/down terminated. The values of this termination are to be determined.

All nodeæ will have ^RE Q IN tied high via a 1R ohm resistor. This allows cards to be removed from the lowest priority end without the need for ~umperingthe backpanel. The CPU will only receive the RE Q OUT line Or the lowest priority node.

m e will be one point of up-down termination of BUS_CLR. 120 ohms up and 180 ohms down will terminate the 64mA driver correctly to a 72 ohm impedence, 3 Volt level and 41.3 mA required sink ourrent. This termination is located on the backpanel.

Individual boards may place high ohmage (greater tban 1~) pull up reslstors on any line tProvided that it does not violate loading rules) for testing purposes.

_116 1306;~10 ....
~ ~ Application Or Epstein et al ....
4. Detailed Descrlption ar NBus 205 4.1 Overview MBus 205 is a bus used for providing a method of lnterfacing expansion memory and video memory locally to LMB B w 203, by means Or which data may be transrerred to and from CPU 101 and IOC 202. MCU 201 perrorms all control funotions on the MBU5 205 and is thererore the only master. MBU9 205 is 39 bits wide, 32 bits provided for data and 7 bits ~or ERCC (error checking and correction) Or the memory (ERCC can be disabled). All transfers on NBu~ 205 are 32(39) bit data transrer~; two-way interleaving 18 supported to help speed accegses. The MBus 205 has been optimized for 120ns, 256R X 1, dynamio rams; however, flexibility has been designed into MBus 205 to provide a reasonable interface ror other devices.

MB w 205 provides a method Or ror CP~ 101 and other I-bus nodes to co G nicate with and use expansion, video, and other space memories. This interrace provides up to sixteen, 1 MByte banks Or memory to be attached to the OPUS cpu or I-bus node. Two-way interleaving is provided between two adJacent banks Or memories. Ei p t groups Or two banks are selected by tbe RAS select lines, the two banks in a group are used for the memory interleaving.

MBus 205 i8 designed to provide the rollowing reatures:

Up to 16 MByt Or memory rOr the OPUS cpu or I-Bus node.
Video memory Interrace .
Auxiliary memory-mapped devices.
Special spaoe memory lnterface.
Error correctlon ror the memorles.
Optlmal control or 120nS, 256~, ~ynamic rams.
~ Interrupt support ror devlces on NBus 205.
4.1.2 Conrlguratlon:

_117-13063~() Applicatlon Or Epsteln et al , .3 As ls seen in Figure 102, M W 201 is located on the OPUS cpu card, communications between the cpu and the memory control takes place over LMB
bus 203. 2 MBytes Or memory are provided on the processor board.
Additionally, 8 MBytes Or expansion memory may reside on a separate card connected to NBus 205. VCU 206 is also on a separate board and located on ~U8 205. The 2 MBytes Or memory on the cpu board occupy bank 0 and bank 1, the eight banks on the expansion memory card reside in bank 2 through bank 9, and the VRAMs 113 in bank 10 and bank 11.

4.2. Sectional Overview This subsection contains general information on the operation Or MBus 205.

4.2.1 Definitions:
.
Card:
A subset Or memory that has its own access control clrcuitry and has homogeneous parameters Or access time, error correction, etc.
Rank:
One o~ tbe sixteen ~ain subsets or memory. The MBus 205 supplles elghteen bits of address to each bank, providing up to 16 MBytes o~ ~emory.
Group:
A memory group consist of two banks Or memory, selected by one and only one of the RAS/CAS select lines. Two-way interleaving is supported between banks within a group.
Error Correction:
The ability to detect a sinele blt error during the read Or a 32 blt double word and correctlng that bit producing an error rree double word rOr use by the system. Additlonally the double blt errors are detected, and given that one is a hard error, the double bit error can be corrected.
.

-.

` 1306310 Applloatlon Or Epsteln et al ., ~` Memory Controller tController):
~- The devlce which ls the master Or MBus205. The ~; controller provides all addresses and all data ~or write operations. It i9 the receiver Or data from read operatlons. The controller is responsible rOr the interface between MBus 205 and any external - -bus (or interface). The controller is also respon-sible ror Error Correction ( each bank must be able to store the 7 bits needed for the correction ).
The controller also periodically provides refresh ~or dynamic RAMS.
Double Word:
A double word is derined as a 32 bit quantity.
4.2.2 Signals 4.2.2.1 Signal Groups Physical b, MBus 205 consists or 89 lines. These 89 lines can be divided into four group~: Data, Address, Bus control, and Interrupt support. Below is a breakdown Or the four groups. (An ^
indioates that the named signal i asserted when the line is TTL
low.) Data:
32 MBD Trl I/O Data lines.
7 MBE Trl I/O Correction bits.
Addr 8:
18 MBA Tot Out Address lines.
~ RASsel Tot Out RAS Select.
8 CASsel Tot Out CAS Select.
Control:
1 STEven Tot Out Start Even Access.
1 STOdd Tot Out Start Odd Access 1 SelE/^O Tot Out Select Even/^Odd CAS.
1 BUS/^CNT Tot Out Bus/^controller address.
1 ^MBWE Tot Out MBus 205 write enable.
1 ^ W TE Tot Out Enable Outputs.
1 Other Tot Out Other space.
1 ^ B CCDis O.C. In E~CC disable.
1 ^MemWait O.C. In Memory access wait.
1 ^MBCLK Tot Out Memory Bus Clock.
:, ~
Interupt support:
1 NMIA Tot In Non-msskable Intr. A
1 NMIB Tot In Non-maskable Intr. B

_ .

,,s" ~ " : : ~"

~ ~ ~3063~0 ~; Application Or Epsteln et al 1 MIA Tot In Maskable interrupt A
1 MIB Tot In Maskable interrupt B
1 CNMI Tot Out Clear NMI
1 CMI Tot Out Clear NI

total 91 Notes: Tri - indicates tri-state bus.
Tot - indicates totem-pole outputs.
O.C. - indicates open collector bus.
I/0 - indicates bus i9 used for both input and output.
In - lndicates that the controller uses the signal as an input, and that the contoller Nill never dri~e this line.
Out - indicates that the controller uses the signal as an output. Devices other than the controller should never drive this line.
4.2.2.2 Data There are 39 signal lines in the data group. They are as rOllaWS:
NBD<0-31> MBU8 205 data lines. These lines are used to transl~it data to and rrom memory.
MBE<0-6> MBus 205 ERC llnes. m ese lines transmit information ror the error correction bits.

4.2.2.3 Address There are 34 lines used for addressing the memory. They are as rOllOws~

NBA<0-17> MBus 205 address lines. m ese 18 lines select ~hich byte within a bank is being accessed. The eighteen lines provide 262144 unique addresses within the bank.
RASsel<0-7> RAS Seleot lines. Each Or the eight lines selects one group ( 2 banks ) Or memory. During norm 1 accesses only one line is asserted. All RASsel lines are asserted during the rerresh cycle.
CASsel<0-7> CAS Select lines. Each Or the eight lines selects one group ( 2 banks ) Or 13063~0 ~ ~ Appllcatlon Or Epsteln et al `~ memory. Only one CASsel line is as3erted~,~ at any one t1me.
MBDC12-29> MBus 205 data lines. ~hen Bus~^CNT is hlgh tbe word addresg is valid OD these llDes.

.2.2.4 Control slgnals There are 10 ¢ontrol slgnal~ on MBus 205:
STEven Start even access. Indicates that an access to the even bank of a group ls to be started.
STOdd Start odd access. Indicates that an access to the odd bank of a group 18 to be started.
SelE~^O Select an even or odd CAS. Selects between the even or odd bank within a - group.
B~S~^CNT Address select from Bus or controller.
Ind~cates Nhere the address ~ignal is valid ~rom. If asserted the valid address is on the data lines, i~ lcw the address line contain the valid address.
^MBWE MBus 205 write enable. Indicates that the current data on the bus ls to bs written into ourrently addressed memory location.
^O~TE Enable Outputs. Enable the drivers on the selected memory to place data on the NBus data and error correction buses.
Other Other space. Indicates that the current transfer is to other space memory.
^ERCCDi3 ERCC disable. Indicates that the curren-tly addre~s board does not use ERC bits and the controller should ignore MBE<0-6>
on the N3U3.
^Mem~ait Nemory access wait. Forces the memory controller to wait until the currently addressed location has completed the operation. ^Mem~ait need not be asserted if the memory can per~orm the operation ;: 13~6;~0 :
,;
Appllcation o~ Epstein et al :, ~^. ~
~f in 120 ns.
, ^MBCLR Memory bus-clock. This is the master clock on MBus 205; lt has cycle ~-time Or 80ns.

4.2.2.5 Interrupt support:

There are eight lines to provide interrupt support for MBus 205;
speci~ically they provide 2 maskable and 2 non-maskable interrupts.
.
MMIA Non-maskable interupt A. This lnterrupt is non-maskable by the memory controller.
Asserting thi_ line causes an interrupt to be signalled to the CPU or I-bus node.
FMIB Non-maskable interrupt B. This interrupt is non-maskable by the memory controller.
A~serting thi~ line cau~es an interrupt to be signalled to the CPU or I-bus node.
MIA Maskable lnte~rupt A. This lnterrupt is a maskable interrupt. If the mask out register is asserted then the interrupt i8 ignored untll the mask out register is de-asserted. When the NIA line iA
asserted and the mask out register is un-asserted, the CP~ or I-bus node is lnterrupted.
MIB Maskable interrupt B. This interrupt ls a maskable interrupt. If the mask out register is asserted then the interrupt is ignored until the mask out register is de-asserted. When the MIA line is asserted and the mask out register is un-asserted, the CPU or I-bu3 node is interrupted.
CNMI Clear no~-maskable interrupts. Indicates that NHI's have been acknowledged and the souroe Or the interrupt should de-assert NMIB.
CMI Clear maskable interrupts. Indicates that MIA's have been acknowledged and the source Or the interrupt should de-assert MIA.

.. . - . . .

~306;~10 , Appllcation Or Epstein et al ,~:
4.2.3 Addressing.

The address space is 16 MBytes organized a~ eight 2 MByte groups, with each group containing two 1 MByte banks. A bank consist o~ 262144 locations 32 bits wlde. Additionally a secondary address space called "special space~ exist on MBus 205 as well.
This special space is organized identically to regular space witb the Other line determining which area is to be accessed. The eight RASsel and eight CASsel lines correspond directly to the eight groups, (RASselO sele¢ts groupO, which contalns bankO and bank1, ~ASseli selects groupl, which contains bank2 and bank3, etc.). The SelE/^O lines determines which bank within a group is selscted. If the line is hlgh then the even banks ( bankO, bank2, bank4,...) is selected, if low, the odd banks ( bankl, bank3, bank5, ...) is selected. The eighteen address lines ( MBA<0-17> ) determines the double word location within the bank is to be addressed. See Fig. 401.

Consecutlve addresses in memory alternate between banks within a group. The first lngical address i9 location zero in bankO, then next address is looation zero in bank1, then location one in bank 0, location one in bank 1, etc. The logical address ln groupO is looation 262143 in bankl the next logioal address ls location zero bank2, looation zero bank3~ location one bank2, etc. This addres-aing aoheme allows two-way interleaving between banks within a group.

- ` ` 1306310 Applleation Or Epstein et al Loeatlon BankO ~ank1 O logical O logieal 1 1 logical 2 logieal 3 2 logical 4 logical 5 3 logical 6 logieal 7 .

262143 logical 524286 logical 524287 Bank2 Bank3 O logical 524288 logical 524289 1 logie~l 524290 logieal 524291 .
Bank14 Bank15 :
.
262143 logieal 4194300 logical 4194301 .2.4 Control Funetions The ~B w 205 performs two data transrers, read Or a 39~ 32 ir ERC is not used on the current bank) bit double word and the writing of a 39 bit double word. ~he two operationa can be com-bined in the rollowing way~

Simple read, read one 32 bit double word. ~; ;
Double read, read two 32 bit double words rrom consecutive double words, restricted to consecutive double words in the same group, with location addresse~ being equivalent.
Simple wrlte, write one 32 blt double word. Double wrlte, write two 32 bit double words into memory, restricted to conseeutive double words in the sa~e group, with the location addresses being equivalent.
Read-Modify-Write read a 32 bit double word, modl~y that double word and wrlte it back to the same location.
Double R-M-~ two eonseeutive read-modiry-write operations, within the same group and to the same loeations.
Rerresh/Snir~ All banks are RASsel'ed to indieate that a row i8 to be rerreshed, one loeation is ~eleeted by CASsel . .
Application of Epstein et al ... .
and SelE/^O to be read from, and if an error exists lt i8 corrected and rewrltten lnto the same location.
., .

4-2.4.1 Baslc Read Operatlon:

The baslc read operatlon consists of three phases: Addre~s phase, read start, and data phase. The address phase betins by having a valid address placed on MBus 205. The address 18 initially placed on MBus 205 data lines, and later on the address becomes valid on the MBus address lines. Ir BUS/^CNT is hlgh then the address ls to be taken from the MBus data lines, when low the address is v~lid on the MBus address lines. ~lso durlng this time the RASsel llnes become valld.

The read ls then initlated on the rising edge of the either the STEven or STOdd lines, at this point in time the address i8 valid and the memory should begin the operation. The memory 19 then expeoted to be able to supply valid data 143ns rrom the rising edte Or this signal. If th~ memory is unable to supply the data, the MemWait signal should be asserted until the memory can have the valid data ror the MBus.

Arter at least 143ns, the memory 18 requested to place its data onto the MBus via the ^OUTE sitnal. When the ^OUTE signal iR
as~erted the data is enabled onto the MBus and held until ^OUTE is de-asserted. When the memory controller has latched the data, either ^OUTE or STEven ~STOdd) is de-asserted.

4.2.4.2 Double Read:

The double read operation ls two simple reads placed back to baok, slnce an operation has taken place already, the RAS pre¢harge tlme has been met for the second operatlon. Because Or thls ract the second read is started immediately, producing the two-way interleavlng. The operation i8 similar in function to the simple : ~ ~306;~10 Appllcatlon of Ep~tein et al read except that the simple read is performed twice.

The double read is initiated by placlng a valid address on the ~U9, as well a valid RASsel, CASsel, and SelE~^O lines. The transaotio4 is then Qtarted by the assertion o~ STEven, the ad-dressed memory then begins its access. When the NBus has been cleared and 143ns have passed, ^O~TE is asserted and the value read by the memory controller. The 143na access time can be extended by the MemWait signal. Arter the data is latched STEven is de-a3serted. At this time all addresseQ are still valid.

The second read is immediately initiated wlth the STOdd command, the odd bank o~ the group then acces3es it addressed location and makes the data ready. A~ter 143ns the ^OUTE has been asserted and the data latched by the controller, again the acces~
time can be increased by the banks assertion Or the ^MemWait line.
~oth ^OUTE and STOdd are de-asserted. During the middle Or the last read the address lines will become invalid.

4.2.4.3 Simple Write Operation:

The simple write operation con3ists of three phases like the read operation: address pha3e, command initiate phase, and the data phase. The address becomes ~alid on the MBus address lines, RASsel, CASsel and SelE/^O llnes. The command 18 lnitlated with the riaing edge Or elther STEven or STOdd, at this point the operation is identical to the read operatlors. Then the operation varies, instead Or the controller asserting ^OUTE, the controller places the data to be written into the memory onto the MBuA, when the data is valid the controller asserts the ^MBWE line. On the active edge Or this signal the memory iQ to write the data on the NBus data lines into the memory.

4.2.4.4 Double Write Operation:

. . .~ . ;
.,, , . ~ .

- .

:` .

1;~06~10 .~ .
~ Application of Epstein et al "
The double write operation consists o~ two write operations happening back to back. The first operation is initited ~y the STEven signal, after the data is written into memory, STEven is de-asserted. STOdd is then asserted and the next double word ~ritten into memory. When the double word has been written STOdd is de-asserted and the operation is complete.

4.2.4.5 Read-Modify-Write Operation:

The read-modlfy-write operation begins identically to a simple read operation, the address becomes valid and the access started.
^W TE is asserted and the data read after 143ns. The controller then de-a~serts ^OUTE and modiries the data internally. The modi~ied data is then placed on the MBus data lines, when the data i8 stable the ^MBWE line is asserted and the data written into the currently addressed location. Data is only held for 50ns after the rising edge Or ^MBWE. The operation is complete when STEven (STOdd) is deasserted.

4.2.4.6 Double Read-Modify-Write Operation:

The double R-M-W operation conslsts of two R-M-W operations happening back to back. The first belng to the Even bank and the second to the Odd bank.

4.2.4.7 Refresh~Snirr Operatlon:

The Rerresh operatlon is a special operation for the rerre-shing Or dynamic memories. The operation is started by placlng a valid address on the MEus. All ei pt Or the RASsel lines are asserted. Both STEven and STOdd are asserted sim~ltaneously, all memories on the MBus should assert their RAS'es refreshing a row One memory location is selected by the CASsel lines and the SelE/^O

~3063~0 Application o~ Epsteln et al line, this location should pre~ent its contents onto the MBus when ^ W TE is asserted. If the data needs to be written back into memory, the ^OUTE is de-asserted and the new data presented on the MBus. ^MBWE is then asserted and the data written back into the MBu~. At the end of the operation all control signals are de-asserted.

4.2.4.8 ERCC Disab~e:

If a bank of memory does not have the extra bits for error ¢orrection, that bank of memory must assert ^ERCCDis during reads.
Asserting the line cau~es the controlle- to ignore lines MBE<o-6>.
Any error3 ln the read operation are then propagated to the source, a~ if no error had occurred.

4.2.5 Timing Sequences The followlng dlagrams illustrate the operations on the MBus, they are intended to describe the ~equencing Or the operations. For information on electrical and timing values see the chapter on electrical specifications.

Flgure 502 et seq 4.2.6 Dynamlc RAM cycle lnitlalization.

Immedlatly after a power up of the MBus MCU 201 provldes elght RAS only rerresh cycles on the bus. m ls ls supplied to insure the proper start up of the dynamlc RANS. The cycle looks llke elght consecutlve refresh operatlons.

4.2.7 Interrupt ~ervice:

; , . :

Application Or Epstein et al Four interrupts are provided on the MBus. Two maskable interrupts (MIA and UIB) and two non-maskable interrupts (NMIA and NMIB). Two interrupt clear signals are provided (CNMI and CMI) one for the non-maskable interrupts and one for the maskable interrupts. ~ach interrupt is level sensitive, as long as a line is asserted an interrupt is pending. An interrupt may be asserted at anytime with the following exception, when the corresponding interrupt clear is asserted the lnterrupt llnes mu3t be cleared.
New interrupts should not be asserted until after the clear line has been de-asserted. The lnterrupts MIA and MIB are cleared by CMI. The interrupts NMIA and NMIB are cleared by CNMI. The maskable, non-maskable interrupts, and their corre~ponding clear~
are lndependent Or each other.

Flgure 510 illustrates the interrupt sequence~

8ecause one clear llne corresponds to a two interrupts a mechanism ror insurine an interrupt i8 not lost. If during the clock perlod that the interrupt is asserted, the clear llne ls also asserted then the current clear pulse ls not acknowledging the interrupt. Fleure 511 shows this situation.

4.3. Electrlcal Characteristlcs 4.3.1 Signal States:

A slenal may be ln one o~ two levels, either hlgh or low. A
"hlgh" refers to a hlgh m level ( >= +2.0V ), a "low" refers to a low m level ( <= +0.8 V ). All signals when valld are to be in one o~ the two levels, sienals are allowed to be in transition ( <=
l2.0 V and >= ~0.8 V ) but are considered invalld during tbe transition time. A signal is asserted when it is in a valid level and that level repre~ents the signal to be logically on. All signals preceded by a n^n are considered asserted when the signal is low. The remaining sign~ls are consldered asserted when the -129_ 1306~10 Application o~ Epstein et al signal is high.
.

4.3.2 Signal types.

Their are three types of signals on the MBus 205, totem pole, tri-state, and open-collector. The signal types are determined by the device that can drive the signal. A totem-pole driver is a one that can force a line into both the high and low states. An open collector driver can only force the line into the low state or turn itsel~ off, not affecting the v~lue o~ the line. A tri-state driver oan force a line into both the high and low states as well as turn itself of~ (not arfecting the contents ~f the MBus).

When a tri-state line ls not being driven it is ~loating, all tri-state lines float into the high state. When an open-collector line is not belng foroed into the lcw state, a p~l1l-up (located on the same card as the controller) causes the signal to be a high.

4.3.3 Signal Loading The following lines have TTL outputs and the following oharaoterlstics:

STEven STOdd SelE/^O BUS/^CNT
^MBWE ^OUTE Other ^MBCLR
^CNMI ^CMI
MAXIMUM LOAD PER M~US:
High -12 Ma Low 8 Ma Capacitance 100pf MAXIMUM LOAD PER CARD
Hlgh -3 Ma Low 2 Ma Capacitance 25pr The rollowing lines have the rollowing drive requirements:

:: :
~3063~0 ~ Application Or Ep~tein et al :
MMIA NMIB MIA MIB
Drive Requirements:
High 40uA Low -17 Ma Capacitance 50pP
~OTE: Only one device should drive these lines.

The Pollowing open collector lines must have the rollowing drive requirements:

^ERCCD~s ^MemWait Drive Requirments: -~
Low -17 Ma Capacitance loopr The Pollowing tri-state line~ have the follcwing drive and load requ~rements:

MBD MBE
Drive Requirements Hlgh 12 Ma Low 48 Ma Capacitance 150 pr MAXIM~M LOAD PER MBUS
Hi p 8 Ma LoW 24 Ma Capaoitanoe 100 pP
Maximum load per card Hlgh 2 Ma Low 6 Ma Capacitance 25 pr 4.3.4 Termination and Pull-ups .

Ul llnes except ^ERCCDis and ^MemWait are terminated with 220Ohms to l5 and 330 ohms to Ground. The ^ERCCDis and ^MemWait lines are pulled up with lR ohm resistors.

130631~) . Applicatlon Or Epstein et al ,. . .

4.3.5 Timing:

Signals are generally asynchronous; however, some signals are constrained to be valid within certain periods of ^MBCLR.

4.3.5.1 Bus Clook~

See Figure 512 4.3.5.2 Bank select setup and hold:

See Figure 513.

4.3.5.3 Address Setùp and hold times.

See Figure 514.

4.3.5.4 Memory Access Requirements: ( leaving ^MemWait unasserted ).

See Figure 515 4.3.5.5 Write Data Setup and hold:

See Flgure 516 4.3.5.6 ^MemWait signal requirements:

See Figure 517 4.3.5.7 ^ERCCDis times:

See Figure 518.

4.3.5.ô Non-maskable interrupt timing:

~ . .. . .... . ... . . . . . . .... .. . ... . .. ... . . .. . .

~306310 ~ ~ Application of Epsteln et al .

.~ See Flgure 519.

i' .

~ 1306;~10 ~ ~ Applicatlon of Epstein et al ~. .
5. DETAILXD DESCRIPTION O~ VCU 206 5.1 OVERVIEW

Re~erring to Figure 102, VCU 206 provides high resolution color graphlcs (1280 x 1024), u~ng 8 bits per pixel. Video Expansion Unit (VEU) 207 may optionally be included to expand the pixel size to 24 bits, giving the effect Or a 24-bit VCU 206. (NOT~: In the ensuing discusslon, "V W 206~8" shall mean th~t VEU 207 is absent and the pixel size is eight bits; "VCU 206~24" shall mean that VE~ 207 is pre~ent and the pixel ~ize is 24 bits; bald reference~ to ~VCU 206" shall apply regardless o~ pixel size.) VEU 207 includes augmentation Or VRAMs 113; thls does not provlde additlonal VRAM locations, but expands the slze of the existlng lccationQ from 8 to 24 bits. VCU 206 drlves a 60 hertz non-interlaced 19" ¢olor monitor. The video outputs to the monitor are RGB
tRED-GREEN-BLUE) sync-on-GREEN with 75 ohm drive impedance.

Pixel data retrieved from VaAMs 113 are not written to the screen directly, but are input to a table lookup function. The table, contained in a separate RAM and known as a "paletten, outputs a 24-blt number. Eight of the 24 bits are converted from digital to analog to provlde the RED video signal, e~ght provide the BLUE, and eight provide the GREEN. There are thus 224 or 16 million colors whlch can be displayed. 8-blt pixels can display any 256 o~ the 16 milllon colors at any given time; the selectlon of whlch 256 may be altered by reloading the palette RAM. 24-bit pixels can display any of the 16 mlllion colors; the corre~pondence of pixel value to color may be altered by reloading the palette RAM.

VCU 206 and VEU 207 con~orm to the Graphics Instruction Set (GIS) ~descrlbed in U.S. Patent No. 4,873,652, issued October 10, 1989 to the applicant).

VEU 207 must be used in con~unction with VCU 206 and connects to VCU 206 via 44 signaIs on the backplane. It provldes an additlonal 16 blts per pixel bringing the total bits per pixel of the graphics display from ô to 24. VEU
207, having circuitry analogous to that ln VCU 206, will not be described in detail. Section 5.5 addres~es the dlfferences between VCU 206 and VEU 207.

, .
.~ ,.. . .

- Appllcation Or Epst d n et al .
;~ Pixel data rrom the host computer may be written directly into YRAMs 113, or miay be combined according to various Boolean rules with data previously in VRAMs 113.

VCU 206 may be operated in ~block moden, "plane moden, or "character moden. tnPixel mode~ is a special ca~e Or block mode, where one pixel at a time is transmitted, while blook mode permits transmission of any number Or bits up to 32.) Block mode provides the moot flexibllity, since any Or a great number Or colors may be drawn at any screen position, but reQUires the host to rorward every bit Or every pixel Or a desired display. Plane mode allows the ho~t to modify a partlcular blt position Or a number Or pixels 3$multaneously.
Character mode is provided to enhance performance, at the expense Or limiting the number Or color~ that oan be displayed ~or a given palette loading to 9 for VCU 206/8 or to 25 for VCU 206/24. Character mode ePrects "planes" or "layers"
Or displays (eigbt planes for VCU 206/8, 24 plane3 ror V~U206/24) wherein the color Or each plane need be speclfied only once, "higher" planes may obscure "lower" plane~, and the host need only send a single bit (denot$ng "0N" or "0FFn) for each pixel position o~ each plane. For example, if it is desired to display a bar graph in which:

1. the background is blue;
2. a green grid ls presented;
3. the bars are yellow; and 4. red labels may appear on the bars, then lt is nece~sary to:
1. a. specify tkat the color ar the background is blue by;
i) loading location 0 Or the palette with a number that errects display of the desired blue; and ii) clearing VRAMs 113 to all 0's, meaning that all palette lookups will access palette location 0 yielding the desired blue of the background;
c. load palette location 1 with a number that i9 displayed as the desired green for the grid lines;
d. load palette locations 2 and 3 wltb a number that causes display Or the yellow desired ror the bars;

:: ~ 1306310 Application of Epsteln et al e. load palette location 4, 5, 6, and 7 with a nu~ber that causes display Or the red desired for the labels;
(at this point, the VRAMs still containing all Ot8, the screen will be entirely blue, the color specified in palette location O);
2. provide one-bits (denoting ~ONn) to the least signi~icant bit (the "lowest planen) Or the p~xels at positions corresponding to the screen position~ comprising the desired 8reen grid line~;
(these pixels will then contain a value of 1, with the result that palette lookups access palette location 1, yielding 8reen; at this point the display will be a green grid on a blue background) 3. "OR" ln one-bits to the next least signiricant bits Or the pixels (the nsecond planen) at positions corresponding to all screen positions ! constituting the desired yellow bars;
(these pixels will have v~lues Or 2 if ORed with a blue background pixel or 3 if O~ed with a green grid line pixel-- in either ca~e, palette lookup yields yellow. Thus, the green grid and blue background are not visible on the yellow bars-- those screen positions contain pure yellow, and not a superimposition or mixture of yellow, blue, and green.) 4. OR in one-bits to the next least signiricant bits (the "third planen) Or the pixels at positions requisite to producing the desired labels.
(These pixels will tben have value~ Or 4 or t, ~ either Or which causes palette output Or red.) The desired bar graph is now displayed on the screen. Although some of the data is obscured (namely, the portions Or the yellcw bars that are under red labels; the portlons Or the green grid that are under yellow bars; tbe portions of the blue background that are under green grid lines) it is still present in VRAMs 113 and will again become visible when the overlaying data is removed.
For example, if zero-bits are sent to the third plane, thus erasing the red labels, the yellow bars will again be ~ully visible with no need to reconstruct any portion Or them; likewise, if zero-bits are sent to the second plane to erase the yellow bars, the green grid will a8ain be fully visible without having to reconstruct it.

Full detail on how to accomplish the arorementioned operations i8 provided hereinbelow.

~ 1306310 Appllcation of Epstein et al y~
5.2 FUNCTIONAL DESCRIPTION
,~, -5.2.1 Hardware Overview Refer now to Figure 501. In the preferred embodiment, VCU 206 and VRAMs 113 are contained on a circult board (Graphics Processor Board 301) whlch is a 15~ x 15" 6 layer board with etch wldtb of 8 mils and etch spaclng Or 8 mils.
The board contains the following maJor components:
o 64 256k VIDEO RAMS 113 with assoclated drlvers and buffers o Address mapping circultry 302 for recelvlng addresses over Nemory Bus 205 and translatlng ~ame to physlc~1 addresses wlthin VRAHs 113 o Data manipulatlng clrcuitry 303 for performing manipulations on data received over Kemory Bus 205 or contained in VRANs 113, and for storing manipulated data ln VRAMs 113. (As wlll be discussed in further detail below, data manipulation circuitry 303 is mainly constltuted by elght Graphics Data Processor (GDP) gate arrays (314 on Figure 502)).
o MicroProcessor 308 for providing overall tlming and control.
o %lgh Speed Output Stage 304 for acoes5slng display data fro~ VRAMs 113 for dlsplay.
o Palettes 309 and Lookup Table 305. Each p~xel value retrieved from VRAMs 113 i~ converted to corresponding RED, GREENj and BLUE values.
o Dlgital-to-Analog Converters 306 for convertlng the RED, GREEN, and BLUE values to corresponding analog vldeo 9lgnals ror directly driving the video monitor.
o Reyboard inter~ace 310 ~or interfacing keyboard 311 through which the user ma~ manually enter lnformation.
o Mouse lnterface 312 for interfaclng Mouse 313 through ~hich the user may enter in~ormation on screen position.

The keyboard, mouse, and vertical blanking ~or the video monitor all interrupt the host processor vla NNIs (non-maskable lnterrupts). The serviclng of NNIs is very fast relative to norm 1 interrupts because the host does not have to is~ue a VECT instruction, or reschedule tasks upon receipt of the interrupt.

: 1306310 Application of Epstein et al The mouse can interrupt the host aQ fast a~ every 33 milllseconds.
Servicing Or the mouse, which includeq cursor plotting/replotting, should require no more 50 microseconds out of every 33 milliseconds o~ time. This is a total of .15% Or the ho~t's cpu time when the mouse is mov~ng, which relatlvely speaking, is not oPten.
!
The keyboard constantly interrupts the host at an interval Or 80 milliseconds. The time required to service the keyboard when it is idle is about 25 microseconds, a total Or .03% of the hosts cpu time. I~ the keyboard i8 not idle, the time to service it is about 200 microseconds.
~ith a typist who can type 60 words~minute (a word being 6 characters), the interrupt load ls equal to about .1# Or the hosts cpu time.

Vertical blanking interrupts can be used to pace the color palette updates. YCU 206 only updates palettes during vertical blanking. It takes 6 rrames to rully update the 3 256-color palettes. Multiple attempts by the syste3l to update the palettes in less than one ~rame will not be realized. The system can use the vertical blanking interrupt to indlcate that VCU 206 has updated the palettes, and to issue another update ir requ~red. Since this function can be done via setting a flag, the tlme to servi~e the interrupt is considered negligible.

Total load on the system, worst case, including both mouse and keyboard, i3 estlmated to be approximately .27S Or the total CPU time.

5.2.1.1 Pixel Flow Overview (Block Mode or Plane Mode) (NOTE: This discussion is ln terms of 8-blt pixels; a discusslon rOr 24-bit pixels would be analagous.) Rererring to Figure 502, pixel data is sent from the host CPU over Memory Bus 205, is processed by tha Graphic Data Processors 314, and eight-bit pixels are stored in "bit map" ~orm in VRAMs 113.
NOTES: 1. The term "host CPU" may refer to CPU 101 Or the local processor, or saDe other node on the I-Bus, as discussed in section 2.) 3063iO
Application Or Epstein et al 2. The "processlng" performed the Graphic Data Processors 314 may take the form Or aligning pixels from the 32-bit bus word onto VRAM pixel boundaries, merging incoming pixel data with pixel data prevlously in VRAMs 113, and the like, all to be described in detail further below.
As is ~ndicated by the bldirectionality Or the arrcw connecting GDPs 314 and VRAMs 113, GDPs 314 have the capability, in response to commands from the the host CPU, to extract bit map data rrom VRAMs 113, perform manipulations upon it, and return it to VRAMs 113. Writing to VRAMs from the host is known as an external" accessn; the latter case is called an "internal" access.

Circuitry 304 extracts bit map data from VRAM's 113 and transforms each pixel to a desired video representation as directed by palette 309 under control of palette lookup table 305. Digital-to-analog converters (DACs) 306 transrorm the video representations to red, green, and blue video slgnals which are ~orwarded to the video monitor ~or display.

5.2.1.2 Character Mode Overview Character ~ode data rollows essentially the same path as pixel data, but is handled difrerently, as shown ln Figure 503. With reference to the bar graph example set rorth in Sect~on 5.1, suppose that as part Or writing the red label~ on the yellow bars it is desired to write the character "An. A
repreJentation Or the character "A~ (element 315) is shown as it mlght appear in a ~rOnt~ Or character3 (fonts, well known to those in the art, may be thought or as prestored bitmaps Or orten-used graphic entities). The prestored oharacter-mode (one bit per pisel) bltmap ror "A~ is shown as element 331.
Where the bitmap contain~ a 1, the color denoted by foreground register 333 will be diQplayed at the corresponding screen position; where it contains a 0, the color denoted by background register 332 will be displayed. The means Or loading the roreground and background registers will be discussed in detail below. The discussion Or the bar graph example ln sectlon 5.1 did not consider use Or these register~; they enhance rlexiblllty by permltting, ~or example, red labels on a black background on the yellow bars. It i9 assumed here that the background register contains a value denoting the yellow Or the .` ;
~ 13063~0 Application Or Epstein et al ' ~ ' `
bars and that the foreground register contains a value denoting the desired red Or the labels.

Figure 503 shows the flow Or the first line Or font bitmap 331; lt i9 sent to VCU 206 via the rightmost five bits Or memory bu3 205, and is 8ated into VCU
206 under control Or ~ask register 317, Or which oniy the rightmost five bits are made permissive (set to 1). It is obvious that other font widths can be accommodated by adjusting the pattern in mask register 317 accordingly.

The GDP 314's will now produce the five pixels necessary to display YELLOW-YELLoW-RED-YELLO~-YELLOW on the qcreen, as ls nece~sary to display the top line Or the "A" in ~ont 315 on the background Or the yellow bars. Each GDP
314 (it will be recalled that there is one GDP 314 for each screen pixel bit~
looks at the five font bits. For each ront bit, each GDP 314 outputs its bit Or the roreground pixel for a font bit Or one, or its bit Or the background pixel for a font bit Or zero, the overall output thu3 being pixels Or as many bits as there are GDP 3148 (8-bit pixels for VCU 206/8). That these pixels are displayed at the desired plac~ on the screen is a function Or having provided the appropriate X and Y scree~ coordinates, to be discussed rurther below.

.2.2 Programming Overview 5.2.2.1 General The video memory (VRAMs 113) contain~ video information whlch is continuously displayed on the screen. The smalle_t picture element that is addressable in the video memory ls called a pixel. Each pixel contalns information that correspouds to a v~1ue that the pixel can take on.
For VCU 206/8, a pixel is represented by 8 bits Or video memory, and can take on any one Or 255 possible values. For VCU 206/24 a pixel i8 represented by 24 bits Or video memory, and can take on a~y one Or 16,777,216 (written as 16M rOr future discussion) possible values.

There are 1280 pixels di3played horizontally and 1024 pixels dlsplayed vertlcally. Tbsre are aotually 2048 VRAM locations horizontally, the laqt 768 J _140_ '`'~ ,:

13063~0 ~ Appllcation Or Epstein et al :-Or which are never displayed. This section Or the video memory can be used tostore temporary pictures, iconQ, character roDts, or small windows Or data.

Each blt Or the pixel is called a 'plane'. When configured as an 8 bit per pixel controller (VCU 206/8) there are 8 planes. ~hen configured as a 24 bit per pixel controller (VCU 206/24), there are 24 planes.

The pixel plane bits are passed to the address rield Or a hlgh speed RAM
lookup table. The data returned by the RAM is then passed to the video output stage. This table allcws the pixel information stored in tbe video memory to be rederined berore being displayed on the screen. This RAM is called the color palette.

On VCU 206/8, 8 bits o~ ln~ormation are placed on the RAM address lines and 24 bits Or data are returned. Because each pixel is 8 bits wide, it can take on any one Or 256 values. The colors represented by the values can be chosen from a range of 16N, since the palette output is 24 bits.

VCU 206/24, with respect to the color palettes, i8 essenti~1ly 3 YCU 206/8 designs in parallel.

5.2.2.2 NORMAL space and OTHER space As desorlbed in section 4, a control bit i9 provided on 15-~us 205 lndlcating whether accesses are to ~NOaMAL" space or "OTHER" space. All accesses to the vldeo memory are done thru NORMAL space. All registers, except the X and Y, SWRCE and DESTINATION registers, are accessed thru OTHER space.
The X and Y, SWaCE and DESTINATION registers are loaded during the address phase Or a NORMAL space access. (nAddress phase" and "data phase" are also discussed in section 4.) Thiq is necessary because the X and Y vaIues Or a pixel position are uset to form the video memory address for the pixel and must be set up prior to the data phase Or the access.

.2.2.3 Restrictions .

3063~0 Application Or Epstein et al VCU 206 is designed to read and write the video memory on pixel boundaries. To accomplish this, VCU 206 manipulates the data internally.
Furthermore, on write cycles, VCU 206 performs a read-modify-write cycle internally. MCU 201, the M-bus controller, is also capable Or perrorming read-modify-write cycles, but cannot manlpulate the data in the same manner as VCU 206. VCU 206 expects only simple reads and writes via the M-bus. If MCU
201 performs a read-modify-write to VCU 206, indeterminate results will occur.

To ensure that MCU 201 executes only simple reads and writes to VCU 206 the following progranming rules must be followed:

o For NORMAL space accesses to VCU 206 only even double word reads or writes are allo~red. Specirically, odd double word reads or wrltes, byte reads or writes, and word reads or Nrltes are disallowed.
o For OTHE~ space accesses to VCU 206, by definition, only even double word reads or write9 are allowed. Specifically, odd double word reads or writes, byte reads or writes, and word reads or writes, are disallowed in the present embodi~ent.
5.2.2.4 Types Or vldeo memory acc~sses VCU 206 ls capable of the rollowing types of video memory accesses:

o Host processor to vldeo memory accesses (and vlce versa).
o Video memory to vldeo memory accesses.
o Speclal character write accesses (rram host processor to video memory The ror~at in which the data is packed is BLOC~ form - the 32 bit data word contains 4 coisecutive 8 bit pixels ror VCU 206/8; and 1 right Justiried 24 bit pixel for VCU 206/24 for video memory accesses. A
special character write contains 32 consecutive pixels in a doubleword access and is independent Or the bits per pixel. -~

5.2.2.5 Keyboard and mouse The keyboard and mouse interrupt the host processor via NNIs to reduce the interrupt servi e time per lnterrupt. VCV 206 will not monitor or -manipulate keyboard data, this is the functlon Or the host processor. This i : 13063~0 ~ ~ Application Or Epsteln et al '. ~, ~:~ permits better e~ulation Or IEM-PC keyboard runctlons. VCU 206 will convert all mouse/tablet data to a 4 byte format and enqueue it to the host, only lnterrupting once for every 4 bytes of data. This reduces the lnterrupt load on the ho~t.

~ 1306~1() Appllcation of Epsteln et al ' ,`:
5.3 DETAILED DESCRIPTION OF GRAPHICS DATA PROCESSOR 314 :
GDP 314, being the seat Or pixel-manipulation lntelligence within VCU 206 and VEU 207, will now be described in detail.

The GDP 314 is packaged ln a a 135 pin gate array designed for graphics products. It accelerates graphics instructions, in particular, the Graphics Instruction Set (GIS~ set forth in U.S. Patent application 623,908. It can handle a variable pixel depth (see Figures 504 and 505). Initi~l implementa-tion i8 on the presently described preferred embodlment of VCU 206, in which each GDP 314 handles one bit of each pixel, and in a lesser embodiment not descrlbed herein in which each GDP 314 handles two bits of each pixel. For completeness of disclosure, this discussion of the GDP 314 will consider implementation in the configuration of the preferred embodiment, and in other conrigurations as well.

GDP 314 accelerates the following GIS commands:

1) BITBLT, (BIT BLock Tran3fer) 2) CHARBLT, (CHARacter BLock Transfer) 3) PIXEL operations, 4) PLANE operations, and 5) ~1l read - modify - ~rite operations.
The GDP 314 supports 1-32 bits per pixel, and up to 2k pixels by 2k pixel memory. A video board using a GDP 314 requires a 32 bit Data bus.

Microcode for different boardæ using the GDP 314 will be identical, except in terms Or difrering resolution. The speed of most operations is independent Or pixel depth.

5.3.1 FUNCTIONAL DESCRIPTION:

5.3.1.1 Hardware Overview:

Operation ~`
1306~10 Appllcat$on Or Epstein et al ~ ' ::
The GDP 314 has special hardware to accelerate: -1) BIIBLT, 2) CHAR~LT, 3) Plane operations, 4) PIXEL operations, and 5) an ALU that can be used with the above to perrc~rm read - modify - writes.

~ n overview Or the the lnternal architecture Or GDP 314 is shown in Figure 506. Each GDP 314 controls 32 vldeo rams. The video rams have a read cycle, and a read-modify-write cycle. All writes are read-modify-writes. The memory is organlzed to provide easy access to plane and pixel data (see Section 5.4.1 ror memory organization).

Inoluded in LALU 318 is speclal hardware to align the bits to and from the video rams, regardless Or bits/pixel. It also provides the ability to access 32 bits, right justified, starting at any pixel address. (See Figure 534 for required Address and CAS (Column Address Strobe) signal generation. CAS is a signal provided by MBus 205; see Section 4.) 5.3.1.2 Control Overview:

The GDP 314 is not a state machine. During an access to/with the GDP 314, elther a register 18 updated, or data is manipulated. Since the GDP 314 perrorms only one function per access, it is flexible and easily tested.

It is possible to construct an embodiment of VCU 206 utillzing a single GDP
314, as diagra~nmed in Figure 504. To increa~e speed Or operation, however, the designer is rree to utilize more than one, with each handling some portion Or each pixel. The prererred embodiment described herein emplogs a separate GDP
314 for each bit Or each p~xel. Thus, eight GDP 314's are employed in VCU 206 (see Figure 505) and an additional sixteen GDP 314's are employed in VEU 207.
, PIN ASSIGNMENTS

~ ~06~0 ` Application of Epstein et al , . .
GDP 314 is a 135-pin gate array. The physical layout of the 135 pins is shown in Fi B re 508. The assignment of 3ignals to tho3e pins is depicted ln Figure 509. A tabulation of signal name~ along with brief description~ of the signal functions are given in Table 301.

PIN NAME NUMBER I/O DESCRIPTION
~ ~BO - 31 32 I/O M bus data interface I VINO ~ 31 32 I Video data inputs I VOUT0 - 31 32 O Video data cutputs I QMDO - 3 4 I Select operation QR0 - 1 2 I Register select QBP0 - 2 3 I Bits per pixel select QID0 - 3 4 I Chip ID
-QRS 1 I chip reset -QA4 1 I Fifth lowest x address blt XOR P~ANE1 -QA0 - 3 4 I lowest 4 blts of x address -QFS 1 I Suppress foreground ~QBS 1 I Suppress background ~QPO - 1 2 I Plane enable lines -QCS 1 I Chip enable QLE 1 I Video lnput latch enable -QOE 1 I Video output enable _______________________________________________________________________ 58 total lnputs 32 total outputs 32 total V o~ 5 _____________________------------------------------------------ :
8 power/grounds 130 total plns used 5.3.1.3 Detailed Controls~

In a multiple GDP 314 system, successive GDP 314's must have thelr M-Bus data llnes rotated by the number of blts each GDP is handling, as shown in Flgure 507 (an example for two bit~ per GDP).

The -QRS llne should be pulled low at power up and then remain hlgh for operatlon.

-QRS 0 ~ reset, 1 - operatlon.

.

`
063~0 ~ Appllcation Or Epstein et al ~"~

Buring RESET ~QCS should go lo~ and then high. -QCS is used by the GDP 314 to latch all the user registers, and to enable the output drivers. When -QCS is hi p all output drivers will be tristated.

The RESET cycle sets the rollowing registers:

1) MASK = 1111111111111111 1111111111111111, 2) DATA = 1111111111111111 1111111111111111, 3) FUNC = 0011 (M bus data), 4) FO~E = 11, and 5) BACR = OO.

Tell the GDP 314's how many bits~pixel tbe system uses:

QBPO-2 blts/pixel O = 1-2 bits per pixel 1 = 3-4 n 2 = 5-8 n 3 = 9-16 n 4 = 17-32 n The Bits/pixel indicates the spacing Or the pixels. The skewed memory insures that each line Or the Nbus is dominated by a single GDP 314. Figure 510 maps the bits controlled by each GDP 314 onto the Mbus, 1 = control, z = disregard:

NOTE: The one bit/pixel system:
1) 1~ a speclal case of the 2 bit/pixel system, 2) it l~ always in plane mode, 3) perrorms character drawing like any other system, 4) performs BITBLT llke any other system, (but mlcro code should special case BITBLT
to lmprove perrormance: described later), 5) should be consldered a 2 bit/pixel system in plane mode unless otherwise noted.

An GDP 314 system can manipulate 32 bits, right justiried from any pixel address. To do this, the GDP 314 must be given the 5 least signi~icant bits from the x coordinate. A barrel shirter in the GDP 314 13063~0 Application Or Epsteln et al :
aligns the data to the proper boundary.

-QA4-0 0 = rotate 0 1 = rotate 1 .

.
15 = rotate 15 Because Or the memory organization, the firth bit, -QA0, does not actually cause a rotate Or 16, but rather is used to unscramble data from the video ramQ: -QA0 = x address lsb 5 The FUNCtion register controls the one cycle read - modiry -write. It ls loaded from the lowe3~ four bits on the mbus, aQ shown ln Flgure 511.

To perform a simple write, the FUNCtlon bits sbould be set to the function 'M~ (0011).

GDP 314 hardware will suppress the roreground, or background, color during character drawing:

-QFS 0 = don't draw foreground 1 = draw foreground -QBS 0 don't draw background ~-1 = draw background :' The GDP 314 perrorms various runctiOns~ the function being determined by the MODE blts (QMD0-3), as shown ln Flgure 512.

A more detailed description Or each M0DE is provided ln Section -~
5.3.2, along wlth many examples.

Rererrlng to Figure 513, there must be an external PLANE ENABLE register, one blt~plane, allowlng the u~er to select one, all or a selected group Or planes. 0~1y one plane may be enabled durlng plane mode, Otherwise, two GDP

13063~0 Appllcatlon Or Epstein et al .
314~s will have a bus confllct. The plane enables should be dirrerent for each GDP 314, and correspond to the planes that the particular GDP 314 ls handling.

Normally a GDP 314 handles both the odd and even planes. But to extend a system to greater than lk pixels~llne, as ln the prererred embodiment:

1) System has one-GDP 314 / plane, 2) Each GDP 314 handles one plane Or data, and ; 3) Two GDP 314's have same ID.
.j But each GDP 314 will have one Or lts plane enables tied high, and the other controlled by the plane enable register. In such a case the ID's and plane enables should be as shown in Figure 514. &ch a system will hencerorth be called an tEXTENDED' system.

5.3.2 Detalled Functional Specification:
~ :

There are three wa~s to a¢cess memory in a GDP 314 system:

1) access 32 blts Or pixel data, 2) access 32 bits Or plane data, or 3) access Or 16 plxels.
Data may be sent to~rrom the host, an EXTernal acces~, or it may be stored and retrieved ~rom the DATA reglster, an INTernal access. Accesslng 16 pixels with more than 2 blts/pixel must be a~ INTernal access.

The GDP 314 performs the following functions, which will be discussed in greater detail later:

1) EXTernal access (32 bits Or pixel data to/from the host), 2) EXTernal PLANE access (32 bits of plane data to/from host), : 3) INTernal access (16 pixels ~tored~retrieved in DATA register), 4) INTernal PLANE acce3s (32 blts plane data in DATA reg.), and 5) Charaoter accesses (write 16 plxels at a t1me).

~306310 Applicatlon Or Epsteln et ~ -Each GDP 314 has a 32 blt MASK register. A 1 for 1 pattern of bits for pixels to be masked should be sent on the Mbus. The GDP 314 expands the mask to the appropriate bits~pixel. In a read - modify - write cycle, data that is masked out, MASK bit = 0, will pass unchanged through the LAL~ and be written back into the video rams (MASK bit =
0: LALU output = video data). Ir the MASR bit = 1 the corresponding bits from the Mbu~ and Video memory will be operated on by the functlon of the LALU - whatever that runction ls (MASR blt = 1: LALU
output = function (M bus, video). Note: the pattern Or plxels masked must be right ju~tified and not exceed 32 divided by the number of bits/pixel.

NOTE: In the following examples:
1) the MASR registers have been aligned to the Mbus for clarity. and 2) depending on the board, the following registers may need to be set:
a) the FOREground register, b) the BACRground regiæter, c) the FUNCtlon register, and d) the PLANE ENABLE register.
To move only certain planes, ~ -~
1) enable the appropriate planes using the PLANE ENABLE register, and 2) perrorm a multiple plane access as usual.
5.3.2.1 EXTernal Acces~

An ~EXTernal' access moves 32 blts Or plxel data from/to video memory to/from the host CPU. Both plane enables must be low.
Since a one bit/pixel syste~ enables only o`ne plane at a time, it will never perform this type Or access. Instead, it will perrorm an EXTernal PLANE access - described later. An example Or register setups and content ror an EXTernal Read ls given in Figure 515.

To write using the GDP 314, rirst set the MASR, then write the data.
The MUSR must be sent a 1 for 1 pattern Or the plxels the user wishes to write. Each GDP 314 knows which bits are assigned to it, and, ., ., ~ ~ . - ..

Appllcatlon Or Epste~n et al therefore, loads its MASB accordingly. Note: the pattern Or pixels masked must be right justiried and not exceed 32 divided by the number of blts/pixel. An example o~ an EXTernal Write i9 given in Figure 516.

; 5.3.2.2 EXTernal PLANE Access !

An 'EXTernal PLANE' access reads/writes 32 blts or plane data to/from the host: one bit of data from 32 sequential pixels. An EXTernal PLANE access is different from other accesses in that all the lines Or the M bus are read from/wrltten to a slngle GDP 314. An example Or a PLANE Read i~ given in Figure 517.

NOTE: PLANE ENA8LE register must be set.

Note that any plane may be selected for an EXTernal PLANE
access. Only one PLANE ENABLE may be low durlng PLANE accesse~. lr two PLA'NE ENABLES are low, two GDP 314'8 will try to drive the ~ame H bus line.

To perrorm an EXTernal PLANE write, rirst set the MASR, then write the data. The MASK must be sent a 1 rOr 1 pattern Or the pixels the user wishes to modify, similar to the MASK ln the HOST
aocess, but note: 1) Since 1 bit/plxel 18 belng accessed, the pixel ma8k i8 also a blt mask, 2) Only the GDP 314 with the deslred PLANE, loads the ma~k, the others load zero~s, and 3) up to 32 pixels may be manipulated. Figure 518 gives an example Or a PLANE Write.

5.3.2.3 INTernal Access An ~INTernal' access manipulates 16 pixels at a time. Each GDP 314 manlpulates 16 bits rrom the two planes it controls. Please note:

Applicatlon of Epstein et al 1) 16 pixels are read, independent Or pixel depth, 2) the upper 16 blts sent to the mask must be 0~8, ; 3) all the GDP 314's do exactly the qame thing, 4) data is intermixed by plane, 5) the DATA register ls used, and 6) the host CPU never receives any data.
Figure 519 provides an example of an INTernal Read.
,~ ~
To implement an INTernal write, first set the MASR, then writes the data. For an INTernal access, the MASR:

1) expands the lower 16 blts lnto the 2 blts/plxel pattern needed for the ma~k. If a plane has been disabled then the correspondlng bits in the mask wlll load zeros.
2) needs a 1 for 1 pattern Or bits for pixels sent -in the lower 16 bits Or the Mbus, and 3) the upper 16 bits must be zero. -~
An esample of an INTernal Write is shown in Figure 520.
. : '' . .
The following two examples are Or INTernal PLANE accesses. N ease note the difrerences:

1) only one GDP 314 ls active, because 2) only one plane Or data is enabled, ~ 3) only one plane Or data is manipulated, 1 4) the lower 16 bits of the MASR are not espanded, and therefore, 5) 16 bit~, not 16 pixels, are manipulated, AND
6) an INT write should follow an INT read.
Figure 521 depict~ an INTernal PLANE Read Or 32 bits; Figure 522 shows an INTernal PLANE Write of 14 bits.

5.3.2.4 Character accesses:

A 'Character' access is a special case Or the INTernal access.
time. The only difference i~:

~306;~1() . .
Application Or Epsteln et al 1) the FOREground and BACRground signals 2) the upper 16 bits must be zero, 3) the DATA/-MBUS line is lo~, and 4) writes only.
I~ each GDP 314 ls handling two difrerent planes, each GDP 314 should get two FOREground and BACKground bits that are correspond with its planes. In the example shown in Figure 523, the FONT is 10 bits. Flgure 524 is an example rOr the one-bit-per-pixel scheme Or the preferred embodiment.

Pulling the ~QFS or -QBS low during a Character Write will suppress the FOREground or the BACKground.

5.3.2.5 ~slng the LALU 318 The GDP 314 lnternally uses a Logical ALU (3183. The user need only ldentlfy the truth table or a desired function to the LAL~ FUNCtlon register 327. See Flgure 537 for a 11st o~ the Boolean runctions that may be performed. The LALU will work in con~unction with all writes. That is, these runctions may be performed between the contents Or two VRAM locations on an INTERNAL write, or between the contents Or a VRAM location and incoming MBus data on an EXTERNAL write.

Figure 525 shows the character drawing example of Fi~ure 523 with an excluqlve-or (XOR) functlon between the character data and the vldeo data.
Note that the only dlfrerence is the F~NCtion blts.

5.3.3 TIMING DIAGRAMS:

REY

.

~; ~306~0 i Applicatlon Or Epsteln et i~1 ,.: .
~ LABEL I MAX TIME (ns) I MIN TIME (ns) .~........ ____________~_ ~ ____________________ ~ ________________________ tl t2 1 1 30 t3 1 1 30 t4 1 1 130 t5 I 1 118 t6 1 1 30 t7 1 1 30 t8 1 1 68 t9 , 1 75 t10 l l 82 I
t11 1 1 57 t12 1 1 65 --t13 ~ I O
tl4 ' I 15 ~ -tl5 1 1 30 :, tl6 ' I 40 tl7 1 1 0 tl8 ' I 60 t19 1 ~ 30 1 .
Flgure 526 t11ustrates the timing Or a HOST READ.

Figure 527 shous the timing Or loading the DREG.

Figure 528 details the tlming Or a WRITE.

Figure 529 deplcts the tlmlng Or loading the FUNCTION REGlSTER.

Figure 530 lllustrates the tim~ng Or a load Or the FOREGROUND/BACRGROUND
register.

Flgure 531 shows RESET timing.

06;~10 ., - .
Applicatlon Or Epstein et al 5.4 VCU 206 DETAILED OPERATION

Having descrlbed the internal operation Or GDP 314, the seat of lntellieence within VCU 206, the operation Or VCU 206 itself will now be described.

5.4.1 Video RAMs VRAMs 113 comprise 64 256R video RAM chips. Referring to Fieure 532, each video RAM chip is internally organized as 64K locations Or 4 bit3 each. It thus takes two video RAM chip~ to make up an 8-bit pixel, each video RAM chip containing 4 plane3 of information. The plane organization of video RAM bank ~1 is such that planes A, B, C, D Or pixel 32nlO are shifted out on the serial clook edge 32nlO. Similarly, on the same serial clock edge, video RAM bank ~2 produces plane~ E, F, G, H Or pixel 32n~0. The two outputs are combined to produce one eight bit pixel.

The random access data ports on the video RAMs are connected to GDP 314 gate arrays which control the flcw o~ data coming from the M-bus to the video RAMs. Each gate array connects to one entire plane Or pixels (32 chips). Since there are eieht planes on a VCU 206/8 board, it takes 8 gate arrays to control the vldeo RAM data.
' :
There are several reasons for this memory organization. First, the gate array needs data ln a rorm where it can access 4 whole pixels at a tlme t8LOC~
MODE) or 32 plane blts at a time (CHARACTER MODE and INTERNAL~PLA~E mode).
Seoond, t~e data needs to be organized ao that when lt comes out the serlal port o~ the vldeo RAMs all planes per pixel arrive simultaneously and pixel~
are consecutively sequential. And third, because Or the speed or the serial port on the video RAks, 16 pixels need to be available simulataneously per shlrt Or the vldeo RAM serial clock.

5.4.1.1 Screen Address to Memory Address Mapping ~;
1306~10 Appllcation of Epstein et al ?, The host CPU, and the user thereof, need not concern themselve3 with addresses within ~RAMs 113, but provide addresses in terms of screen coordinates. VCU 206 automatically translates tbese to VRAM addresses.

There is circuitry to randomly address any pixel in terms Or its screen coordinates, and circuitry to refresh the VRAM's by sequentially stepping -through the addresses. The sequenkial refresh addresses are provided by the 8031 microprocessor. The pixel address circuitry is shown in Figure 555, and the refresh address circuitryin Figure 556.

Acces~es are per~ormed upon VCU 206 in two phases-- an address phase and a data phase. During the address phase, two bus transfers are made: one to transPer the X screen coordinate and one for the Y screen coordinate. Data are then transferred during the data phase.

The screen comprise3 1280 x 1024 pixels, each o~ which is speciried by an X
and a Y coordinate. The upper-left-most pixel is the origin, with coordinates 0,0. All 1280 pixels on the same horizontal ro~, called a ~scan linen, have the same X coordinate.

For simpllcity in the rollowing dlscussion, the "A~ and "E" planes will be stressed (referrir~ to Figure 532), but it should be borne in mind that planes "Bn, "cn, and "D" are associated with plane "An, and that planes "Fn, "Gn, and "H" are associated with plane "En.

Figure 533A shows how each scan line Or 1280 pixels is divided into 64 memory columns which cut across all 64 VRAMs. Numbers are in deci~al, with hexadecimal equivalents provided ln parentheses. Note that the chips are grouped in pairs, each pair receiving the same CAS (column address strobe) and together producing one full pixel. (CAS is provided by MBus 205; see Section 4.) Figure 533B shows the actual half-planes stored in the first 64 memory columns Or each chip tsubsoriPts are in hexadecimal). Note that only the rirst 40 out Or 64 memory columns are displayed on the screen. The other planes associated wlth "A" and "En can be thought Or as existing behind the plane Or _ ~ 1306;~10 Appllcation of Epstein et al the ~igure, as shown. Note that one memory column acces3 will produce 32 full pixels. Each of the 64 VRAM chips will supply either an "A" or an "E"
half-pixel; each chip provides 40 half-pixels per scan line.

Figure 533C shows a single 256 x 256 t64R) VRAM, which will supply 40 half-pixels per scan line. Tbe first 40 columns of r w O contain all the half-pixels this chip supplies to qcan line 0, and 90 on. Note that with each of 64 VRAM chip~ supplying 40 helf-plxels per scan line, each scan line will contain 1280 pixels, as required.

The X and Y screen coordinates are mapped into VRAM addresses in the following way: XREG(0-4) (the low order bits) are used to provide the CAS
signal~ that select a pair of the 64 VRAMs; the row address of half-pixel in a VRAM is provided YREG(0-7); tbe column address is provided by XREG(5-10) and YREG~8-9).

Figure 533D traces the mapping of a pixel whose screen address is (600,500) to a VRAM address. This pixel can be found near the middle o~ scan line 500.
The coordinates are stored in b~nary form in the XREG and the YREG. XREG bitC
0-4 are used to produce CAS24, which sele¢t~ chips 48 and 49. Y~EG bits 8-9 appended to XRE& bits 5-10 select column 82, wh1le YRE& bits 0-7 Qelect row 244. The VRAM location (244,82) is selected for both cips 48 and 49, which togetber produce a full pixel.

CAS signals are applied in two phases: Phase 0 and Phase 1. Figure 534 ~hows which VRAMs receive which phase.

5.4.2 Video output stage The maximum shift frequency of the shirt register in the video RAMs is much lower than the pixel rate. Because of this, 16 pixels of 8 bits each must appear on the serial data output lines simultaneously. These 16 pixels are then loaded and shifted with high speed shift registers to get to the video dot rate. Since the total number of video RAMs are 64, serial clocking the video RAMs will produce 256 simultaneous bits (4 serial llnes per chip), while only 128 are required. Utilizing the SOEO and SOE1, two ` 1;~063~0 Appllcation Or Epsteln et al :::
s control signAls that connect to the serial out eDables on the video RAMs, only 128 bits at a time are enabled.

Remember that tha data stored in the video RAMs comes out as A0, A32, A64, A96 ... from the rirst chip in the even bank; and A1, A33, A65, A97 ...
from the first chip in the odd bank.

Physically, the serial out data lines Or the video RAMs are connected to 32 TTL ~hift registers, which are conrigured a3 a 8 to 1 shift. The TTL
signals are tran~lated into ECL levels and shirted 2 to 1. The pixels are ncw at the video dot rate which are red into the 3 palette DAC~ which drive the 75 ohm RED, GREEN, and BLUE video output lines. The palette DACs also contain the built-in 25~ x 8 palette lookup RAMs which provide for a total Or 16M possible palette colors.

5.4.3 M-bus interface The M~bus lnterrace ha~ 2 PALS for address decoce, and three eight bit latches to hold parts Or the address field. There arfi 2 11-bit latches and 2 decimal latches to store the x and y, source and destlnation coordinates, respectively. Additionally, the outputs or these latches are connected to a PAL which generates address_minu3_1, used by barrel shirters 316 and 323 (see below). These address-minus-1 outputs and the latch outputs are then connected to 2 quad 2-1 muxe~ which mix the RAS and CAS address lines for the video RAM
array.

The data portion Or the M-bus inter~ace has 4 octAl latching tran3ceivers to burrer and hold the write data during a write operation and drive the data onto the M-bus on a read operation. The internal data bu3 also has 8 GDP 314 gate arrays connected to it. These gate arrays each handle 1 plane per pixel Or video inrormation. Each gate array has, in addition to the 32 internal data bus I/0 pins, 32 video data outputs and 32 video data inputs. Each gate array has an assortment of control lines which are used to nanipulate the data to and ~rom the video RAMS. It should be noted that MBuY 205 cannot access VRAM3 113 dlrectly, the way it can access Memory 102 directly, but accesses VRAMs 113 through the data manipulation olrcuitry within VCU 206.

l3a63l0 Application Or Epsteln et al s~ The data manipulation circuitry includes two barrel shifters (316 and 323 on Flgure 506) for aligning data from MBus 205 format to VRAM 113 format.
Although Memory 102 and VRAMs 113 are double-word t32-bit) oriented, the barrel shirters eliminate the need to transmit data on double-word boundaries, thus enhancing flexibility. For example, referring to Figure 557, ~uppo~e a pixel mode transmission on the NBus sends a right-~ustified 8-bit pixel "E~ to replace pixel "D" in VRAM 113. It is of no consequence that D and E are not co-aligned. Using the address rurnished rOr pixel D, pixels C and D are retrieved from that location; using the derived address-minus-1, pixels A and B
are retrieved fro~n the previous location, all keeping their alignment, resulting in nCDAB~ being in barrel shifter 319. Barrel (circular) shifting by 16 bits take place, giving "ABCD" in shifter 319; pixel D is now aligned with its replacement, pixel E, which can simply be moved into place. The resulting ABCE is shlrted to CEAB, which is returned to VRAM 113. ~ -VCU 206 does not check or generate syndrome blts, and therefore wiil assert the M-bus signal ERCC DISABLE when accessed.

LAR bits 9-12 define the address space of the VCU 206 board. VCU 206 can reside in RAS select ~7 upper or lower 1 Mbyte Or memory space.

5.4.4 Basic timing Lasic tlming 18 generated by an 107.352 Mhz cryst~1 module which has ECL compatible outputs. The ECL crystal module i8 bufrered and passed to the VEU 207 board, lf it exist3. The output Or the crystal module, called the ~vldeo dot clock', 18 divlded down by a high speed counter chip to generate the 8031 uP clock, serial control slgnals for the video RAMS, and serlal control signals ror the ECL video chain. Where TTL level signals are required, ECL/TTL translators are used.

The following are the clock rates and cycle times on VCU 206:

~ 130631() .
~ Application of Epsteln et al 'd'~' description time/freq ___________________________ __ o dot clock 107.352 Mhz o pixel width 9.315 nsec o 8031 uP clock 10.735 Mh~
o 8031 uP instruction time 1.118 usec o M-bus cy¢le time 80 nsec o Read cgcle time 800 nsec o Write cycle time 720 nsec 5.4.4.1 Video timing The raw video timing is controlled by the 8031 uP chip. The support clrcuitry ror thls chip includes a 4k PRoM, which contains the rirmware, and an octal latch which latches the lower address field from the 8031. The raw tlming outputs (Hblank, Vsync, and Vblank) are connected to rlip-flops which are used to syncronize the raw video timing to the video dot clock. The syncronized video timing signals are then passed to the palette DACs.

The horizontal para~eters that drive the monitor are as follcwQ:
description time/freq how derived _________________________ ____________ ________________ o sweep rrequency 63.90 ~hz o total scan lnterval 15.649 usec 14 - 8031 cycles o display scan interval11.923 usec 1280 - plxels o blanking lnterval 3.726 usec o ~ront porch 0.242 usec o sync wldth 1.118 usec 1 ~ 8031 cycle o baok porch 2.366 usec 2 - 8031 cycles The vertic~1 parameters that drive the monitor are as rollows:
descriptlon tlme/freq how derlved _________________________ ____________ ________________ o sweep ~requency 60.00 hz o total scan lntervi~116.666 msec 1065 - h scans o display scan lnterval16.025 msec 1024 - h scans o blanklng lnterval 641.627 usec 41 - h scans o ~ront porch 46.948 usec 3 - h scans o sync wldth 46.948 usec 3 - h scans o back porch 547.731 mseo 35 - h scans 5.4.5 Video palette The 8031 data bus is connected to the data I/Os on the palette DACs.
This enables the 8031 to HRITE and READ the RAM contained in the palette :
``: 1306310 Appllcatlon Or Epsteln et al r DACs. The address from the 8031 i8 connected to TTL/ECL translator~, and wire-ored with the video data (E U levels~ at the address inputs Or the palette DACs. The video data is enabled to the palette DACs during actlve vertical time. The 8031 addresses, for updating the palettes, are enabled to the palette DACs during vertical blanking time.
, :

5.4.6 Refresh The video RAM~, being dynamic ln nature, must be RAS refreshed every 4 msec. A RAS occurs every horizontal blanking time (for active vertlcal) during the transrer cycle. The transrer cycle transrers a R0W Or memory (256 bits) into the video RAM shirt register for display on the next scan line.

Since the horizontal scan time i8 about 15.65 usec, each row would be rerreshed every 256~15.65 usec, or 4.006 msec. This is ~ust slightly over the 4 msec spec rOr the video RAMs. So, to guarantee the spec will be met, an additional RAS is given to the video RAMs immediately followirg the transrer cycle, with the msb ROW address toggled. Thls scheme guarantees that when ROW O is rerresh~transrered RaW 128 i3 rerreshed, when RaW 1 is rerresh~transrered R0W 129 is rerreshed, ...... when ROW 128 is refresh/transrered ROW O is rerreshed, etc.

Rerresh/transrer addresses are controlled by the 8031 uP chip. The 8031 i~ connectet to a 10 bit counter ant a PAL which generates sequential rerresh/transrer addresses for the video RAMs. The 10 bit counter is connected to the adtress driver circultry going to the video RAMs.

If a host processor attempts to access the VCU 206 board during this rerresh time, VCU 206 will hold Orr the access by asserting the ^MEMWAIT
line. Arter rerresh is complete, the access will be performed normally.
Rerresh oocurs during both horizontal blanking and vertical blanking time (at the horizontal rate).

5.4.7 ~eyboard - ~3063~0 Application of Epstein et al ;,., ~ .
}- The keyboard circuitry consists Or a shirt register, a PAL, and some termination resistors. Data is transmitted ~erially to the VCU 206 board from the keyboard. The shlft register converts the serial data to parallel data for the host to read. When 8 bits of data have been tranmitted frcm the keyboard, an lnterrupt is generated on the NMIA or NM B tprimary or secondary board) line Or the host. The only way to olear the interrupt is for the host to write the LED data word to the keyboard. The shirt register in this case takes the host parallel data and converts lt to serial data, which is sent to the keyboard.

5.4.8 Mouse The mouse interrace consists Or an EIA driver chip ~or mouse data OUT
and a transistor level shirter ror mouse data IN. The mouse I/O lines are connected to the 8031 serial port. The 8031 handles all mouse I/O and passes the data to the host via the COM register.

5.4.9 COM DATA/COM STAT~S registers The COM DATA register conslsts Or 2 octal register~ and 2 octal transcelvers. They are connected to the 8031 uP data bus such that 32 bits Or informatlon can be read from the 8031 uP and 16 bits Or lnrormation can be written to the 8031 uP. The COM STAT~S register is a read only register whloh oontains keyboard NMI status, a vertlcal blanking status bit, 8031 uP
selr test ralled rlag, and hand shaking bits for the host-8031 uP
oommunioations.

5.4.10 DC/DC converter A 12 volt to -5.2 volt DC to DC converter supplies 4 amps Or -5.2 volts ror the ECL chips on VCU 206 and VEU 207.

~}~ ` 13063~0 Application Or Epstein et al ~. .
~- ~ 5.5 YEU 207 VEU 207 is very similar in hardware design to VC~ 206. The following paragraphs describe the differences between them.

There are no address generation, rerresh control, and X and Y source and destination reglster sections on V~ 207. The address that goes to the video RAMs is passed via a cable to the VE~I 207 board from the VCU 206 board.

There is no 8031 uP and associated circuitry (this includes the CON
DATA register and C0M STATUS register); the necessary video timing signals and data bus inrormation are pa~sed via a cable to VEU 207.

There are two video output chains (shirters, etc.) and twice as much memory (128 vldeo RAMs) on VEU 207 as there i9 on VCU 206. Note that this memory does not yield any additional locations, but expands the size Or the existing locations. There are only two DACs on VE~ 207, one per video output stage.

There is no keyboard or mouse interrace on VEU 207.

5.5.1 Converting VC0 206~ô to VCU 206/24 There exists a Jumper cable that is connected on the backplane when both VC~ 206 and VEU 207 are present in a system. This cable passes signals from VC0 206 to VEU 207 and vice-versa. One Or the signals on the cable tells the VCU 206 board that a VEU 207 is connected so that it (VCU 206) conrigures itselr appropriately.

The RED gun and GREEN gun cables are connected to the VEU 207 slot. The 9LUE gun, keyboard oable, and IDouse cable are connected to the VCU 206 slot.

- ~ : . , : `

.. ' , . ... ' ... . . ' ' ' . ' .

~ 1306~0 Applicatlon Or Epstein et al 5.6 PROGRAMMING DESCRIP~ION

5.6.1 Board selecting/LAR

The present embodiment allows a maximum of two video boards in a system.
The VCU 206 board actually only uses RAS ~7 to decode board seleot tRAS ~6 is only looked at to make sure that system refresh i9 not happening) The primary/secondary board is detected Orr Or MBA12. The total memory space alloted ror video boards is 4 Mbytes. A VCU 206 board takes up 1 Kbyte of local memory 3pace. The VEU 207 board, lr used, takes up no additional local memory space.

All external accesses to VC~ 206 are done via the M-bus. Tbe 15-bus address lines lndicate how the address is to be interpreted and which registers are to be updated. The address on the M-bus is set b~ the Logical Addre~s ReBister (LAR). The LAR is only visible to the microcoder.

The LAR must hold a valid address before a microcode read or write.
Arter a read, data will be latched into the Memory Data Register Input MDRI). Berore a wrlte, the outgoing data must be placed in tbe Memory Data Register Output (MDRO). ALL three registers are in MCIJ 205 and are described in section 4.

Flgure 535 illustrates the LAR bit mappings to M-bus Address lines. ~its 9-11 are used to decode one Or eight RAS SELECT lines, bits 12-29 for upper eiBhteen bits Or address, bit 30 is the least slgniricant address biS
identifying the odd or the even address and to start the memory access, and bit 31 is used as part Or the command to decode the type Or the access. Bit 31 is always zero for VCD 206 accesses in norm 1 or other space.

5.6.2 OTHER space accesses , Figure 536 illustrates how the M-bus address is decoded when the OTHER
space bit (on MBus 205, described in section 4~ is asserted, indicating an OTHER space access is occurring.

~306310 Applicatlon Or Epstein et al :
~' ~
All of the registers on VCU 206, except the X and Y, S W RCE, and DEST~NATION registers, are contained ln OTHER space.

5.6.2.1 LALU register The LALU register 327 (see Figure 537) is 4 blts wide and may be used to select one oP Qixteen po3sible logieal operations governing the combination of VRAM 113 data and MBus 205 data. The LALU is a write only register.

5.6.2.2 PLANE ENABLE register (Figure 538) VCU 206 reads or writes data in BLOCR mode. The PLANE ENABLE register is used to enable/disable indlvidual plane bits oP a pixel. For VC~ 206/8 there are 8 enables, and Por VCU 206/24 there are 24 enables. This register is a write only register. The effects of thi~ register are only realized on writes and reads to video memory. A write with a plane disabled causes that plane bit to remain as it was in video memory before the write. A read with a plane disabled caUQes the data to be returned as a logic one.
:
The bits per pixel bits of this register dePine how many bits per pixel ~ -are being acted on. Normally, ror VCU 206/8 this reglster is set Por 8 bits per pixel, and Por VCU 206J24 this reglster is set Por 24 (32) bits per pixel. IP, however, only 1 bit per pixel need to be written then this reglster can be set Por 1 bit per pixel. Note that this allows 32 pixels per double word to be written at one time (or read in the case oP a read operatlon) instead Or 4 pixels when conPlgured as an 8 bit per pixel oontroller. IP this register i8 set to less than the number oP bits per plxel Por what the board is capable oP (1,2 or 4 Por VCU 206/8; 1, 2, 4, 8, or 16 Por VCU 206~24) then the unused planes M~ST BE DISABLED. For example, iP VCU 206/8 i8 conrigured as 2 bits per pixel with this register, then planes A,B,C,D,E,F must be disabled. When perPorming ~pecial character write accesses, bit 0 o~ the PLANE ENABLE must be 1 (PLA~E mode) and indlvidual plane enable bits Or a plxel can either be zero or one, as desired. This allows Por simNltaneous setting or clearing Or all 32 pixels in a dou U e word or plotting Or a 32 bit wide character font.

: ~ . : . .

;"

Appllcation of Epstein et al ~::
5.6.2.3 Foreground register (Figure 539) The ability to plot characters at the same speed on both VCU 206/8 and VCU 206/24 i9 due in part to the FOREGRWND and BACKGRWND registers. These registers hold the color informatlon (or plane data) for the planes Or a plxel. These reglsters wlll baslcally substitute a single bit Or pixel lnformat$on with elther 8 bits or 24 bits Or color lrformatlon. Thls means a write Or 32 bits over the M-bus on VC~ 206/8 cau3es a write Or 32~8 bits ln the video memory, and 32~24 bits on VCU 206/24.

The FOREGROUND register, in character drawing mode, will substitute the roreground color specified when a one is wrltten to the vldeo memory.
The FOREGRWND register 18 write only. If the foreground suppress bit is set, then the data will not be written. This allows the writlng Or transparent characters, (l.e. the character tf`oreground bits] remains unchar.ged, while the background i8 changed to a particular color). Note that lr the roreground ~uppress blt and background suppress bit are both set then nothing happens.
:
5.6.2 4 Background register (Figure 540) The BAC~tGRWND register, in character drawing mode, will substitute the baokground color 3peoiried when a zero 19 written to the video memory. The BACDGRWND retister is write only. If the background suppress bit i8 set, then the data will noS be wrltten. This allows the writing Or transparent character backgrounds, (i.e. the character is changed to a particular color wh1le the background reoains unchanged). Note that if the ~oreground suppress bit and background suppress bit are both set then nothing happens.

5.6.2.5 COM DATA register The COM DATA register is used to pass infor~ation between the host and 8031 uP. The register which holds the data on a host write (host to 8031 uP) is 16 bits wide, and the register which holds the data on a host read (8031 uP to host) ls 32 bits wide. The DATA passed by between the host and 8031 uP is defined as the following:

1306~0 ~ Appllcation Or Epsteln et al . . .
.
From 8031 uP to host (host read):
o mouse data o echo (diag) data returned From host to 8031 uP (host write):
o mouse commands o palette data o NMI enable/disable o blink enable/disable o set mouse/tablet double ollck delay o echo data (diag) command The host read COM DATA register is 32 bits wide. It can be read with one lnstruction by the host, but the 8031 uP requlres four wrltes to load it. ~riting the low byte (it should write the other 3 bytes rirst) Or this register by the 8031 uP sets the DATA VALID bit in the COM STATUS register.
This indicates to the host that valid data is in the COM DATA register ror it to read. If DATA VALID NMI enable is sst an NMI is generated to the host.

The host write COM DATA reglster i8 16 bits wide. Referring to Flgure 541, it can be written with one in~tructlon by the host, but the 8031 uP requires two reads to retrleve it. When tbe 8031 uP reads the low byte (lt should read the high byte rirst) the READY FOR DATA blt in the COM STATUS reglster is set lndlcating the host can wrlte another word to the COM DATA register.

5.6.2.5.1 Mouse/Tablet Referring to Figure 543, Mouse/Tablet commands are issued vla the COM DATA
register. The 8031 uP reads the mouse/tablet command rrom the host wrlte COM
DATA register and shlps it uninterpreted to the mouse vla the serlAl port o~
the 8031 uP.

The mouse/tablet sends 3/5 bytes (respectlvely) Or posltion inrormatlon via the 8031 uP serial port to the 8031 uP. The 8031 uP compresses this information lnto rOur bytes and writes them to the COM DATA register. An NMI is generated (ir enabled) when the 8031 uP wrltes the last byte. The host then reads the mouse posltion wlth one 32 bit read Or the COM DATA
reglster.

: ` 13063~0 Appllcation Or Epstein et al ~-, 5.6.2.5.2 Palette loading (Figure 544) The 8031 uP can read/write the palette ~AM contained in tbe palette DACs. There are 3 palettes to load for each phase Or bllnking (phase O and phase 1). They are the RED, GREEN, and BLUE gun palettes, each having 256 entries. When the host writes new palette colors to the COM DATA register, the 8031 uP places these colors into a palette table. During vertical blanking the 8031 uP transrers the palette table into the palette DACs.
It take~ a total Or six screen rerresh times (or 100 msec) for the 8031 up to update the palette.

Each of the 6 p~lette tables has a pointer which indicates whlch entry in the table (0-255) will ~e written. This pointer is auto~atically incremented after every write to the palette table. O~ly the color and phase pointer which was writ'en to increments, the other 5 remain unchanged.

To load the palette table, the RESET ADDRESS function must ~irst be issued. This resets the internal RED, GREEN, and BLUE table pointers. A
table pointer points to the nest location in the palette table that will get the palette data. Resetting this pointer causes all three table pointers, ror that phase, simultaneously to point to the location speciried in bits 24 to 31 Or the data double word.

The palettes are set to display an all white screen on power-up for approximately 2 seconds. After the 2 seconds the derault palettes are loaded. (Note: the derault palettes are black.) 5.6.2.5.3 NHI enable/disable (Figure 545) This co~mand to the 8031 uP enables or d~sables the vertical blanking NMI or DATA VALID NMI. Note that disabling NMIs does not disable the state Or these bits in the COM STATU$ register. The derault on power up is both the ^VBLAN~ and DATA VALID NMIs are disabled.

5.6.2.5.4 Blink enable/disable (Figure 546) ~ ~ ` 1306310 Applloation of Epsteln et al This command enables/disables the blinking feature. Default on power up is blinking disabled. Blinking is done by switchiDg approximately once a second between the palette entries in the phase O table and the phase 1 table. If the phase O and phase 1 tables are identical then no blinking will occur even if blinking is enabled. When blinking is disabled only the phase O table entries are displayed.

5.6.2.5.5 Set mouse/tablet n-cllck delay (Figure 547) This command sets the delay time between the depression o~ a button and the timeout packet. Two down key cllcks that occur before the ti~eout occurs are counted as double cllcks, three down key cl~cks that occur before the timeout occurs are counted as triple clicks, those longer than the delay are single. The counting o~ the clicks i8 the responsiblity Or the host based on the presence of the timeout packet returned.

5.6.2.5.6 Echo (diag) mode (Figure 548) ~ sed to verify the data path to and from the COM data register. Note that this command wlll not check the COM DATA register to see ir the host has read the last double word placed ln it before echoing the data received rrom the host.

5.6.2.5.7 Manu~acturlng test mode (Figure 549) This command provides to manu~acturing and diagnostlcs a means to ~urther test the status Or the board through the 8031up.

There are 2 significant runctions to this mode depending upon the value Or bit 19. ~hen this command is executed i~ bit 19 is zero, the 8031 will immediatey Jump to the first address space outside the range of its code prom (decimal 4096 ). Thi~ allows the execution Or diagnostic code rrom an area other than the 8031 code prom. If the commmand is executed and bit 19 is 1, then a status byte is sent back immediately destroying the value of the co~mdata register, lr any.

_169 -: - 130fi~'3iO
Application of Epstein et al 5.6.2.6 COM STATUS register (Flgure 550) The COM STATUS register i~ read only and returns the following lnformation:

o vertical blanking state o READY TO ACCEPT data state o DAT~ VALID qtate o keyboard interrupting state There are three events that can oause an NMI ~rom VCU 206. All three oan be checked via the COM STATUS register. Two Or them can be disabled.

An NNI is generated when the EEYBOARD register on V~U 206 i~ loaded by the keyboard. This NMI will always occur. The orly way to clear this NMI is to write the LED register. Refer to the REYBOARD~LED register section below ~or more detail.

An NMI i8 generated when DATA VALID i9 set by the ôO31 uP. This NMI can ~ -can be disabled by sending a command to the 8031 uP. Thi3 NMI and status bit are cleared when the COM DATA register iiB read.

An NMI i8 ~enerated when ^VBLANK is asserted. This NMI can be disabled by sending a command to the 8031 uP. This NMI is cleared when the COM STATUS
register is written. Note that writing the CON STATUS register does not alter anythlng else, it only clears the NMI for ^VBLANK. The status bit is oleared when ^VBLANg is deasserted.
~Flgure 15) 5.6.2.7 ~eyboard/LED register The keyboard register and LED register have the same register address.
The keyboard register is read only, while the LED register is write only.

Referring to Figure 551, when a key i8 struck on the keyboard, it sends the keycode and poisition (up/down) to the keyboard register on VCU 206.

~3063~0 Applicatlon Or Epstein et al Loadlng the keyboard reglster also sets an NMI to the host to inform the host that the keyboard has ~ust placed data into the keyboard register. Bits 24-31 Or the M-bus data word contaln the keyboard data durlng a read Or the keyboard reglster. Blt 24 contains the keystate bit (up/down~, and blts 25-31 define the keycode.

With reference to Figure 552, the LED register contains bits which set or clear the state Or the LEDs on the keyboard, as well as the bell oD~orr bit.
~riting the LED register clears the NMI generated by the keyboard and send~ the keyboard a new LED word. The keyboard cannot transmit the next keyword to the host until the NMI is cleared by writing the LED register.

Note that the beeper is programmed exactly opposite the way the LEDs are programmed, namely a 1 turns LEDs ON, but the beeper OFF.

The keyboard generates a timeout word tall ones) every 80 milliseconds ir no key changes state. This timeout word can be used ror type-o-matic keys and the repeat key to generate a new character after a predetermined amount Or timenout words have beeD received. The timeout word also allows the host to update the LED register, even if no keys have been pressed, and can also used to "rorce" through pending screen operations that have been lnterrupted.

Rerer to the appropriate keyboard specification ~or complete inrormation on keycodes and programming.

5.6.2.ô PIXEL ENABLE register (Flgure 553) The PIXEL ENABLE register controls which pixels get written into the video memory. Each bit in the PIXEL ENABLE register corresponds to a pixel in the data word. So, for 8 bits per pixel only the 4 least signiricant bits Or the PIXEL EN B LE register have any meaning, ~ince only 4 pixels can be written at any one time. For 2 bits per pixel only the 16 least significant bits have any meaning, etc.. This allows for simple treatment Or boundary conditions when the wldth Or the block is not a multiple Or 4 pixel~ on VC~ 206/8. This can be very 1306;~10 Application Or Epstein et al userul in BITBLT and CH~BLT type operations. This also allcw3 single pixels to be written by simply setting only the least significant bit Or this register.

5.6.3 NORMAL space accesses Figure 554 illustrate3 how the M-bus address is decoded uhen the OTHER
space bit is not asserted, indicating a NORMAL space access is occuring.

A NORMAL space access can elther be an external access, character mode access, or an internal aocess.

5.6.3.1 Host accesses ~external) External accesses are normal read/write acce~se~ to the v$deo memory via the M-bus.

5.6.3.2 Internal aocesses Internal accesses do not use the ~-bus. Durlng an INTERNAL !IEAD data i9 read frum the video memory and stored in an on-board reglster. On an INTERNAL WRITE operation, the data that was prevlously ~tored in the on-board register rrom the INTERNAL READ is written back to the screen burfer, potentially at another address. Because internal accesses do not use the M-bus, the transrer Or data i9 not bandwldth limited by the N-bus to 32 bits per access; but rather limited to the bandwidth Or the video memory data lines. For VCU 206 it i8 32 times the number of planes per pixel.
This yields a transrer rate Or 256 blt~ per transrer for VCU 206/8 and 768 bits per transrer ~or V W 206/24. In both oases, this translates to 32 pixels per transrer.

5.6.3.3 Character drawing Character mode accesses are a special case Or the external access;
however, bit O Or the PLANE ENABLE register must be 1 (plane mode). The gate arrays are loaded with the foreground and background colors for the characters. Only a simple character ront (simple means a 0 bit represents ~;~06310 Appllcation Or Ep~teln et al the background color, and a 1 bit represents the foreground color) needs to be written to the video memory in this mode, as the mapping Or foreground and background colors are done by the gate array. Note that only writes are valid in this mode. The drawing speed here i8 not a function of the number oP bits per pixel (planes), meaning characters will be drawn with equal speeds on ~C~ 206J8 and VC~ 206/24.

5.6.3.4 X and Y, S W RCE and DESTINATION reglsters The SOURCE reglsters are normally used as pointers to a row and a column of the window to be moved or drawn. VCU 206 can use either pair of registers to read or write. This allows for easy handling of block moves and logic operations from video memory to video memory.

By providing seperate SOURCE and DEST registers ~or X and Y addresses, window moving ln either the X or the Y plane can be accompliished much more e~fiolently because only one coordinate address needs to be sent after the lnitlal X and ~ address is loaded.

Note that both the S W RCE and the DEST registers can be used for readlng and writing. Labels "source" or "dest" are used ~or clarity only, although SOURCE register normally holds the top right coordinate of the window So be read and DEST register normally holds the top right coordinate o~ the window to be written.

5.6.4 Read/write pixel PIXEL operations may be used to draw lines, circles, and other pixel-by-plxel graphics ePficiently. Pixel read and pixel write are Just special cases o~ BLOCR READ and BLOCK WRITE respectively.

All accesseis are double word accesses. However, if the pixel enable register contain~ a value of 00000001 (hex) then on a host wrlte access, a pixel write is accomplished. The pixel to be written mUQt always be right ~usti~ied. Slmilarly, on a host read, the right mo~t pixel of the double word read from the ~ideo memory l~ the pixel addressed, the rest of the pixels must ~ ~ 1306~0 Appllcatlon of Epsteln et al ';
be masked out by the host CPU. Note that the PIXEL ENABLE register is used by VCU 206 only on a write cycle.
., PIXEL accesse3 requlre the setup Or the following registers:
1) the X and Y S W RCE or DESTINATION registers 2) the LALV register 3) the PIXEL ENABLE register 4) the PLANE ENABLE register 5.6.5 ReadfWrite BLOCK

A double word acce~s will access elther 4 consecutive pixels on X
VCU 206/8 or 1 pixel on VCV 206~24. For VCU 206~8, each pixel 18 ~ bits wide, æo 4 pixels will fit into a double word. For VC~ Z06~24 each pixel is 24 bits wide, so only 1 pixel will rit in a double word. This 24 bit pixel is RIGHT JUSTIFIED in the 32 bit double word. Note that, setting or clearing Or the video video memory is faster ir a special character write access is perrormed instead.

BLOC~ addressing may be used when it is required to move or draw a large rectangular blocks Or graphics memory more erficiently. C~BLT, 2DLINE,and BITBLT instructions use BLOCR transrers. Note that BLOCR
aocesses are NOT limited to double word boundaries Or pixels, but are limited to pixel boundries.

BLOCR accesses require the setup Or the following registers:
1) the X and Y S0~ROE or DESTINATION registers 3) the LALU register 4) the PIXEL ENABLE register 5) the PLANE ENABLE reglster 5.6.6 Interrupts Interrupts on VCU 206 can be generated by any one Or three sources:
o COM DATA reglster o keyboard o Yertical blanking 3063~o ~.
Application or Epsteln et al Successlve commands sent to the 8031 uP can be handled by polling the RTA status blt. However, lt 18 lmportant that the emulator not be sitting around polllng for data comlng FROM the VCU 206 board (mostly mouse~tablet data). For this reason, the assertlon Or DV (data valid) causes a non-maskable interrupt to occur, whlch quickly give~ control to the termlnal emulation code. The emulation code may then read the mouse data, track the cur~or, etc. The lnterrput is maskable on the VCU 206 board but not by the host. The interrupt and the status blt are cleared when the host reads the COM DATA reglster.

In additlon, the keyboard control logic can generate an NMI. The termlnal emulatlon code must read the VCU 206 status register to determine which device generated the non-maskable interrupt. Keyboard lnterrupts cannot be disabled. This is l~portant rOr BREAR key handllng.

A third NMI called VBLANR is also available. This is generated by the VCU 206's video timing unit to notify the microcode that it 18 in vertical blanklng period. This is userul rOr operations like: scrolllng, cursor tracking and diagnostics. The VCU 206 status register also contains the VBLANR status to help determine the NMI source (refer to Figure 12). This status bit cleared when vertical blanklng deasserts. ~owever, the NMI does not clear unless a write to the COM STATUS register is perrormed. Thls NMI
18 maskaU e on the VCU 206 board but not by the host.

~3063~0 ;~ Appllcation Or Epstein et al .
~ 6. Detailed De3criptlon Or the Operating Syste2 ~. .
6.1 Overview The most immediate prior art to the present operating system is the AOS/VS operating system, marketed by Data General Corporation. Refer to Data General Corporation publication nu~bers 069-016 and 093-150 for explanation Or some of the terms to be used herein.

Operating systems are well known to those skllled in the art, and have been provided rOr digital computers almost since the inception of digltal computeræ. An operating system may be defined as an organized collection of programs and data that is specirically designed to manage the resources Or a computer system (Rarry Katzan, Jr., Operatlng Systems, van Nostrand Relnhold 1973). Operating systems generally provide services which experience has shown to be required by many Or the users of a computer system-- rather tban requ~ring each user to program these functlons ror herself, they are centrally provided for each user to slmply lnvoke. These services typlcally lnclude such things as edlting, compillng, and relocatably loading the user's programs; running the user's programs; allocating memory space and I/O
storage space; perrorming I~O and communications; rielding interrupts; and rielding "traps" resulting rram software and hardware errors.

Early computers, and thus early operating systems, provided for one user at a time to run one program at a t~me. Computers and their operating systems have in recent years evolved into multi-user mNlti-tasking 3ystems in which a plurality Or users Jointly run a plurality of programs. Flgure 601 depicts such an envlronment. For clarity, Figures 602A, B, and C show further detail Or the lnteractlons between the operating system, the dlstrlbuted computer system, a single one Or the users depicted in Figure 601, and a single one Or the programs depicted in Figure 601.

Prlor-art distributed computer systems have had oompanion operating systems which, among other things, perform the necessary transmissions among the computers comprising the distributed computer system. The operating system Or the present lnventlon makes novel use of the novel hardware (MCU

~.30~i310 ~ Applioation o~ Epstein et al `:
201, I~us 204) to facilitate such transmissions, performing them ln a manner that is transparent to the user. That is, the user need not be cogni~ant of whether a requested resource is resident in the same computer with her program, or in some other computer in the system; the user simplr requests the resource from the operating system, which determines whether the resource 8 local or remote and appropriately carries out the user's request either on the local computer or via TRus 204 on the remote computer.

Refer now to Figure 602A. The present invention's siEniricant departures from prior-art dlstributed operating systems center on DCALL
(deflection call) handler 502, GNS (global naming service) 503, and TSMI
(transport service management inter~ace) 504.

DCALL (deflection call) handler 502 is so named because it may resolve a request on the local computer (the computer which was running the program that lodged the request) or may "deflect~ the request to a remote computer on the distributed system.

GNS 503 keeps track Or where resources are located, ~on the local computer, or on which remote computer) and provides this information to DCALL
handler 502.

TSMI 504 handles details of communicating throu p MC~ 201 and over TRus 204 with other computers o~ the distributed computer system.

Figure 602A depicts Operating System 501 as surrounding the distributed computer system, and as having multiple occurrences Or DCALL handler 502 and TSNI 504. This is the nature Or a distributed operating system; it is the composite of all the operating srstem elements residing in or associated with all Or the individual computers comprising a distributed computer system.

As Figure 602A shows, a request rrOm a user program ror an operating system service takes the rorm Or a DCALL, which is fielded by DCALL handler 502, which consults GNS 503 to determine whether the necessary rererence can be resolved on the local computer, or must be de~lected to a remote Appllcation Or Epsteln et al computer. Figure 602B illustrates the former case, and Figure 602C the latter.

Figure 602B qhows the reference being handled ln the local CPU 101, and the result being routed by DCALL handler 502 back to the user program.

..
Figure 602C shows the reference being routed to TSMI 504, which transmits the request through looal MCU 201 over IBus 204 to the MC~ 201 Or the appropriate remote computer (the one previously identified by GNS 503).
~emote TSMI 504 receives the request and rorwards it to remote DCALL handler 502, which fills the request in the same manner lt would fill a request orlginatlng from the same computer wlth whlcb it 13 assoclated. The result i8 passed bac~ to the user program over the same path over which the request was rorwarded.

6.2 Functional Overview 6.2.1 Distribution Services Functional Overview The Distribution Services System (DSS), comprising DCALL handler 502 and Global Name Service 503, i8 the system component responsible for maintaining the database Or globally registered resources, performiDg address translation to determine the location or a resource given its ~ID
~unique identirier, see below), perfQrming the derlection Or individual operatlons when appropriate, and interfacing to the communicatlons subsystem tTSMI 504). These runotions fall into two maJor desien areas, the Global Name Service (GNS) 503 and DCALL handler 502.

While these are separate subsystems, the Na~e and Derlection services are not independent Or each other. The derlection opera~
tion oannot be accomplished without the use of the lnformation in the Global Name Service's databases, and the Name service exists to supply inrormation necessary to the derlection operation. The design Or efricient interface primitives between these two compon-.

`

Appllcation Or Epsteln et al ,~ ents is, thererore, important to the overall system performance.
In particular, ir trade-orrs will have to be made between such areas as the design of Name Service databases for efficient lookup versus efflcient update~, the needs Or the more frequent operation (lookup) will dominate.
.
The DSS components are designed to readily take advantage Or a continually evolving operating enviroD~ent. The initial implementation strategies for many portions Or the subsystem~ in question will evolve with changing technologies and patterns Or use. To that end, efrort is directed toward defining appropriate (fixed or extensible) interraces between components.
These interraces will serve to isolate service users from internal ohanges, and will allow the designs Or individual components to evolve as necessarg with minimal disruption to their users.

6.2.2 Global Name Service Punctional Overview That portion Or the Distribution Services System that deals with the introduction, verirication, translation and unlisting Or glob~l names will be considered to be part Or the Global Name Service (GNS 503) component Or OS 501. There are two sets Or interfaces to the GNS - system oalls available to both end-u~ers and other system 8ervices, and speoial pùrpose requests that can only be made by other 3~stem services.

The Name Service runctions that a user is permitted to invoke directly are those pertaining to the addition, deletion and llsting Or resources in the registry Or globally acoessible names. ~hile certain sy~tem services may be able to determine that a particular resource should be removed rrom the global registry (ror example, a disk mieht become unavailable as a result Or a hardware fault), only users can determine what should be placed in the registry, and, in the absence Or a failure, what should be removed. In addition, users will be permitted to interrogate the global regis-~ ~ Applioation Or Epstein et al `~ try for a list of all registered names, and their type, or for a liRt o~ all names Or a given type.

Since the granularity of resource registration operations is an LA~
(logical allocation unit, to be described below), updates Or the database of globally available resources will occur relatively infrequently. Direct queries by users will be more frequent, but are still presumed to be reasonably unoommon relative to thelr general system call mix. Thus, direct user interaction with the GNS should not present a signiricant communications burden.

By far the most common ~NS interactions wlll be with the Deflection Call Service. These will consist prlmarily Or queries requesting the transport service address associated with a particular resource. Other GNS-DCS trarfic may be possible, particularly ln response to error conditions.

6.2.3 Deflection CP11 Service Functional Overvlew In a dlstributed operating system, operation~ are most ef~ectively performed by acting on data at the site(s) on which they reside.
OS 501 will provide this environment by means Or a functlon invoca-tion mechanism that indioates that an operation is looation-sensitive, and its execution should occur at the location Or the key ob~ect indlcated. This mechanism allows implementors to use a slngle interrace rOr all data, regardless Or it3 locatior..
In addition, the choice of the approprlate execution slte for a dlstrlbutable operation can be deferred to executlon time, at which point the Deflection Service will be responsible for decidlng whether or not to derlect the operation to a dirferent locatlon.

The actual De~lection Call Service is invoked by use Or the Derlec-tion Call (DCALL) mechanism. Briefly, DCALL provides the means for indicating that a particular operation is to be performed against a parameter list, with the location-sensitlve parameter's UID

06~10 Applicatlon or Epstein et al :- .
speoifled. The exact syntax of DCALL invocation 18 described in ~,~ section 6.4.4 /

~hen a DCALL is used to invoke a function, the UID Or the resource whose location will determine the site of execution o~ the function i8 indicated. The caller has no knowledge of where the resource resides, only that it has the potential for being on a remote system. Regardle~s Or whether the runction is executed locally, the issuer Or the DCALL will see the same behavior - the DCALL is executed (in place Or a strictly local function inrocation mechanism), and execution Or the caller resumes following the DCALL, Just as it would with a strlctly local mechani~m.

The Deflection Call Service actually perrorms a bidirectional function. When a DCALL is i~sued, the DCS is responsible for either derlecting the operation to a remote 3ystem, or causing efficient invocation Or the local function. When a derlection occurs, it is received and processed by the Deflection Call Service on the remote host. In handling this portion or its function, the DCS must cause the appropriate functions to be invoked and results returned to the issuer or the original DCALL. Section 6.4 provides rurther details on both the specific interface to, and the internal operation of, the DCS.

6.3 Global Naming OS 501 extends the AOS/VS resource naming and management scheme by adding the concept of Logical Allocation Units ~LAU). LAU's are a oolleotion of obJects to be managed by the same servers and provi-ding a scope for AOS/YS names. LAU's will act as the distributlon key ror OS 501'8 derlection mechanisms. The naming syntax, however, has been extended by the addition Or the use Or Registered Resource names, rather than LAU names. While these may, in certain cases coincide, the use Or individual resource names allows the user to oontrol resource usage at a more appropriate level.

-1~1- :

Application Or EpQtein et al To allow further control of naming, and allow for lnterconnection Or networks wlthout redefinition of names, OS 501 provides COMWUNI-TIES which identify the scope within which names are to be lnterpreted. Registered resource names and COMMDNITIES will be managed by GNS 503.

6.3.1 Goals OS 501's main goal is to provide a distributed operating system environment in a natural, "seamless~ manner. An essential compon-ent in such an environment i8 the use Or a consistent global naming mechanism for all resources. Such a naming scheme will be ho~t independent and will also allow consistent naming ror both local and remote resources.

Additionally, the global naming mechanis~ should provide for splitting a OS 501 net~ork into one or more administrative subnet-Norks of users and res~urces. This mechanism must provide adminis-trative boundarieQ in a consistent manner that permits access acroQs these boundaries as necessary. Finally the mechanism should allow ror the merger Or dis~oint machines or networks in a manner with little or no impact to the individual users.

6.3.2 Name Format The rormat Or global names in OS 501 is:

::community::registered_name:VS_name where obJects such as directories or process execution groups are identified by registered names. The global name rormat i~ an extension Or the existing AOS/VS naming scheme~ and functions aocording to very ~imilar rules. Just as a simple filename can currently be resolved, by means Or working directory and/or Application Or Epsteln et al searchlist, into a single fully qualifled pathname, making it unnece3sary to always use expllcit full pathnames, similar conven-tions will be used to provide default values for the COMMUNITY
field.

While OS 501 is being designed with support for connection and ~subdivision Or networks, this function lity will not be visible to users in the initial release. The portion Or the global name rormat that will be exposed to users inltially will consist Or:

::registered_pame:vs_name This format will support ruture introduction Or the u~e Or tefault community name settings and explicit naming syntax extensions in a compatible manner when communities are made visible.

6.3.3 Logical Allocation Units Logioal Allocation Units (LAU's) funotion as containers for system resources. The LAU i~ a group Or resources, such as processes or rlles, that reside on a slngle system and are logically grouped.
The LAU provides a coutrol point rOr the naming, location, and management Or ob~ects ln the system. Three speoirlc examples Or types Or ob~ects fount in LAU's ln OS 501 are file tree~, peripheral~, and proce~ses.

While all resources are contained in LAU's, not all LA~'R are visible to users or ser~e as the names that are known to the Global Name Servioe as registered resources. For example, process groups (which are LAU's) are the unit Or re6istration for process manage-ment re~ources on OS 501. On the othei hand, file system LAU's correspond to loeical disks (LDU's)! but resource registration actually occurs on directorie3. -.

-t83-13063~0 Appllcation Or Epsteln et al A LAU will be given a unique identifier (LAUID) at oreation time;
this number will provide a unique handle ~or referencing the LAU in all communities. Resources within each LAU will be referred to by an additional identifier that is unique within the LAU, known as the Object Serial Number (OSN). Together, the two numbers will ¢reate a network-wide unique identifier (UID) for any resource.

6.3.4 ~egistered Names Registered names must be unique within a community, ~ust as two riles may not have the same name in a directorv (in this sense, the Global Name Registry may be viewed as a directory of registered names). When a user attempts to register a resource that would result in the dupllcation Or an existing registry entry, the sy3tem will report the error. A user then ha~ two options: he may rename the resouroe he was trying to register, and then register it by its new name, or he may register the ob~ect under an alternate name that i8 only interpreted by the GNS.

6.3.5 Communities The COMhUNITY rield designates the Name Service wlthin whose scope an ob~eot re~ides. The community provides rOr partitioning the oolleotion Or registered resouroes in the network to bound name scopes. It also allows for interconneotion Or networks ln an easily named manner that is an estension to, rather than a rederin-ition Or, the naming used within previously independent environments.

~ommunities have no relationship to systems except in the fact that LAUs in a oommunity reside on one or more syste~s. A system with two LAU's may have eaoh LAU registered in a difrerent community. A
oommon example Or this will be a ¢entral file server with difrerent ~30631() Appllcation of Spstein et al ~ i file system LAU's for each of several dlfferent communities in the network. Another common case will be a computational node with different process LAUs for each community it serves.

Since the community indicates the Name Service which will be lnterrogated for a particular registered name, the same name can exist in each oP sever~l interconnected communities without causing any naming conflicts. This provides a straight forward way for previously isolated net~rorks to be joined without invalidating existing name usage, since, for example, ::ADMIN::UTIL:FOO.PR is different from ::LANG::UTIL:FOO.PR.

The current community can, a~d generally will, be defaulted; a community need only be specified to refer to an object not located in the user's default community. A user in a commurity would, by means of the COMMUNITY setting in his envirorment, actually be addressing a particular Name Service when looking for ::UTIL:FOO.PR, without explicitly naming the community.

The format specified for names provides for growth in the future, should it become necessary. While it shoult be possible ror the administration of unique community names to be accomplished within an organizatlon, ~llowing previously independent networks to be connected without name collisions, it is not reasonable to assume that large~ or physically dlsJolnt or independent organizations will want to centralize such name selection. To accomodate inter-connection of such groups Or networks, extensions to the naming structure will be defined. By supporting default values for these added fields, e2isting name usages wlll continue to be valid.
: '.
.. : .:
6.3.6 Application of Global NaminB to OS 501 Subsystems .
As mentioned earlier, OS 501's global naming strategy is actually a set of extensions to the current AOS/VS naming rules. To accomo-date these additions, the components inoluded in a process' envi-ronment will be expanded to provide default values for the new name 13063~0 Appllcation o~ Ep~teln et al fields as well ~or those found in AOS/VS. In this way, OS 501 users will be able to use both full and partial pathnames according to not only the rules currently defined by AOS/VS, but also accor-dlng to rules that reflect the naming extensions pro~ided by OS 501.
-The uses of global names in the ~ile system, proce~s management andperipheral manag~ment services of OS 501 are discus~ed below.
Where appropriate, the OS 501 ~odel will be compared to that provided by the prior-art AOS/VS.

6.3.6.1 File System For basic file system uses,`the unit of resource registration will be at the individual directory level. ~hile the ~ile system design specification contains a detailed description of the implications Or this runctionality, it is summarized here.

The registration of a directory makes the entire subtree of which the directory is the root, a glob~1ly visible resource. All users, rsgardless o~ their physical location then have the potential to use any portion Or the subtree, sub~ect to the usual access rightq constraints. Those directories that are not registered are ~lnvisible~ to users not initlally running on the same system as the file~ themselves reside.

In this way, users have flexible control over the amount and portions (if any) Or their local ~ile resources that remote users can manipulate.

6.3.6.2 Peripherals, Queues and Global IPC Ports , One Or the benefits OS 501 will offer i~ the ability to place expensive peripherals such a~ plotters or high quality printers in 1:~06310 Appllcatlon Or EpEteln et al a few locations on a network, and make them easlly available to all users. Currently, u~ers name all devices they wish to use by means Or either placing Q or :PER in thelr searchli~t, or by givine the fully quali~ied pathname to the device. This works in the AOS/VS
context because there can only be one peripherals directory on a system.

Two other classes Or resources, global IPC ports and spool queues, are named in :PER in addition to peripherals. Global servers currently establish "well-knownn ports rOr use by their customers by means Or agreed upon convention. The corresponding riles are placed in :PER. Most spooled devices are referred to by the name the assoclated spool queue, not by the device name. These queues are named ln :PER. Both Or these meohanisms need to be extended by OS 501 so that servers and spoolers can function in a distrlbuted environment and provide globally accessible service.
The registration Or global ports and queues into ::PER would parallel the extensions provided rOr devices, and would serve to make these resources available on a global basis.
' The PER directory on any node could be registered, making, the tevices named in that directory globallY available, but that presents certain problems. Ir more than one system had a resource in :PER that lt Nlshed to reglster, several directorles, only one Or whlch could be named ::PER, would have to be created. In additlon, a user wlth any devlce or similar resource that he desired to share would have to make all his local devlces vlsible, and rely strictly on ACL protection to prevent their use by others.

Flnally, locating resources reglstered in thls way would requlre elther placlng ::reglstered_name on the user's searchlist for every global peripherals directory, or knowlng that the devlce i~ named throu p a particular registered directory. ~hile this 18 not necessarily a problem in all cases, the number Or directories that can be placed on the searchlist i8 limited, and gairing access to physically dispersed peripherals through anything other than ~ ~ ~ 1306310 Appllcation o~ Epsteln et al explicit re~erences to the containing LAU could be impossible.
.
OS 501 will solve the naming and searchlist proble~s by creating a separate name registry for peripherals. This registry will be treated as a directory, although it will only support a limited set Or dlrectory-like operationA. It will be called ::PER. The act o~
registering a devioe will serve to effectively to create a link of the given name in the global peripherals directory. A user can place ::PER in a searchlist and be able to list and reference devices in much the same way as he can manipulate riles.

6.3.6.3 Processe3 In the AOS/VS-defined model, processes may be referred to by two baslc mechanisms: a text process name, or a numeric prooess identi-fier (PID). The AOS/VS model imposes the requirement that both types Or identification must be spaoe unique - that is, no two processes can exist simultaneously ln the same system system that have either the same process name or PID. Since many VS applica-tions make these assumptions about their e m ironment, OS 501 Deeds to provlde these reatures ror ¢ompatlblllty. The distributed environment makes this much more complex than it is ln AOS/VS.

While VS can easily guarantee at the tlme a process 19 created that no other process Or that name exists ln that system, OS 501 can only cheaply ensure this within a ei~en node. To provide such uniqueness throughout the distrlbuted environment, OS 501 will use process LAU ' s.

A process LAU will act in a slmilar, but not identlcal, manner to today's AOS/VS process tree. PIDs and process names will be allocated uniquely ln the LAU, with network-wide uniqueness guaranteed by the LAU
name belng unique and belng required as a quallfier. Process names wlll be returned and dealt with in the same manner as network host names ~306310 Applioatlon o~ Epsteln et al i:
may be used today with AOS/VS networking. This ln¢ludes the abllity Or the various network calls lnvolving host and virtual pid3 (i.e. PID's from another LAU) to work as they currently do in AOS/VS.

Unlike the AOS/VS model, prooess trees may cross LAU's. Figure 603 shows a posslble environment. - -~ote that two process in the same tree may have the same slmple process name as long as they are in difrerent LA~'s.

A system may mana8e more than one process LAU. A global servlce may be created in its own process LAU 80 that lt will have the s2me name no matter what syste~ it resides on. A name such a~ ::INFOS:OP:INFOS is completely host lndependent, and will be the common rOrm for all global services.

6.4 Deflection Call Interraces ~ -The Derlection Call Service (DCS) provides the interrace between the rest Or the operatlng system (and users) and the actual mechan~
isms used to deliver a request to the appropriate (possibly remote) host. It is the component Or OS 501's Deflection Service Systeo that actually determines where a resource is located, and thererore is responslble for irvoking either the local or remote copy o~ the runotion being requested.

The DCS i9 designed to both initiate remote requests and respond to them. When an operation is derlected from another srstem, it is the DCS that reconstructs the original request and causes the proper runction to be invoked on the system that manages the resource. Once the activity i~ complete, its results are returned via the DCS to the requesting system, where that host's DCS returns the results to the requesting task.

6.4.1 Goals ~ ~ 13()631~) Appllcation of Epstein et al : ~

By providing a eeneral purpose interrace, the DCS becomes responsi-ble for actually interacting with the communications transport function. This isolateR the rest Or the system from understanding the particular requirements Or the particular protocols involved, meaning only one system component must learn to package network messages. As a result, changes to the protocols will have minimal impact on the system itself.

Similarly, the transport service will be defined in such a way that the interface it presents to the DCS will be independent Or the actual communications hardware being used. ml8 isolation will permit the evolution Or loc~1 network~ to provide better perfor-mance characteristics with only minimal (e.g. driver le~el) changes in the software. A further advantage Or this interface definitio~
is that it permits OS 501, including the DCS itselr, to per~orm distributed runctions without regard to the actual connectlon mechanisms, so that user-visible operations are performed indepen-dently Or the underlying hardware. While lndividual hardware configurations may make some links inherently more expensive to use, they will not be any more difficult to use.

~.4.2 Identifying and Locating Resources . .

05 501 provides a transparent distributed enviroDment at two levels. By the use or the global naming scheme for user-visible resource names, any resource in a globally registered LAU can be identified by using a single set of conventions regardless Or its location. In an analogous way, the inter~aces to the DCS must provide callers with a single meohanism to operate on re~ources regardles9 Or their location.

Internally to OS 501, every resource is identi~ied by a unique 13063~0 Appllcation Or Epsteln et al identifier (UID) that consists Or two portions. The rirst, the LAUID, rully identifies the Logical Allo¢ation Unit in which the resource resides. This, in turn, can be used by the Distribution Service to determine the location, in terms Or both the machine and community, Or the subsystem operating on the LAU ti.e. the ob~ect manager ror the LAU). The second portion, the Ob~ect Serial Number (OSN) i~ interpreted by each subsystem, and only has meaning to that sub~ystem.

Many lnternal system operations are perrormed on a resource iden-tified by some non-textual handlej or by a pair Or identiriers, one Or which is not a text tring. The handles currently in use generally correspond to the OSN portion Or a UID. ~ithin OS 501, full UIDs will be used ror these handles. Just as systems must have a means Or deriving the internal representations from text names, the GNS will provide a mechanism to determlne the LAUID
portion Or a ~ID from a text name (each sub~ystem provides the OS~
port~on independently).

There i8 a ~econd class Or internal system identifier ror an ob~ect, and that is a context-sensitive "nickname~. These identiriers, e.g. channels, allow the system to accelerate the mapping between a particular resource user, the resource itselr, and the particular use being made of the resource. The DCS will want to use a similar mechanism to indicate the continued use or a particular global resource. To accomplish this, an (optional) accelerator will be passed back ror later use in this way.

The ~eflection C~1l Service uses the LAUID portion Or a resource's ~ID to deter~ine the location Or the obJect, and thus whether the requested operation will occur locally, or lr not, on which remote system. This determination is made by querying the Name Service component Or the system. The Global Name Service (GNS) and its local component maintain the registry Or local and globally regis-tered LA~s. This registry will provide the DCS with the informa-tion needed to invoke the communications transport service lr the _191_ ~3063~0 Appllcation o~ Epsteln et al LA~ is on another host.

, ~ .
6.4.3 Invoklng the DCS

The Deflection Call Service will be invoked by means Or a procedure call interface. The actual derlection call i8 desig~ed to be 3ubstituted for the current invocation mechanism~ for internal system subroutines and 3ervices. That is, rather than using LCALL
or LJSR to invoke a system routine, operations that would most appropriately be per~ormed at the locatlon owning the resource would be invoked by means of a defleotion call (DCALL). The existing oalling sequences to routines invoked in thio manner may have to be reorganized to pr~vide ror the addition of tbe speciric parameters the DCS will use to detcrmine the processing paths it selects.

The DCALL deflection mechanism distributes based on the lot,ation of a resource, identified by either a UID or an accelerating handle, passed as an argument to the call. It is intended to function, in the local case, as much llke an LCALL or LJSR as possible, witb the target routine being lndloated by a functlon type, and the argu-ments that would be passed to the local routlne being included in the DCALL's parameter 11st. In both the local and remote cases, DCALL will provlde for normPl and error return~ in the same fashion as is currently done for subroutine calls~

If the resource is looal, control i3 transrerred to the routine indicated on the DCALL. Ir the resource is remote, however, some preprocessing must be performed to allow the deflection ar the operation to occur. The DCS wlll dispatch to a message packaging routine based on a function type parameter, and this routine will ~assage the arguments passed to the target routine into a self-contained packet with no references to memory addre~ses. This packet will then be used by DCS in the message it sends to the ` Application or Epsteln et al derlectlon handler on the remote system. A parallel unpackaging routine on the remote system will recon~truct the argument stream ror the functlon to be executed there.
;

6.4.4 The Derlectlon Call There are many operatlng system deflection points that either perform ~one Qhot" operations (e.g. eetting the fully quallfied pathname o~ a file), while others mark the beginning Or a contlnu~
lng serles Or tr~nsactions or operations to be perrormed against a particular resource ~e.~. opering a file). Both types Or opera-tions share the reature that they occur asynchronously to prevlous operations, and 90 do not occur within the context of an ongolng relatlon between a process and the partlcular remote resource ln questlon, although the second group initiates such a pattern Or use. Thls group Or derlectlon polnts will benefit from the DCS
returning an accelerator to the caller that can be used to indlcate the ongolng relatlonship, and shortcut the procedures needed to determlne the resource's location.

A thlrd group Or derlection points conslsts Or the operations that oocur withln an ongoing relationship between a caller and a resource. The derlection or these operatlons can be ac oelerated by the use Or the handle returned by the DCS when the relatlonshlp was establlshed.

The teflectlon call is designed to allow the DCS to use both short hand and full ldentlricatlon, as appropriate, to locate an operatlon's target resource. When a DCALL ls lssued, lt is the caller's responsiblllty, based on the function involved, to know whether to resource identifler ls a ~ID or an accelerator, and to indicate this to the DCS. In additlon, when a ~ID i8 being passed it is the caller's responslbllity to request that an accelerator be returned rOr ruture reference to the obJect.

~ ~ 1306310 Appllcation Or Epstein et al Tbe actual syntax of a DCALL i9:

DCALL(func_type_~_~lags,~lD_or_handle,arg_bloc~_ptr) where runc_type_4_flags indicates the processing routlne and pa¢kaging~unpackaging routines to be used in handllng the deflected operation. This argument also includes flags to indicate special processing options. The only flags defined initially are:
?ACEL the value pas~ed in the first argument is the short hand accelerator for the resource.
?GHNDL return an accelerator for the resource's location on returning from the DCALL.
~ID_or_pandle is the ~ID or accelerating handle of the resource that wlll detenGine tbe execution location of the operation. If the ?ACEL
rlag is set in the rlag/runction argument, this i8 an accelerating shorthand rOr referring to the resource's looation. If the ?GHNDL flag i3 ~et, the DCALL
will return an accelerator in this argument.
arg_U ock_ptr Points to a blook of data consisting o~ either the argument list as outlined in the discu~sion belcw on generic parameter passing corventions, or the speciflc argument block expected by routines that do not conrorm to the conventions.

-19~ ~,:

` 1306~10 Applioatlon of Epsteln et al , .
DCALL is a boolean function with a true result indlcating an error haso¢curred. In the event of an error, the FUNC_TYPE ~_FLAGS
argument will contain the error code being returned by the DCS.
, :

~.4.5 Parameter Passing and Packaging Data Many of the argument llsts being manipulated at derlection points lnclude pointers to buffers containing data to be acted on by a routine. The exact nature Or the data depends on the operation involved, and generally such argu!ments are passed without any explicit indication D~ the length o~ the buf~ered data, since the routine being called can determine this in context.

The~e mechanisms are errective in a ~trictly local ervirorment, since the memory containing the bufrers is directly addressable, and therefore, will not have to be copied be~ore being maripulated.
When a routine is invoked by a DCALL, however, the potential exists ~or the routine having to be run on a remote system against the same parameter ~lst. In cases where the operation must be de~lec-ted to another system, the arguments must be incorporated into a message to be passed to that system.

For a remote system to act on data, all polnters mu~t, at some point, be resolved to indicate data that can be incorporated into a message. Since this involves copying data from one place in memory to another, it should only be done when nece~sary, i.e. when a DCALL will really result in a derleotion. T~o basic approaches exist Por dealing with thiQ requirement.

The rirst is that arg~ment lists be tuned ror strictly local reference, much as they are now. As part Or the derlection operation, the resolution Or pointers and tho burrers they indicate into a bounded set of data would be accomplished by calling a speciric massaging routlne ror each function or class of functions.

Applloation of Epstein et al This would impose no overhead on local operatlons, but would require an extensive set of data translation routines be written and supported for putting argument lists into, and taking them out Or, messages being sent to remote sites.

A second way to build the argument list portion Or the message is to organize the original parameter list in a more bounded, generic fashion. If the argument list actually consisted of an argument count, followed by pairs of argument pointers and their lengths, then a slngle message building routine could operate on all argu-ment lists. Since the data bounding operation must always be perrormed locally at some point in processing an argument list, the only additional overhead associated with this method is the addi-tion Or the argument count value, a minimal overhead addition.

6.4.5.1 Generic Parameter List Convention It should be possible to use the sec~nd format at the majority Or derlection points in OS 501. This will provide both good response ror local operations, and mlnimize the number Or DCS operations that will be dependent on the actual functions being deflected.

The generic parameter list rormat for the content3 Or the ARG_BLOCR_PTR block is as shown in Figure 604.

The total length Or the argument list indicated by ARG_3LOCR_FTR
is, therefore, (8~n)~(?alhln~4) bytes.

~ithin each ar~u~ent block, the paramter type~data type entry is used to determine the rormat Or the data beine sent (the data type), as well as when it is used by the caller or target runction (the parameter type). The possible values rOr parameter type are:

Application Or Epsteln et al :
lnput - the parameter is passed by the caller and never modiried by the receiving function.
, ~ output - the parameter is returned to the caller; the value ; ~ent to the called function is not important.
update - the parameter is read by the receiver, and is returned to the caller after having been (possibly) modified.
The amount Or data actually transferred either over the LAN or between memory buffers can be minlmized by using the parameter type value to lndicate in which direction(s) DCALL argument~ must actually be sent. These optimizations can be particularly impor-tant when an argument is a block (or larger) bu~fer that is only being read tor written).

The data type value indicates the rormat Or tbe data being pointed to by the parameter address rield. The posslble values lnclude the expected range of bit, byte, and word, as well as page (to minimize data re-copying) and immediate. In tbe case Or imediate data, the actual data i8 passed in the parameter address field, since it is known to be capable Or fitting in the 64-bit field. This conven-tion ellminates the need to construct a pointer to data that is of equal or smaller size to the pointer itselr.

Users o~ the generlc parameter convention will be identified as suoh to the GNS as part Or the database maintained for function code mappings. If all system-supplied routines use the generic oonventlon, thiQ inrormation will not be necessary, since any user-visible DCALL mechanism would only permit the use Or the generic interface.

6.4.5.2 Specific Parameter Passing Convention For those operations that do not lend themselves to this format because Or other processing requirement~ (some I/O operations, for ~3063~0 Application of Epstein et al .
example), it will still be possible for the DCS to dispatch to function-speciric routines. The goal has only been to min~mize the need for such routines, not ellminate them. In such cases, the ARG_COUNT parameter still determines the number of pairs of argu-ments that rollow.

When the function requires the use Or a specific parameter packaging/unpackaging routine, the DCALL parameter ARG_BLOCR_PTR is used to point to a block whose rormat is to be interpreted by the specific routine that will do the formatting. The lnterface to those routines will be Or the format:

xxx_FACR(arg_block_ptr,message_buf_ptr) where routine_~_arg_ptr points to the argument block passed in on the DCALL.
message_buf_ptr is a byte pointer into the message bufrer being built, in~icating the start Or the data area. On return, it will have been updated to indicate the rirst unused bufrer location.

For each packaging routine required to format data for transmls3ion to a remote system, there will be a corresponding unpackaging routlne for ths recelver to use to reassemble the request prlor to issuing lt. The lnterrace to the messages conslsts Or the same arguoents, bu ln this case, the ARG_3LOCR_PTR polnts to the burfer that will recelve the reformatted argument 11st, and MESSAGE_PUF_PTR indlcates the source Or the data.
:, :
6.5 Global Name Service Interface '.

The Name Servlce (NS) i9 called by OS 501 through a fixed interface Or internal calls. These calls manipulate local and global databa~

-:- . , , Application Or Epstein et al ses of the Name Service providing support for:
Deflectlon Call Service -- routines to translate UID's to transport addresses and funct$on codes to routine addresses.
Name Resolution -- routines to translate UID's to and from LA~ names.
LAU Manipulation -- routines to create, delete, register and deregister LAU's.
Ob~ect Management -- routines to add and remove function code support.
The sy~tem interrace level routines descr~bed here presume that all input has been validated.

6.5.l aoals The Na~e Service'3 goal is to provide a rast, redundant distributed database Or Logical Allocation Unit entries. In particular the service must provide very ~ast support for deflection calls.

The Name Service will be designed with an interface that will allow the internal implementation to change, allowing it to reflect usage patterns and new algorithms found once OS 501 is in the rield.
Also, the interrace will be general enough 90 that extensions to the global naming sohe~e will not arfect the oalllng conventions ror the Name Service.

6.5.2 Name Service Database ~he Name Service manages a network wide global database Or entries describing Logical Allooation Units. This databa~e is oonceptually two pieces oonsisting Or a oollection Or local LAU's Por each system and a database Or global LAU's visible to the network.

The local database contains entries ror all LAU's on a system -199- :

13063~0 Application Or Epstein et al the network. A LA~ is lnvislble to the system until it i3 entered i into the Name Servioe's looal database. The system will have ~i~ entered the f~le syste~ root and lnitial process tree as LAU's in the Name Service at boot time.

LAU's are supported by object managers which may be either system services or user proce~ses. These obJect managers operate on LAU's which they support in response to speciric function requests from either local or remote service requestors. ~emote requests are issued by means of the Distribution Service's derlection call (DCALL), which routes requests to the proper obJect manager, and permits both the requestor and the serivce provider to treat both local and remote requests alike. The type Or obJects contained in a LAU will determine the actual action taken in response to certain function codes.

The Name Service's local database consists Or an entry Por each LAU
on the system. Each entry has three primary pieces Or information:
Local Name The local LAU name is a 1 to 31 character name Or the same rorm as a rile name. This is a user visible handle ror the LAU, and is visible rrom the time the LAU is created until it is deleted. This name must be unique on the system, and oannot conrllct with any globally registered name (see 'Registered Name' below). Multiple systems in a single community may within the community use the same local LAU
name in strictly local usage.
Unique Identlfier (UID) The ~ID is the unique identifier of the LAU. This is a normal UID witb a speoial value ror the ObJe¢t Serial Number (OSN) to indicate it is the LAU id. This identifier is network-unique. The allocation Or LAUID's is one Or the Name Service's responsiblities.
Function Codes The LAU has associated with it a list Or runction codes the obJect manager ror the LAU supports and the addresses Or the routines to support these runctions.

Appllcation Or Epstein et al The global database contains entries for all LAU's visible to the network. A LAU is invisible to other than the local system until it is entered into the Name Service's global database. This Name Service database represents a community in the context Or global naming.

The Name Service's global database consist~ of an entry for each LAU in the communlty. Each entry has four primary pleces of lnformation:
Registered Name The ~egistered Name has the same format as the local name described above. This is the network wide user visible - handle rOr the LAU entered into the Name Service-~-whe~F'the LA~ is registered.
~nique Identifier (UID) The UID is the unique identifi~r of the LAU as described ror the local database. This is the identifier that the deflection call service routes its requests on. '~ ~
, 'S
~ Transport Address - The transport address is the address used by the 'netwo~k transport service to route messages to the system where the LAU resldes.
Subsystem Data Area (SDA) The SDA 18 a subsystem specific value retained by the Name Service on behalf of the sub~ystem. This is information used by the subsystem that would be available in context for strlctly local resources, but may not readily be accesslble on the system orlginatlng the call ln OS 501.
6.5.3 De~lectlon Service Support Routines The Name Service is primarily a database server for the deflection call service. The rollowing calls reflect the requirements Or the DCS as presently defined.

6.5.3.1 Return Transport Address ~ -201-" rf.

Applicatlon of Epstein et al ~::
N When handling a DCALL the deflection call service, uses a UID to ; deflect to the proper node in the network. To locate the target node of the call, the DCS will call the Name Service with XADDR to get the transport address to deflect to. This call will be tuned to provide the fastest possible response for the deflection service. The syntax of the call is:

XADDR ( UID, Transport_Address Where UID is a pointer to the UID whose address on the network is desired.
Tran~port_Address is the transport address Or the resource returned by the Name Service 6.~.3.2 Return Functlon Address Once a DCALL request has been routet to the node containing the LAU, the DCS must be able to dispatch to a servioe routine for the speclfled funotion in the obJect manager for that LAU. This lnfor-mation ls stored in the Name Service Or the node containing the LAU. The derlection call servlce will call FADDR for the address to tlspatch to. The syntax Or the call is:

FADDR ( UID, Functlon, Paddr ) ` ~306310 Applloation of Epi3tein et al where UID is the UID whose ob~ject manager function i8 desired Function i9 the function code to be executed by the ob~ject manager for the LAU
Paddr is a pointer to a two entry blook whose entries will be returned by the Name Service. The first entry is the address of the process table Or the process the service routine for the function resides in. The second entry is the logical address in the process of the function service routine.

6.5.4 Name Translation Routlnes The most co~mon interaction of the Na~e Service and the OS 501 ~ystem not involved with deflectlon will be in the resolution of ~global names to and from a UID. The following calls were designed ~or ease of writing generalized name resolution routines.

6.5.4.1 Lookup by Name Thi~ is the primary translation service of the NS. For system CallJ involving resolution of pathnames or process names, this call returns the UID of the glob 1 portion of the name. The actual syntax of the oall i3:

GET ~ID ( Name, UID, SDA ) :
: :

~306310 - Application Or Epstein et al where Name is a bytepointer to a pathname or process name Or the resource to be resolved. (Note: this is a pointer to the string arter the leading ::, identifying the name as elobal. The Name Service returns with the pointer at the character after the global portion of the strlne UID is the UID of the innermost default context to re~olve in, (normally COMMUNITY, when OS 501 supports more than a COI~MUNITY, it may be one the higher scopes), 0 if no default.
The Name Service returns the UID of the LAU or ::PER entry SDA ls the sub~ystem ~pecific data area for this LAU returned by the Name Service 6.5.4.2 Lookup by UID

This i8 the inverse Or the GE2_UID operation. This call provides the full global portion Or the name Or a resource, given its UID.
GE2_NANE will be used by the system to provide the global portion Or a name for calls su¢h as ?GNAME. The call will always return the the registered name Or the LA~ if possible, otherwise it will return the local LAU name. The leading double :: i~ not returned by GE~ UID for the convenience of process management which will not return a :: in its process name to the user. The syntax of the call is:

GET NAME ( UID, Name, Name_length ) -204_ - - . , :--.. .. : : : .

: 1306310 Appllcatlon o~ Epsteln et al ~here UID is a pointer to the UID whose name is desired to be returned Name is a byte pointer to a burfer to receive the fully qualified LAU
name, ie community::lau. Note no leading colon is returned, and the byte polnter ~ill point to the character after the returned global name string.
Name_~ength is input with the length Or the burfer to receive the name Or the LAU, and returns the length Or the name 6.5.4.3 Get a 11st of global names ror a community This call i~ the working portion Or the ?GNGN call. The c 11 returns a fixed block of name~ for each time entered. No template matching is perrormed at this level. The ~yntax Or the call i~:

LIST_LA~ ( Start, Community, Buffer ) Where ~-Start is a value returned by the previuos LIST_LAU call. Initially LIS~_LAU
is oalled with 0. The returned value should be used rOr next invooation of the routine Community is a byte pointer to the community name to scan, a value Or zero mean~
~can the locally entered LAU's ~ufrer is a bytepointer to a 1024 byte long buffer to recieve 32 LAU names.
A null LA~ name indlcates the end of the list, if the routine returns an EOF error.

G.5.5 LAU Manipulation Routines :
~3063~0 Appllcation o~ Epste~n et al ,~ ~
The following routines are the Name Service portion of the user visible system calls to manipulate LAU's. These calls directly support the LAU creation and deletion function~ of ?CLAU and ?DLAU.
The registration routine will be used by the ?REGISTER and ?CLA~
calls, with the deregister routine provide the inverse for ?DEREGISTER and ?DLAU.

, . .. . .
6.5.5.1 Enter a LAU into the Name Servlce This operation make~ a LAU known to the Name Service o~ the node the LAU re~ides on. For many LAU's this can be thought of as a create operation. The operation associates a LAU name with a UID
and a SDA. The operation will generate the UID if required. This call must be per~ormed before any other operation is valid on the LAU. The format Or the call is:

LAU_ENTER ( Na~e, UID, SDA ) where Nameis a bytepointer to the LAU name of the resource UID18 a pointer to the UID of the LAU, if the ~ield contain~ -1 the UID is to be returned by the Name Service ~ -SDAis the ~ubsystem specific data area to be assooiated with the LAU

6.5.5.2 Register a LAU or ::PER entry This routine makes a LAU globally visible in the current oommunity o~ the process invoking the call. The LAU must be known to the Name SerYice of the node it resides on, by a previous call to LAU ENTER.
This interface is analogous to creating a link to the LAU in the community. Note the interrace handles the special case of the ,: ~, :, . ~

- - ~3063~0 ` - -;-`;
Applicatlon of Epstein et al ::PER LAU. The lnterface is asqumed to be invoked on the system with the resource being registered, ie the register system call must deflect on the UID Or the resource being registered using a DCALL. The syntax Or the call is:

REGISTER ( Name, UID ) where Name is the name to register the LA~ as in the community, or a name Or the Porm ::PER:device_name to reglster a peripheral entry UID i8 the UID of the resource to be reglstered 6.5.5.3 Deregister a LAU or ::PER entry ::

This operation removes a LAU's global visibility. The operation deletes the ~ID to Name association Prom the global Name Service, leaving the LA~ only visible on its local node. The interPace, unlike REGISTER, i8 may be invoked on any node, ~ince the node where the LA~ resides may have Pailed, causing a user to issue tbe DERE~ISTER to remove the LA~ entry. The interPace oP the call is:

DERE5ISTER ( ~ID ) where UID is the ~ID of the resource to be deregistered Prom the Name Service 6.5.5.4 Remove a LA~ ~rom the Na~e Service This operation completely removes a LA~ Prom the Name Service. The operation deletes the Punction table Por the LA~, and will deregis-ter the LA~ ir it is currently regi~tered. This call is analogous 130~310 Appllcatlon Or Epsteln et al to the deletlon of a LA~. The interfa¢e to the ¢all is:

LAU_REM W E ( UID ) where UID i8 the ~ID Or the LAU to be removed from the Name Service 6.5.6 Object ~anager Support Routines The following object manager support routines provide the deflec-tion call service on the machine the LA~ resides on with a database of function support routine address to be used by FADDR.
Initially, this fun¢tionality will be only available to the system, but eventually system calls corresponding to the following routines will be supported.

6.5.6.1 Enter support for one or more function codes A LA~ is serviced by an ob~ect manager to support the appropriate runotions. The ob~ect manager must ldentify to the Name Service of the node where lt and the LAU resides, whi¢h functions are sup-ported and what address should be dlspatched to for each functlon.
This routlne may be called multlple ti~es for a given LA~ until all servlces are identlfied. The syntax of the call is:

FUNC_EWTER ( ~ID, Fun¢_List ) where UID is the UID of the LAU whose obJect mana8er 1~ being defined Func_List is a pointer to a 11st of functlon code, support routine address pairs that are terminated with a pair of -1 for function code, and address ~ ` 130~310 Appllcation o~ Epsteln et al 6.5.6.2 Duplicate a LA~'s function 11st This call allows a service to specify that the functlon code for two LAU's should be tied (for example the file sy~tem would only have to lssue FUNC_~NTER for the first file system LAU the could use this call to specify all other support). IQsuing thls call means that any FUNC_ENTER or FUNC_REMOVE operation performed on any LAU connected by a FUNC_DUPLICATE affects all LAU's so connected.
The syntax of the call is:

FUNC_DUPLICATE ( ~ID, SUPPORTED_UID ) where ~ID is a pointer to the UID of the LAU
to define an ob~ect manager for SUPPORTED_UID is a pointer to the UID of the LAU
whose functlon table ls to be associated with the LAU specl~iet by the UID.

6.5.6.3 Remove support For one or re runction codes An obJect mana8er may remove support for one or more ~unctions.
Thls may be all functlons served by this ob~ect manager such as when the procesis is terming, or it may be a selective removal Or a group runctlon~. The syntas Or the call is:

FUNC_REMOVE ( UID, Func_List ) Application Or Epstein et al where ~ID is a pointer to the UID of the LA~ -whose ob;ect manager is removing the support for the given runction~ -Func_List is a pointer to a list Or functions no longer to be supported for this LAU or -1 for all functions supported by the caller 6.6 Deflection Call Servioe Details The Derlection ~all Service consists Or two components, one that performs the initial processing and invokes the requested runctiOn either locally or remotely, and one that processes a request Prom a remote DCS, causing the requested function to be performed as ~ -though initiated by d prooess running locally to the serving sy3tem. The ~irst component is said to be the INVOKING side, and the second is the SE~VING side.

In keeping with the system design philosophy Or OS 501, the INVORING funotlons will be executed in the ~ystem by the running user task. This will, in turn, help minimize the overhead associated with DCALLs that resolve to strictly local proce~sing.

The operations Or the SE~VING side are not, however, assoclated with a currently running user process on the system providing service. A pool Or sy~tem tasks must be made available to perform these runctions. These tasks will be provided by a second system process that will per~orm all of the Distribution Service Subsystem's runctions that cannot be executed by a running user task.

All or the descriptions that rollow assume that the interrace to the transport service will be that 3peciried by Lyman Chapin or the ACS roup. The actual protocol and communications management will be perrormed by transport runctions that will be included in 13063~0 Applloation or Epsteln et al the Distribution Service prooess, but will be provided (and maintained) by the ACS group.

6.6.1 Invoking Side Operation The executing task enters the DCS by calling the DCALL routine with ACO containing the function to be invoked by the DCS and AC1 containing a pointer to the ~ID Or the target obJect. Since AC2 does not contain an argument speciric to the operation Or DCALL
ltselr, it can contain data to be used by the routine that will perrorm the indicated function. Any remaining argument~ to the 3pecified runction will be pushed on the stack.
: ~
~Packaging~ Or the runction's arguments into messages will be performed by a routine that will be able to determine the exact rormat Or the arguments involved. Sinoe the packaging involves the resolution Or addreæses into pointers to portions Or the message to be sent, it need only occur when the DCS determines that the function must be perrormed on a remote system. Deferrirg the building Or the message until that point will make handllng strictly local processing more efricient, and will not have an adverse errect on remote processing. The actual mechanism ror determining how paokagins occurs will be determined following rurther study Or the dirrerent message~argument rormats that will be necesssry.

The prooessing flow, beginning with the call to the DCS will be as shown in Figure 605 6.6.2 Serving Side Operation The system receiving the request from an Invoklng DCS will have a pool Or (1 or more? tasks to function on behalf Or remote users.
Any tasks not currently processing a remote request will be 1306~10 Application Or Epstein et al pended; one Or these waiting task~ will handle the next incoming message. Flow control can be affected by altering the priority Or the Distribution Service process, or by limiting the number Or resources, either tasks or buffers, available to the DCS function.
Until the task llmit ~if any) 18 reached, the receipt Or a message by the last waiting task will cause it to create anotber task to wait for the next message.

The flow is as shown in Figure 606.

6.6.3 General Comments The database referred to in the preceding sections is intended to serve two purposes. The rirst i9 to provide the invoking side DCS
with a cache Or currently used LAUID-host address pairs, to accellerate the determination Or an obJect 1 9 location. me second, and more slgniricant purpose, i8 to permit the DCS on both the invoking and serving sides to be able to track remcte resource users in the event Or node or process railures. The e~act content and ~ormat Or these database entries will be deter~ined in part by the final deslgn Or the other subsystems' data structures and error handling requlrements.

13063~L0 Appllcation Or Epsteln et al 6.7 TRANSPORT SERVICE MANAGER INTERFACE (TSMI) ;

TSMI 504, it will be recalled rrom the dlscussion above and from Figure 602C, i8 the Transport Servicc Manager Interface.

The Transport Service Message Interface (TSMI) gives OS 501 Distribution Services transaction-oriented access to the Transport Service. The TSMI uses a simple protocol to manage Transport connections and transactions (request-response message pairs). The TSMI operates as an "entity~ in an "entity enviroment" and provide3 system-independent support for event-driven entity scheduling and erficient inter-entity parameter passin~.

The basic relationship~ between the TSMI, the DTSI, and the Transport Service are shown in Figure 607. From the architectur~l standpoint Or Open System~
Interconnection (OSI) (well known to those in the art), the TSMI provides a rudimentary Session Layer service.

GROUND RULES:

1. Most Or the communication that will take place to support OS
501 distribution will be transaction-oriented; that i8J it will consist o~ independent request/response Pairs (analogous to the ramiliar system-call/system-call return).
~owever, some runctions, such as distributed system management, tbe global name service, and the global w er prorile service may require an asynchronous (unpended) send/receive capability as well.
2. The Transport Service is not responsible for user-level authen-tlcation or access control. Transport Service users (sucb as OS 501) must implement an appropriate remote resource access control policy. Authentication could be provided as a TSMI
service, but would require the derinition and implementation Or a third-party authentication server.
. Tbe TSMI does not support atomic transactions. If no response to a transaction request is received (perhaps because the remote system crashed and never sent a response, or because the response message was irretrievably lost in transit), the TSMI will in~orm the originator Or the transaction; but it is up to the originator to determine (i~ it must kncw) whether or not the requested opera-tion was ln ract performed by the remote server, and to implement (if necessary) a commitment strategy that allows railed transao-30~310 ~ ~ Application Or Epstein et al .
tions to be "backed out" without side errects. Similarly, ir the originator Or a transaction aborts the transactlon or tbe origina-tor terminates before the transaction is completed, TSMI will clean up loc~1ly, but it will not take any user-level error recovery action and will not inform the remote user.
4. When one host in a distributed system crashes (or surrers a non-transient separation from the rest of the distributed system, which a~ounts to the same thing), each host that was acting a3 a customer Or or server to the failed host must be informed Or the crash, 90 that cleanup routines can be run to ensure that resources held by the failed host are deallocated. This is analogous to what happens in an AOS/VS system when a process terminates: the opera-ting system runs a termination demon to close open riles, delete IPC-type riles, notiry processes ?CONnected to the dead process, etc. If the TSMI has a Transport connection to a host at the tlme that host crashes, it will inform the local management entity Or the identity Or the host that crashed; however, rrom the standpoint Or the Transport Service, there is no way to distinguish between a host that has crashed and one that has become ~unreachablen. The TSMI can therefore only report that a remote host can no longer be reached via Transport; whether that ho3t ha~ in ract "crashed~ is not known. There may be situations in which a host is operating normally and is not aware that it has become urreachable from another host. m ere may also be situations in which the TSMI does not have a Transport connection to a remote host at the time that host dies, and thererore cannot inrorm the local management entity Or a host crash. m e management entity must provide its own mechanism for determininB whether the other hos~s in the local management domain are active or inactive.
In the case Or OS 501 Distribution, the individual operating system termination paths are responsible for sending messages (via TSMI) to remote hosts to explicitly close open riles (and perform any other cleanup operation that might be required) when a process terminates or a LAU is deregistered.
5. Although ror most purposes the distribution Or OS 501 runctions wlll be limited to hosts that are connected to a common high-speed medium (a single LAN or I-Bus), it is highly undesirable to desi g the Transport Service ln such way that cooperating hosts must be connected to the same high-speed medlum. OS 501 dlstribution should work consistently regardless Or hoN the pieces Or the distributed system are lnterconnected, although Or course the desi B Or the Transport Service will optimize the performance Or OS 501 in the single-LAN case.
6.7.1 TSMI F~NCTIONAL DESCRIPTION

6.7.1.1 OVervieN
:::

. ~

~306310 Applloation of Epsteln et al The TSMI provides datagram, send, transaction, and broadcast servlces. These services are all "connectloalessn, in that they do not maintain ~tate lnformatlon across service-lnvocatlon boundarles. ~o expllcit connectlon service is provided by the TSMI.
.
Mo~t of the functions that are needed to provlde these TSMI servi-ces are actually performed by the underlying Transport Service.
The TSMI itselr per~orms two basic runctlons: it provides a pended Transactlon service, which a~sociates transaction request messages with the corre~pondlng transactlon replles; and it manages Tran-sport connectlons, maintaining a single Transport connection between each pair Or hosts and multiplexing all transactions (and other TSMI traf~ic) over that connection. It also defines a standard "message" as the unit of information exchange between cooperating TSMI user~; the concept of a "port~ as the source and destination of messages; and a port identification scheme based on standard Transport Addresses. Messages, ports, port identifiers, and the TSMI servlces are all descrlbed--in the following sections.

6.7.1.2 Messages A message ls an ordered, unstructured, unbounded block Or bytes.
message may be Or any length that is an integral number of bytes.
The TSMI transmits messages without regard to their content.
Messages may be ~ragmeated and reassembled during transmission, but are alwayo presented lntact at the destlnation. The Transport Service guarantees the lntegrlty Or messages, 80 that the message recelved at the destinatlon contains the same bytes ln the same order as the message ~ent from the source.
.
A number Or design-level buffer management optimizations will be necessary to ensure that the TSMI, and the Transport service underneath it, can operate erriciently. These are discussed in sectlon 6.7.2.2 :~- 13063~0 Application Or Epstein et al 6.7.1.3 Ports The TSMI transmits messages between ports. Porti~ represent queues derined within the TSMI, and must be explicitly oreated. When a port is created, the TSMI associates the port with a semaphore declared by the creator, which is then signallad whenever a message arrives on that port's queue. A port may be created with attribu-tes that expllcitly limit the number and source Or messages that may appear on its queue. As of the rirst revision Or TSMI, no port attributes are supported. There is no intrinsio limit to the number Or ports that may be created, although in ary implementation there will be a practical upper bound. In the rirst release of TSMI, an upper bound Or 256 ports bas been implemented.
~.
A port must be oreated before any mesisages oan be received through TSMI, At least one port should be created by a TSNI user to receive unsolicited messagei~ from remote peers (that is, messages that arrive spontaneously as a result Or remote events rather than in response to messages previously sent from the local host), ir these are expected (the obvious example is the serving side Or OS 501 Distribution, which waits ror requests deflected frcm remote oustomers). Sinoe each o~ the message-sendine primitives (Transaction, Send, etc.) includes a~ a parameter the source port address, a TSMI user must also create an appropriate source port be~ore sendlng a messaBe; in the normal course Or events, if a reply to the message is expeoted rrom the remote peer, it will come in on that port. It is not nece3sary to create a new port for each new message~

6.7.1.3.1 Port Identiriers .

A TSMI port is identi~ied by a port identifier (port ID), which ~ 1306310 Application of Epstein et al oonslsts of a standard Transport Address followed by a port selec-tor suffix. The relationship between a OS 501 u~er-visible name and the port identifier of a TSMI port belonging to a server giving access to the named ob~ect is maintained outside the Transport Service and TSMI by the OS 501 Global Name Server; the TSNI identi-fies ports by port identifier only. As an internal ~atter, of course, OS 501 distribution may choo~e to giye its callers a short handle to use for repetitive operations like reading from or writing to an open file (e.g., a local channel number), and main-tain a table associating the short handle~ with full port IDs.

The standard Transport Address ¢onsist3 o~ a Network Address followed by a Transport Service Access Point Identifier (TSAP-ID).
The Network Address part of the Transport Address identi~ies a particular host system; the TSAP-ID serves to 3ubaddress different u3ers o~ the transport servlce within a single host. The Network Addres~ component is assigned according to the international standard ISO 8348/DAD2, and consists of a string of up to 20 octets (bytes). The TSAP-ID component 18 identified in the international standard ISO 8073 (the Transport Pro~ocol Specification) as part of the standard Transport Address, but its lergth and permisslble values are not defined. The TSAP-ID component Or the Transport Address Or the TSMI on each host host system will be the same; the precise value wlll be chosen during the design Or the TSMI.

The Transport Address may be formally defined as:

TYPE byte_type = t1..256];
TYPE transport_address_type =
RECORD
networ~_address : ARRAY [1..20~ OF byte_type;
tsap_id : ARRAY t1..4] OF byte_type END;

The TSMI port identifier may be formally defined as:

` Appllcation Or Epsteln et al - : .
TYPE port_identifier_type =
RECORD
~` transport_address : transport_address_type;
port_selector_sufrix : ARRAY ~1..4~ OF byte_type END;

The TSMI port selector sufrix values are chosen by the users of TSMI when TSMI ports are created. It is assumed that the OS 501 developers will pick a sufrix value ror the DCALL TSMI port (and possibly for other ports), and will use that v~1ue ror all DCALL-ba~ed distribution; this su~fix therefore does not need to be stored in the OS 501 directory. Similarly, since TSMI will always use the same TSAP_ID value in its interactions with the Transport Service, it does not need to get this rrom OS 501. At the inter-Pace to TSMI, therefore, what TSMI needs from OS 501 i3 the Network address o~ the target host, and the user's port seleotor suffix.

At least initially, for the purpo~es of OS 501 distribution we wlll use only the "Lo¢al n ~ormat Or the standard Network address (identified by the value "49" encoded as "0100 1001~ in the rirst byte Or the address; re~er to ISO B348~DAD2). m e actual LAN
station address (MAC address and LLC LSAP selector) Or the target system will be directly encoded in the remainder Or the Network address rleld as a sequence of binary-valued byte~ followlng the lnitlal ~n49n) byte. Since the LAN statlon address consists Or at most 7 bytes, the total maximum length Or this "Local" Network address format is 8 bytes.

It should be emphasized that using this "Local" format restricts OS 501 distributlon, at least initially, to a DG-only, single-LAN
(or multiple real LA~, single logical LAN) environment. To support general Transport level access to other ~ystems (whether through DCALL or via a direct interface to the Transport service), the directory service designed ror OS 501 should be capable or handling full Network addres3es, which may be as long as 20 bytes. The global management server should also be designed ln such a way that '~-:

:~ 130~S310 ~ Applioation of Epstein et al '~
it can tell a newly-initialized host what its Network address i5, lf its Network address is something other than "49" followed bg its looal LAN station address. Depending on how we decide to handle access to the DG and non-DG "outside worldn, individual stations o~
the LAN either will or will not ever have to know what their "real"
(externally visible) Network addresses are.

It i~ assumed that some me¢hanism exists for both the TSMI and its users to find out what the local Network address is. This implies that there is some "automatic" means whereby the looal LAN station address can be obtained, either dire¢tly Prom the LAN controller, or indirectly during system inltialization.

6.7.1.3.2 Well-~nown Ports All ports defined on the same host system have the same port identifier up to the port selector suffix; that is, only the port selector suffix i~ different for ports on the same bost. Ports on dlfferent hosts must have different port IDs up to the port selec-tor surrix, but may have the same sufrix. This provides a cor,ven-lent meohanism for associating ports on different hosts that belong to a 9ingle type Or distributed service~ by defining a convention that res~rve~ specific values of the port selector surfix for use by speclflc servers on each host. Such a port 18 "well-knownn, in that the nature Or the servlce available at the port, regardless of the host lt happens to be on, can be determined from the port selector surfix and kncwledge of the convention for assigning surrixes to distributed ~ervice types.

For the purposes Or OS 501 distribution, a "well-kncwn~ port (OS 501_PORT) l~ defined within the TSMI to be the receive port for OS 501 Distribution Services. The port selector suffix of the OS 501_PORT port ID is the same for all instances of the OS 501 operatlng system. O~her operating systems using the TSMI may 130631(~
Appllcatlon Or Epstein et al oreate a OS 501_P0RT and define a OS 501-to-Other translation mechanism to interpret messages coming in on that port. Other well-known ports may be defined; for example, it may be useful to have a separate well-known port for the OS 501 Name Server.

6.7.1.4 TSMI Services A user Or the TSMI Transaction service will always be informed i~
the remote host that contains the tarBet of the Transaction request fails (becomes unreacbable) before the Transaction i8 completed.
However, there may be clrcumstances in which the completion o~ a Transaction does not end the user'~ need to be in~ormed a~aut the failure of the target host. It is the responsibility of the management component Or the distributed system to keep track Or the active/inactive status Or other hosts within the local management domain, and to signal host crashe~ to those TSMI users who have declared a need to know about them.

6.7.1.4.1 TSMI Datagram Service The datagram ls an unpended, uncon~ir~ed ¢onnectionless service.
The speclried message is sent uslng the connectionless Transport Service, which makes no guarantees about the success or railure Or the message to reach its destination. Errors that are detected in the local syQtem (such as transmitter failures, invalid destination addresses, and the like) are reported (although no attempt is made to recover fro~ them), but errors that occur after the message has le~t the local system ~such as destination host errors~ are not detected or reported.

6.7.1.4.2 TSMI Send Service :: 1306~110 Applicatlon Or Epsteln et al .
m e send servlce is essentially an "ackncwledged datagram": the TSMI sends messages over Transport connections, which ensures that the message ls delivered even in the presence or sort errors (errors recoverable by retransmisslon and/or connection re-establishment within the Tran~port Service). Unless the TSMI
reports a hard (unrecoverable) Transport-level error, the sender can be sure that his message reached at least the Transport Service component on the correct destlnatlon host. Send does not guarantee, however, that the message was correctly processed by the remote TSMI component; that lt ~as RECE N Ed by the sender's peer on the remote host; or that the sender~s peer correctly lnterpreted the message. Unrecoverable transport errors may not be identified until arter a message has been sent to the transport service and the user has been released with a successrul completlon. Thi~
means that transport errors may be reported o~ly the the management entity.

6.7.1.~.3 TSMI Transaction Service The transactlon service is a pended, synchronized, and reliable request/response interrace. If the Transport Service is able to deliver the request message to the correct destinatlon, the TSMI
pends the caller untll either the response to the caller's request message ls received or a transaction-speciric timer expires. In the latter case, the caller kncws that his remote peer did not respond wlthin the tlmeout perlod, but does not know whether or not his remote peer actually perrormed the requested operation; a transaction response that arrives arter a timeout will be discarded by the TSMI wlthout notificatlon to the user. The timeout interval may be ad~usted through OS 501 distributed systems management to accomodate variations related to the size Or the local transport domain, the speed Or the underlying communications network, and the speed Or the host machines participating in the distributed system.
Users Or the transaction service may also influence the timeout ~3063~0 Appllcatlon o~ Epstein et al interval on a per-transaction basis, to account ror variations in the expected delay attributable to the type Or operation the remote server i8 being asked to perrorm.

The task that requests the transaction service remains pended until the transaction is completed (either normally or abnormally). A
transaction will al~ys be completed eventually, but at any time prior to its completion, it may be explicitly aborted by the originator. When a transaction is aborted, the pended task returns wlth an appropriate error indicatlon. Abort requests for transac-tions are completely lo¢al requests. A transaction response that arrives after the corresponding tran~action has been aborted is discarded by the TSMI (since there is no longer any pended user task waiting to receive the response). This facility enables 0S 501 distrlbution to recover a user task pended on a transaction, i~ the user redirects or kill~ the task (?TABT), or the u~er's process dies.

The sequence Or events at the sending and receiving host systems during a traDsaction is illustrated in Figure 608.

6~7.1.4.4 TSMI Broadcast Service Broadcast distributes a single message Or no more than the maximum number of data bytes contained in a single buffer, a constant value limited by the nature o~ the broadcast medium, probably between 14~0 ard 1500 bytes, to one port on every potential receiver host without conrirmation. The set Or "potentl~1 receiver hosts~
includes only hosts connected to the same subnetwork (e.g., to the same LAN). The TSMI does not guarantee the delivery Or a broadcast message to each Or these ports (the conditions are the same as for the Data8ram service described above), and will report only global ~rather than destination-host ~pecific) errors to the sender.

:

- ~3063i0 Applicatlon of Epstein et al A broadcast message is delivered to ports w~th the same (speci~ied) port selector suffix (only one port on each potentlal receiver host, therefore, can be the destination of a broadcast message).
Thus, ~or esample, a broadcast message can be directad to a parti-cular server on all potentlal-receiver hosts lf each of the servers is known to be accessible via a specific (nwell-knownn) port within its host.
.

6.7.1.4.5 TSMI Abort Service An Abort request is a purely local service. - A user issuin~ an Abort ~or a particular transaction ld will cause the ta~k pended on that transaction to return ln error. All state in~ormation conoer-ning that tran3action will be destroyed. Ir a reply to that speci~io transaction ls received arter the Abort is processed, it will be discarded. When the transaction task returns, the transac-tion id 19 available ~or reuse.

Any ~backing out~ o~ an aborted transaction on the remote side is the responsibility of the u~er and must be done through another transaotlon. The remote h de will get no indication that the transactlon has been aborted. It is not necessarily true, however, that the remote side has actually received and processed the transaction since the reply will be discarded.

6.7.2 TSMI DESIGN CONSIDERATIONS

6.7.2.1 Tasking Structure and Control Flow TSMI aotivities that are prompted directly by the action of a user task can run on that u3er's task, which enters TSMI via one of the TSMI primitives (described below) until it needs to access TSMI
global resources. At thls point, control must be passed to the XTS

13063~0 Applioation Or Epstein et al Entity Environment. Other a¢tivltles, such as the processing Or me~sages that arrlve asynchronously from other host systems, unrelated to any immediate activity Or local users, cannot be handled by user tasks, and must run under the XTSEE.

All of the pieces of the Transport system except for a small inter~ace to TSMI will run as entities in the XTS entity environment. During system inltialization, one task will be created to run the XTSEE scheduler; all XTSEE entities run Orr this task. There will be parts Or TSMI that run on user tasks and parts that run on the XTSEE task coming up into TSMI with Transport message~ to be processed by TSMI.

Specifically, for outgoing messages (DCALL calls into TSMI with data to be sent via TRANSACTION, SEND, DATAG~AM, or BROADCAST), the user task will do any work possible without acessing TSMI
resources, and pend while the XTSEE task continues processing.
XTSEE event code will unpend the user task when processing is complete and it will return to DCALL. For incoming messages, the XTSEE task processing the Transport-level event will plow into TSMI
with an appropriate Transport-interrace Indication (such as a T_CONNECT Indication, T_DATA Indication, etc.), and Will run whatever TSMI code is oalled for by the particular Indication.
This will result elther ln signalling a DCALL task waiting on a semaphore deolared at the time the target TSMI port was created (ir thls 18 a messaee destined ror such a port), and hardlng the message Orr to that task when it does a TSMI_~ECEIVE, or completing a transaction by handing Orr to a user task that is pended in TSMI
waitlng for Just such a completion (if this 1~ a transaction-response message). In both cases, the XTSEE task then returns to the XTSEE world. Figure 609 illustrates this task flow.
: ':
6.7.2.2 3uPrer Management and Data Flow One Or the goals of OS 501 distribution ls to avoid copying data .. . . . . ~ . . ... ~ .

~ ~306310 Application of Epsteln et al ~rom one place to another unless either (2) lt is absolutely unavoidable, or (b) the slde errects Or the errorts to avoid copying are ~ore destructive than the copying itself (it is usu lly better, for example, to accept a memory-to-memory data move ir the alternative ls an extra data channel transfer between the host and a communicatlons controller). TSMI expects its users to pass it blocks of data o~ arbltrary length, descrlbed by a byte pointer to the start Or data and a byte count o~ its 3ize. The interrace expects a list of descriptors, along with other request speciflc parameters. TSMI must concatenate these blocks o~ data for the Transport sy~tem to transmit. By allowing multiple blocks of data input with arbitrary lengths, it should not be necessary ~or DCALL
to move it~ user data berore passlng it to TSMI. TSMI will move the data ~rom the u3ers context when it kncwæ it can get tbe resources to send the data.

It is assumed that the TSMI and its users (initially, the OS 501 DistributioD Services) have access to a common memory pool, such that a buffer allooated by a TSMI user ¢an be relea~ed by TSMI.
When passing burfers to TSMI, DCALL must indicate in the buf~er descrlptor whether the ownership Or the page or pages that the data blook touches will be passed islong with the data. If TSMI i~ gi~en ownership, it can optimize its data movement if the format Or the passed block matches the format needed by the transport system. If ownershlp is not passed, TSMI must copy the data and the user is responsible ~or ~reeinB the page. When TSMI passes data up to users like DCALL, ownership Or tbe pages will NEVER be passed and there~ore, users are required to return all buf~ers to TSMI via TSM2_FREE.
: :
Figures 610 and 611 illustrate the data rlOw between users, OS 501, and the TSMI. In Figure 610 user data, in the form Or an argument block containing data descriptors to bufrers, is passed to DCALL. DCALL builds block~ of data (the first is its own beader with tbe argument block (a)) and references eaob block of data with an entry in the bu~er block. TSMI rece~ves the request -225_ 13063~0 Application of Epsteln et al and begins to format transport page buf~ers. It fii~t inserts its header, and then, one by one, moves user data into the page burfers. If the data does not all fit, TSMI will allocate another page buffer and continue filling it until all the buffer descrip-tors in the bufrer block are exhausted. There i9 no rixed limit to the size of a TSMI message, and therefore no rixed maximum number of buffers that can be chained together for a single TSMI request.
Ir the user instructs, the Transport service will release the buffer pages to the free memory pool after the Transport operation is complete, otherwise, the user will get them back.

Figure 611 (~Inoomingn) i8 similar to Figure 610 with the dlrection Or data flow reversed. This ex~mple covers only the case Or an arriving TSMI_TRANSACTION response; incoming data may also contain OS 501 Distribution-specific control messages, new Transac-tion requests from remote hosts, and other messages that do not go to a local User; the data flow for these will be ~lightly difrerent, in that OS 501 will proce3s the data in tbe page bufrers ~rather than moving them into user bu~rers) berore returning them to TSMI.

Multiple buffers can be passed to TSMI on TSMI_TRANSACTION, TSMT SEND, and TSM~_REPLY requests and returned on TSMI RECEIVE
requests by listing those burfers in a Bufrer Blook attached to the request packet. The Buffer Block will contain a list Or buffer descriptors (byte pointer and byte length pair). The request paoket will contain the number of bufrer descriptor entries in the burrer block in the bufrer block size rield. Ir only one bufrer needs to be associated with a request, the u~er may set the Buf~er Block size to O and place the buffer pointer and length directly in the request packet. If a bufrer block is used, each entry in the block will indicate the length of the block it references. Re~er to Figure 612 on bu~fer layouts for clarification.

On TSMI_~ECEIVEs and TSMI TRANSACTION replies, TSMI will allooate and pass a burrer block in much the 3ame way. The incoming bufrer ~ 1306310 Application of Epsteln et al block size field will contain the number of buffer descriptors in the block and the incoming buffer block pointer field will contain a pointer to the buffer block. If the buffer block size fieid is zero, the buffer block pointer field becomes a buffer pointer and points to the one buffer that was received, and the data length field will hold the byte count of the data received. The data length field is only valld if no buffer block is returned. The incoming data fields are only valid if the reque~t complete3 suc.cessfully.

6.7.3 TSMI SERVICE PRIMITIVE SPECIFICATION

The individual TSMI prim~tives are defined belcw. All requests made to TSMI will pass-a polnter to a request speciric parameter packet. The rollowing sections descrlbe the format Or these packet~ and other request specific lnformation. For all primitives, the STATUS parameter either lndlcates the succe3sful completion Or the operation or returns an error code. Where a parameter 19 speciried as "dest_transport_addr n or ~source_transport_addrn, it lndicates the Transport Address part of a TSMI port identifier; where a parameter i8 specirled as ~port_number~ "dest_port_number~, or ~source_port_numbern, it indicates the port selector suffix part Or a TSMI port identlfler.

F~oh functlon will be explained ln a subsection which follows. In the ofrset tables, tbe column marked "R/W" nay be translated as rOllOW9:

tR] - Field to be Read by TSMI, filled in by user.
[V~ - Field to be Wrltten by TSMI, read by user.
[R/W] - Field ls Read by TSMI for a request or response;
Wrltten by TSMI for an indlcation or confirm.
t ] - Field not used to communicate between user and TSMI.

6.7.3.1 TSMI_CREAT~ PORT

13~)63~0 Application Or Epstein et al A TSMI user must specify that a port be created w~th a particular port selector suffix; the specified value will be used as long as it is not already in use (this capability ls provided to support the use Or "well-known" ports). The creation Or a port defines a queue structure within the TSMI, and associates a set of attributes with the queue. A created port persists until it i8 deleted.

The return from TSM~_CREATE_PORT conveys to the caller the full TSMI port identifier for the newly created port. The full port ID
contains the Transport address as well as the TSMI port selector sufrix (see action 6.7.1.3.1).

Hhen a port i9 created, the creator must specify the address of an initialized semaphore to be signalled when a valid message arrives at the port Sthe message may then be dequeued via the REGEIVE
primitive).

CREATE PORT PARAMETER PACRET~

I [H] status 1 2 Mords ~ _______________________--__-------------------------------------- I .~ , ::
¦ tW] ecode ' 2 words -~
______________________________________---- ----_----~ ,.~:. :
I [] reserved 1 4 wordo ; ~
~ _________________________------------------------------ -- I :.
I ~R] port_number ¦ 2 word3 ~ ______________________________________________~ :
t ~R] attributes ¦ 4 wordY
______________________________________________~
I ~R] semaphore_address ' 2 words ~ ______________________________________________~
t [W] transport_address 1 12 words ______________________________________________~ -The port_number will be used to identify the port as long as it is not already in use.

The attributes that may be associated with a port are:

13(?~310 Appllcatlon of Epstein et al a) receive from <same source port_id> only b) receive only from sDurces within hosts connected to the same subnetwork as this host .
c) re~ect messages longer than <message_lengtb_upper_bound>

d) restrict queue size to <maximum number_o~_mes9ages>

The semaphore_address is the address of a semaphore to be signalled when a valld message arrives at ~he port. The user is responsible for initiall~ing the semaphore.

The transport_address returned by TSMI is the nodes local transport address.

The status rield will contain the result of the create port request. The possible values are:

OperatioD Successful Local System Error (ENTLSE) Looal Interraoe Violation (ENTLIV) The ecode field will ¢ontain a more speciric error code lr an error occured.

Port Already Exists (ENTPE) Invalid Attribute (ENTINVAT) Assorted system errors The four reserved words are for TSMI's internal use. Their values will be modified by TSMI.

. ...... ..

: 1306310 ` Applicatlon o~ Epstein et al ,: .

.
:.
6.7.3.2 TSMI_DELETE_PORT

When a port is deleted, any messages that may remain on the queue are discarded. The ~emaphore is signalled with a "broadcast error"
signal waking all tasks waiting on that semaphore with a port deleted error. If a RECEIVE is then perrormed against the port, lt will return with a "port does not exist" error. This ensures that the task waiting on the ~emaphore can be retrieved when the corres-ponding TSMI port is deleted.

DELETE PORT PARAMETER PACKET:
~ _____________________.. ________________________I ~i :
I tW] status 1 2 words ~
______________________________________________~ ~:~:~

I tW] ecode t 2 words ~ ~
+___________________________________________--------+
¦ t~ reserved ¦ 4 words ~ ________________________________-------- ------------------I -~:
I tR] port_pumber 1 2 words ______------------------~~ ~; ~

:::
The port_number is the same value which was used on the TSMI_CREATE_FORT.

The status rield will contain the result Or the transaction request. The possible values are:

Operation Successrul Local Interface Violation (ENTLIV) The ecode rield will contain a more detailed descriptlon Or an error ir one occurred.

Port Does Not Exist (ENTLPNE) 13063~0 Applicatlon Or Epsteln et al Assorted Ayste~ errors .. .. . .. . ..
The four reserved words are for TSMI's internal use. Tbelr values will be modifled by TSMI.

6.7.3.3 TSM~_TRANSACTION

The TRANSACTION -prlmltl~e lnitlatea a pended reQuest-response sequence that ls guaranteed to ¢omplete (either successfully or unsuccessrully) wlthln a rixed tlme period. The message to be sent must be contained in page bufrers as described in Aectlon 6.7.2.2.

... . . .. . . .

. : . , . . . : , . , - ~ . . . .. I

: 13063~0 Appllcation of Epstein et al ,: ~
TRANSACTION PARAMETER PACKET:
+ ----------------------------------------__--_________________~
I tW] status 1 2 words +_____________________________~_________________+ ...
I [W] ecode 1 2 word~
+_______________________________________________+
I [] reserved 1 3 words +_______________________________________________+
I [W] buPP desc id ¦ 1 word ~ ______________________________________________+
I [R~ origlr~port_number 1 2 words t--------------------__----_________________________________+
I [R] dest_port_number 1 2 words ______________________________________________~ ~
I tR~ dest_transport_addr ~ 12 words +_______________________________________________+
I tR] out burfer_ptr~bur~er_blk_ptr 1 2 words ~ ~
+________..________---------------------------- ~
I [R] out dat~_len 1 2 words ~ _____________________------__------------------------------ I . :
I tR] outgoing bufrer_blk_size 1 1 word +_______________________________________________I .
tH] incoming buf~er_blk_size 1 1 word ~ ~
+_____________________-------------------------- + . :
I tW] inc bufrer_ptr/burrer_blk_ptr 1 2 word3 -~
+_______________________________________________.~
I [W] inc data_len ¦ 2 words ~ _________~____________________________________+
I tR~ tranQactior id 1 2 word3 ______________________________________________~

I [R] timeout_interval 1 1 word ~ ______________________________________________+
I tR] options 1 1 word ~ ______________________________________________~

The transactio4_1d is chosen by the caller, 80 that the caller may ABORT the transaction (see below) ir necessary. With respect to a given TSMI port, the tran~action_id must be unambiguous; that is, the caller must ensure that only one transaction with a given transactior~id and source_port_pumber is outstandlng at any one time. For the purposes Or OS 501 Distribution, a simple way to choo e unique tran~action_ids for deflected system call transac-tions would be to use the concatenation Or the calling user's PID
and task id as the transaction id.

The originLport_number field contains tbe source_port_numb~r. It ~ 1306~10 ~ Applicatlon or Epstein et al ; has been given the name origin_port_~umber on a transactlon request to avold oonruslon over which port number i8 meant ln the transac-tion reply.

The tlmeout_interval provides information about the extent to whlch the ~erver's actlvities in performing the speciric requested operation wlll arfect the expected -request-response dèlay. This parameter will be in seconds. A -1 indicates that this request should not be timed out.

Note: A¢tual timeout intervals may exceed the timeout requested, but will ~ever be lesæ than the re-quested v~ue. Also, small timeout value~ (<=5 sec) are not recommended since the request may be returned with a timeout error rather than a perman-ent node unreachable error ir the remote node is do~n. This is due to a race conditlon between the transport services connection setup and TSNI
timeouts.

Ir the "encrypt" option ls selected, the entire me~æage will be encrypted before leaving the source (sending) host, and decrypted after entering the destinatlon (receiving) host prior to delivery at the destination port (see section 6.7.1.4).

Separate burrer blocks must be used rOr the outgoing transaction data and the lncoming transactlon reply so that the user can locate his transmlt burrers on the return Or the transaction request, The burrer_blk_size fields lndicate the number Or bufrer descrlptors ln the buPrer blocks attached to the request. The bufrer_bl~_ptr rlelds point to these blocks. The user will set all the~e parame-ters ror the outgoing burrers, and TSMI wlll set them for incoming burrers. If only a single bufrer is being transmitted, the outgoing burrer_block_size should be zero and the request block will contain the bur~er pointer and data length. The same is true on incoming data ir only a single burrer is received. The lncoming data length : 13()6310 Appllcation of Epstein et al .`'' , ,.
field i~ only valid lr a single buffer 1~ returned.

The burfer block is a block Or memory that contains a fixed (buffer_bl~_size) number Or buffer descriptor entries. Each entry looks like:

~ ______________________________________________.~, ~, 7 bufrer_byte_pointer 7 2 words I Owner_flag 7 bufrer_byte length 1 2 words ~ ______________________________________________~
I reserved 1 1 word ~;
~ ______________________________________________,~, bufr desc id 7 1 word where buffer_byte pointer is a byte pointer to the start Or the buffer, burfer_brte_length is the length in byte~ Or the data in the buffer, and owner_flag is the ownership bit. It is the high order bit Or thls doubleword. It is set by the user i~ ownership Or the page or pages touchet by the bufrer pointed to by this burfer descriptor 18 being passed along with this burfer. Thi~ rleld is valid only on requests to TSMI and ha~ no significance when set in a burrer block returned to a user. Ir set, TSMI will be responsible for rreeing the pages that the burfer touches. If not set, the c ller will ~till own the page~ when the request returns.
Ir the ownershlp bit is set, TSMI will not ~ust rree the bufrer, it will rree all pages that the bufrer touches. It is required that any pages that a user wlshes to have TSMI free be allocated through the standard system memory allocation primitive, be allocated a3 single pages tpage aligned 1024 word blocks) and be addressed by ring 0 pointers.

Users should not pass ownership Or burrers to TSNI unless owning that bu~fer will allow TSMI to not have to copy it. In a LAN-based XTSEE e~vironment, where transport burrers have a strict rormats, unless the rormat is matched exactly, TSMI will still have to copy 1306~10 Appllcatlon of Ep3teln et al the buffer. It ls recommeDded that buffer cwnership not be paqsed unless the formats will match, since it forceq the user to allocate his buffer space ln page block~ and force~ TSMI to incur w erhead calculating where these pages begln to free them. This feature is lntended to optimize page passing for ~ome other tranqport mechan-i~m other than LANs, like tbe I-bus. Thi~ feature may not be available in early (rev.~ release) LAN-only versions of TSMI.
i The buffer descriptor id field contains TSMI specific information about the associated buffer, 90 that TSMI can free it correctly.
This field is relevant only on buffers passed to the user from TSMI
and must be passed back to TSMI (via TSMI_FREE) in tact. -~

The status field will contain the result of the transaction request. The possible values are:

Operation Successful Local Interface Violation ~NTLIV) Tsmi Error (ENTERR) Local System Error (ENTLSE) Nods Unreachable - Permenant (ENTNUP) Node Unreachable - Temporary (ENTNT) Severe Local Transport Error (ENTNSEV) The ecode field will contain a more detailed description Or an error, lr one occurred.

~nrecognized Option (ENTUNOP) Destlnation Port Does Not Exist (ENTDPNE) `.
Appllcation Or Epstein et al '' Request Timeout (ENTTO) Transaction Aborted (ENTABORT) Assorted transport, link and system errors.
.. ' The reserved words are for internal TSMI uQe. Their contents will be modifled by TSMI.

The events that take place on the sending host when the TRANSACTION
service is lnvoked are lllustrated ln Flgure 613.

6.7.3.4 TSMT RECEIVE

After the semaphore ident~fied in CREATE_PORT has been i~ignalled, a RECEIVE on the correspond'ng port will retrieve a message enqueued to the port. Only comple~.e messages may be dequeued.

~ Appllcation Or Epsteln et al ;

:
RECEIVE PARAMETER PACRET:
~, _________~____________________________________ I ~W] status 1 2 words +_______________________________________________+
I [W] ecode 1 2 words ~ ______________________________________________~
I [] reserved 1 3 words ~ ______________________________________________~ .
I [W] buff desc ld ¦ 1 word ~ ______________________________________________~
I [R] port_number 1 2 words ~ ______________________________________________~
I [~1] source_port_number ¦ 2 words ~ ______________________________________________~
t tW] tranRactio~_ld ¦ 2 words ~ _____________________________------------------------------ I `
I ~W] unique_~d 1 2 word3 ______________________________________________~
I [W] remote_transport_addr 1 12 words ___________________________~__________________~
I [W] burfer_ptr~burrer_blk_ptr 1 2 words ______________________________________________~
I rW] data len ¦ 2 words ______________________________________________~
I r~l] burrer_blk_size 1 1 word ________---------------- : .

The port_number i9 used to identlry the user's port.

The RECEIVE is the result Or incoming data (SEND, DATAGRAM, BROADCAST, or incomlng TRANSACTION), and was initiated by TSMI
signalling the user's semaphore address.

1~ a transaction_id i8 returned to the user on the RECEIVE
completion, a REPLY i8 expected to complete a transactlon at the sending port tsee Figure 608).

An incoming transactiorL id, source_port number, and unique_ld form a unique message id for a transaction. These rields must be echoed to TSNI on the corresponding REPLY, lr a REPLY is required.

The burrer_blk_slze, burrer_ptr~burrer_blk_ptr, and data length rields are explained rully in the TSMI_TRANSACTION portion Or this ~'' : ~306310 , Appllcatlon Or Epsteln et al ~' ~
seotion, as well as ln the Bu~fer Management portion in section 6.7.2.
' ¦ The transport address of the remote node will be returned in the remote_transport_address field.

The status field will contain the result Or the recelve request.
The posslble values are:

Operation Successful Local System Error (ENTLSE) Local Interface Violation (ENTLIV) The ecode field will contain a more detailed error code if an error occurred.

No Data Available (ENTNDA) Local Port Does Not Exi~-t tENTLPNE) Assorted System Errors She reserved words are for TSMI's internal use. Thelr values will be modlfied by TSMI.

The events that take place on the receiving bost when the TRANSAG-TION service i8 invoked by the sender and a RECEIVE 18 lssued by a si~nalled receiver are lllustrated in Figure 614.

6.7.3.5 TSMI_ABORT

The ABORT primitive can be used only to abort a transaction, since the transaction service- is the only one that pend~ the calling task Appllcation Or Epsteln et al ~, .
on a remote aotlon. ABORTs are only locally ~ignificant.

ABORT PARAMETER PACRST:
~ ______________________________________________~
I [W~ status 1 2 Nords ~ ______________________________________________~
~ ~W] ecode ¦ 2 words ______________________________________________l I [] reserved Z 4 word8 ____________~_._______________________________~
I [R] source_port_number Z 2 word8 +_______________________________________________~
Z [R] transactio~_ld Z 2 wordB
______________________________________________~

The transaction_id 18 the identifier supplied in the TSMI_TRANSACTION reque~t that i8 to be aborted. If no transactiorL ld iB speciried te.~ -1), all outstanding transac-tions associated with the speciried source port number are aborted.
The pended task(s), when scheduled, will return from the aborted transaction(s) with an appropriate error in the STATUS parameter of the TRANSACTION primitive.

The source_port_pumber is the local port identifier.

The status rield will contain the result Or the transaction request. The possible values are:

Operation Successful Local Interrace Violation (ENTL n ) Local System Error (ENTLSE) The ecode field will contain a more detailed error code if an error occurred.

Transaction Not Found (ENTTNF) .30631.0 .5.'~ . Application o~ Epsteln et al ~ Assorted System Errors .
The reserved word3 are for TSMI's internal use. Their values will be modlried by TSMI.

Note that the TSMI does not anthenticate ABORTers; it allows any i task to ABORT a transaction.

6.7.3.6 TSMI_BROADCAST

Broadcast measages are limited to a rixed maximum len~th, since the TSMI and the Transport Service can support a broadcast service only by mapping lt onto the native broadcast racilities Or an underlying subnetwork. This length is the same as the maxlmum number Or bytes that can be ¢onveyed rrom a user to TSMI in a single page buffer tsee section 6.7.2.2), and is expected to be in the range Or 1400-1500 ~ytes.

TSMI BROADCAST will return an error to the caller if the source host is not connected to a subnetwork that provides a native llnk-level broadcast.

1301tS31~) :
~ Appllcatlon Or Epsteln et al ,,:
7.'. BROADCAST PARAMETER PACKET:
__________________________----___________________+
I ~W] status 1 2 words t----------------------------__~______________________________I
I [~l] ecode 1 2 words ~ ______________________________________________~ .
I t] reserved 1 4 words ______________________________________________~
I [R] source_port_number 1 2 words ~ ______________________________________________~
I ~R] dest_port_number ¦ 2 words ______________________________________________~
I [R] bu~fer_ptr 1 2 words ~ ______________________________________________I , I [R] dat~_length 1 2 word~
______________________________________________~
I [R] options ¦ 1 word ____________________________ _________________~

The reserved words are for TSMI's internal use. Thelr values will be modified by TSMI.

The ~dest_port_number" must be speclfied; BROADCAST attempts to deliver the message o~ly to ports with that port seleotor surrix on every potential receivlng host (see sectlon 6.7.1.4.4). The value "dat~_length" 19 the number Or bytes in the TSMI user's message.

If the "encrypt" option i8 selected, the entire message will be encrypted berore leaving the source (sending) host, and decrypted a~ter entering the destination (receiving) host(s) prior to deliv-ery at the destination port(s) (see section 6.7.1.4).

The status field will contain the result Or the broadcast request.
The possible values are:

Operation Successrul Local System Error (ENTLSE) Local Interface Violation (ENTLIV) .: .

`- ~ ` 1306~'310 "~
- Application Or Epsteln et al '~ ~

The ecode field will contain a more detailed error code if an error occurred.

~nrecognized Option (ENTUNOP) Buffer Too Large ~ENTBFOV) Assorted System Errors 6.7.3.7 TsMl-pATAGRAM

The DATAGRAM primitive uses the connectionless Transport service to send a dataeram to the destination port. The message to be sent is limited to a fixed maximum length. This length is the same as the maximum number Or bytes that can be conveyed ~rom a user to TSMI in a single page bu~fer (see sectlon 6.7.2.2), and i~ expected to be in the range of 1400-1500 bytes.

DATAGRA~ PARAMETER PAC~ET:

~ ______________________________________________I
I ~W] status 1 2 words ~ ______________________________________________~
I tH] ecode 1 2 words ~ ______________________________________________~
I ~] reserYed I 4 word~
~ ______________________________________________+
I tR~ source_port_number 1 2 words ~ ______________________________________________I
I ~R] dest_port_number 1 2 words +_______________________________________________~
I ~R~ dest_transport_addr 1 12 words ~ ___________________________---------------------------------- ~ ::
I tR] buffer_ptr 1 2 words ~ ~
~ ______________________________________________~ :~

I tR] data length ¦ 2 words ~ ______________________________________________~ -¦ ~R] optlons ¦ 1 word ~ ______________________________________________~ , : ~ ~
. - ~306:~10 .
~ Applicatlon Or Epsteln et ~1 :~`
The rour reserved word~ are for TSMI's lnternal use. Thelr v~1ues will be modified by TSMI.

The status field will contain the re~ult of the datagram request.
The possible values are: -.. . ..
Operation Successful Local System Error (ENTLSE) Local Interface Error (ENTLIV) The ecode field will contain a more detailed error code if an error o¢curred.
~nrecognized Optlon (ENTUNOP) Buffer Too Large (ENTBFOV) Assorted System Errors The value of "data_length~ is the number of bytes in the TSMI
user's message.

If the "enorypt" option i8 sele¢ted, tbe entire message will be enorypted before leavlng the source (sending) host, and decrypted arter entering the destination (receiving) host prior to delivery at the destination port (see section 6.7.1.4).

6.7.3.8 TSMT_SEND

The SEND primitive uses a Transport connection (shared with all other traffic between the same two hosts) to send a message to the destination port. The message to be sent must be contained in page bur~ers as described in sectlon 6.7.2.2.

,: , ., ~ , . -....:
, . .. .. ;

~ 1306310 ~pplication Or Epstein et al .

SEND PARA~ETER PACRET:
_____________------------------------------------------------------------------t' I tW] status 1 2 words ~ ______________________________________________+
I [~1] ecode ~ 2 words ~ ______________________________________________~
I t] re9erved 1 4 words ~ ______________________________________________~
I tR] 90urce_port_number ' 2 words ~ ______________________________________________~
I rR] dest_port_number 1 2 words ~ ______________________________________________~
I [R] dest_transport_addr 1 12 words ~ ______________________________________________~
~ tR~ buffer_ptr/buPfer_blk_ptr 1 2 words ~ ______________________________________________~
I [R] data length ¦ 2 words ~ ______________________________________________~
I tR] bufPer_blk_size I 1 word +_ _____________________________________________I
t [R] options 1 1 word ~ ______________________________________________~

IP the "encrypt" option is selected, the entire message will be encrypted before leaving the source (sending) host, and decrypted aPter entering the destination (receiving) host prior to delivery at the destination port (see section 6.7.1.4). ~ ~
~ ~ .
Use of the buPPer_blk_size, buffer Dtr/buPPer_blk_ptr and data_length fields ~s described in the TSMI_TRANSACTION portion o~
this sectlon. See section 6.7.1 on buPPer management for more inPor~ation.

The status field will contain the result of the send request. The possible ~lues are:

Operation Successful Local Interface Violation (ENTLIV) Local System Error (ENTLSE) ~:

.
; Appllcation of Epsteln et al ~::, ,.
Node ~nreachable - Temporary (ENTNT) ... . . . . ..
Node ~nreachable - Permenant (ENTN~P) Severe Looal Transport Error (ENTSEV) , The ecode field will contain a more detailed error code lf an error occurred.

~nrecognized Option (ENTUNOP) A~sorted transport, link and system errors.

The four reserved words are for TSMI~s lntern 1 use. Their v~lues will be modi~ied by TSMI.

6.7.3.9 TSMI_REPLY ~ ~;

REPLY is similar to SEND, except that in addition to the destiLa-tion port itentifier, a transactlon_id is speci~ied: REPLY comple-tes a transactlon at the recelver, and is used to return a message oontaining a response to a request prevlou31y RECEIV~d (see Flgure 614). The message to be sent must be contained in page burrers -`
as desoribed in ~ection 6.7.2.2 `':~

~ 1~06310 . ~ .. ...
Application o~ Epsteln et al - - REPLY PARAMETER PACKET:
I ______________________________________________+
I ~W~ status 1 2 words +_______________________________________________+
I ~W] ecode 1 2 words +_______________________________________________+
I ~ reserved ¦ 4 words +_______________________________________________+
I tR] local port_number 1 2 words ______________________________________________~
~ I tR] originLport_number ¦ 2 words +_______________________________________________+
, I ~R] transactio~_id 1 2 words +----------------_______________________________________+
~ I ~R] unique_id 1 2 words +_______________________________________________+
~ I LP] dest_transport_address 1 12 words +____________________________________~__________~
I tRi buffer Dtr/buffer-blk-ptr 1 2 words +----------------------------_--_______________________________+
I tR] data_length I 2 words +_______________________________________________+
I ~R] bu~er_bl~_size t 1 word +_______________________________________________+
I ~R] options 1 1 word +________________________________------------------------------+ ~:

The local port_number is the port number o~ the user sendlne the TRANSACTION REPLY. Loca1 Dort_number was used to avoid confusion over the duration of the transaction.

~he origin_port_number iæ the port number Or the user that ~ni-tiated the TRANSACTION. Origin_port_number was used to avoid confusioD over the duration o~ the transaction.

The origir~_port_number, transactioD_id and unique id fields must be echoed to TSMI as they appeared in the corresponding incoming TRANSACTION.

The local_port_number is the user's port number.

The destinatio~_transport_address i~ the transport addresR of the remote host.

Application o~ Epsteln et al CALLING SEQUENCE: TSHI_FREE(bb_~ize,bblk,bdes) The bb_size parameter ls the slze of the buffer block as returned by TSMI from any of the other TSMI entry points. If this is zero, a single buffer, and no buffer block will be freed.

The bblk parameter ls a buffer block/buffer pointer union type as returned by TSMI from any of the other TSMI entry point~.

The bdes parameter is the buffer descriptor id as returned by TSMI
from any of the other TSMI entry points.

The buffers passed to this routine are assumed to be burfers that have been passed to TSMI users through TSMT RECEIVES and TSMT TRANSACTIONS.

6.7.3.11 ERRORS ;

This sectlon explains the errors which can be returned by TSMI, and what their implications are. All TSMI request packets contain two error fields: status, ecode. The status field returns an error category which users can loo~ at to determine the basic typ~ or error whlch occurred. The ecode rield returns an error oode whlch more explicitly describes an error. This rleld ~lll be userul in determining the exact problem. The~ ecode field will return such things as transport and link error codes which can be used to pinpoint a network problem, system error codes which can be used to identify system problems (low on memory), and specific user errors. The following is a li~t Or the status errors returned, and the eoode errors associated wlth them:

OPERATION SUCCESSFUL ~0) - No errors occurred.

LOCAL INTERFACE VIOLATION (ENTLIV) - Error is viewed as a -24~-~306~0 ~ Appllcatlon Or Epstein et al ., The reply to a tran~actlon request is always encrypted if the request was, and is not encrypted if the request wasn't; there ls no ~encrypt" option on the REP~Y primitlve.

The burfer_blk~size, buffer_ptr/bufrer_blk_ptr, and dat~_leDgth rields are used to send REPLY data to the remote host. Theoe rlelds are explained rully ln the TSMI_TRANSACTION portion Or this sectlon, and the Buf~er Management portion in sectlon 6.7.2.

The status field will contaln the result Or the reply request. Tbe possible values are:

Operation Successrul Local Interrace Violatlon (ENTLIV) Local System Error (ENTLSE) The ecode field wlll contain a more detailed error code lr an error ocourred.

Assorted Transport, llnk and sy~tem errors.
.
Tbe rour reserved word~ are for TSMI's lnternal use. Thelr value3 will be modirled by TSMI.

The SEND and REPLY prlmitives are illustrated in Figure 615.

6.7.3.10 TSM2_FREE

TSMI_FREE is a TSMI module which must be used by TSMI users to free bu~rers passed back to them by TSMI. TSM~_FREE takes burfer inrormation exactly as it ls returned to users rrom the other TSMI
entry points.

306~10 ,.- ~ .: .
` Applicatlon Or Epstein et al `~ ' ' ~ user error.
,.
UNRECOGNIZED OPTION (ENTUNOP) - The option specifled in a TSMI parameter packet is undefined.

LOCAL PORT DOES NOT EXIST (ENTLPNE) - The local port number specified ln a TSMI RECEIVE request does not exist.

NO DATA AVAILABLE (ENTNDA) - There is no data awaiting the user. This error i8 returned on receive requests.

TRANSACTION NOT FOUND (ENTTNF) - This error is returned on an abort ir the transaction belng aborted could not be round. This error is not necessarlly fatal since the transaction may have already completed.

PORT ALREADY EXISTS (ENTPE) - This error is returned on create port requests ir the requested port already exists.

INVALID ATTRI~UTE (ENTINVAT) - An attribute re-quested in a create port packet is invalid.

~UFFER TOO LARGE (ENTBFOV) - This error may be returned on broadcast or datagram requests lr too much data is sent to TSMI. Remember, these requests have size limitations.

TSMI ERROR tENTERR) - These errors are usually non-fatal errors specific to the TSMI inter~ace. I.e., they are more like inrormative messages. , ~ESTINATION PORT DOES NOT EXIST (ENTDPNE) - This 1306~310 Appllcation of Epstein et al error is returned on a tran~action if the destina-tion port set by the user does not exist on the remote machine.

TRANSACTION TIME W T (ENTTO) - This error is returned on timed out transactions.

TRANSACTION B ORTED (ENTABORT) - This error is returned on aborted transaction~.

LOCAL SYSTEM ERROR tENTLSE) - m is error type is returned when any local system errors occur. These include errors from r~SMEM, RSMEM~ system termination errors, or any error returned from system calls.

NODE UNREACHABLE - PERMANENT (ENTNUP) - This error type is returned on transport errors considered "permanentn.
Permanent here means that the node is unreachable as rar as the transport system can tell, and unless something is done about lt, another attempt to get to that node will probably fail. (Fix the cable, bring the other machine back up....) As of ncw, the only error considered "permanent" is NO
RESPONSE FRQM REMOTE.

NODE UNREACHABLE - TEMPORARY (ENTNT) - This error type is returned on transport errors considered ntemporaryn.
Temporary here means that the node was unreachable on this attempt, but another attempt may succeed. All transport errors not permanent are considered temporary. ~ a seemingly temporary error is actually permanent, it will show up as permanent in the next attempt to reach that node.

SEVERE LOCAL TRANSPORT ERROR (ENTNSEV) - This error type is returned when the request cannot be completed because of a severe problem wlth the local system.

. , .... . . .... , .. ~ .. .. . .. ... . . . . ...... .. . . ....

:` :

130fi~310 ~ Application Or Ep3tein et al ,.~
LINK NOT AVAILABLE (ENLNAV) - No link is available over which to send data. This probably means that there was some fatal problem when the link wa~
brought up.

LIN~ NOT ENABLED (ENLNE) - No link is available over which to send data. This probably means that there waQ some ratal problem when the link was brought up. , ~ .

S~FFICIENT RESODRCES NOT AVAILABLE (ENRNA) - There were not enough resources available to complete the request.

Other errors can mean that the transport system is sick.

The Transaction Timeout error can only be returned on a Transaction request in which a timeout value (other than -1) was speclfied. The error indicates that a Reply to the Transaction request wa~ not received by TSMI within the time period speciried.
TSMI makes no guarantee that the remote system did not perform the requested actlon, however. Tlmeouts will be started as soon as a transaotion request is recelved ~rcm a TSMI user. It is therefore posslble ror a transaction to time out beror it i3 sent. The assumption here is that a user has a reason to want a transaction to stop and the requesting task to be released within a speciric amount of time, whether or not the transaction was ~end. The user may reissue the Transaction, or perrorm peer to peer error recovery with a new Transaction.

6.7.4 Comprehensive Examples ~.306:~10 Application oP Epstein et al The followlng example~ assume two users, User 1 and ~er 2, running ln different computers of a distributed computer network, with each initiating actions tbat must be fulfilled in the other's computers. The ensuing action is described in narrative form, and depicted in state diagrams.

6.7.4.1 Example 1 The state diagram for example 1 is presented in Figure 616.

~er 1 - lJ~J ~ na 1. Registers the local directory :MYDIR a~ ::GLOBAl via the ?RECISTER system call.
2. m e System Call Handler calls the ~REGISTER code ln the GNS, whlch invokes the File Systems's pathname analysis tusing Resolve and Operate) to get the UID of :NYDIR.
3. The GNS then creates an entry in the Global Name Registry (::P) for GLOBSAL, matching ~t with the UID ~rom the Flle System and the local transport address.
4. Next the GNS updates the GNR databasss on ~11 other nodes by issuing a GNS primitive via ~3MI's broadcast facility.
5. m e user creates an IPC port (file) called PORTR in the global directory ::GLOBAL.

~ser ~ - ~D~u~ a A. The user program issues a ?ILRUP system call to obtain the IPC port associated wlth the IPC file ::GLOBAL :PORTR.
B. The SCH cPlls IPC Management, which in turn issues a ?FSTAT
system call to get the necessary information.
C. The File System decomposes the ?FSTAT into two operatlons.
The first is to perform pretix analysis, which requires it to obtain the ~ID of ::GLOBAL from the GNS.
D. The next File System step i8 to use DCALL to invoke the filestatus verslon Or Resolve and Operate to obtain the information based on the known UID and the partial pathname PORTR.
F.. DCALL obtains the transport address Or the node ::GLOBAL is on from the GNS, and determines that it 19 on other node.

`
130631() Application Or Epstein et al -,:
F. DCALl uses TSMI to deflect the Resolve and Operate request to the Serving DCALL Subsystem on the proper node.
. The SDCS invokes the local File System routine (located by the GNS database) to proce~s the request.
. The results returned to the SDCS are returned to the invoking DCALL service, and ultlmately to the ¢aller Or DCALL.
I. The File System returns the ?FSTAT infor~ation to IPC
Management.
J. IPC management conQtructs and returns an IPC part number.

6.7.4.2 Example 2 The state diagram for Example 2 is presented ln Figure 617.

~ser 1 ~ JIIJel action~

1. m e program issues an ?IREC sy~te~ call to wait for an IPC
message on the agreed upon port (::GLOBAL :PnRTR). This reque~t wlll be satis~ied by an IPC message received in step F as a re~ult Or actions initiated by User 2.
2. Arter processing the received ~essage, the ~ser 1 program issues an ?ISC-ND to send a response to User 2 via the IPC
Port.
3. IPC management invokes its send-message code via DCALL.
4. The DCALL processor queries the GNS for the transport address corresponding to the target proce3s Or message sent by this port.
5. Since the target process is remote, the DCALL processor invokes the transport service to initiate remote serving of the request.
6. TSMI on ~ser 2's system notiries the Serving DCALL Subsystem that there is a remote request for it.
7. The SDCS interrogates the GNS to determine the correct local service address, and invokes the appropriate IPC Management ~unction.

- - , ~ .- . i . v .. . . i . ~. . . . . . . . . . . . . . . . . . . ` . . . .

... - ~ .:: . ~ . ~, . I

13063~0 Appllcation of Epsteln et aL
, 8. The IPC Management subsystem perrorms the locaL processing to sa~isfy the locally issued receive request made by User 2 (in step H below).
9. Successful completion of the ?ISEND is reported back to the lnitiator (User 1).
., - ' , A. The pro~ram issues an ?ISEND system caLl via the agreed upon IPC port, to send a message to the User 1 process.
R. IPC management invo~es its send-meQsage code via DCALL.
C. The DCALL processor interrogates the GNS to determine that the target process is remote.
. DCAL invokes TSMI to initiate remote ~ervicing Or the request by the SDCS component on the target system.
E. SDCS on the target system obtains the proper local service address from the GNS, and invokes the IPC Management sub~ystem.
F. The OIPC subsystem performs the local processing on this request, including using it to satLsfy the locally issued ?IREC initiated by USER 1 in Step 1.
G. Successrul completion Or the ?ISEND is reported back to the original remote initiator.
H. Following notirication that the message was successfuLly sent, ~ser 2 issues an ?IREC caLl to receive the reply from User 1. This is the request that is satisried by the proces~ing in step 8.

06:310 APPENDIX A
Data Iransrer Flow Diagrams A.1 8-bit TransPer~
In all 8-bit transPers, the unused 24 source bits are undePined and the unused 24 destination bits are unchanged.
A.1.1 Write to Byte 0 from ~yte 0 (UnjustiPied) The following is sent out during the address phase:
DA line 0 1 2 3 4 . . . . . . 30 31 ' I
O I O I O I O I addres q I O
l_l l l_ The Pollowing i8 the result during the data phase:

0 . . . . . 15 16 . . . . . 31 . . . _ .
1. 1 1 Data lines I byte 0 I byte 1 I byte 2 I byte 3 v Memory ¦ byte 0 l_ . l . l Address XXXX Address XXXX~1 - ~?~S-~ 1306~0 Appllcation of Epstein et al Appendix A

.

A.1.2 ~rite to Byte 1 fro~ Byte 1 (unjustified) The following i8 sent out during the addre-qs phase:
DA line 0 1 2 3 4 . . . . . . 30 31 I
1 1 1 0 I O I O I address I o I

The following is the re~ult during the data phase:

. O . . . . . 15 16 . . . . . 31 Data lines I byte O I byte 1 I byte 2 I byte 3 ~ = .
Memory I I byte 1 Address XXXX - Address XXXXI1 -~5~ --; ~ 13063~) : Application of Epstein ~t al Appendix A

A.1.3 Write to Byte 2 from Byte 2 (Unjusti~ied) The following is sent out during the address phase:
DA line 0 1 2 3 4 . .. . . . 30 31 . ~ ~

I O I O I O I O I address 1 1 1 1. 1 1 The following is the result during the data phase:

O . . . . . 15 16 . . . . . 31 Data lines I byte G I byte 1 I byte 2 I byte 3 v l l l l l Nemory l l I byte 2 I
Address XXXX Address XXXXI1 ,~s7--Application of Epstein et al Appendix A
~:

A.1.4 Write to Byte 3 from Byte 3 The ~ollowin,~ is sent out during the address phaRe:
DAllne 0 1 2 3 4 . . . . . . 30 31 1 1 1 0 ¦ O ¦ x ¦ address 1 1 1 The following ih the result durlng the data phase:

O . . . . . 15 16 . . . . . 31 .
I I J ~ ~
Data lines ¦, byte O I byte 1 ~ byte 2 I byte 3 _ I .

-- .. v_ Memory I ~ byte 3 Addr:ess XXXX Address XXXXI1 -d''!~--., ~ .. . . .

: 1306 ~1() Application of Epstein et al . Appendix A
:, . ~ .

' A.1.5 Write to Byte O from Byte 3 (Ju~ti~ied) . .
, The rollowing i9 sent out during the address phase: -'I DA line 0 1 2 3 4 . . . . . . 3031 I
I O I O I O 1 1 i addre~s I O

The following is the result during the data phase:

O . . . . . 15 16 . . . . . 31 -Data line3 I byte O I byte 1 I byte 2 I byte 3 v Memory I byte O
_ _ l -Addre~s XXXX Address XXXXI1 - ~5q ~

:~
:
~ 1306:~10 Applieation Or Ep3tein et al Appendix A

;. :
.~
, .;

A.1.6 Write to Byte 1 from Byte 3 (Justified) The following is sent out during the address phase:
DA line 0 1 2 3 4 . . . . . . 3031 1 1 1 0 1 O 1 1 1 address 1 0 1 I_ The following is the result during the data phase:

O . . . . . 15 16 . . . . . 31 Data llnes ¦ byte O ¦ byte 1 I byte 2 ¦ byte 3 /
/
v Memory I ¦ byte 1 l~
Address XXXX Address XXXX+1 ~ 2 6 ~ ~

: ~ :
~`
~ ~ 13063~0 Applioatlon Or Epsteln et al Appendix A

:
.:
~:^
A.1.7 Write to Byte 2 Prom Byte 3 ~Justiried) The following is sent out during the addreqs phase:
DA line 0 1 2 3 4 . . . . . . 3031 ¦ O ¦ O ¦ O 1 1 1 address 1 1 l_l l l_l .

The ~ollowing is the result during the data phase:

O . . . . . 15 16 . . . . . 31 Data lines I byte O I byte 1 I byte 2 I byte 3 I

I
Memory l l I byte 2 Address XXXX Address XXXXI1 . . , , . ~ . .

:: :
1306~10 ~;~ Application Or Epstein et al : Appendix A
,-; -,~, ;, ~
~ ., A.1.8 Read from Byte O to Byte 3 (Ju~tifled) The following ls sent out durlng the addres~ phase:
DA llne O 1 2 3 4 . . . . . . 30 31 i I O 1 1 1 0 1 1 1 addre~
I I I I I _ I

The rOllOwing i9 the result during the data phase:
Address XXXX Addre~ XXXX~1 v _ , v Memory ¦ byte Q

`
v_ :
Data lines I byte O I byte 1 I byte 2 I byte 3 .. l - l l l O . . . . . 15 16 . . . . . 31 - 2~a-~ .

Appllcatlon of Epstein et al Appendlx A
`:

ii .
A.1.9 Read from Byte 2 to Byte 3 (Justified) The following i8 sent out during the address phase:
DA line 0 1 2 3 4 . . . . . . 30 31 I O 1 1 1 0 1 1 1 address 1 1 __ . . l l The following is the result during the data phase:
Addresis XXXX Address XXXX~1 v v I
Memory l l ¦ byte 2 _ \

v_ Data lines I byte O I byte 1 I byte 2 I byte 3 __ I I I , O . . . . . 15 16 . . . . . 31 ~ ~ ~ 3 ~
:

Applicatlon o~ Epsteln et al Appendix A

- A.2 16-bit Transfers In 1l 16-bit transfers, the unused 16 source bits are undefined while the unused 16 destination blts are unchanged.
A.2.1 Write to Word O from Word 1 (justified) The following i~ sent out during the address phase:
DA line 0 1 2 3 4 . .. . . . 30 31 . . _ .

I O I O 1 1 1 1 1 address I O I
l l l_l l - .

The following i8 the result during the data phase:

O . . . . . 15 16 . . . . . 31 -- . . . ~, , Data lines I word O I word 1 ... I

._ /
/
/

Nemory I word O ¦ I
I I I
Address XXXX Address XXXX~1 ~3063~0 Appllcatlon Or Epstein et al - Appendlx A

..,:
. i A
A.2.2 Write to Word O from Word O (un~u3tified) The following is sent out during the address phase:
DA line O 1 2 3 4 . . . . . . 30 31 _ j_ I l _ _ _ I
I O I 1 I 1 I 1 I address 1 0 I

The following ls the result during the data phase:

O . . . . . 15 16 . . . . . 31 Data llDes ¦ word O ¦ word 1 - I I I . . .

I t Memory Iword O

Address XX~X Address XXXX+l : :: -~, " ~

. . ~

S~ , ~ "

~ ~ ~ 1306:~10 Application o~ Epsteln et ial : Appendix A

~`:
~, A.2.3 Write to Word 1 ~rom Hord 1 I The rollowing i9 sent out during the addre~s phase:
' DA line 0 1 2 3 4 . . . . . . 30 31 ,, _ I I
¦ O ¦ x 1 1 ¦ 1 1 addre s 1 1 1 I_ I I I_I l I

The following i~ the result during the data phase:

O . . . . . 15 16 . . . . . 31 I
Data llnes ¦ word O I word 1 v l l I
Memory l l word 1 Address XXXX Address XXXX-1 . ,.

~ ;2 6 6 ~
.

Appllcatlon of Epstein et al - Appendix A

A.2.4 Read from Word O to Word 1 (ju~tified) The following i8 sent out during the address phase:
DA line 0 1 2 3 4 . . . . . . 30 31 1 1 ¦ 1 1 0 1 1 ¦ address 1 0 l_l l l l l l The following i9 the result during the data phase: :

Addres~ XXXX Addre~s XXXX~l ~
v _ _ V
Memory I word O
I

\l ~
v :~
Data lines I word O I word 1 O .. . . .15 16 . . . . . 31 ;~

''; ~

13063~() Application Or Ep~tein et al : Appendix A

A.2.5 Read from Word 1 to Word 1 The ~ollowing i9 sent out during the addresæ phase: .
DA llne 0 1 2 3 4 . . . . . . 3031 1 1 1 1 1 0 1 1 1 address ¦ 1 1 The following 19 the result during the data phase:

Address XXXX Address XXXXI1 v V
. .
Memory l l word 1 I 1.. _ I

v Data llnes I wort O I word 1 . I -.. ~_ I
O . . . . . 15 16 . . . . . 31 - 2 6 ~ -.. ,, , . . .,,. ~.--, . .. . . . .

130631() Application of Epstein et al Appendlx A

A.3 32-bit Transfers A.3.1 Write Odd Double Word The following is sent out during the address phase:
DA line O 1 2 3 4 . . . . . . 30 31 1 1 1 0 1 1 1 1 1 address 1 1 1 I_I I I_I

The ~ollowing is the result during the data phase:
O . . . . . 15 16 . . . . . 31 Data lines ¦ High order word I Low order word l_ I I `~

_, , _ \ \ :
v v Memory I High order word I Low order word I .High order word Address XXXX Address XXXX~

Applioation of Epsteln et al Appendix A
:

A.3.2 Write Even Double Word The following is sent out during the address phase:
DA line 0 1 2 3 4 . . . . . . 30 31 I
1 1 1 0 1 1 1 1 1 address 1 0 1 I_I_1- I I

The following is the result during the data phase:
O . . . . . . . . . . . . 31 Data lines 1 32-bit Hide Hord v Memor~ l I

Address XXXX Address XXXX~1 ~ 2 ~7~

130631() Appllcation o~ Epstein et al Appendix A

A.3.3 Read Odd Double Word The following i8 sent out during the address phase:
DA line O 1 2 3 4 . . . . . . 3031 I
1 1 ¦ 1 ¦ 1 1 1 ¦ address ¦ 1 ¦

The following iB the result durlng the data phase:
Addre s XXXX Address XXXXI1 v Memory ¦ High order word ¦ Low order word I High order word v . v Data lines I High order word I Low order word I :~
I . I I
O . . . . . 15 16 . . . . . 31 - ~71--13063~0 Application of Epstein et al Appendix A

A.3.4 Read Even Double Word The following i~ sent out during the address phase:
DA llne 0 1 2 3 4 . . . . . . 30 31 ¦ 1 ¦ 1 ¦ 1 ¦ 1 1 address I O
I_I I I_I

The following i9 the result during the data phase:
Address XXXX Addre~s XXXX~1 ~. v Memory 1 32-bit Wide Word v_ Data Lines O . . . . . . . . . . . . 31 , -- ;~ 7~--1~06310 Il Application Or Epsteln et al ~ Appendix A
.~
~, A.4 Block Transfers A.4.1 Write Block The following is sent out during the address phase:
DA llne 0 1 2 3 4 . . . . . . 30 31 I O ~ 0 1 address 1 0 IIII_I II
The rollowlng i8 the result durlng the data phase: ~

O . . . . . . . . 31 < - - 32-bits wide ---> ;~
l I transrer 1 I Data Lines 1------------~------------>1 Address XXXX
I\ 2 ¦ `---------->¦ Address XXXX+l I~
I\ 3 I `---------->I Address XX%X+2 I
I\ 4 I `---------->I Adtre~s XXXXI3 \ 5 `---------->I AddresY XXX%+4 l\ 6 I `---------->I Address XXXX~5 \ 7 `---------->¦ Address XXXX~6 \ 8 `---------->I Addre~s XXXX+7 Note: All address locatlons must be ~rom the same node.

- ;~ 7 :~ -!

:
Application of Epste1n et al Appendix A
:

A.4.2 Read Blook The following is sent out during the address phase:
DA line 0 1 2 3 4 . . . . . . 30 31 I
I O 1 1 i O I O I address 1 0 1 t I l~

The ~ollowing is the result during the data phase:

< - 32-bits wide ---> O . . . . . . . . 31 I I transfer 1 1 1 I Address XXXX ~ ---------->1 Data Lines l I I~_ I
l l 2 /
¦ Address XXXX~
I

I Addrsss XXXX~2 1~ ----------' I
l l 4 /
¦ Address XXXXI3 1~ ----------' t Address XXXX~4 I- ----------~
l l 6 /
¦ Addres~ XXXX~5 1~ ----------~

t Address XXXX16 I- ----------' I
I . I I
I Address XXXX~7 1~ ----------~
I . I

Note: All address locations must be from the same node.

- ~ 7 ~ ~

~ 1306310 . .
`
,.
Appendix B -- Programming the 8031 This ~ection is intended for the design engineer writing 8031 code which generates timing signals, and handles the mou~e. Careful programming i8 required to guarantee that timing signals are generated continuously, even when the mouse are being taken care of.
Several 8031 signals are used directly to drive control hardware on the VCU 206 board. These signals and their runctions are listed below in Table B-2. In addition, the MOVX instruction is used to talk to external registers and memory. These are outlined in Table B-1.
` :
Table EL1. MOVX instructions _________ -------------------- ~.~

Addres3 13...8 R~W Function _____________________________________________________________________ xOOxxx R/H Read/Write the palette storage RAM
001xxx R Read the palette storage and write the palette DACQ on VCU 206 (1 operation).
101xxx R Read the palette storage and write the palette DAC~ on VEU 207 (1 operation).
010xxx R Read the palette DACs on VCU 206.
110xxx R Read the palette DACs on VEU 207.
x11x11 W Hrite COM DATA byte 3.
x11x10 W Hrite COM DATA byte 2.
x11x01 R/H Read/Write COM DATA byte 1.
x11xOO R/W Read/Write COM DATA byte O and set DV (write)/clear RTA
tread).

-.27~--::~

Application of Epstein et al Appendix B

Table B-2. 8031 port signals _________________________________ Port pin 8031 pin signal I/0 function number name ==========================================================================
P0.0-7 32 - 39 UAD0-UAD7 I/0 register data, see table C-1 above.
__________________________________________________________________________ P1.0 1 STF 0 0 = 8031 uP self test passed.
1 = 8031 uP self test ~ailed.
P1.1 2 ^REFRST 0 used to reset the refre~h counter at the start of every new frame. Mu~t be asserted prior to the flrst ^HPULSE
signal (scan line zero) and removed prior to the next ^HPULSE 3ignal.
P1.2 3 VCU 206/8 I 0 = VCU 206~24 1 = VCU 206/8 P1.3,4 4,5 Not used.
P1.5 6 VSYNC 0 vertical sync, 0 = vert sync not asserted 1 = vert ~ync asserted P1.6 7 ^HPULSE 0 controls the trailing edge of HBLANK on the high to low transition.
P1.7 8 ^VBLANK0 0 raw vertical blanking, 0 = vert blanking asserted 1 = display active ______________________________________.. ___________________________________ , P2.0-5 21-26 A8 - A15 0 High portion of 8031 uP
address fleld.
P2.6,7 27,28 Not used.

- ;2 7 ~ ~

13063~0 Appllcation of Epstein et al Appendix ~
~: :
Table B-2. 8031 port signals (continued) __________________________________--___--___------Port pin8031 pin signal I/O function number name ==__====___====_================_========================================= ~
P3.0 10 MOUSEIN I Mouse/tablet receive data serial port.
P3.1 11 MOUSECUT O Mouse~tablet transmit data serial port.
P3.2 12 DV I When asserted, lndioates that 8031 uP has placed data into the COM DATA register ~or the host to read.
Cleared when th0 host reads tha data.
P3-3 13 DVEN O When asserted enables an ~MI
to occur when the DV bit i8 asserted. When deas~erted the NMI does not occur but the DV status is still valid and oan be read via the COM STATUS register.
P3.4 14 RTA I When as~erted, indicates that the 8031 uP has read the data last sent to the COM DATA register by the host, and is ready to accept another. Cleared when the 8031 uP reads the data.
P3.5 15 VPINTEN O When asserted enables an NMI
to occur when vertical blanking i9 asserted. When deasserted the NMI does not occur but the vertical blanklng statu3 is still valid and can be read via the COM STATUS register.
P3.6 16 ^UWR O Asserted when an external write accurs.
P3.7 17 ^URD O Asserted when an external read accurs.

- .2 '7 ~~

:

Claims (3)

1. A digital computer system comprising:
display means for displaying representations of data; a CPU; CPU bus means connected to the CPU for conducting information including instructions and data to and from the CPU; display memory means comprising a plurality of locations, each responsive to a unique address, for receiving from the CPU and storing data whose representations are to be displayed on the display means; display memory bus means for conducting display data to and from the display memory; and data manipulation means connected to the display memory bus means and the CPU bus means, the data manipulation means having:
data register means;
means for receiving data from the display memory bus means;
means for storing data from a first memory location in the data register means;
logical operation means, connected to the CPU bus, the display data bus and the data register means and responsive to commands from the CPU, for performing a selected logical combinational operation on the data from the data register means and data from a second memory location;
means connected to the display memory bus means and the logical operation means, for converting data from the display memory bus means format into the CPU bus means data format; and means for supplying the result of the logical operation to the display memory bus means.

2. The apparatus of claim 1 further comprising means, connected to the display memory bus means and the logical operation means, for converting the result from the logical operation means format into the memory data bus format.

3. A digital computer system comprising:
display means for displaying representation of data; a CPU; CPU bus means connected to the CPU for conducting information including instructions and data to and from the CPU; display memory means comprising a plurality of locations, each responsive to a unique address, for receiving from the CPU and storing data whose representations are to be displayed on the display means; display memory bus means for conducting display data to and from the display memory;
background means, connected to the CPU and the display memory bus means and responsive to selected portions of the data on the display memory bus means, for inserting background color information into the data on the display memory bus means, foreground means, connected to the CPU and display memory bus means and responsive to selected portions of the data on the display memory bus means, for inserting foreground color information into the data on the display memory bus means, and data manipulation means connected to the display memory bus means and the CPU bus means, the data manipulation means having:
data register means;
means for receiving data from the display memory bus means;
means for storing data from a first memory location in the data register means;
logical operation means, connected to the CPU bus, the display data bus and the data register means and responsive to commands from the CPU, for performing a selected logical combinational operation on the data from the data register means and data from a second memory location; and means for supplying the result of the logical operation to the display memory bus means.