IBUS Input Device Protocol Specification Unisys Corporation Revision 1.3 by Gary W. Hanning 03/14/91 Note: This Document is not under ECN at this time. It is therefore subject to change without notice. Table Of Contents 1: Revision History x 2: Introduction x 2.1: Background Information x 2.2: Document Scope x 2.3: Related Documents and Specifications x 3: Input Device Configurations x 3.1: Single Ported Devices x 3.2: Dual Ported Devices x 3.3: Device Connectivity x 3.4: VM103/VC103 Configurations x 4: Software Controllable Hardware Resets x 4.1: Power On Reset x 4.2: VM103/VC103 Reset Pulse 5: Device Identification Codes x 5.1: ID Code Scheme x 5.2 Registered ID Codes x 5.3 Registering ID Codes for IBUS Input Devices x 5.4 K6 Keyboard ID considerations x 6: Byte Protocols x 6.1: Data Format x 6.2: Device Identification Protocol x 6.3: Inbound Protocol x 6.4: Interrupting Inbound Data Transmissions 6.5: Outbound Protocol x 6.5.1: Set Inbound Pass Thru Mode x 6.5.2: Reset Inbound Pass Thru Mode x 1: Revision History Revision Date Engineer Description Version 1.0 11/15/83 David Christie First Publication Version 1.1 02/05/90 Gary W. Hanning Update Specification Version 1.2 03/03/90 Gary W. Hanning Support Sgen Monitors Version 1.3 08/24/90 Gary W. Hanning K6 Keyboard 2: Introduction 2.1: Background Information The IBUS provides a low speed serial interface to the host CPU for input devices such as keyboards and mice. This document describes the protocol of the IBUS as well as specifications that input devices must follow in order to work well in the IBUS environment. The IBUS is designed to be modular in that input devices can be chained together serially. In order for a device to support other devices chained off of it, it must be dual ported. One port o f a dual port device is connected towards the host keyboard controller ( or UART ) and the other port can support additional dual ported devices or a single ported device. See the diagram below. The dotted lines represent the IBUS medium, a cable with SDL or 6 pin Mini Din type connectors on one or both ends of each section. The operator may plug and unplug input devices without tools at any time, even while the system is running. In actual fact the cabling between the host controller and the first input device is via the base of the video display monitor. Most monitors just mechanically pass the ibus signals through between the host and devices and therefore do not participate in protocol communications. However, the Sgen series of monitors ( VM103, VC103 ), when used with NGen series computers, are in fact input devices that do participate in protocol communications. Refer to the section on Input Device Configurations. The input device protocol specifies a standard manner in which the Host CPU and the Input Devices communicate. All input devices must conform to this protocol so that the host CPU can communicate with input devices with which it has no direct connection. In order to allow the greatest amount of flexibility, the input device protocol allows input devices to be interchangable. This means that devices are not restricted to a unique physical location on the IBUS by protocol. However, the number and location of devices on the IBUS is limited by the number and placement of dual ported devices. For example, the IBUS may have at most one single ported device and it must be the last device on the IBUS. See the section on input device configurations for more information on placement of devices on the IBUS. 2.2: Document Scope This protocol specification is designed to serve as a guide for the development of input device firmware and system software for use with the CTOS operating system. As such, the protocol description is presented generically with exceptions for particular devices noted where applicable. Generic devices are either two ported ( the device contains two uarts ) or single ported ( the device contains one uart ). 2.3: Related Documents and Specifications - NGen Input Device Protocol Specification, Version 1.1, 1983 - Detailed Functional Specification for Keyboard Microcontroller Firmware, Version 1.0, 1990 - VM103/VC103 Monitor Firmware External Design Specification, Revision 1.0, 1989 3: Input Device Configurations The most common IBUS configuration consists of: A dual ported device ( keyboard ) connected to the host through one of its ports. A single ported device ( mouse ) connected to the second port of the dual ported device. 3.1: Single Ported Devices Single ported devices are those that have only one receiver/transmitter port. Since all single ported devices have only one port, no other input devices can be chained off of a single ported device. Nevertheless, a single ported device may be connected directly to the host or to the open port on a dual ported device. 3.2: Dual Ported Devices Dual ported devices have two receiver/transmitter ports. Most dual ported devices are ambidextrous and permit the connection to the host to be made through either port. Other input devices can chain to the port that is not connected to the host. Since Dual ported devices Pass Thru data from other devices, they must implement the IBUS protocol for Inbound data transmissions. See the sections on Ibound and Outbound Protocol. 3.3: Device Connectivity The operating system software should be able to detect and adjust to any changes in the IBUS configuration. Normally, devices can be unplugged and the configuration may be altered without rebooting the system. In order to function in this manner, all IBUS devices should be able to receive a power-on hardware reset ( described in section 4 ) from the host and respond via the identification protocol( described in section 5 ). 3.4: VC103/VM103 Configurations As mention earlier, the SGen series of monitors ( VM103, VC103 ) communicate with NGen hosts via the IBUS. These monitors are dual ported devices with dedicated host and input device ports. The IBUS connects to the host through the video connector. Other input devices can chain to one of two ports on the front of the monitor. These ports are 6 pin Mini Din connectors. Refer to the VM103 firmware specification for more information of this one active port model. At this time it is not decided to support a two active port model on these monitors. Note that these monitors do not communcate via the IBUS when connected to SGen hosts. Instead, they communicate via a half duplex asynchronous channel called the Backchannel. Refer to the SGen Keyboard Microcontroller Firmware Specification for more information on the Backchannel. 4: Software Controllable Hardware Resets 4.1: Power On Reset When the processor is powered up or reset, or when an IBUS device is plugged into the host ( or a dual ported device ), the IBUS device(s) will receive an active low reset signal with a width that exceeds 10 milliseconds. In addition, this reset is software controllable reset via a keyboard reset port on the NGen series hosts or through a command interface on SGen series hosts ( see the appropiate technical reference manual for the exact port/command ). If the reset signal is generated by the host through software or from power-on, then it is passed on and must be recognized by all devices on the IBUS. If a device is plugged into an already active IBUS, it is reset - the other devices remain active. It is a requirement that all dual ported devices reset into Prevent Ibound Pass Thru Mode. Refer to the section on Inbound Protocol for more information. 4.2: VM103/VC103 Reset Pulse If an NGen series host detects a SGen series monitor (VM103 or VC103), the operating system will issue a special hardware reset to the monitor. This is necessary to set the monitor into a mode where it communicates to the host via the IBUS. This reset signal consists of the following sequence of pulses: A logic 1 pulse (active low) with a width of 2.5 milliseconds nominal +-20% A logic 0 pulse (active low) with a width of 2.5 milliseconds nominal +-20% A logic 1 pulse (active low) with a width of 7.5 milliseconds nominal +-20% Upon receiving this reset signal, the monitor changes mode to IBUS and then issues a standard IBUS reset signal to all devices chained off its one active port. Refer to the VM103/VC103 Microcontroller Firmware Specification for more detailed information. 5: Device Identification Codes 5.1: ID Code Scheme Each type of input device has its own unique ID code. For example, every PD-001 (three button mouse) has the same ID but all B27 mouse ( two button mouse ) have a different ID than the PD-001. The ID code for a IBUS input device consists of two bytes. The ID code is transmitted from the input device to the host during the identification protocol handshake. During this handshake, the low-order byte of the ID code is sent first followed by the high order byte. The first, or low-order byte contains flag bits that describe the device attributes. This byte is sometimes called the generic attribute byte. The bits of this byte are defined as follows: BSDR 0000 7 0 Where: B 0: Device can not communicate with boot rom. 1: Device is capable of communicating with the boot rom S 0: Standard boot sequence desired - no boot rom interaction is desired unless a boot error occurs. 1: Boot rom interaction is desired. NOTE: Bit S is forced high by the K1-K6 style keyboards when the space bar is held down at the instant of IBUS reset. By default, this bit should be 0. D 0: The device is single ported 1: The device is dual ported R 0: Reserved all other devices 1: Reserved for keyboards only Bits 0 through 3 are reserved for future use and should be 0. The second, or high order byte contains the unique code identifying the particular type of device. 5.2 Resigistered ID Codes The following is a list of Registered ID codes. These ID codes are raw - no bits have been forced to indicate desire for boot rom interaction. In addition, no reserved protocol bytes may be asigned as IDs for any IBUS device. Type Code Attr. Byte Device (High Byte ) (Low Byte) 12" & 14" Video Monitor 02 00 K1 Keyboard 04 B0 Multibus Adapter 06 00 PD-001 Three Button Mouse 08 00 Summa Optical Mouse 0C 00 14" & 15" Color Monitor 0E 00 VM103/VC103 SGen Monitor 20 30 K6 Keyboard - USA 21 B0 K6 Keyboard - Arabic 22 B0 K6 Keyboard - Belgium 23 B0 K6 Keyboard - Canada 24 B0 K6 Keyboard - Finland/Sweden 25 B0 K6 Keyboard - French 26 B0 K6 Keyboard - German 27 B0 K6 Keyboard - New Greek 28 B0 K6 Keyboard - Hebrew 29 B0 K6 Keyboard - Iceland 2A B0 K6 Keyboard - Italy 2B B0 K6 Keyboard - Netherlands 2C B0 K6 Keyboard - Norway/Denmark 2D B0 K6 Keyboard - Portugal 2E B0 K6 Keyboard - South Africa 2F B0 K6 Keyboard - Spain/Latin America 30 B0 K6 Keyboard - Swiss-German 31 B0 K6 Keyboard - Swiss-French 32 B0 K6 Keyboard - Turkey 33 B0 K6 Keyboard - United Kingdom 34 B0 K6 Keyboard - Yugoslavia 35 B0 K6 Keyboard - Reserved 36 B0 K6 Keyboard - Reserved 37 B0 K6 Keyboard - Reserved 38 B0 SuperSet 2 button Auxilary Device 64 01 SuperSet Keyboard - USA 65 B0 SuperSet Keyboard 66 SuperSet Keyboard 67 SuperSet Keyboard 68 SuperSet Keyboard 69 SuperSet Keyboard 6A SuperSet Keyboard 6B SuperSet Keyboard 6C SuperSet Keyboard 6D SuperSet Keyboard 6E SuperSet Keyboard 6F SuperSet Keyboard 70 SuperSet Keyboard 71 SuperSet Keyboard 72 SuperSet Keyboard 73 SuperSet Keyboard 74 SuperSet Keyboard 75 SuperSet Keyboard 76 SuperSet Keyboard 77 SuperSet Keyboard 78 SuperSet Keyboard 79 SuperSet Keyboard 7A SuperSet Keyboard 7B SuperSet Keyboard 7C SuperSet Keyboard 7D SuperSet Keyboard 7E SuperSet Keyboard 7F SuperSet Keyboard 80 Swiss Bank MCR 81 Hardware Identifier 82 Villers Escalles K4 Keyboard 90 Villers Escalles MCR-M1 91 Villers Escalles MCR-M2 92 Villers Escalles Pin Pad 93 Villers Escalles 4 Port Splitter 94 Villers Escalles Proof Keyboard 95 RESERVED - PROTOCAL AA BULL kbu 7410 Keyboard B0 B0 BULL kbu 7411 Keyboard B0 B0 K2 Keyboard /French CA B0 K2 Keyboard /New Canada CB B0 K2 Keyboard /Portugal D1 B0 K2 Keyboard /Yugoslavia D2 B0 K3/K5 Keyboard /Iceland D7 B0 K3/K5 Keyboard /Hebrew D8 B0 K3/K5 Keyboard /Arabic D9 B0 K3/K5 Keyboard /Greek DA B0 K3/K5 Keyboard /Portugal DB B0 K3/K5 Keyboard /Yugoslavia DC B0 K3/K5 Keyboard /Norway-Denmark DD B0 Burroughs B30/Unisys B27 Mouse DE 00 K3/K5 Keyboard /Turkey E0 B0 K3/K5 Keyboard /Belgium E1 B0 K3/K5 Keyboard /United Kingdom E2 B0 K3/K5 Keyboard /Swiss-German E3 B0 K3/K5 Keyboard /Swiss-France E4 B0 K3/K5 Keyboard /South Africa E5 B0 K3/K5 Keyboard /Netherlands E6 B0 K3/K5 Keyboard /Spain-Latin America E7 B0 K3/K5 Keyboard /Italy E8 B0 ALC Keyboard - CER I-311 E9 K3/K5 Keyboard /Germany EA B0 K2 Keyboard /Arabic EB B0 K3/K5 Keyboard /France EC B0 K3/K5 Keyboard /Finland-Sweden ED B0 K2 Keyboard /Turkey EE B0 K3/K5 Keyboard /USA EF B0 K2 Keyboard /Belgium F0 B0 K2 Keyboard /United Kingdom F1 B0 K2 Keyboard /Swiss-German F2 B0 K2 Keyboard /Swiss-France F3 B0 K2 Keyboard /South Africa F4 B0 K2 Keyboard /Norway-Denmark F5 B0 K2 Keyboard /Netherlands F6 B0 K2 Keyboard /Spain-Latin America F7 B0 K2 Keyboard /Italy F8 B0 K2 Keyboard /Germany F9 B0 K3/K5 Keyboard /Canada FA B0 K2 Keyboard /France FB B0 K2 Keyboard /Finland-Sweden FC B0 K2 Keyboard /Canada FD B0 Reserved - IBUS ID Sync. Byte FE K2 Keyboard /USA FF B0 * - Note: These ID's are proposed, not approved. 5.3: Registering ID Codes for IBUS Input Devices To register an ID code you need to: - Formulate the low byte of the device ID needed according to the scheme above. NCG Technical Support will asign you the high byte ( the unique ID byte ). - Submit the names, descriptions and the lower byte ( formulated above ) of the device(s) that will use the ID(s) to: NCG Techincal Support Attn: Registry Coordinator 2310 North First Street P.O. Box 6685 MS 9-007 San Jose, CA 95150 Phone:1-800-858-8255 FAX: (408) 435-5344 CT-Mail: Message/TS2 Note: When sending CT-Mail to message/TS2 please include your phone/FAX number. - Your request for the ID(s) must be verified and approved by NCG Technical Support before they are considered valid and reserved for your product. 5.4: K6 Keyboard ID Considerations The K6 keyboard firmware was modified to support ID's in the range of 00 - 3F. This is diffierent from the K3/K5 keyboards where the range supported was C0 - FF. New versions of the K6 should be asigned IDs in the appropiate range. 6: Byte Protocols 6.1: Data Format All data on the IBUS is transmitted at 1200 baud. The format of the data is: one start bit ( low ) eight data bits one stop bit ( high ) Since dual-ported devices have only a limited amount of buffer space, a device which is plugged into a dual ported device must not occupy 100% of the bus bandwidth or buffer overrun may occur. 6.2 Device Identification Protocol The IBUS identification protocol specifies that upon reset the device will transmit a sequence of 40 or more ID-sync bytes. The ID-sync byte is FEh. The ID-sync byte stream is followed immediately by the low order byte and high order byte of the device ID. The operating system can recognize the transmission of the identification protocol at anytime during operation. It is required that all two ported devices reset into prevent ibound pass-through mode. This means that a dual ported device must not transmit any data to the host other than its own ID sequence until it receives a set inbound pass-through command from the host. Since most dual ported devices do not have a dedicated host port, they must broadcast their ID out both ports and then listen for possible transmission of an ID from a chained device. If such an ID is received it identifies a device attached to the port and it is the responsibility of the dual ported device to buffer the ID and report it to the host upon receiving a command from the host to do so ( set inbound pass-through ). If no such ID ( or other data ) is received through a port, that port is assumed to be open and the dual ported device must send a special nothing to report ID code after receiving the set inbound pass through command from the host. Receipt of data other than an ID-sync stream indicates that the processor is connected to that port. The ID codes of input devices are not reserved protocol bytes. Rather they are triggered after a sequence of 40 or more FE's. A sequence of less than 40 ID-sync bytes is considered data. 6.3 Inbound Protocol The IBUS uses two different input device protocols: ibound and outbound. Inbound protocol is what the input device sends to the host processor. Outbound protocol is what the device receives from the host processor. This section covers inbound protocol. Inbound protocols can be device specific with expection to the following reserved bytes: FEh ( 40 or more) ID-Sync CEh Set Inbound Pass Thru Mode - no data lost CFh Set Inbound Pass Thru Mode - data lost DFh Reset Inbound Pass Thru Mode Note that only dual ported devices need to respect the Set and Reset Inbound Pass Thru commands. Single ported devices never have other devices chained to them and therefore would never perfom a pass thru function. The operating system keeps a count of the number of Set Inbound Pass Thru bytes received to determine the source of the received data. If 0 Set Inbound Pass Thru bytes are received, the OS assumes the data came from the first physical device on the IBUS. If 1 such byte is received, the OS assumes the source was the second physical device on the IBUS. If the Reset Inbound Pass Thru byte is received, the OS will adjust its counter and begin to accept data from the device issuing the Reset Inbound Pass Thru on the IBUS. It is the responsiblity of all dual ported devices to insert a Set Inbound Pass Thru byte before beginning to transmit data to the host from a chained input device. Futhermore, when a dual ported device wishes to start transmitting its own data after transmitting data from a chained device, it must first send a Reset Inbound Pass Thru byte to tell the host to adjust for the new source of data. A special case is when a dual ported device is asked to pass thru a Reset Inbound Pass Thru byte from a chained device. In order for the host to recognize this byte and determine which device is now transmitting, every dual ported device must pass thru twice the number of DFh bytes that is receives.. The OS will recognize this sequence as a switch to the device at postion log base 2 of the number of contiguous DFh bytes received. 6.4 Interrupting Inbound Data Transmissions The IBUS protocol provides for the interruption of a data transmission by another input device. This is necessary because some dual ported devices do not buffer data from other chained input devices. An example of such a scenario is when the user moves the mouse and enters keystrokes on the keyboard at the same time. Since only a dual ported device can pass through information from a chained device, it is obivious that only a dual ported device can interrupt a data transmssion from a chained device. If a dual ported device finds that it will interrupt ( or terminate ) a data transmission from a chained device, it must behave in the following manner: - It should send a single DFh ( a reset inbound pass thru byte ) towards the host. The protocol specifies that this byte be doubled by each dual ported device between the interrupting device and the host. - Transmit its inbound data packet - Send a single CEh or CF (if data lost from chained device) towards the host to indicate the previously interrupted device in now communicating again. - A set inbound pass thru byte will cause the host to switch to the device who was communicating before the most recent interruption. Hence, the operating system allows for the interruption of a device who is currently interrupting a device itself. 6.5: Outbound Protocol The IBUS outbound protocol defines the transmission of data and commands from the host towards the input devices. This protocol insisits that only the host can originate outbound data transmissions. Outbound protocols are device specific with the following codes reserved as protocol bytes: CEh: Set Outbound Pass Thru Mode DFh: Reset Outbound Pass Thru Mode D0h: Allow Inbound Pass Thru D1h: Prevent Inbound Pass Thru Again, since dual ported devices are the only devices that pass through data from chained devices, they are the only devices that need to recognize these reserved codes. 6.5.1 Set Outbound Pass Thru Mode The Set Outbound Pass Thru Mode byte is sent by the OS to inform a device that the data following this byte should be passed thru to the next physical device on the IBUS. Dual ported devices must strip one CEh byte when passing through data originating from the host. This permitts the host to send x-1 CEh bytes to direct data to the device at physical position x on the IBUS. 6.5.2: Reset Outbound Pass Thru Mode The Reset Outbound Pass Thru Mode byte is sent by the OS to inform a device on the IBUS that data being passed thru to chained devices is being terminated. If a dual ported device receives a sequence of DFh bytes greater than one, then the command is not meant for it. Rather the dual ported device has the responsibility of passing on one less than the number of DFh bytes received. The device that receives the Reset Outbound Pass Thru command byte will change mode and no longer pass data through to chained devices until it receives a Set Inbound Pass Thru byte from the Host. 2 PROPRIETARY -- DO NOT COPY Page # ~2P'`$ $ YN 1 H[݋ 5 89:;<=>?@ABCDEFGH[؄؅  5@  @G HG H@  h &*,GHGH@  hG H @h &*,H 9%ĴěO8{|}݂ݤݫݷ؉#QwԳʴ=hԚʛMsԝ8[ʑʹE{|}ԀԁԖԗCԆԿԇԈԉԋ~ GHGH  G HG H &*,G HGH@  @G H@  hG H\&:  .  5 y Ֆ Ī I d 7Y\ĉ6SuխF"#$:;<  NOНвг - . ` b ж з    1 2 3 u v w В Г Д Ѝ Ў E F G b c d 789ЅІЈвгЕЖ34STЉЊ$qrrstЕЖЬЭЭЮЄЅF  &*,@   GH &*,FGHG H &*,GH@  @ &*,GHy7+DEHNUaepĚܛT "U֒֗֘ 67tֳ -.Rvwֵֶ78 !Eopָ֚-Wւ֦Kr֙8dּ֓Jw֞! J s ֧ * H f ք ֢  8 V t ֒ ְ ) G e փ ֡ ֿ  6 _ փ ֧ %En֗Mv֞Cs֥&TD  &*, &*,  GH@  @GH@  @GHmĥ).aěķ 8 \ , Į .ĢոD.\ʉʾ 4_ʇʷ3fʗ,]ʕʿDwʢ+,_`aʅʆ12wʲʳ ,?JKe~ʙʚ;ʁʘʙʾʿ Q ʟ ʵ ʶ / G Y q r 5 6 [ \ ʟʠʡʸʹʻʽ9mʞʞʟʯʰAB\  &*, FGH &*, G HGH &*, @  @GH/ɸɂԃ$@ɦL x ɿ @ ϶*+πρσ)Z[πs !";<=efϋϲϢϤI J t u @ @ ڿ @ H , GH@hG H , &*, &*, GH@  @GHFGH j^@ @ @@!$@&(**/= .@@@@@@@@Courier Helvetica- Helvetica! Helvetica Helvetica% Helvetica( Helvetica$ Helvetica) Helvetica",,ccc,cd~dx@dxxdxddxx_d,Txdxdxddd@xexxdhhdddxh@x  hxVxxhhhwCTCPrCPP]CPCCPPCPCPCPCCC]Px]C]PPCCCCWPPPxx9xPP\\\\wCTCCU5PP]CPCCCCCxCCCq5xC55x5PxCxxxxP>PPPCCCCWPxPPPP.PPP\\\\NbN]N]]mN]NN]]N]N]N]NNNm]mNm]]NNNNe]]]C]]llll  <<< <YpYYrGkk|YkYYYYEY .YYYGYGGG kYkSkkkY@@YYYtk@k@kkk=kkk@@@{{{{NbNNc>]]mN]NNNNNNNN>N>>>]N^I^]]NNNNe]]]]]5]]]llll  <<< <YpYkYkk|YkYYkk8Y .kYkYkYYY|k|Z|kkY@@YYYtk@k@kLkk@@@{{{{wCTCCU5PP]CPCCCCCxCCCq5xC55x5PxCxxxxP>PPPCCCCWPxPPPP.PPP\\\\GL?308$OBJECT0>>?? GwQG|y_q|y_qwQGwQ %S )] _qd{d{؄ ؄ y QyyQQ HyH؄ް؄ްy Qy`y`QQ QypypQQ y؄U؄Uy 0Ӏ60Ӏ60Ӏ60Ӏ60Ӏ6$\Z_OZ_h&l SimplexRomanT[T[|JHost8U8UW] SimplexRoman8<8<Devicebbck SimplexRoman8<8<Portedllu SimplexRoman8<8<PDual8Uǯ8U<ǿ] SimplexRoman8<8<@8 @ @@ B@ @@@ B@ @@@ @ @O@ D<@  @H@ D&@p"Q @H@ D"@"  H@ D"@"Q @H@ D"@"Q @M@ bd6@"2 @J@ X<@8" @@ @ @@ @ @@ @ @ @ @@ @ @@ @ @@ @ @@ @ @~ @ @?  @B @ @!  B @ @!  @B8>@ @!~ @~&!l"@ @?!&a# @#!~#@ @ >!A @#!#@ @  @"aD"@ @ " A,2@ 1@`x @8,@ `@!@O@ @!a @ @ # @ @0 @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @@ @ @?@ b@ @! B@ @a B<@ Dx@AH Bf&3@ E@AH& BB!@  I@AD B~?@ 9@a?G B@  0@!"C" rv&3@ @1B   @ x@b @ B @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ ? GLmmmmmmmmmmm ""?      b n Picture 10B0$0b00 S_2XXXPPB@4, mo mo , , @$40@$8?)PB@4 JU( JU( 5M5MnPB@4-X,-XnFnF,-X,PB@0>n>PPnPB@4Mu,Munene,Mu,@4l,lnn,l,PB@0`n`wzwznPB@4kkkkk@(ZT)ZG@( +T) +G@(ZN[ +N[@(qP O@( O YN[@( YN[ L@( L Ks@( Ks YI@( YI H@( HqG@(qGBG@(BGH@(HYI@(YIKs@(KsL@(LYN[@(YN[O@(OBP@(BPqP@(AN[O@(O*P@(*PYP@(YPO@(OBN[@(BN[M1@(M1L@(LpL@(pLKs@(KsAJJ@(AJJAI@(AIH@(H*G@(*GYG@(YGH@(HBI@(pT)pJJ@(pJJH@(HAG@(AGG@(PP@(1N=1N5@(1N=2=@(2=3 =i@(3 =i3}<@(3}<3;@(3;3:@(3:38@(3837@(373}6@(3}63 6@(3 625@(251N5@(487 8@(7 87 9@(7 96:Q@(6:Q6:@(6:6e;@(6e;5;@(5;5}:@(5}:5 9@(5 948@(4847@(475 6@(5 65}6@(5}655@(556e5@(6e566@(667 6@(8;95@(:6;95@(;=;N=i@(;N=i;}=@(;}=;N>0@(;N>0;=@(;N;;N5@(>9>e:@(>e:>;@(>;=|;@(=|;=:@(=:<9@(<9<8@(<8<7@(<7<6@(<6=6@(=6=|5@(=|5>5@(>5>e6@(>e6>6@(?8B8@(B8B9@(B9A:Q@(A:QA:@(A:AM;@(AM;@;@(@;@d:@(@d:@9@(@9?8@(?8?7@(?7@6@(@6@d6@(@d6@5@(@5AM5@(AM5A6@(A6B6@(1T1K@(1T2T@(2T37S@(37S3fSP@(3fSP3R@(3R3Q_@(3Q_3fP@(3fP37P6@(37P62O@(2O1O@(5Q_57P@(57P4P6@(4P64O @(4O 4NG@(4NG4M@(4M57LX@(57LX5K@(5K6K@(6K6}LX@(6}LX6M@(6M7 NG@(7 NG7 O @(7 O 6P6@(6P66}P@(6}P6Q_@(6Q_5Q_@(8NQ_8NK@(8NO 8}P6@(8}P68P@(8P97Q_@(97Q_9Q_@(:T:M@(:M;LX@(;LX;eK@(;eK;K@(:NQ_;Q_@(O @(>O >O@(>O>P@(>P>}P@(>}P>Q_@(>Q_=Q_@(=Q_=7P@(=7PK@(>K>}LX@(>}LX>M@(BTBK@(BP6AP@(APAdQ_@(AdQ_@Q_@(@Q_@|P@(@|P@P6@(@P6?O @(?O ?NG@(?NG@M@(@M@|LX@(@|LX@K@(@KAdK@(AdKALX@(ALXBM@(47d47\@(47d5}d@(5}d6d>@(6d>6ecy@(6ecy6b@(6b6a@(6a6_@(6_6^p@(6^p6e]@(6e]6\@(6\5}\@(5}\47\@(8 a8 ^@(8 ^87\@(87\8\@(8\9 \@(9 \9}\@(9}\:^@(:a:\@(=|a=|\@(=|`= a@(= ad>\@(P=P5@(P=Q=@(Q=R|=i@(R|=iR<@(R0@(Z>0Z|=@(Z;Z5@(^9]:@(]:]d;@(]d;\;@(\;\{:@(\{:\9@(\9[8@([8[7@([7\6@(\6\{6@(\{6\5@(\5]d5@(]d5]6@(]6^6@(_58ac8@(ac8ac9@(ac9a5:Q@(a5:Qa:@(a:`;@(`;`;@(`;_:@(_:_d9@(_d9_58@(_58_57@(_57_d6@(_d6_6@(_6`5@(`5`5@(`5a6@(a6ac6@(PfTPfK@(PfTRT@(RTRS@(RSRSP@(RSPRR@(RRRQ_@(RQ_RP@(RPRP6@(RP6RO@(ROPfO@(TQ_TP@(TPT7P6@(T7P6T O @(T O T NG@(T NGT7M@(T7MTLX@(TLXTK@(TKU}K@(U}KULX@(ULXV7M@(V7MVfNG@(VfNGVfO @(VfO V7P6@(V7P6UP@(UPU}Q_@(U}Q_TQ_@(WQ_WK@(WO WP6@(WP6X7P@(X7PXQ_@(XQ_Y Q_@(Z7TZ7M@(Z7MZfLX@(ZfLXZK@(ZK[K@(YQ_ZQ_@(\O ^7O @(^7O ^7O@(^7O^P@(^P]P@(]P]|Q_@(]|Q_\Q_@(\Q_\P@(\P\7P6@(\7P6\O @(\O \NG@(\NG\7M@(\7M\LX@(\LX\K@(\K]|K@(]|K]LX@(]LX^7M@(a|Ta|K@(a|P6aP@(aP`Q_@(`Q_`6Q_@(`6Q__P@(_P_|P6@(_|P6_NO @(_NO _NNG@(_NNG_|M@(_|M_LX@(_LX`6K@(`6K`K@(`KaLX@(aLXa|M@(SdS\@(SdTd@(TdUfd>@(Ufd>Ucy@(UcyUb@(UbV a@(V aV _@(V _U^p@(U^pU]@(U]Uf\@(Uf\T\@(T\S\@(WfaWf^@(Wf^W\@(W\W\@(W\X}\@(X}\X\@(X\Ye^@(YeaYe\@(\a\\@(\`\}a@(\}a\a@(\a[a@([a[7a@([7aZ`@(Z`Z_@(Z_Z^@(Z^Z]@(Z][7\@([7\[\@([\\\@(\\\}\@(\}\\]@(^Nd^N\@(pccpdn@(pdnozd@(ozdnd@(ndn5dn@(n5dnmc@(mcmb@(mbnb@(nbn5a@(n5anaU@(naUo`@(o`p`,@(p`,p4_@(p4_pc_@(pc_pc]@(pc]p]@(p]oz\@(oz\n\@(n\n5]@(n5]m]@(qzdqdn@(qdnqd@(qdqe5@(qe5qzd@(qbq\@(sbs\@(s`sa@(satb@(tbtb@(tbta@(tau`@(u`u\@(xbx[@(x[xbZ@(xbZx4Z]@(x4Z]wY@(wYwKY@(wKYvZ]@(x`x4a@(x4awb@(wbwKb@(wKbva@(vav`@(v`vb_@(vb_vb_@(vb_v]@(v]v]@(v]wK\@(wK\w\@(w\x4]@(x4]x]@(zdz\@({K_}y_@(}y_}y`@(}y`}JaU@(}JaU}a@(}a|b@(|b|3b@(|3b{a@({a{y`@({y`{K_@({K_{K_@({K_{y]@({y]{]@({]|3\@(|3\|\@(|\}]@(}]}y]@(mTmK@(mTnT@(nToKS@(oKSozSR@(ozSRoR@(oRoQa@(oQaozP@(ozPoKP8@(oKP8nO@(nOmO@(qQaqLP@(qLPpP8@(pP8pO@(pOpNI@(pNIpM@(pMqLLZ@(qLLZqK@(qKr4K@(r4KrLZ@(rLZrM@(rMsNI@(sNIsO@(sOrP8@(rP8rP@(rPr4Qa@(r4QaqQa@(tcQatcK@(tcOtP8@(tP8tP@(tPuKQa@(uKQauQa@(vTvM@(vMwLZ@(wLZwzK@(wzKwK@(vbQawQa@(xOzO@(zOzO@(zOzP@(zPzP@(zPz3Qa@(z3QayQa@(yQayKP@(yKPxP8@(xP8xO@(xOxNI@(xNIxM@(xMyKLZ@(yKLZyK@(yKz3K@(z3KzLZ@(zLZzM@(~3T~3K@(~3P8}P@(}P}yQa@(}yQa|Qa@(|Qa|P@(|P|4P8@(|4P8|O@(|O|NI@(|NI|4M@(|4M|LZ@(|LZ|K@(|K}yK@(}yK}LZ@(}LZ~3M@(mc=mc5@(mc=n=@(n=o4=@(o4=o<@(o^@(wc>^w4=@(wc;Dwc5@(z:zy:@(zy:z;D@(z;Dy;D@(y;Dy3:@(y3:x:@(x:x8@(x8x8,@(x8,x7@(x7y36=@(y36=y5@(y5z5@(z5zy6=@(zy6=z7@({8~8@(~8~9@(~9}:~@(}:~}:@(}:}a;D@(}a;D|;D@(|;D|y:@(|y:|:@(|:{8@({8{8,@({8,|7@(|7|y6=@(|y6=|5@(|5}a5@(}a5}6=@(}6=~7 @mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmP|ibusdiagram.art.picKilleribusДlДlДl _DHdDF+>@gn.) FP666+8 x G ]`]5/>9 LaserWriter+2.35 &Y7P