mirror of
https://github.com/dekuNukem/USB4VC.git
synced 2025-10-31 11:26:46 -07:00
517 lines
23 KiB
HTML
517 lines
23 KiB
HTML
<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">
|
|
<html><head>
|
|
|
|
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
|
|
|
|
<meta content="Mozilla/4.76 [en] (Win98; U) [Netscape]" name="GENERATOR">
|
|
|
|
<meta content="Adam C" name="Author">
|
|
|
|
<meta content="This site contains info on the PS/2 protocol and interfacing keyboards and the PS/2 mouse." name="Description">
|
|
|
|
<meta 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" name="KeyWords">
|
|
<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 vlink="#3333ff" link="#0000ee" bgcolor="#ffffff" alink="#3333ff">
|
|
<a href="http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/PS2/ps2.htm">http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/PS2/ps2.htm</a><br>
|
|
<x-claris-window right="1012" left="0" bottom="607" top="0"> <x-claris-tagview mode="minimal"> </x-claris-tagview></x-claris-window>
|
|
<table cols="1" width="100%" cellspacing="0" cellpadding="4" border="0" bgcolor="#faf0e6">
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
<center><font size="+2"><br>
|
|
PS/2 Mouse/Keyboard Protocol</font><br>
|
|
This article is Copyright 1999, Adam Chapweske </center>
|
|
<br>
|
|
|
|
<p><b>Introduction:</b> </p>
|
|
|
|
<p>The PS/2 device interface, used by many modern mice and keyboards,
|
|
was developed by IBM and originally appeared in the IBM Technical Reference
|
|
Manual. However, this document has not been printed for many years
|
|
and as far as I know, there is currently no official publication of this
|
|
information. I have not had access to the IBM Technical Reference
|
|
Manual, so all information on this page comes from my own experiences as
|
|
well as help from the references listed at the bottom of this page. </p>
|
|
|
|
<p>This document descibes the interface used by the PS/2 mouse, PS/2
|
|
keyboard, and AT keyboard. I'll cover the physical and electrical
|
|
interface, as well as the protocol. 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="http://panda.cs.ndsu.nodak.edu/%7Eachapwes/PICmicro/keyboard/atkeyboard.html">The
|
|
PS/2 (AT) Keyboard Interface</a> <br>
|
|
<a href="http://panda.cs.ndsu.nodak.edu/%7Eachapwes/PICmicro/mouse/mouse.html">The
|
|
PS/2 Mouse Interface</a></blockquote>
|
|
I also encourage you to check this site's <a href="http://panda.cs.ndsu.nodak.edu/%7Eachapwes/PICmicro">main page</a>
|
|
for more information related to this topic, including projects, code,
|
|
and links related to the mouse and keyboard. Please send an <a href="mailto:achapwes@panda.cs.ndsu.nodak.edu">email </a>if you find any
|
|
mistakes or bad advice on this site.<br>
|
|
<br>
|
|
<b>The Physical Interface:</b><br>
|
|
|
|
<p>The physical PS/2 port is one of two styles of connectors:
|
|
The 5-pin DIN or the 6-pin mini-DIN. Both connectors are completely
|
|
(electrically) similar; the only practical difference between the two is
|
|
the arrangement of pins. This means the two types of connectors can
|
|
easily be changed with simple hard-wired adaptors. These cost about
|
|
$6 each or you can make your own by matching the pins on any two connectors.
|
|
The DIN standard was created by the German Standardization Organization
|
|
(Deutsches Institut fuer Norm) . Their website is at <a target="_top" href="http://www.din.de/">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.
|
|
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. 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.) All modern keyboards built for the PC are
|
|
either PS/2, AT, or USB. 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.)
|
|
The most popular type is probably the PS/2 mouse, with USB mice gaining
|
|
popularity. 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.
|
|
This document applies only to PS/2 mice. If you want to interface
|
|
a serial or USB mouse, there's plenty of information available 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. If you need a longer cable, you can
|
|
buy PS/2 extenstion cables from most consumer electronics stores. You
|
|
should not connect multiple extension cables together. If you need a
|
|
30-foot keyboard cable, buy a 30-foot keyboard cable. Do not simply
|
|
connect five 6-foot cables together. 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. 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. SDL was created by a company called "AMP."
|
|
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.
|
|
If you need more information on this connector, you might be able to find
|
|
it on AMP's website at <a target="_top" href="http://www.connect.amp.com/">http://www.connect.amp.com</a>. I have only seen this
|
|
type of connector on (old) XT keyboards, although there may be AT keyboards
|
|
that also use the SDL. 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. 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>
|
|
|
|
<table width="468">
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
|
|
<center>Male <br>
|
|
<img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/fpindin.JPG" width="80" height="68" align="bottom">
|
|
<br>
|
|
(Plug)</center>
|
|
</td>
|
|
<td>
|
|
|
|
<center>Female <br>
|
|
<img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/fpdin1.JPG" width="80" height="68">
|
|
<br>
|
|
(Socket)</center>
|
|
</td>
|
|
<td><b>5-pin DIN (AT/XT): </b> <br>
|
|
1 - Clock <br>
|
|
2 - Data <br>
|
|
3 - Not Implemented <br>
|
|
4 - Ground <br>
|
|
5 - Vcc (+5V)</td>
|
|
</tr>
|
|
|
|
</tbody>
|
|
</table>
|
|
<br>
|
|
|
|
<table width="469">
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
|
|
<center>Male <br>
|
|
<img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/spindin.JPG" width="80" height="68" align="bottom">
|
|
<br>
|
|
(Plug)</center>
|
|
</td>
|
|
<td>
|
|
|
|
<center>Female <br>
|
|
<img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/spindin1.JPG" width="80" height="68" align="bottom">
|
|
<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>
|
|
|
|
<table width="469">
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
|
|
<center><img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/sdl.jpg" width="114" height="49" align="bottom">
|
|
</center>
|
|
</td>
|
|
<td>
|
|
|
|
<center><img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/sdl1.jpg" width="114" height="49" align="bottom">
|
|
</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: 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. The keyboard
|
|
or mouse should not draw more than 100 mA from the host and care must be
|
|
taken to avoid transient surges. Such surges can be caused by "hot-plugging"
|
|
a keyboard/mouse (ie, connect/disconnect the device while the computer's
|
|
power is on.) Older motherboards had a surface-mounted fuse protecting
|
|
the keyboard and mouse ports. When this fuse blew, the motherboard was
|
|
useless to the consumer, and non-fixable to the average technician. Most
|
|
newer motherboards use auto-reset "Poly" fuses that go a long way to remedy
|
|
this problem. However, this is not a standard and there's still plenty
|
|
of older motherboards in use. Therefore, I recommend against hot-plugging
|
|
a PS/2 mouse or keyboard.<br>
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p><u>Summary: Power Specifications</u><br>
|
|
Vcc = +5V. <br>
|
|
Max Current = 100 mA.<br>
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>The Data and Clock lines are both open-collector with pullup resistors
|
|
to +5V. An "open-collector" interface has two possible state: low,
|
|
or high impedance. In the "low" state, a transistor pulls the line to
|
|
ground level. 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. 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. A general open-collector interface is shown below:<br>
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p><font color="#ff0000">Figure 1: General open-collector interface.
|
|
Data and Clock are read on the microcontroller's pins A and B, respectively.
|
|
Both lines are normally held at +5V, but can be pulled to ground by
|
|
asserting logic "1" on C and D. As a result, Data equals D, inverted,
|
|
and Clock equals C, inverted.</font><br>
|
|
</p>
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
<p><img alt="" src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/ps2.JPG" 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.
|
|
I use the same pin for both input and output, and I enable the PIC's
|
|
internal pullup resistors rather than using external resistors. A line
|
|
is pulled to ground by setting the corresponding pin to output, and writing
|
|
a "zero" to that port. The line is set to the "high impedance" state
|
|
by setting the pin to input. Taking into account the PIC's built-in
|
|
protection diodes and sufficient current sinking, I think this is a valid
|
|
configuration. 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. The bus is "idle" when both lines are high (open-collector).
|
|
This is the only state where the keyboard/mouse is allowed begin transmitting
|
|
data. The host has ultimate control over the bus and may inhibit
|
|
communication at any time by pulling the Clock line low. <br>
|
|
</p>
|
|
|
|
<p>The device always generates the clock signal. If the host
|
|
wants to send data, it must first inhibit communication from the device by
|
|
pulling Clock low. The host then pulls Data low and releases Clock.
|
|
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: <i>Idle state.</i><br>
|
|
Data = high, Clock = low: <i>Communication Inhibited.</i><br>
|
|
Data = low, Clock = high: <i>Host Request-to-Send</i></p>
|
|
</blockquote>
|
|
All data is transmitted one byte at a time and each byte is sent
|
|
in a frame consisting of 11-12 bits. These bits are:
|
|
|
|
<ul>
|
|
<li> 1 start bit. 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. 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.
|
|
The number of 1's in the data bits plus the parity bit always add up to
|
|
an odd number (odd parity.) This is used for error detection. 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> The clock frequency
|
|
must be in the range 10 - 16.7 kHz. This means clock must be high for
|
|
30 - 50 microseconds and low for 30 - 50 microseconds.. If you're designing
|
|
a keyboard, mouse, or host emulator, you should modify/sample the Data line
|
|
in the middle of each cell. I.e. 15 - 25 microseconds after
|
|
the appropriate clock transition. 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. 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. 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. If it's not,
|
|
the host is inhibiting communication and the device must buffer any to-be-sent
|
|
data until the host releases Clock. The Clock line must be continuously
|
|
high for at least 50 microseconds before the device can begin to transmit
|
|
its data. </p>
|
|
|
|
<p>As I mentioned in the previous section, the keyboard and mouse use
|
|
a serial protocol with 11-bit frames. These bits are: </p>
|
|
|
|
<ul>
|
|
<li> 1 start bit. 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. 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. Figures 2 and 3
|
|
illustrate this.<br>
|
|
|
|
<p><font color="#ff0000">Figure 2: Device-to-host communication.
|
|
The Data line changes state when Clock is high and that data is valid
|
|
when Clock is low.</font> <br>
|
|
</p>
|
|
|
|
<blockquote><img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/waveform1.jpg" width="432" height="139">
|
|
</blockquote>
|
|
|
|
<p> </p>
|
|
|
|
<p><font color="#ff0000">Figure 3: Scan code for the "Q" key (15h)
|
|
being sent from a keyboard to the computer. Channel A is the Clock
|
|
signal; channel B is the Data signal.</font> </p>
|
|
|
|
<blockquote><font color="#ffffff">---</font><img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/qscope.JPG" width="386" height="255">
|
|
<br>
|
|
</blockquote>
|
|
|
|
<p> The clock frequency is 10-16.7 kHz. The time from the rising
|
|
edge of a clock pulse to a Data transition must be at least 5 microseconds.
|
|
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. <br>
|
|
</p>
|
|
|
|
<p>The host may inhibit communication at any time by pulling the Clock
|
|
line low for at least 100 microseconds. 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. A "chunk" of data could be a make code, break code, device ID,
|
|
mouse movement packet, etc. 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. However, if new data is created that
|
|
needs to be transmitted, it will have to be buffered until the host releases
|
|
Clock. Keyboards have a 16-byte buffer for this purpose. If more
|
|
than 16 bytes worth of keystrokes occur, further keystrokes will be ignored
|
|
until there's room in the buffer. Mice only store the most current movement
|
|
packet for transmission. </p>
|
|
|
|
<p></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.
|
|
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. When the device detects this state, it will begin
|
|
generating Clock signals and clock in eight data bits and one stop bit.
|
|
The host changes the Data line only when the Clock line is low, and
|
|
data is read by the device when Clock is high. 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.
|
|
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) Bring the Clock line low for at least 100
|
|
microseconds. <br>
|
|
2) Bring the Data line low. <br>
|
|
3) Release the Clock line. <br>
|
|
4) Wait for the device to bring the Clock line low.
|
|
<br>
|
|
5) Set/reset the Data line to send the first data bit
|
|
<br>
|
|
6) Wait for the device to bring Clock high. <br>
|
|
7) Wait for the device to bring Clock low. <br>
|
|
8) Repeat steps 5-7 for the other seven data bits and the
|
|
parity bit <br>
|
|
9) Release the Data line. <br>
|
|
10) Wait for the device to bring Data low. <br>
|
|
11) Wait for the device to bring Clock 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. 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: Host-to-Device Communication.</font>
|
|
<br>
|
|
<img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/waveform2.jpg" width="504" height="131">
|
|
</p>
|
|
|
|
<p><font color="#ff0000">Figure 4: Detailed host-to-device communication.</font>
|
|
<br>
|
|
<img src="The%20PS_2%20Mouse_Keyboard%20Protocol_files/waveform3.jpg" width="552" height="247">
|
|
<br>
|
|
</p>
|
|
|
|
<p>Referring to Figure 4, there's two time quantities the host looks
|
|
for. (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 packet to be sent, which
|
|
must be no greater than 2ms. If either of these time limits is not
|
|
met, the host should generate an error. Immediately after the "ack"
|
|
is received, the host may bring the Clock line low to inhibit communication
|
|
while it processes data. 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. If this does not happen, the host generates
|
|
an error. </p>
|
|
|
|
<p></p>
|
|
|
|
<ul>
|
|
|
|
<ul>
|
|
|
|
</ul>
|
|
|
|
</ul>
|
|
|
|
|
|
<p> </p>
|
|
|
|
|
|
<blockquote> </blockquote>
|
|
<b>Other Sources / References:</b>
|
|
|
|
<ul>
|
|
<li> <a href="http://govschl.ndsu.nodak.edu/%7Eachapwes/PICmicro/index.html">Adam's
|
|
micro-Resources Home</a></li>
|
|
|
|
</ul>
|
|
<br>
|
|
</td>
|
|
</tr>
|
|
|
|
</tbody>
|
|
</table>
|
|
|
|
<center> </center>
|
|
|
|
<center></center>
|
|
|
|
<p><br>
|
|
</p>
|
|
|
|
<p><b></b></p>
|
|
<br>
|
|
|
|
</body></html> |