http://localhost:8088/docs/patent/US5193174.pdf page 13
KEYBOARDLESS OPERATION
To implement keyboardless operation three problems arise. First, a
keyboard must always be initialized if service is needed. This is
necessary to allow the Customer Engineer to access the reference
diskette or advanced diagnostics. Second, a missing keyboard and a
defective keyboard may look alike from a software perspective. Third,
more than one kind of system configuration needs keyboardless support.
Both systems configured as servers and systems with an ASCII Console
need the additional support provided by keyboard less operation.
POST must determine which port has a keyboard installed. Therefore,
software must have the ability to differentiate between a keyboard and a
mouse. This is accomplished by reading an ID from the keyboard and
mouse. Since the IDs are similar for both keyboards and mice, the "READ
ID' procedure must test for valid IDs and not invalid IDs. This is to circumvent the condition where a mouse looks like a defective keyboard,
and/or a keyboard looks like a defective mouse. Since, this method uses
the existence of a keyboard first and then the existence of a mouse to determine the configuration of the system, a default setup is not relied
upon when a keyboard is not found. Physical port A is scanned first, and physical port B is scanned second. Therefore, both ports are truly
switchable and the external configuration is solely responsible for the
setup of the ports. This situation is different from previous switchable
port implementations for the keyboard and mouse that used the presence
or absence of the keyboard in the first connector as the sole test for
setting the configuration. For a system that has a keyboard as a
mandatory piece of equipment, the single test for a keyboard in port A
and port B is sufficient to configure the system correctly.
POST initializes the keyboard controller to either the DEFAULT or the
SWAP state. To determine the correct state, the following method is implemented. The physical keyboard port is tested and initialized. If a keyboard is found, POST sets the state as DEFAULT. If a keyboard is not
found, the physical mouse port is tested and initialized. If a keyboard
is found, POST sets the state as SWAP. If no keyboard is found in either
port, the mouse determines the state of the port assignment. FIG. 6 illustration gives the complete flow for determining the port selection.
The procedure used to initialize the keyboard and mouse subsystems is
shown in FIG. 6. Since this procedure is a portion of the overall POST
this section occurs after other POST activities have already been
completed (step 500).
Two states are defined to implement the swapability of the keyboard and
mouse ports. The first state is the DEFAULT state. This state maps the
logical keyboard port to the physical keyboard port. Likewise, the
logical mouse port is mapped to the physical mouse port. The second
state is the SWAP state. In this state, the logical ports are assigned
to the opposite physical ports. The logical keyboard port accesses the
physical mouse port directly and vice versa. The enhanced keyboard
controller supports both the DEFAULT and the
SWAP states.
Next, POST sets the Selector state to its DEFAULT setting (step 502). A
"READ ID" command is issued to the logical keyboard port (step 504).
Based on the ID returned, if any, a decision is made if there is in fact
a keyboard attached to the current logical keyboard port (step 506). The
test of step 506 is for a predetermined value returned as the first byte
of an ID word. If no keyboard is identified then the Selector bit is
tested to determine if it is in its SWAP state (step 508). If the
Selector bit is not in the SWAP state then both physical ports have not
yet been checked so the Selector bit is set to the SWAP state (step
510). With SWAP set the check for a keyboard is repeated.
If a keyboard is found in step (506) then the keyboard is tested (step
514). The result of the keyboard test is then checked (step 516). If the keyboard passes then the keyboard is initialized and marked as present
(step 518). The keyboard is marked present by storing its ID in the
extended BIOS data area (EBDA). If the check of the keyboard test in
step (516) indicates that the keyboard is not functioning correctly then
an error is reported (step 520).
If the Selector bit is set to SWAP in step 508 then a check for
keyboardless operation is made (step 512). If keyboardless operation is
not indicated by the system console parameter data then POST was
expected to find a keyboard and did not so an error is reported (step
520). If keyboardless operation was allowed from step (512) then the
procedure continues with no error.
The state of the SWAP bit is saved and called SWAPTMP (522). Next a READ
ID command is is sued to the logical mouse port (step 530). The ID, if
any, is then checked to determine if a mouse device is present (step
532). If a mouse is found then it is marked as present (step 534) and
POST then continues (step 542). An IBM or IBM-compatible mouse is
identified by a predetermined response, such as 0AAh followed by a value
of 00h. Any other pointing device can return any value as a second byte
as long as the first byte is 0xAA. If no mouse device was found in step
(532) then a check is made if a keyboard had been found previously (step
536). If a keyboard has been found then it is already occupying the
other physical port so no swap is necessary and POST is allowed to
continue (step 542). If step 536 does not indicate that a keyboard had
been previously found then the SWAP bit is compared against SWAPTMP
(step 538) and if found to be different then control is passed to step
(step 542) and POST continues. If step (538) determines that SWAP is
equal to SWAPTMP then this indicates that the other physical port still
needs to be checked for a mouse. The SWAP bit is toggled (step 540) and
control is routed to again check for a mouse.
To facilitate the service requirements POST always looks for and
initializes a keyboard if present. If keyboardless operation is
selected, POST suppresses a keyboard error when it occurs. The reason
for this is a defective keyboard may look like a missing keyboard to
POST. Since POST always tests for a keyboard, the system initializes the keyboard if present. Thus, a Customer Engineer can attach a keyboard to
service a machine that is configured as keyboardless.
To provide a mechanism where any system can be configured as
keyboardless, POST uses a bit in NVRAM to determine if keyboardless
operation is desired. The bit in NVRAM is set up by the set console
utility on the reference diskette. This bit in NVRAM is independent of
server configuration and independent of the ASCII Console support. Thus,
any system can be configured as keyboardless.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)