appliancerepairfirst

Motorola followed its 6800 family by leaping directly to a hybrid 16/32-bit
microprocessor architecture. Introduced in 1979, the 68000 is a 16-bit
microprocessor, due to its 16-bit ALU, but it contains all 32-bit registers and
a linear, nonsegmented 32-bit address space. (The original 68000 did not
bring out all 32 address bits as signal pins but, more importantly, there are no
architectural limitations of using all 32 bits.) That the register and memory
architecture is inherently 32 bits made the 68000 family easily scalable to
a full 32-bit internal architecture. Motorola upgraded the 68000 family with
true 32-bit devices, including the 68020, 68040, and 68060, until switching
to the PowerPC architecture in the latter portion of the 1990s for new
high-performance computing applications. Apple Computer used the 68000
family in their popular line of Macintosh desktop computers. Today, the
68000 family lives on primarily as a mid-level embedded-processor core
product. Motorola manufacturers a variety of high-end microcontrollers
that use 32-bit 68000 microprocessor cores. However, in recent years
Motorola has begun migrating these products, as well as their general-purpose
microprocessors, to the PowerPC architecture, reducing the number of new
designs that use the 68000 family.

The 68000 inherently supports modern software operating systems (OSs)
by recognizing two modes of operation: supervisor mode and user mode.
A modern OS does not grant unlimited access to application software in
using the computers resources. Rather, the OS establishes a restricted
operating environment into which a program is loaded. Depending on the
speci?c OS, applications may not be able to access certain areas of memory
or I/O devices that have been declared off limits by the OS. This can prevent
a fault in one program from crashing the entire computer system. The OS
kernel, the core low-level software that keeps the computer running properly,
has special privi- leges that allow it unrestricted access to the computer for
the purposes of establishing all of the rules and boundaries under which
programs run. Hardware support for multiple privilege levels is crucial for
such a scheme to prevent unauthorized programs from freely accessing restricted
resources. As microprocessors developed over the last few decades, more
hardware support for OS privileges was added. That the 68000 included such
concepts in 1979 is a testimony to its scalable architecture.

Sixteen 32-bit general-purpose registers, one of which is a user stack pointer
(USP), and an 8-bit condition code register are accessible from user mode as
shown in Fig. 6.11. Additionally, a supervisor stack pointer (SSP) and eight
additional status bits are accessible from supervisor mode. Computer systems
do not have to implement the two modes of operation if the application does
not require it. In such cases, the 68000 can be run permanently in supervisor
mode to enable full access to all resources by all programs. The SSP is used
for stack operations while in supervisor mode, and the USP is used for stack
operations in user mode. User mode programs cannot change the USP,
preventing them from relocating their stacks. Most modern operating systems
are multitasking, mean- ing that they run multiple programs simultaneously. In
reality, a microprocessor can only run one program at a time. A multitasking
OS uses a timer to periodically interrupt the microprocessor, perhaps 20 to
100 times per second, and place it into supervisor mode. Each time supervisor
mode is invoked, the kernel performs various maintenance tasks and swaps
the currently running program with the next program in the list of running programs.
This swap, or context switch, can entail substantial modi?cations to the
microprocessors state when it returns from the kernel timer interrupt. In the
case of an original 68000 microprocessor, the kernel could change the return
value of the PC, USP, the 16 general-purpose registers, and the status register.
When normal execution resumes, the microprocessor is now executing a
different program in exactly the same state at which it was previously interrupted,
because all of its registers are in the same state in which they were left. In such a
scenario, each program has its own private stack, pointed to by a
kernel-designated stack pointer.

The eight data registers, D0D7, can be used for arbitrary ALU operations. The
eight address registers, A0A7, can all be used as base addresses for indirect
addressing and for certain 16- and 32-bit ALU operations. All 16 registers can
be used as index registers. While operating in user mode, it is illegal to access
the SSP or the supervisor portion of the status register, SR. Such instructions will
cause an exception, whereby a particular interrupt is asserted, which causes the
68000 to enter supervisor mode to handle the fault. (Exception and interrupt are
often used synonymously in computer contexts.) Very often, the OS kernel will
terminate an application that causes an exception to be generated. The registers
shown above are present in all 68000 family members and, as such, are
software is compatible with subsequent 68xxx microprocessors. Newer
microprocessors contain additional registers that provide more advanced privilege
levels and memory management. While the 68000 architecture fundamentally
supports a 4-GB (32-bit) address space, early devices were limited in terms
of how much physical memory could actually be addressed as a result of pin
limitations in the packaging. The original 68000 was housed in a 64-pin DIP,
leaving only 24 address bits usable, for a total usable memory space of 16 MB.
When Motorola introduced the 68020, the ?rst fully 32-bit 68000 microprocessor,
all 32 address bits were made available. The 68000 devices are big-endian,
so the MSB is stored in the lowest address of a multibyte word.

Figuur 6.11 68000 register set.

The 68000 supports a 16-MB address space, but only 23 address bits, A[23:1],
are actually brought out of the chip as signal pins. A[0] is omitted and is unnecessary,
because it would specify whether an even (A[0] = 0) or odd (A[0] = 1) byte is
being accessed; and, because the bus is 16 bits wide, both even and odd bytes
can be accessed simultaneously. However, provisions are made for byte-wide
accesses in situations where the 68000 is connected to legacy eight-bit peripherals
or memories. Two data strobes, upper (UDS*) and lower (LDS*), indicate
which bytes are being ac- cessed during any given bus cycle. These strobes are
generated by the 68000 according to the state of the internal A0 bit and
information on the size of the requested transaction. Bus transactions are
triggered by the assertion of address strobe (AS*), the appropriate data strobes,
and R/W* as shown in Fig. 6.12. Prior to AS*, the 68000 asserts the desired
address and a three-bit function code bus, FC[2:0]. The function code bus
indicates which mode the processor is in and whether the transaction is a
program or data access. This information can be used by external logic to
qualify transactions to certain sensitive memory spaces that may be off limits
to user programs. When read data is ready, the external bus interface logic
asserts data transfer acknowledge (DTACK*) to inform the microprocessor
that the transaction is complete. As shown, the 68000 bus can be operated in
a fully asyn-chronous manner. When operated asynchronously, DTACK* is
removed after the strobes are removed, ensuring that the 68000 detected the
assertion of DTACK*. If DTACK* is removed prior to the strobes, there
is a chance of marginal timing where the 68000 may not properly detect the
acknowledge, and it may wait forever for an acknowledge that has now
passed. Writes are very similar to reads, with the obvious difference that
R/W* is brought low, and data is driven by the 68000. Another difference
is that the data strobe assertion lags that of AS*.

Figuur 6.12 68000 asynchronous bus timing.

Advanced microprocessors such as the 68000 are designed to recognize fault
conditions wherein the requested bus transaction cannot be completed. A bus
fault can be caused by a variety of problems, including unauthorized access
(e.g., user mode tries to write to a protected supervisor data space) or an
access to a section of memory that is not ?lled by a memory or peripheral
device. Software should never access areas of memory that are off limits,
because the results are unpredictable. Therefore, rather than simply issuing
a false DTACK* and continuing with normal operation, the 68000 contains
a bus error signal (BERR*) that behaves like DTACK* but triggers an
exception rather than continuing normal execution. It is the responsibility of
external logic to manage the DTACK* and BERR* signals according to
the speci?c con?guration and requirements of the particular system.

Operating the 68000 bus in an asynchronous manner is easy, but it reduces
its bandwidth, because delays must be built into the acknowledge process to
guarantee that both the 68000 and the interface logic maintain synchronization.
Figuur 6.12 shows read data being asserted prior to DTACK* and an
arbitrary delay between the release of AS* and that of DTACK*. The data
delay is necessary to guar- antee that the 68000 will see valid data when it
detects a valid acknowledge. The second delay is necessary to ensure that
the 68000 completes the transaction, as noted previously. These delays can
be eliminated if the bus is operated synchronously by distributing the
microprocessor clock to the interface logic and guaranteeing that various
setup and hold timing requirements are met as speci?ed by Motorola. In
such a con?guration, it is known from Motorolas data sheet that the
68000 looks for DTACK* each clock cycle, starting at a ?xed time after
asserting the strobes, and then samples the read-data one cycle after detecting
DTACK* being active. Because synchronous timing rules are obeyed,
it is guaranteed that the 68000 properly detects DTACK* and, therefore,
DTACK* can be removed without having to wait for the removal of the
strobes. 68000 synchronous bus timing is shown in Fig. 6.13, where each
transaction lasts a minimum of four clock cycles. A four-cycle transaction
is a zero wait state access. Wait states can be added by simply delaying
the assertion of DTACK* to the next cycle. However, to maintain proper
timing, DTACK* (and BERR* and read-data) must always obey proper
setup and hold requirements. As shown in the timing diagram, each
signal transition, or edge, is time-bounded relative to a clock edge.

Read timing allows a single clock cycle between data strobe assertion and the
return of DTACK* for a zero wait-state transaction. However, zero wait-state
writes require DTACK* assertion at roughly the same time as the data strobes.
Therefore, the bus interface logic must make its decision on asserting DTACK*
based on the requested address when AS* is asserted. If the requested device
is operational, DTACK* can be immediately asserted for a fast transaction.
Unlike reads, where the microprocessor must wait for a device to return data,
writes can be acknowledged before they are actually transferred to the device.
In such a scheme, writes are posted within the bus interface logic.

One or two cycles later, when the device accepts the posted write data, the
bus interface logic ?nally completes the transaction without having delayed
the microprocessor. If completion of the posted- write transaction takes
longer than a few cycles, it could force a subsequent access to the same
device to incur wait states. Either a read or a write would be blocked
until the original write was able to complete, thus freeing the device to
handle the next transaction.

Figuur 6.13 68000 synchronous bus timing.

In addition to the basic bus interface, the 68000 supports bus arbitration to
enable DMA or other logic to use the microprocessor bus for arbitrary applications.
A bus request (BR*) signal is asserted by a device that wants to temporarily gain
control of the bus. On the next clock cycle, when the microprocessor is not
inhibited by other operations, it asserts a bus grant (BG*) signal and places its
address, data, and control signals into tri-state so that they may be driven by the
other device. The re- questing device then asserts bus grant acknowledge
(BGACK*) to signal that it is controlling the bus, and it is then free to assert
its own strobes, address, and data signals.

A variety of interrupts and exceptions are supported by the 68000. Some are
triggered as a result of instruction execution and some by external signals (e.g.,
BERR* or an interrupt request). Examples of instruction exceptions are illegal
user mode register accesses or a divide-by-zero error. Most microprocessors
that provide division capability contain some type of divide-by-zero error
handling, because the result of such an operation is mathematically unde?ned
and is usually the result of a fault in the program. The 68000 contains an
exception vector table that is 1,024 bytes long and resides at the beginning
of memory at address 0. In a multitasking system, the bus interface logic may
restrict access to the vector table to supervisor mode only. In such a case, a
bus error could be triggered if a user mode program, indicated by FC[2:0],
tried to write the table. Each of the 256 vector entries is four bytes long
and provides the starting address of the associated ISR. The one deviation
from this rule is the reset vector, which actually consists of two entries at word
addresses 0 and 4.

Upon reset, the 68000 fetches an initial PC value from address 4 and an initial
SSP value from address 0. Vectors 0 through 63 are assigned or reserved by
Motorola for various hardware exceptions. Vectors 64 through 255 are
assigned as user interrupt vectors. Like other microprocessors in its category,
the 68000 supports bus vectoring of user interrupts where an external interrupt
controller asserts an interrupt number onto the data bus during an interrupt
acknowledge cycle performed by the 68000 in response to an interrupt
request. This interrupt number is multiplied by four and used to index into
the exception table to fetch the address of the appropriate ISR.

door : E-book Complete_Digital_Design

Intel moved up to a 16-bit microprocessor, the 8086, in 1978 just two years after
introducing the 8085 as an enhancement to the 8080. The x86 family is famous
for being chosen by IBM for their original PC. As PCs developed during the
past 20 years, the x86 family grew with the industry ?rst to 32 bits (80386,
Pentium) and more recently to 64 bits (Itanium). While the 8086 was a new
architecture, it retained certain architectural characteristics of the 8080/8085
such that assembly language programs written for its predecessors could be
converted over to the 8086 with little or no modi?cation. This is one of the
key reasons for its initial success.

The 8086 contains various 16-bit registers as shown in Fig. 6.9, some of which
can be manipu- lated one byte at a time. AX, BX, CX, and DX are
general-purpose registers that have alternate functions and that can be treated
as single 16-bit registers or as individual 8-bit registers. The accumulator,
AX, and the ?ags register serve their familiar functions. BX can serve as a
general pointer. CX is a loop iteration count register that is used inherently
by certain instructions. DX is used as a companion register to AX when
performing certain arithmetic operations such as integer division or handling
long integers (32 bits).

The remaining registers are pointers of various types that index into the 8086s
somewhat awk- ward segmented memory structure. Despite being a 16-bit
microprocessor with no register exceeding 16 bits in size, Intel recognized the
need for more than 64 kB of addressable memory in more advanced computers.
One megabyte of memory space was decided upon as a suf?ciently large
address space in the late 1970s, but the question remained of how to access
that memory with 16-bit pointers. Intels solution was to have programmers
arbitrarily break the 1 MB address space into multiple 64-kB special-purpose
segments one for instructions (code segment), two for data (primary data and
extra data), and one for the stack. Memory operations must reference one
of these de?ned segments, requiring only a 16-bit pointer to address any
location within a given segment. Segments can be located anywhere in memory,
as shown in Fig. 6.10, and can be moved at will to provide ?exibility for
different applications. Additionally, there is no restriction on overlapping of
segments.

Each segment register represents the upper 16 bits of a 20-bit pointer
(2²⁰ = 1 MB) where the lower 4 bits are ?xed at 0. Therefore, a segment register
directly points to an arbitrary location in 1 MB of memory on a 16-byte boundary.
A pointer register is then added to the 20-bit segment address to yield a ?nal
20-bit address, the effective address, with which to fetch or store data.
Algebraically, this relationship is expressed as: effective address =
(segment pointer ? 16) + offset pointer.

Figuur 6.9 8086 register set.

Figuur 6.10 8086 segments.

Inside the microprocessor, this math is performed by shifting the segment pointer
(0×135F) left by four bits and then adding the offset pointer (0×0102) as
shown below.

This segmented addressing scheme has some awkward characteristics. First,
programs must orga- nize their instructions and data into 64-kB chunks and
properly keep track of which portions are be- ing accessed. If data outside
of the current segments is desired, the appropriate segment register must be
updated. Second, the same memory location can be represented by multiple
combinations of segment and offset values, which can cause confusion in sorting
out which instruction is accessing which location in memory. Nonetheless,
programmers and the manufacturers of their development tools have ?gured
out ways to avoid these traps and others like them.

Instructions that reference memory implicitly or explicitly determine which
offset pointer is added to which segment register to yield the desired effective
address. For example, a push or pop instruction inherently uses the stack
pointer in combination with the stack segment register. However, an instruction
to move data from memory to the accumulator can use one of multiple pointer
registers relative to any of the segment registers.

The 8086s reset and interrupt vectors are located at opposite ends of the
memory space. On reset, the instruction pointer is set to 0xFFFF0, and the
microprocessor begins executing instructions from this address. Therefore,
rather than being a true vector, the 16-byte reset region contains normal
executable instructions. The interrupt vectors are located at the bottom of
the memory space starting from address 0, and there are 256 vectors, one
for each of the 256 interrupt types. Each interrupt vector is composed of a
2-byte segment address and a 2-byte offset address, from which a 20-bit
effective address is calculated. When the 8086s INTR pin is driven high,
an interrupt acknowledge process begins via the INTA* output pin. The
8086 pulses INTA* low twice and, on the second pulse, the interrupting
peripheral drives an interrupt type, or vector number, onto the eight lower
bits of the data bus. The vector number is used to index into the interrupt
vector table by multiplying it by 4 (shifting left by two bits), because each vector
consists of four bytes. For example, interrupt type 0×03 would cause the
microprocessor to fetch four bytes from addresses 0×0C through 0×0F.
Interrupts triggered by the INTR pin are all maskable via an internal control bit.
Software can also trigger interrupts of various types via the INT instruction.
A nonmaskable interrupt can be triggered by external hardware via the NMI
pin. NMI initiates the type-2 interrupt service routine at the address indicated
by the vector at 0×08-0×0B.

Locating the reset boot code at the top of memory and the interrupt vectors at
the bottom often leads to an 8086 computer architecture with ROM at the top
and some RAM at the bottom. ROM must be at the top, for obvious reasons.
Placing the interrupt vector table in RAM enables a ?exible system in which
software applications can install their own ISRs to perform various tasks. On
the original IBM PC platform, it was not uncommon for programs to insert their
own ISR addresses into certain interrupt vectors located in RAM. The system
timer and keyboard interrupts were common objects of this activity. Because
the PCs operating system already implemented ISRs for these interrupts, the
program could redirect the interrupt vector to its own ISR and then call the
systems default ISR when its own ISR completed execution. If properly done,
this interrupt chaining process could add new features to a PC without harming
the existing housekeeping chores performed by the standard ISRs. Chaining
the keyboard interrupt could enable a program that is normally dormant to
pop up each time a particular key sequence is pressed.

Despite its complexity and 16-bit processing capability, the 8086 was originally
housed in a 40-pin DIP the same package used for most 8-bit processors of the
time. Intel chose to use a multiplexed address/data scheme similar to that used
on the 8051 microcontroller, thereby saving 16 pins. The 8086s 20-bit address
bus is shared by the data bus on the lower 16 bits and by status ?ags on the
upper 4 bits. Combined with additional signals, these status ?ags control the
microprocessors bus interface. As with Intels other microprocessors, the 8086
contains separate address spaces for memory and I/O devices. A control pin
on the chip indicates whether a transaction is memory or I/O.

While the memory space is 1 MB in size, the I/O space is only 64 kB. The
8086 bus interface oper- ates in one of two modes, minimum and maximum,
determined by a control pin tied either high or low, respectively. In each of
these two modes, many of the control and status pins take on different functions.
In minimum mode, the control signals directly drive a standard Intel-style bus
similar to that of the 8080 and 8051, with read and write strobes and address
latch enable. Other signals include a READY signal for inserting wait states for
slow peripherals and a bus grant/acknowledge mechanism for supporting DMA
or similar bus-sharing peripherals. Minimum mode is designed for smaller
systems in which little address decoding logic is necessary to interface the 8086
to memory and peripherals devices. Maximum mode is designed for larger
systems where an Intel companion chip, the 8288 bus controller, integrates
more complex bus control logic onto an off-the-shelf IC. In maximum mode,
certain status and control pins communicate more information about what type
of transaction is being performed at any given time, enabling the 8288 to take
appropriate action.

The 8086s 16-bit data bus is capable of transacting a single byte at a time for
purposes of access- ing byte-wide peripherals. One early advantage of the 8086
was its backward bus compatibility with the 8080/8085. In the 1970s, Intel
manufactured a variety of I/O peripherals such as timers and parallel I/O
devices for their eight-bit microprocessors. The 8086s ability to perform
byte-wide trans- actions enabled easy reuse of existing eight-bit peripheral
products. Two signals, byte high enable (BHE*) and address bit zero (A[0]),
communicate the width and active byte of each bus transaction as shown in
Table 6.3.

Intels microprocessors follow the little-endian byte ordering convention.
Little-endian refers to the practice of locating the LSB of a multibyte quantity in
a lower address and the MSB in a higher address. In a little-endian 16-bit
microprocessor, the value 0×1234 would be stored in memory by locating 0×12
into address 1 and 0×34 into address 0. Big-endian is the opposite: locating the
LSB in the higher address and the MSB in the lower address. Therefore, a
big-endian 16-bit microprocessor would store 0×12 into address 0 and 0×34
into address 1. To clarify the difference, Table 6.4 shows little-endian versus
big-endian for 16- and 32-bit quantities as viewed from a memory chips
perspective. Here, ADDR represents the base address of a multibyte data
element.

Proponents of little-endian argue that it makes better sense, because the low
byte goes into the low address. Proponents of big-endian argue that it makes better
sense, because data is stored in memory as you would read and interpret it. The
choice of endianness is rather religious and comes down to personal preference.
Of course, if you are designing with a little-endian microprocessor, life will be
made simpler to maintain the endianness consistently throughout the system.

At the time of the 8086s introduction, 16-bit desktop computer systems were
almost unheard of and could be substantially more expensive than 8-bit systems
as a result of the increased memory size required to support the larger bus. To
alleviate this problem and speed market acceptance of its architecture, Intel
introduced the 8088 microprocessor in 1979, which was essentially an 8086
with an eight-bit data bus. A lower-cost computer system could be built with the
8088, because fewer EPROM and RAM chips were necessary, system logic
did not have to deal with two bytes at a time, and less circuit board wiring was
required. A tremendous bene?t to Intel in designing the 8088 was the fact
that it was chosen by IBM as the low-cost 16-bit heart of the original PC/XT
desktop computer, thereby locking the x86 microprocessor family into the
IBM PC architecture for decades to come.

A variety of companion chips were developed by Intel to supplement the
8086/8088. Among these was the 8087 math coprocessor that enhanced the 8086s
computational capabilities with ?oating-point arithmetic operations. Floating-point
arithmetic refers to a computers handling of real numbers as compared to integers.
The task of adding or multiplying two real numbers of arbitrary magnitude is far
more complex than similar integer operations. Certain applications such as scienti?c
simulations and realistic games that construct a virtual reality world make signi?cant
use of ?oating-point operations. The 8087 is a coprocessor rather than a peripheral,
because it sits on the microprocessor bus in parallel with the 8086 and watches for
special ?oating-point instructions.

These instructions are then executed automatically by the 8087 rather than having
to wait for the 8086 to request an operation. The 8086 was designed with the 8087s
existence in mind and ignores instructions destined for the 8087. Therefore, software
must speci?cally know if a math coprocessor is installed to run correctly. Many
programs that ran on older systems with or without a coprocessor would ?rst test
to see if the coprocessor was installed and then execute either an optimized set of
routines for the 8087 or a slower set of routines that emulated the ?oating-point
operations via conventional 8086 instructions.

As the x86 family developed, the optional math coprocessor was eventually
integrated alongside the integer processor on the same silicon chip. The 8087 gave
way to the 80287 and 80387 when the 80286 and 80386 microprocessors were
produced. When Intel introduced the 80486, the coprocessor, of ?oating-point
unit (FPU), was integrated on chip. This integration resulted in a somewhat more
expensive product, so Intel released a lower-cost 80486SX microprocessor
without the coprocessor. An 80487SX was made available to upgrade systems
originally sold with the 80486SX chips, but the overall situation proved
somewhat chaotic with various permutations of microprocessors and systems
with and without coprocessors. Starting with the Pentium, all of Intels high-end
microprocessors contain integrated FPUs. This trend is not unique to Intel.
High-performance microprocessors in general began integrating the FPU at
roughly the same time because of the performance bene?ts and the overall
simplicity of placing the microprocessor and FPU onto the same chip.

door : E-book Complete_Digital_Design

Modems can be troublesome. If you have a telephone communications problem, there are a number of things you can do to check to see if the modem is working.

Here is a list of places in Windows where you can check to see whether a modem is working:

1. 
   

   Modem Properties in Device Manager, General page: If you see a message that indicates a problem, the modem might need to be reinstalled or replaced. Follow the directions or from the modem manufacturer to reinstall the driver.

   
   
2. 
   

   Query Modem: Go to Modem Properties from either Control Panel or Device Manager and click the Diagnostics tab if one is present. Then, click the Query Modem button and wait for the report. If the last couple entries in the report indicate OK, the query hasn’t detected a problem. You will often see the line “COMMAND NOT SUPPORTED” at one point in the report. You can ignore this.

   
   
3. 
   

   HyperTerminal: Go to Start > Programs (or All Programs) > Accessories > Communications > HyperTerminal, if it is installed. You will be prompted to set up a connection. Give it a simple name; you won’t be saving it. Figuur 8.9 shows this page.

   
   

   
   Figure 8.9: Naming a HyperTerminal connection.

Then, enter a single-digit telephone number. Make sure your modem is listed in the Connect using box. Click OK and you will be prompted to dial the number you entered. Click Cancel. You will see a blank HyperTerminal window. Type “AT” and then press . A working modem should respond with “OK,” as shown in Figure 8.10. Then, you can close HyperTerminal and elect not to save the connection.

Figure 8.10: Autodetecting the modem in HyperTerminal.

It is also a good idea to test a suspect modem with every function in which it can be used on the computer. This is to rule out the possibility that a program, rather than the modem, is malfunctioning. For example, if a modem works with faxing and Phone Dialer (Start > Programs (or All Programs) > Accessories > Communications > Phone Dialer), but not on the Internet, it is likely that the problem is in the Internet software or service rather than with the hardware.

It is unfortunately common to get certain numbered error messages such as 619 of 693 when trying to connect using a modem. You might try several times in a row and get several different error messages. Often, these error messages bear no relationship to the truth. When you get one of these, first attempt to rule out the problem that the message indicates, assuming you can understand the message. The problem could be as simple as a bad telephone cord, the Caps Lock being on and altering the password, or that the telephone line is in use. Other possibilities include problems with the remote computer or service, or incorrect password or username. If the computer locks up every time you try to connect, you probably have a resource conflict. See Chapter 2 for information on resolving it.

Once you have ruled these out, the next step is to reboot the computer, especially if you have a laptop. With some laptops, a design flaw causes certain functions not to work after the computer comes out of standby or hibernation. Rebooting might solve other problems as well. If none of these steps works, delete the connection and recreate it. If you still have the problem, it is time to try new hardware. Swap the modem for a known good unit and retry the connection. This is the perfect time to try an external modem if you have one. If you still can’t connect, and the modem is removable, try it in another system.

If a built-in modem on a laptop fails and you have reinstalled the driver to no avail, unless the laptop is under warranty, your only recourses are to install a PC-Card modem or use an external serial or USB modem. You might want to disable the built-in modem in the BIOS, if such a setting exists. Note, however, that sometimes seemingly permanent modem failures can occasionally resolve themselves over time.

door : Book-PC Repair and Maintenance: A Practical Guide