summaryrefslogtreecommitdiffstats
path: root/docs/www.computer-engineering.org/ps2protocol/index.html
blob: 8adffd9e60fe8d74507a136ca86b7848c1e543b9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>

                                            
  <meta http-equiv="Content-Type"
 content="text/html; charset=iso-8859-1">
                                            
  <meta name="GENERATOR"
 content="Mozilla/4.76 [en] (Win98; U) [Netscape]">
                                            
  <meta name="Author" content="Adam C">
                                            
  <meta name="Description"
 content="This site contains info on the PS/2 protocol and interfacing keyboards and the PS/2 mouse.">
                                            
  <meta name="KeyWords"
 content="PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PIC, microcontroller, interfacing, keyboard, mouse, mice, AT keyboard, PS/2 mouse, PC keyboard, interfacing, mouse, PS/2">
  <title>The PS/2 Mouse/Keyboard Protocol</title>
                                             <!--This file created 3:58 PM  2/5/2000 by Claris Home Page version 3.0-->
</head>
  <body bgcolor="#ffffff" link="#0000ee" vlink="#3333ff" alink="#3333ff">

   <small><b><font face="Arial,Helvetica"><font size="+3"><small>The PS/2 
Mouse/Keyboard  Protocol</small></font></font></b></small><br>
              
<center></center>
              
<center>               
<hr width="400" size="1" align="left" noshade="noshade"></center>
                  <br>
     <font face="Arial,Helvetica">Source: <a
 href="http://www.Computer-Engineering.org">http://www.Computer-Engineering.org</a></font><br>
      <font face="Arial,Helvetica">Author: Adam Chapweske<br>

     Last Updated: 05/09/03<br>
     <br>
    <br>
     </font><b>Legal Information:</b><br>
     <br>
     All information within this article is provided "as is" and without
any   express or implied warranties, including, without limitation, the implied
  warranties of merchantibility and fitness for a particular purpose. &nbsp;<br>
    <br>

    This article is protected under copyright law. &nbsp;This document may
 be  copied only if the source, author, date, and legal information is included.<br>
    <br>
    <b>Abstract:</b>   
<p>This document descibes the interface used by the PS/2 mouse, PS/2    keyboard, 
 and AT keyboard.&nbsp; I'll cover the physical and electrical  interface, 
  as well as the protocol.&nbsp; If you need higher-level information,  such 
  as commands, data packet formats, or other information specific to the keyboard
  or mouse, I have written separate documents for the two devices:      
 </p>
                                                             
<blockquote><a href="../ps2keyboard">The    PS/2 (AT) Keyboard Interface</a>

          <br>
                  <a href="../ps2mouse">The    PS/2 Mouse Interface</a></blockquote>
   <b>The Physical Interface:</b><br>
                                                             
<p>The physical PS/2 port is one of two styles of connectors:&nbsp;    The 
 5-pin DIN or the 6-pin mini-DIN.&nbsp; Both connectors are completely   
(electrically) similar; the only practical difference between the two is 
 the arrangement of pins.&nbsp; This means the two types of connectors can 
  easily be changed with simple hard-wired adaptors.&nbsp; These cost about 
  $6 each or you can make your own by matching the pins on any two connectors.&nbsp; 
   The DIN standard was created by the German Standardization Organization 
 (Deutsches  Institut fuer Norm) .&nbsp; Their website is at       <a
 href="http://www.din.de" target="_top">http://www.din.de</a> (this site is
in German, but most of their pages are also available in English.)      

</p>
                                                             
<p>PC keyboards use either a 6-pin mini-DIN or a 5-pin DIN connector.&nbsp; 
     If your keyboard has a 6-pin mini-DIN and your computer has a 5-pin DIN
   (or visa versa), the two can be made compatible with the adaptors described
   above.&nbsp; Keyboards with the 6-pin mini-DIN are often referred to as
 "PS/2"  keyboards, while those with the 5-pin DIN are called "AT" devices
 ("XT" keyboards  also used the 5-pin DIN, but they are quite old and haven't
 been made for  many years.)&nbsp; All modern keyboards built for the PC
are  either PS/2,  AT, or USB.&nbsp; This document <i>does not</i> apply
to USB  devices, which  use a completely different interface. </p>
                                                             
<p>Mice come in a number of shapes and sizes (and interfaces.)&nbsp;    The 
 most popular type is probably the PS/2 mouse, with USB mice gaining  popularity.&nbsp; 
  Just a few years ago, serial mice were also quite popular,  but the computer 
  industry is abandoning them in support of USB and PS/2 devices.&nbsp; This 
  document applies only to PS/2 mice.&nbsp; If you want to interface a serial 
  or USB mouse, there's plenty of information available&nbsp;elsewhere   on
 the web.<br>

             <br>
       The cable connecting the keyboard/mouse to the computer is usually 
about    six feet long and consists of four to six 26 AWG wires surrounded 
by a thin   layer of mylar foil sheilding. &nbsp;If you need a longer cable, 
you can  buy PS/2 extenstion cables from most consumer electronics stores. 
&nbsp;You   should not connect multiple extension cables together. &nbsp;If 
you need  a 30-foot keyboard cable, buy a 30-foot keyboard cable. &nbsp;Do 
not simply   connect five 6-foot cables together. &nbsp;Doing so could result 
in poor  communication between the keyboard/mouse and the host.<br>
               </p>
                                                             
<p>As a side note, there is one other type of connector you may run    into 
 on keyboards. While most keyboard cables are hard-wired to the keyboard, 
    there are some whose cable is not permanently attached and come as a separate
    component.&nbsp; These cables have a DIN connector on one end (the end
 that  connects to the computer) and a SDL (Sheilded Data Link) connector
on the  keyboard end.&nbsp; SDL was created by a company called "AMP."&nbsp;

 This  connector is somewhat similar to a telephone connector in that it
has  wires  and springs rather than pins, and a clip holds it in place.&nbsp;
If you need more information on this connector, you might be able to find
it on AMP's website at <a href="http://www.connect.amp.com"
 target="_top">http://www.connect.amp.com</a>.&nbsp;  Don't confuse the SDL
connector with the USB connector--they probably both  look similar in my
diagram below, but they are actually very different.&nbsp;  Keep in mind
that the SDL connector has springs and moving parts, while the  USB connector
does not. </p>
                                                             
<p>The pinouts for each connector are shown below: <br>
          &nbsp;                                                     
<table width="468">

           <tbody>
                    <tr>
           <td>                                                         
                                                       
      <center>Male <br>
                      <img src="fpindin.JPG" height="68" width="80"
 alt="">
           <br>
          (Plug)</center>
           </td>

            <td>                                                        
                                                        
      <center>Female&nbsp; <br>
                      <img src="fpdin1.JPG" height="68" width="80"
 alt="">
           <br>
          (Socket)</center>
           </td>
            <td><b>5-pin DIN (AT/XT):&nbsp;</b> <br>

          1 - Clock <br>
          2 - Data <br>
          3 - Not Implemented <br>
          4 - Ground <br>
          5 - Vcc (+5V)</td>
           </tr>

                                                                        
          
  </tbody>                                                    
</table>
            <br>
          &nbsp;                                                     
<table width="469">
           <tbody>
                    <tr>
           <td>                                                         
                                                       
      <center>Male <br>
                      <img src="spindin.JPG" height="68" width="80"
 alt="">

           <br>
          (Plug)</center>
           </td>
            <td>                                                        
                                                        
      <center>Female <br>
                      <img src="spindin1.JPG" height="68" width="80"
 alt="">
           <br>
          (Socket)</center>

           </td>
            <td><b>6-pin Mini-DIN (PS/2):</b> <br>
          1 - Data <br>
          2 - Not Implemented <br>
          3 - Ground <br>
          4 - Vcc (+5V) <br>

          5 - Clock <br>
          6 - Not Implemented</td>
           </tr>
                                                                        
          
  </tbody>                                                    
</table>
            <br>
          &nbsp;                                                     
<table width="469">
           <tbody>

                    <tr>
           <td>                                                         
                                                       
      <center><img src="sdl.jpg" height="49" width="114" alt="">
                      </center>
           </td>
            <td>                                                        
                                                        
      <center><img src="sdl1.jpg" height="49" width="114" alt="">
                      </center>
           </td>
            <td><b>6-pin SDL:</b> <br>

          A - Not Implemented <br>
          B - Data <br>
          C - Ground <br>
          D - Clock <br>
          E - Vcc (+5V) <br>
          F - Not Implemented</td>

           </tr>
                                                                        
          
  </tbody>                                                    
</table>
            </p>
                                                             
<p> </p>
                                                             
<p><br>
                <b>The Electrical Interface:</b><br>
                </p>

                                                             
<p>Note:&nbsp; Throughout this document, I will use the more general    term 
 "host" to refer to the computer--or whatever the keyboard/mouse is  connected 
  to-- and the term "device" will refer to the keyboard/mouse.       </p>
                                                                        
                   
<p>Vcc/Ground provide power to the keyboard/mouse. &nbsp;The keyboard   or 
 mouse should not draw more than 275 mA from the host and care must be   taken
 to avoid transient surges. &nbsp;Such surges can be caused by "hot-plugging"
    a keyboard/mouse (ie, connect/disconnect the device while the computer's
   power is on.) &nbsp;Older motherboards had a surface-mounted fuse protecting
   the keyboard and mouse ports. &nbsp;When this fuse blew, the motherboard
  was useless to the consumer, and non-fixable to the average technician.
&nbsp;Most    newer motherboards use auto-reset "Poly" fuses that go a long
way to remedy    this problem. &nbsp;However, this is not a standard and
there's still plenty    of older motherboards in use. &nbsp;Therefore, I
recommend against hot-plugging    a PS/2 mouse or keyboard.<br>
             </p>

                                     
<blockquote>                                             
  <p><u>Summary: Power Specifications</u><br>
       Vcc = +4.5V to +5.5V. &nbsp;<br>
        Max Current = 275 mA.<br>
               </p>
             </blockquote>
                                     
<p>The Data and Clock lines are both open-collector with pullup  resistors 
   to Vcc. &nbsp;An "open-collector" interface has two possible state: low,
   or high impedance. &nbsp;In the "low" state, a transistor pulls the line
  to ground level. &nbsp;In the "high impedance" state, the interface acts
 as an open circuit and doesn't drive the line low or high. Furthermore,
a  "pullup" resistor is connected between the bus and Vcc so the bus is pulled
 high if none of the devices on the bus are actively pulling it low. &nbsp;The
 exact value of this resistor isn't too important (1~10 kOhms); larger resistances
   result in less power consumption and smaller resistances result in a faster
   rise time. &nbsp;A general open-collector interface is shown below:<br>

            </p>
                             
<blockquote>                                    
  <p><font color="#ff0000">Figure 1: General open-collector interface.  &nbsp;Data 
 and Clock are read on the microcontroller's pins A and B, respectively. 
&nbsp;Both lines are normally held at +5V, but can be pulled to ground by 
  asserting logic "1" on C and D. &nbsp;As a result, Data equals D, inverted, 
  and Clock equals C, inverted.</font><br>
              </p>
            </blockquote>
                             
<blockquote>                                    
  <p><img src="ps2.JPG" alt="" width="352" height="330">
              <br>

              </p>
            </blockquote>
                                                     
<p><br>
      Note: When looking through examples on this website, you'll notice
I  use   a few tricks when implementing an open-collector interface with
PIC  microcontrollers.   &nbsp;I use the same pin for both input and output,
and  I enable the PIC's   internal pullup resistors rather than using external
 resistors. &nbsp;A line  is pulled to ground by setting the corresponding
 pin to output, and writing  a "zero" to that port. &nbsp;The line is set
to the "high impedance" state  by setting the pin to input. &nbsp;Taking
into account the PIC's built-in   protection diodes and sufficient current
sinking, I think this is a valid   configuration. &nbsp;Let me know if your
experiences have proved otherwise.<br>
             <br>
            <b>Communication: General Description</b><br>

             </p>
                                                     
<p>The PS/2 mouse and keyboard implement a bidirectional synchronous    serial 
 protocol.&nbsp; The bus is "idle" when both lines are high (open-collector).
     &nbsp;This is the only state where the keyboard/mouse is allowed begin
  transmitting   data. &nbsp;The host has ultimate control over the bus and
  may inhibit communication at any time by pulling the Clock line low. &nbsp;<br>
             </p>
                                     
<p>The device always generates the clock signal. &nbsp;If the host wants
to send data, it must first inhibit communication from the device by pulling
  Clock low. &nbsp;The host then pulls Data low and releases Clock. &nbsp;This
  is the "Request-to-Send" state and signals the device to start generating
  clock pulses.<br>

             </p>
                                     
<blockquote>                                             
  <p><u>Summary: Bus States</u><br>
       Data = high, Clock = high: &nbsp;<i>Idle state.</i><br>
       Data = high, Clock = low: &nbsp;<i>Communication Inhibited.</i><br>
       Data = low, Clock = high: &nbsp;<i>Host Request-to-Send</i></p>

             </blockquote>
       &nbsp; All data is transmitted one byte at a time and each byte is 
sent   in a frame consisting   of 11-12 bits.&nbsp; These bits are:      
                                                                       
<ul>
     <li> 1 start bit.&nbsp; This is always 0.</li>
     <li> 8 data bits, least significant bit first.</li>

     <li> 1 parity bit (odd parity).</li>
     <li> 1 stop bit.&nbsp; This is always 1.</li>
     <li> 1 acknowledge bit (host-to-device communication only)</li>
     
</ul>
                                                             

<p> The parity bit is set if there is an even number of 1's in the data bits 
 and reset (0) if there is an odd number of 1's in the data bits.&nbsp;  
 The number of 1's in the data bits plus the parity bit always add up to 
an  odd number (odd parity.)&nbsp; This is used for error detection. &nbsp;The
     keyboard/mouse must check this bit and if incorrect it should respond
 as   if it had received an invalid command.<br>
            </p>
                             
<p>Data sent from the device to the host is read on the <i>falling       </i>edge
of the clock signal; data sent from the host to the device is read on the
      <i>rising </i>edge<i>.</i>&nbsp; The clock frequency must be in the
range 10 - 16.7 kHz. &nbsp;This means clock must be high for 30 - 50 microseconds
and low for 30 - 50 microseconds.. &nbsp;If you're designing   a keyboard,
mouse, or host emulator, you should modify/sample the Data line   in the
middle of each cell. &nbsp;I.e.&nbsp; 15 - 25 microseconds after the  appropriate
clock transition. &nbsp;Again, the keyboard/mouse always generates  the clock
signal, but the host always has ultimate control over communication.    
   </p>

                                                             
<p> </p>
          Timing is absolutely crucial. &nbsp;Every time quantity I give
in  this   article  must be followed exactly.<br>
                <br>
                <b>Communication: Device-to-Host</b><br>
                                                             
<p>The Data and Clock lines are both open collector. &nbsp;A resistor    is
connected between each line and +5V, so the idle state of the bus is  high.
 When the keyboard or mouse wants to send information, it first checks  
the  Clock line to make sure it's at a high logic level.&nbsp; If it's not,
  the  host is inhibiting communication and the device must buffer any to-be-sent
    data until the host releases Clock. &nbsp;The Clock line must be continuously
    high for at least 50 microseconds before the device can begin to transmit
   its data.&nbsp;        </p>

                                                             
<p>As I mentioned in the previous section, the keyboard and mouse use    a
serial protocol with 11-bit frames.&nbsp; These bits are: </p>
                                                             
<ul>
     <li> 1 start bit.&nbsp; This is always 0.</li>
     <li> 8 data bits, least significant bit first.</li>

     <li> 1 parity bit (odd parity).</li>
     <li> 1 stop bit.&nbsp; This is always 1.</li>
     
</ul>
                The keyboard/mouse writes a bit on the Data line when Clock 
 is  high, and  it is read by the host when Clock is low. &nbsp;Figures 2 
and 3 illustrate   this.<br>
                                                                

<p><font color="#ff0000">Figure 2:&nbsp; Device-to-host communication.&nbsp; 
     The Data line changes state when Clock is high and that data is valid 
 when   Clock is low.</font> <br>
                </p>
                                     
<blockquote><img src="waveform1.jpg" height="139" width="432" alt="">
             </blockquote>
                                     
<p>    </p>
                                                             

<p><font color="#ff0000">Figure 3:&nbsp; Scan code for the "Q" key (15h) being
sent from a keyboard to the computer.&nbsp; Channel A is the Clock signal;
channel B is the Data signal.</font> </p>
                                                             
<blockquote><font color="#ffffff">---</font><img src="qscope.JPG"
 height="255" width="386" alt="">
           <br>
             </blockquote>
                                     
<p>   The clock frequency is 10-16.7 kHz.&nbsp; The time from the rising
   edge of a clock pulse to a Data transition must be at least 5 microseconds.&nbsp; 
     The time from a data transition to the falling edge of a clock pulse 
must   be at least 5 microseconds and no greater than 25 microseconds.&nbsp; 

<br>
             </p>
                                     
<p>The  host may inhibit communication at any time by pulling the Clock 
 line low for at least 100 microseconds.  &nbsp;If a transmission is inhibited 
   before the 11th clock pulse, the device must abort the current transmission 
   and prepare to retransmit the current "chunk" of data when host releases
   Clock. &nbsp;A "chunk" of data could be a make code, break code, device
 ID,  mouse movement packet, etc. &nbsp;For example, if a keyboard is interrupted
   while sending the second byte of a two-byte break code, it will need to
 retransmit  both bytes of that break code, not just the one that was interrupted.<br>
            </p>
                             
<p>If the host pulls clock low before the first high-to-low clock transition,
   or after the falling edge of the last clock pulse, the keyboard/mouse
does    not need to retransmit any data. &nbsp;However, if new data is created
that   needs to be transmitted, it will have to be buffered until the host
releases   Clock. &nbsp;Keyboards have a 16-byte buffer for this purpose.
&nbsp;If more  than 16 bytes worth of keystrokes occur, further keystrokes
will be ignored  until there's room in the buffer. &nbsp;Mice only store
the most current movement packet for transmission.       </p>

                                                                        
                                                                  
<p><b>Host-to-Device Communication:</b><br>
                </p>
                                                             
<p>The packet is sent a little differently in host-to-device communication... 
           </p>
                                                             
<p>First of all, the PS/2 device always generates the clock signal.&nbsp; 
     If the host wants to send data, it must first put the Clock and Data 
lines     in a "Request-to-send" state as follows: </p>
                                                             
<ul>
     <li> Inhibit communication by pulling Clock low for at least  100  
microseconds.</li>

     <li> Apply "Request-to-send" by pulling Data low, then release   Clock.</li>
     
</ul>
           The device should check for this state at intervals not to exceed
  10  milliseconds.&nbsp;   When the device detects this state, it will begin 
  generating  Clock signals   and clock in eight data bits and one stop bit.&nbsp; 
  The host changes the         Data line only when the Clock line is low, 
and   data is read by the device when Clock is high.&nbsp; This is opposite 
of  what occours in device-to-host communication.                        
                            
<p>After the stop bit is received, the device will acknowledge the received 
   byte by bringing the Data line low and generating one last clock  pulse.&nbsp; 
 If the host does not release the Data line after the 11th clock pulse, the 
 device will continue to generate clock pulses until the the Data line is 
released (the device will then generate an error.)       </p>

                                                             
<p>The host may abort transmission at time before the 11th clock pulse   
 (acknowledge bit) by holding Clock low for at least 100 microseconds.  
      </p>
                                                             
<p>To make this process a little easier to understand, here's the steps 
   the host must follow to send data to a PS/2 device: </p>
                                                             
<blockquote>1)&nbsp;&nbsp; Bring the Clock line low for at least   100 microseconds. 
   <br>
          2)&nbsp;&nbsp; Bring the Data line low. <br>
          3)&nbsp;&nbsp; Release the Clock line. <br>

          4)&nbsp;&nbsp; Wait for the device to bring the Clock line low. 
         <br>
          5)&nbsp;&nbsp; Set/reset the Data line to send the first data bit 
          <br>
          6)&nbsp;&nbsp; Wait for the device to bring Clock high. <br>
          7)&nbsp;&nbsp; Wait for the device to bring Clock low. <br>

          8)&nbsp;&nbsp; Repeat steps 5-7 for the other seven data bits and 
 the   parity  bit <br>
          9)&nbsp;&nbsp; Release the Data line. <br>
          10) Wait for the device to bring Data low. <br>
          11) Wait for the device to bring Clock&nbsp; low. <br>

          12) Wait for the device to release Data and Clock</blockquote>
                                                                
<p><br>
                <font color="#000000">Figure 3 shows this graphically and 
Figure    4  separates the timing to show which signals are generated by the
host,   and  which are generated by the PS/2 device.&nbsp; Notice the change
in timing    for the "ack" bit--the data transition occours when the Clock
  line is  high (rather than when it is low as is the case for the other
11  bits.)</font>         </p>
                                                             
<p><font color="#ff0000">Figure 3:&nbsp; Host-to-Device Communication.</font> 
           <br>

                <img src="waveform2.jpg" height="131" width="504" alt="">
           </p>
                                                             
<p><font color="#ff0000">Figure 4:&nbsp; Detailed host-to-device communication.</font> 
           <br>
                <img src="waveform3.jpg" height="247" width="552" alt="">
           <br>
          &nbsp; </p>

                                                             
<p>Referring to Figure 4, there's two time quantities the host looks  for. 
 &nbsp;(a) is the time it takes the device to begin generating clock pulses 
 after  the host initially takes the Clock line low, which must be no greater 
 than  15 ms. (b) is the time it takes for the&nbsp; packet to be sent, which 
 must be no greater than 2ms.&nbsp; If either of these time limits is not 
met, the host should generate an error.&nbsp; Immediately after the "ack" 
is received, the host may bring the Clock line low to inhibit communication 
  while it processes data.&nbsp; If the command sent by the host requires 
a  response, that response must be received no later than 20 ms after the 
host  releases the Clock line.&nbsp; If this does not happen, the host generates 
  an error.<x-claris-window top="0" bottom="607" left="0" right="1012"> <x-claris-tagview
 mode="minimal">   </x-claris-tagview></x-claris-window>  </p>

                   <br>
  <br>
 <br>
</body>
</html>