 |
Description  |
|
|
RELATED APPLICATIONS
This application is related to co-pending Ser. No. 08/145,400, now pending
filed Oct. 10, 1993, entitled "Method of and Apparatus for Disabling
Individual Slots on a Computer Bus," and to co-pending Ser. No.
08/145,339, filed Oct. 10, 1993, now pending entitled "Detecting the
Presence of a Device on a Computer System Bus by Measuring the Response
Time of Data Signals on the Bus, and Maximizing System Performance Based
on that Response Time," all of which have been assigned to the assignee of
this application.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to computer busing systems, and more particularly to
a method of and apparatus for determining the configuration and types of
boards installed on a computer bus.
2. Description of the Related Art
The microcomputer industry has experienced tremendous growth over the last
twenty years. From the days of its infancy when only a few interested
"hackers" could fathom its quirks and nuances, the microcomputer has now
evolved into a powerful business and personal tool found on virtually
every office desk and in virtually every home.
The microcomputer's road to success has not been without its problems,
however. While advances occur at an astounding pace, those advances must
accommodate the standards found in the then existing base of microcomputer
systems. This is known as upwards compatibility. To maintain such
compatibility, the industry has seen one microcomputer standard laid on
top of another, with a resulting hodgepodge of standards-within-standards
that designers must maintain to allow existing users to upgrade their
equipment. These multiple standards gradually shed their oldest layers,
replacing them with new layers reflecting the state-of-the-art. In this
way, only the very oldest microcomputer systems become obsolete.
One early idea to enhance microcomputer systems was the addition of
hardware enhancing boards. These boards were generally plugged into a
system bus to provide added functionality, such as telecommunications,
disk storage, and improved video. These boards obviously had to Conform to
some standard. With the introduction of the IBM PC by International
Business Machines Corp., and the later introduction of the PC/AT by IBM,
the AT system bus soon became a de facto standard known as the Industry
Standard Architecture bus, or the ISA bus. The AT bus accommodated both
the 8-bit boards of the PC and newer 16-bit boards developed for the AT.
Third-party manufacturers could economically design standard boards
compatible with the wide variety of IBM PC and AT compatible microcomputer
systems.
Further advances in microprocessor technology, however, pushed the ISA bus
to its limits. For this reason, another "layer" was added to the ISA bus
standard. This added layer became known as the Extended Industry Standard
Architecture bus, or the EISA bus. Boards designed for the EISA bus had
more pins, providing a wider data path for information to flow through the
microcomputer system bus, analogous to adding lanes to a highway. The EISA
bus also added more address lines to the standard, permitting more memory
locations to be individually specified, much as would adding more digits
to a phone number or a zip code.
One limitation of the ISA bus involved its method of handling I/O
addressing. An address enable signal (AEN) was driven low by an ISA bus
master to indicate to all of the cards that the currently asserted address
was an I/O address or a memory address rather than a direct memory access
(DMA) operation. But because AEN was asserted low to all cards, each card
had to be physically configured to respond to a different range of I/O or
memory addresses to avoid conflicts. This address differentiation was
usually accomplished when installing the boards by setting microswitches
on dual in-line packages (DIP) or by connecting jumpers on each board.
Improperly setting these switches could result in conflicts on a read or
write to a particular I/O or memory address and could even result in
physical hardware damage.
While the ISA standard provided 16 bits of I/O addressing, in developing
boards for PC-compatible computers, vendors often only used or decoded the
lower 10 bits. Thus, to be fully compatible with the available boards, the
I/O address space of the ISA bus effectively was only from 0 to 03FFh.
Thus, a large portion of the I/O space was unusable.
The EISA bus standard has resolved this problem to some extent. The EISA
bus definition provides for a conflict-free I/O address space for each
slot. This is fully described in U.S. Pat. No. 4,999,805 and the EISA
Specification, Version 3.1, which is Appendix 1 of U.S. Pat. No.
4,101,492, both of which are hereby incorporated by reference. The
expansion board manufacturers include a configuration file with each EISA
expansion board, and optionally, with switch programmable ISA products. A
configuration utility program provided by the system manufacturer uses the
information contained in the configuration files to determine a
conflict-free configuration of the system resources. The configuration
utility stores the configuration and initialization information into
non-volatile memory and saves a backup copy on diskette. Details of this
configuration process are provided in Ser. No. 07/293,315, U.S. Pat. No.
5,263,148 Nov. 16, 1993 entitled "Method and Apparatus for Configuration
of Computer System and Circuit Boards," allowed on May 10, 1993, which is
hereby incorporated by reference. The system ROM power up routines use the
initialization information to initialize the system during power up, and
device drivers use the configuration information to configure the
expansion boards during operation.
However, this slot specific addressing does not help with ISA boards. Slot
specific ISA board disabling can prevent such physical conflicts between
two boards during their initialization. Briefly, a mask register is
provided to mask off the AEN signal to selected slots. Details are
provided in Ser. No. 08/145,400 now pending entitled "Method of and
Apparatus for Disabling Individual Slots on a Computer Bus," filed
concurrently herewith, which is hereby incorporated by reference.
Further, the slot specific addressing is of no assistance with memory
operations, as the EISA bus standard does not provide for slot specific
memory spaces for ISA cards.
Determining what addresses that board responds to is not trivial. Unlike
EISA boards, ISA boards do not provide an identification register. Thus,
the occupied address space of an ISA board must be determined in some
other way.
It would be desirable to provide the functionality of EISA configuration
software for ISA boards. That is, it would be desirable for the system to
be able to determine what ISA boards were installed in which slots, and to
appropriately respond to any conflicts or mismapping of those devices.
Finally, it would be desirable to determine where an ISA board is mapped
in the address and memory space and to configure the system accordingly.
SUMMARY OF THE INVENTION
In a computer system constructed according to the invention, initialization
software determines whether an expansion board is present in a selected
slot and what input/output (I/O) addresses that selected expansion board
drives. The system first disables all the expansion slots except for the
one under test. The system then cycles through all the relevant I/O
addresses, creating a map of the I/O addresses to which an expansion board
in the enabled expansion slot responds. A response other than a normal
undriven bus value indicates an installed board in the enabled slot is
driving the data bus in response to a read from that I/O address. The
returned value is stored in the map. For each I/O address from which the
system reads a normally undriven bus response (0FFh in typical systems),
this is stored in the map as an "undriven" response for further testing.
The system further tests each address returning such an "undriven" response
to determine whether an installed board is actually driving the bus to
that normally undriven value. First, if the expansion slot under test
asserts certain bus control lines in response to an I/O read, that
indicates that an installed device is responding to that I/O read. If so,
that response is stored in the map.
If not, the system then analyzes the data line response time to an I/O read
at the address being tested. Specifically, the system measures how long
the data lines take to rise to an undriven state of 0FFh from an
artificially driven state of 00h. Hardware first drives the data lines to
zero at the beginning of an I/O read cycle. The hardware then times the
rise time of the data lines. Because the response time for a driven bus is
less than that for an undriven bus, a timer value less than the normal
response time indicates that a device is actually driving the normally
undriven value onto the data bus. Thus, the particular expansion slot
under test both contains an expansion board and that board is driving the
bus in response to a read from the I/O address under test.
In this way, the system creates a map of the I/O address locations used by
a board in a selected expansion slot and the actual response values of
that board. Configuration software then determines the actual board type
by comparing the I/O map with "signatures" compiled for various known
expansion boards. Once the board type and its address map are known, the
configuration software passes that information to an extended version of
EISA configuration software, which both sets up device drivers and
otherwise configures the system. Further, the EISA configuration software
determines whether there are any conflicts between the expansion boards
installed into the various slots of the system bus. If so, the EISA
configuration software can warn the user, can suggest to the user the
proper switch settings, or can even disable the board entirely.
Further according to the invention, a corresponding memory map of an ISA
board is created in a manner similar to that for creating an I/O address
map. The technique is similar, except memory "response time" need not be
checked to determine if a memory address is being driven, as instead, two
different predetermined values are written to that memory location and
then read back. If those values are properly stored, the corresponding
value will be returned on a read. If the values are not properly stored,
the read will return a value other than what was written on at least one
of the reads. This map is also then used by the configuration software.
BRIEF DESCRIPTION OF THE DRAWINGS
A better understanding of the present invention can be obtained when the
following detailed description of the preferred embodiment is considered
in conjunction with the following drawings, in which:
FIG. 1 is a block diagram of a computer system incorporating the method and
apparatus according to the invention;
FIG. 2 is a flowchart of configuration software that determines the system
configuration according to the invention;
FIGS. 3 and 4 are flowcharts of software used to implement the method
according to the invention;
FIGS. 5A and 5B are exemplary address maps created by the software of FIGS.
3 and 4; and
FIGS. 6 and 7 are schematics of the control line status latching circuitry
used according to the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Turning now to the drawings, FIG. 1 is a block diagram of a microcomputer
system 100 in which the method and apparatus according to the invention is
implemented. The microcomputer system 100 includes a host bus 102 and a
system bus 104. A microprocessor 106, memory 108, and a video subsystem
110 internally communicate at high speed with each other over the host bus
102. The host bus 102 is designed for speed rather than expansion, so the
host bus 102 has little, if any, provision for expansion boards.
A system bus controller 112 provides an interface between the host bus 102
and system bus 104. The system bus controller 112 is located on the system
board of the microcomputer system 100. The system bus controller 112 is
preferably implemented using an application specific integrated circuit
(ASIC) but could be implemented using discrete components.
The system bus 104 is typically an EISA bus, but could be another bus using
similar addressing protocols. The system bus controller 112 implements the
functions of an EISA bus controller. It is also within the system bus
controller 112 that the data bus response time circuitry according to the
invention is preferably implemented.
The system bus 104 consists of address lines 114, data lines 116, and
control lines 118. Connected to the system bus 104 is a system board slot
120. The system board slot 120 is not a separate physical connection, but
instead logically connects "devices" integrated into the system board of
the microcomputer system 100 itself to the system bus 104. Further
connected to the system bus 104 are slots 122. The slots 122 are physical
connectors for inserting expansion boards compatible with the standard of
the system bus 104 to provide the added functionality to the microcomputer
system 100. Shown inserted in the first, fifth, and seventh of the slots
122 are respectively a hard disk controller 124, a floppy disk controller
126, and a network interface board 128.
The lower byte of the data lines 116, denoted as SD[7..0], are pulled up by
pull-up resistors 117. These pull-up resistors 117 ensure that the
undriven data lines 116 return a value of 0FFh. The EISA standard
specifies that these pull-up resistors 117 should be 8.2 k ohm.
As is further discussed below, the pull-up resistors 117 can instead be
pull-down resistors. In such a case, the value returned by an I/O read of
an undriven data bus is then 00h instead of 0FFh.
Each device connected to the system bus 104, whether a device plugged into
one of the slots 122 or a system board device corresponding to the system
board slot 120, includes an individual slot specific address enable line
SSAEN[Z], where Z equals 0 to 7. These signals correspond to the AENx
signals of the EISA specification or AEN signal for ISA systems, but
further implementing slot specific disabling.
FIG. 2 is a flowchart of a routine CONFIG 400 that uses address maps
provided by a routine ADDRESS.sub.-- UTILIZATION 200, discussed below in
conjunction with FIGS. 3 and 4, to determine board presence and to check
for conflicts among the slots 122. Beginning at step 402, the routine
CONFIG 400 calls the routine ADDRESS.sub.-- UTILIZATION 200, retrieving an
address map for each of the slots 122, as is discussed below in
conjunction with FIGS. 5A and 5B. The routine CONFIG 400 then proceeds to
step 404, where it determines the presence or absence of an expansion
board in each of the slots 122.
This is done by checking the address map discussed below in conjunction
with FIGS. 5A and 5B to see if any address locations were responsive to
I/O reads when that particular slot 122 was enabled. That address map
preferably indicates the values read from each I/O address, the values on
the control lines 118 on a read from each I/O address, and the rise times
of the data lines 116 if the address otherwise appears unresponsive. Based
on these values, the address map also indicates whether the particular I/O
address is responsive. If all of the I/O addresses were indicated to be
unresponsive, then no ISA expansion board or EISA expansion board with ISA
functions occupies that particular slot 122.
The routine ADDRESS.sub.-- UTILIZATION 200 also determines the presence of
EISA boards in slots by reading from the EISA identification registers. If
an EISA board does in fact occupy a slot 122, the address maps discussed
above and below in conjunction with FIGS. 5A and 5B need not be checked,
as the EISA configuration registers both indicate board presence and
uniquely identify those expansion boards.
From step 404, the routine CONFIG 400 proceeds to step 406, where it
attempts to determine the board types and address spaces using signature
analysis routines. The system software includes a library of ISA boards
and their address space signatures. A "signature" is a definition of the
possible address spaces occupied by a board used to (hopefully) uniquely
identify both the functions on and the types of boards installed. For
example, a parallel port may return a unique configuration of bits on an
I/O read. That configuration is the "signature" of the parallel port
function on an expansion board. An expansion board implementing four such
ports might have four such parallel port "signatures" spaced four I/O
addresses apart each. Such parallel port "signatures" plus the port
spacings would then form that expansion board's signature. Each board may
have multiple signatures, in that each board may include more than one
logical device or function. In that case, the signature of the board would
represent more than a single device, and both of those determined
"devices" could be passed to further configuration software for
configuration of each of those devices. Using this library, the routine
determines the various ISA boards installed in the system.
From step 406, the routine CONFIG 400 then passes the identifications and
selected base addresses of the ISA boards, along with the identifications
of the installed EISA boards, to expanded EISA configuration software
EISA.sub.-- CONFIG at step 408. This EISA configuration software can
further resolve conflicts or inform the user of such conflicts, and can
complete the configuration of the system, including setting up the device
drivers to properly drive each installed board. This EISA configuration
software is more fully described in Ser. No. 07/293,315, U.S. Pat. No.
5,263,148, Nov. 16, 1993 entitled "Method and Apparatus for Configuration
of Computer System and Circuit Boards," which is hereby incorporated by
reference. That EISA configuration software relies on the board IDs
returned by the identification registers of EISA boards and on saved
configurations for ISA boards.
FIG. 3 is a flowchart of the routine ADDRESS.sub.-- UTILIZATION 200 that
determines both the presence of an expansion board in a slot 122 and, if
present, the particular addresses that device uses.
Beginning at step 202, the routine ADDRESS.sub.-- UTILIZATION 200 sets a
variable SLOT# equal to one. This variable corresponds to the specific
slot 122 under test on the system bus 104. Proceeding to step 204, the
routine enables the slot 122 that corresponds to SLOT# by writing to an
arbitrary I/O address P.sub.-- SSAEN used to disable the remaining slots
122. Writing zeros to all the bits of P.sub.-- SSAEN except the bit
corresponding to SLOT# prevents all of the slots 122 except SLOT# from
responding to any I/O operations. Even if enabled, the slot 122 SLOT# only
responds if a board is both installed and mapped to a particular I/O
address under test.
For example, if SLOT# equals 3, the routine writes 00001000b (08h) to I/O
address P.sub.-- SSAEN. A write to that address stores that value in a
mask register which then prevents the AENx signal from going low to the
disabled slots. This selective slot disabling is further described in Ser.
No. 08/145,400, (now pending) referenced above.
In the first time through the routine ADDRESS.sub.-- UTILIZATION 200, SLOT#
equals one, enabling the first of the slots 120. Because the designers of
the system 100 know the I/O address map of the system board slot 120, the
system startup software can skip mapping the system board slot 120 (SLOT#
equal to zero) and proceed straight to SLOT# equal to one.
Proceeding to step 205, the routine ADDRESS.sub.-- UTILIZATION 200
determines whether an EISA board is installed in the slot 120 SLOT#. This
is done by reading I/O addresses containing EISA board identification
information, as defined by the EISA Specification, Version 3.1, referenced
above. An EISA board need not be mapped because the identification
registers uniquely define that board. So, if an EISA board is detected,
the routine proceeds to step 206 where it saves that identification
information for later use by the EISA configuration software, and then to
step 222 to process the next slot 120.
If no EISA board is detected at step 205, the routine ADDRESS.sub.--
UTILIZATION 200 then proceeds to step 207, where it reads all significant
I/O addresses and stores the read values in an address map. In this
embodiment, the routine only needs to read I/O addresses an ISA expansion
board would use, or the address range 0100h to 03FFh. ISA systems only
effectively employ ten significant address bits SA[9..0] on the address
lines 114 of the system bus 104. Further, bits SA[9..8] equalling zero
corresponds to an ISA system board address in the system board slot 126 or
to an EISA address. ISA expansion boards should not respond to system
board addresses, so the routine need only examine those 10-bit addresses
in which SA[9..8] do not equal zero. The significant address range is
therefore 0100h to 03FFh. Addresses with bits SA[15..10] other than zero
are also disregarded, because in an ISA system these addresses are
generally considered to be aliases of the I/O addresses located in the ten
address bit expansion board range. Thus, by checking an address range of
0100h to 03FFh, the routine maps all I/O addresses used by an ISA board.
As noted above, addresses in which bits SA[9..8] equal zero can correspond
not only to ISA system board addresses but also to EISA addresses. Under
the EISA standard, EISA board addresses are handled through circuitry that
enables a specific slot enable SSAEN[X] when SA[9..8] equal zero, with X
corresponding to the four high order bits of the full 16-bit address, or
SA[15..12]. Thus, EISA devices installed in the slots 122 will not
conflict with each other because each slot 122 has its own separate EISA
address range.
In reading the significant addresses at step 206, the microprocessor 106
will read an 0FFh if no device is installed in the slot 122 under test or
if the device is not mapped to the I/O address read. This results from the
pull-up resistors 117 pulling the data lines 116 high. Conversely, reading
a value other than 0FFh indicates the slot 122 has an enabled device
mapped to the I/O address read. In such a case, the routine stores a
"true" flag in the address map indicating this I/O address is occupied by
a device in the slot 122 SLOT# under test. In either case, the data value
read is stored in the address map.
For simplicity, memory locations are not tested. Occupation of certain I/O
addresses alone should be enough to establish a unique signature for a
particular board under test. At that time, a memory check can be performed
if desired.
However, simply because an I/O read returns 0FFh does not mean that a
device in the slot 122 under test is not driving the data lines 116. A
device installed in the slot 122 may be driving the data lines 116 to the
normally undriven value of 0FFh. The routine ADDRESS.sub.-- UTILIZATION
200 later, at step 212, determines this by checking whether the device
under test asserts certain control lines in response to an I/O read from
the address under test and, if not, whether the response time of the data
lines 116 to an I/O read is quicker than the response time of an undriven
bus.
At step 208, the routine ADDRESS.sub.-- UTILIZATION 200 determines the
response time of the undriven data lines 116. First, the routine enables a
rise time measurement mode by writing an enabling bit to a status/control
register at an arbitrary I/O address P.sub.-- CTRLSTAT. The routine then
disables all of the slots 122 by writing 00h to P.sub.-- SSAEN. The
routine then reads from an ISA expansion board I/O address in rise time
measurement mode. This read operation is special as the data lines 116 are
first driven to zero and then a timer is started. The timer is stopped
upon the data lines 116 reaching predefined voltage levels or upon
reaching a predetermined timer value limit. In this case, because all
slots 122 are disabled, no installed device can respond. The routine then
reads the value of the timer from an arbitrary I/O address P.sub.-- TIMER.
This returns the rise time in HCLKs, or host bus 102 clock cycles, for a
read of an undriven I/O address after first driving the data bus to zero.
The hardware enabled by the rise time mode bit written to P.sub.--
CTRLSTAT performs the precharging of the data lines 116 to logic zero and
then the timing of the bus rise time to a value other than logic zero.
This hardware is preferably implemented in the system bus controller 112
in FIG. 1, and is further described in Ser. No. 08/145,339 (now pending)
entitled "Detecting the Presence of a Device on a Computer System Bus by
Measuring the Response Time of Data Signals on the Bus," which is hereby
incorporated by reference. This undriven data line 116 response time is
saved for later comparisons.
At step 210, the routine ADDRESS.sub.-- UTILIZATION 200 stores in an
address pointer variable ADDRPTR the next I/O address determined to be
"undriven". The first time through this inner loop, the first I/O address
is the first I/O address in the address map created at step 206 that
returned a normally undriven I/O read value of 0FFh. The routine 200 then
proceeds to step 212, where it checks for the assertion of control lines
118 in response to a read and checks the rise time of the data lines 116
during a read from the I/O address pointed to by ADDRPTR. This is done in
a routine CHECK.sub.-- PRESENCE 212, discussed below in conjunction with
FIG. 3.
Proceeding to step 214, if the routine CHECK.sub.-- PRESENCE 212 determined
a device actually drove 0FFh onto the data lines 116, then at step 216 the
routine ADDRESS.sub.-- UTILIZATION 200 stores a true value into a flag in
the address map that indicates the address was responsive to a read.
Otherwise, the routine ADDRESS.sub.-- UTILIZATION 200 instead proceeds to
step 218, where it stores a false value in that flag, indicating the
address was non-responsive to a read. That is, any device, if present, in
the slot 122 under test is not mapped to this address.
From both steps 216 and 218, the routine ADDRESS.sub.-- UTILIZATION 200
proceeds to step 220, where it determines whether any I/O addresses that
initially returned 0FFh remain in the address map. If so, the routine
proceeds again to step 210, where it stores the next "undriven" I/O
address in the map into ADDRPTR. If no such addresses remain, the routine
proceeds from step 220 to step 222.
At step 222, the routine ADDRESS.sub.-- UTILIZATION 200 determines whether
SLOT# equals MAXSLOT. In an EISA system, this could be up to 14, the
greatest number of non-system board slots EISA systems support. Because
the system designers actually know how many slots 122 are present in the
system 100 the designers can set MAXSLOT equal to the appropriate number
in the configuration software. This eliminates the mapping of slots 122
that are not present.
If SLOT# is not equal to MAXSLOT, the routine ADDRESS.sub.-- UTILIZATION
200 proceeds to step 224, where it increments SLOT#, and then proceeds to
step 204 to enable that next slot 122. The entire loop is repeated,
creating another address map of the I/O addresses to which a device in the
next slot 122 responds.
If at step 222 SLOT# equals MAXSLOT, then the routine ADDRESS.sub.--
UTILIZATION 200 is done checking for I/O address utilization and has
created its address maps, so it returns to the configuration software
CONFIG 400.
FIG. 4 is a flowchart of the routine CHECK.sub.-- PRESENCE 212. This
routine uses the rise time circuitry as shown and described in Ser. No.
08/145,339, (now pending) previously referenced, to determine the response
times of the data lines 116. This routine also uses latching circuitry
described in conjunction with FIGS. 6 and 7 to determine expansion board
presence.
The routine CHECK.sub.-- PRESENCE 212 begins at step 300 by enabling a
latching mode by writing a bit to the arbitrary port P.sub.-- CTRLSTAT
previously discussed. On an EISA or ISA system, some expansion boards
respond to I/O reads by asserting certain control lines among the control
lines 118. They may do so even if they drive the data bus to 0FFh. If
these control lines are asserted on an I/O read, the selected expansion
board of slot 122 is mapped to that I/O address, so no further testing
need be done. The hardware for implementing this latching mode is
described below in conjunction with FIGS. 6 and 7; it essentially latches
the values of certain control lines 118 at appropriate times in a I/O read
cycle.
At step 300, with the latching mode now enabled, the routine CHECK.sub.--
PRESENCE 212 then performs an I/O read from the address under test pointed
to by ADDRPTR. The routine then reads the arbitrary register P.sub.--
CTRLSTAT, which returns the latched values of the particular control lines
mentioned above. The routine then stores that returned value in the
address map.
Proceeding to step 304, the routine CHECK.sub.-- PRESENCE 212 examines the
latched value read at step 302 to see if an expansion board has driven the
control lines 118. If so, the routine proceeds to step 306, where it sets
a return parameter to true, indicating that a read from this address
results in a response from an expansion board in the slot 122 that is
enabled. The routine then returns that parameter at step 308.
If at step 304 it was determined that no expansion board asserted any of
the relevant control lines 118 in response to a read, the routine
CHECK.sub.-- PRESENCE 212 proceeds to step 310. Even though an expansion
board, if any, in the slot 122 under test failed to assert these lines,
this does not necessarily mean that an expansion board in the slot 122
under test is not driving the data lines 116 in response to a read from
the I/O address ADDRPTR. The routine at step 310 further determines
expansion board presence by enabling the rise time mode by writing a
particular bit to the arbitrary port P.sub.-- CTRLSTAT discussed above.
The routine then proceeds to step 312, where it checks the rise time of the
data lines 112 in response to a read from the address under test ADDRPTR.
This is accomplished by the hardware in Ser. No. 08/145,339, (now pending)
referenced above. To summarize, this hardware first drives the data lines
116 to 00h and then counts the number of HCLKs until one of those data
lines 116 changes to one. The routine then reads that timer at an
arbitrary I/O address P.sub.-- TIMER. As discussed in Ser. No. 08/145,339,
(now pending) the choice of using pull-up resistors 117 and driving an
initial value of 00h onto the data lines 116 is not the only way to
im | | |
