PC Diagnostics '95

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

Copyright (c) Craig Hart

Welcome to PC Diagnostics '95!


> Start here

*DISCLAIMER*

This program is written with the target audience being a trained, experienced
technician. It is *NOT* designed to be used by those ignorant of computer
servicing. Displays are not 'pretty' but functional. Information is not
explained since we are not trying to educate. This software should be
considered to be just like any other tool in a tech's toolbox. It is to be
applied with care, in the right situation, in order to find answers to specific
problems. If you are an end user who is less than confident of dealing with
computer hardware, this is probably not a program for you.

Since full documentation hasn't yet been written (But I'm making progress
now!), please start by reading the first part of this file carefully. It WILL
answer 99% of your questions. Also check DIAGS.FAQ to see if answers to your
questions are in there. If not, then you should email me with your question.

I try to answer all serious emails although I should not be taken for a free
hardware repair assistance service; I will not respond to requests for
fault-finding assistance or what to do when diags reports something. If you do
not understand what you see, I strongly recommend you seek the assistance of a
qualified, experienced computer technician; your local retailer should have a
fully equipped workshop backing them up (If not, I suggest you seek a retailer
that does).




> History behind PC Diagnostics '95

PC Diagnostics '95 (hereon referred to as "Diags") was originally written to
accompany a POST Diagnostic card that was sold on the Australian market around
1995-96.

For those of you that don't already know, a POST card is a piece of hardware
that you plug into the ISA bus on a motherboard. It then displays various codes
during a machine's POST (Power On Self Tests). The idea behind a POST card is
that it can help pinpoint errors that occurs without a video card (or before
the video card is initialized) or RAM fitted to the motherboard. Because a
'bare' motherboard + CPU can be tested (to an extent, but not thoroughly) by the
POST, the POST is very good at deciding what's faulty - the board itself or the
parts being plugged into it.

Because each POST code as a specific test associated with it, one can directly
relate a 'hang a POST code xx' to a specific form of hardware failure, as long
as you have the 'magic list' of what each post code represents. Typically, each
BIOS vendor has their own set of meanings for their brand of BIOS... many
vendors also have multiple sets of tables for the different generations of
their BIOS.

In practice, however, POST cards are of very limited value since nobody repairs
a faulty motherboard; the service world operates on a 'swap out the whole
thing' mentality (partly due to the very high scale of integration found on
modern motherboards) so the only value a POST card has is to confirm a
technician's suspicion that the motherboard itself is actually bad - a check
that takes most techs under 30 seconds.

Anyhow, DIAGS was supposed to add value to the hardware product by providing
better tests than those present in most POST's, as well as outputting it's own
collection of codes to the POST card.

The POST card is long dead in that you can no longer buy one (although I still
own one), however I never removed the code that outputs to the POST card. Any
POST card (such as those made by Micro 2000) can still be used to display the
codes DIAGS outputs. Simply monitor port 80h (The standard POST I/O port).
Those of you with POST cards can thus make use of this feature. Note, however,
that addition of new codes to DIAGS was discontinued many versions ago, so many
tests have no associated code. Those codes that ARE outputted are listed at the
end of this document, along with extra information on how to cope with the
errors associated with these codes.

DIAGS does NOT *REQUIRE* the presence of a POST card, and will function 100%
without one; just ignore the references to POST cards found throughout the
manual and in the software.





> How to run the program

Only run this program after a plain boot. That means you need to start the
computer in one of these ways:

MS-DOS 5.0 or earlier
Make a DOS Boot disk with no config.sys or autoexec.bat files.
This program probably requires at least DOS 3.3, but I have not checked.

MS-DOS 6.xx
Press F5 at 'Starting MS-DOS...' prompt to arrive at a command prompt
without autoexec.bat or config.sys bieng processed.

Windows 95/98
Press F8 at 'Starting Windows 95...' prompt (Before clouds logo appears)
and select 'Safe mode, command prompt only'.

OS/2, Windows NT, Linux
DIAGS Will not run under there OS's at all. Make an MS-DOS boot disk and
boot the system from that. (See MS-DOS 5.0).

IBM-DOS, DR-DOS, Open-DOS, etc.
I have not tested DIAGS under these OS's. I'd expect DIAGS to work as
long as the same guidelines as per MS-DOS 5.0 are followed.

Failure to boot into a 'clean' environment will mean that DIAGS either will not
run at all, or will give false errors and possibly crash at random. Diags
attempts to recognize programs it is known to be incompatible with and will
refuse to run. These programs include: HIMEM.SYS, EMM386.EXE, DesqView, MS-DOS
Task Manager, Windows 3.x/WFW/95/98/NT and OS/2.



> Up and Running

The FIRST TIME ONLY you start DIAGS, you will be asked to register the program.
Enter your name and company name (one space+enter to leave a field blank). Any
info may be entered here; there are no 'magic numbers' to be entered and the
software will behave exactly the same no matter what is entered. This only
happens the FIRST time you run DIAGS; your registration details are appended to
the end if DIAGS.EXE and are thus stored permanently. This is the *ONLY* time
any part of DIAGS will write to any disk. You may safely write protect any
floppies DIAGS is run from without complaint after the rego details are stored.

After displaying the registration details DIAGS displays a test pattern to the
POST card to verify that it is working properly. Check your POST card is
working, or if you don't have a POST card, simply press any key to move onto
the main menu.

Once DIAGS displays the main menu, press space to (dis)able a test group,
arrows to navigate the menu, + and - to change screen size on EGA/VGA equipped
PC's, enter to start a test group and ESC to exit the program. Help and status
information on the current activity is always found on the statusbar at the
bottom of the screen.




> Caveats, cautions, restrictions, upgrades and "gotchas".

It is normal for external loopback tests of the serial and parallel ports to
fail unless you have manufactured special loopback plugs (see the DIAGS95.FAQ
to find out how to build your own loopbacks).

DIAGS is not perfect. We have an ongoing commitment to make DIAGS THE most
accurate and up to date product on the market, bar none. It is, however,
impossible to cater for every non-standard piece of equipment out there;
therefore ALL diagnostic packages have known (and unexpected) limitations,
DIAGS included.

DIAGS has one current known fault that cannot be fixed in software alone. Due
to what we feel is an oversight by the designers at Cyrix, it is impossible to
detect a Cyrix 6x86 CPU in a manner that is totally crash-proof. There exists a
possibility of crashing a M/B that has a non-Cyrix compatible chipset (ie uses
I/O port 22h & 23h - anything with an 82C212 for example is a known problem
chip). DIAGS will only ever crash on 486 type boards, with these faulty
chipsets. DIAGS will halt at POST code 12, when running the CPU Type check at
startup. In this case, you may supply DIAGS the X parameter to disable Cyrix
6x86 detection code. (Ie enter DIAGS X at the commandline), or by setting the
686 option in diags.ini to no (read diags.ini for more info). The Cyrix M2 CPU
fixes this fault by having CPUID enabled by default at power-on.




> Other Limitations

At the moment, the RAM tester isn't as good as some. It won't work over 64Mb of
RAM (which is quite common nowadays) - a revision is 'in the pipeline' however
it is not included at this stage. Use our stand alone program TESTMEM for that
purpose until then. TESTMEM is available from our website - see info below.

DMA Channels & Memory regions used by Network cards do not always show up on
the other information screens. This lack of consistency is being addressed.

EISA Information is limited, possibly buggy. We are trying to obtain an EISA
based machine and cards for testing purposes.

PCI NE-2000 clones are not yet tested (common models are now detected),
although we have verified that the test code currently in diags does work on
PCI NE-2000's. This is being added and will appear in a future release.




> Why is Diags better?

Unlike most so called "diagnostic" programs, Diags re-examines the hardware
each time a screen is selected; the system is not analyzed 'once' at startup,
but as often as you select menus. Diags is able, therefore, to detect system
changes such as 'turbo switch' action in real-time. Diags 'burn in' mode is
designed specifically to pick up hardware that fails intermittently, by
re-testing the hardware over and over, as long as you leave diags running.

Diags does not "assume" anything, or take any external software's word for
anything; all information displayed is the result of actual testing and
verification. Unlike other packages, Diags does not rely on the presence of
drivers, environment variables, or even a properly configured system. As long
as you can boot plain DOS, Diags can do it's work.

Diags also operates from a single bootable floppy disk (even a 360k disk!) and
does not force you to load a complex operating system or sit through time
consuming installation procedures. Diags was designed as a 'one floppy cures
all' product - no mucking about involved!




> Contacting the Author

You can Email me: chart@hyperlink.net.au
Visit our web site at http://members.hyperlink.net.au/~chart

We always have the latest version of DIAGS available for free download at the
web site. We like to receive feedback on DIAGS in the form of E-Mail but will
NOT be offering assistance with fault-solving. Please do not E-Mail us with the
expectation that we will be able to assist with or solve a fault for you -
these messages will be ignored.

We also write a selection of other useful utilities for technicians - all of
which are free for the asking. Visit our website for all the details.



> The rest

The rest of this text file is a pretty rambling guide to using DIAGS with a
POST card, as well as a good text on general fault finding techniques. This
text should be used as a supplement to the rest of the DIAGS manual, for
advanced users to read and hopefully make use of in the course of your work.


CPU's and NPX's DIAGS recognizes:

Intel
8088,8086,8087
80188,80186
80286,80287,287XL
80386SX,DX,80387SX,DX
80486SX,DX,DX2,DX4,Pentium Overdrive
Pentium,Pentium-MMX
Pentium Pro
Pentium II, incl. PII-333MHz+, Celeron & Celeron-A Models

NEC
V20,V30

AMD
80386SX,DX
80486SX,DX,DX2,DX4,5x86
K5,SSA5 (6x86?)
K6
K63D
K63D+

Cyrix
486SLC,DLC
486Su,Su2,SX,DX,DX2,DX4
5x86 (M1sc)
6x86,6x86L (M1)
6x86MX (M2)
MediaGX,GXm
All Cyrix NPX's

Texas Instruments
All Cyrix rebadged CPU's

IBM
386SL
486SL
486SL2
486BL3
All Cyrix rebadged CPU's

IIT
All Mathcos

ULSI
All Mathcos

Centaur
C6

UMC
U5S, U5D (486SX Clones)
486DX
486SX

Diags has been written to use the CPUID instruction (Found in all current CPU's
and expected to be a standard part of all new CPU's), so DIAGS will always be
able to cope with new CPU's as they come out. I would appreciate hearing from
anyone who has a CPU that supports CPUID which Diags does not correctly
recognize.



> HDD Butterfly test

New to DIAGS 2.73á, the butterfly test checks the accuracy of the drive's head
positioning mechanisms, by generating worst-case seek operations. The heads are
moved from the outermost track to the innermost track, then back out to the
outermost track-1, then the innermost track-1, then the outermost track-2, etc.
Eventually the distance the head is traveling decreases until the centermost
track(s) are reached, and test then ends.

Seeks are most likely to fail in this test as any "slop" in the seeking
mechanisms is most likely to show up due to the use of 'gross' movements
followed immediately by 'fine' movements. The 'back and forth' seeking
technique is designed to try and make the heads "overshoot" the target track,
so it is a good test of the automatic position sensing and correction
mechanisms within the drive.

*NOTE* some IDE caching and some SCSI controllers ignore seek-only commands,
which improves drive performance, in which case this test will complete in only
a fraction of a second, and the drive will not make any noises. Once you've
heard a drive doing a butterfly test, you'll be able to tell in a moment if the
test is 'really' happening or not - the sound is very distinctive - the drive
makes a low pitched humming noise that steadily rises in pitch and speed to a
crescendo at the end of the test. BBBBBBBUUUUUUZZZZZZAAAAATTT! It's also a
great conversation piece when 'played' to your geek friends on an old 5.25"
full height drive :-). On a "modern" 9ms IDE HDD (WD13200) the test takes about
5 seconds to run.



> HDD BLOCK READ TEST

New to DIAGS 2.73á, HDD block read test is an essential tool for fault-finding
random data corruption/read errors on modern EIDE & SCSI setups.

History

In the 'good old days' data was transferred one sector at a time between the
the HDD and the PC. This was very inefficient if you wanted to read several
sectors that were physically next to each other - the extra overheads of setting
up many sector reads was killing performance.

Multi-sector or "Block" mode was introduced to fix this problem. All modern IDE
drives support this mode, where up to 32k (64 sectors) worth of data may be
transferred in one single operation. This is much more efficient than 64 single
sector read operations as you eliminate the overheads of 63 "setup" and "finish
off" cycles. The BIOS takes care of the 'behind the scenes' work of
implementing block mode, the net result being that ALL programs gain a
performance improvement, even though they were never written with block mode in
mind.


The problems

The M/B BIOS/Drivers need to know if a drive supports block mode, and if so,
how large a block size is supported (various sizes from 1k to 32k are
possible). Many BIOS's guess wrongly, and this is the root of the data
corruption problems. Many early IDE drives (that were designed before IDE
standards were formally laid down and accepted industry wide) incorrectly
respond to software enquiries about their block size abilities, returning
garbage values to the BIOS. This is equally true for both SCSI and IDE drives,
although SCSI has far less problems - 95% of the time the user has manually
overridden the SCSI BIOS in an attempt to squeeze extra speed out of the drive.

Similar rules apply to PIO modes in EIDE systems - early drives don't report
their PIO mode properly, which normally means they get run at mode 4 instead of
their proper mode 0, 1 or whatever.

SCSI bus disconnection is another area often giving problems - only modern
drives support disconnect; most SCSI BIOS's allow disconnect to be disabled
however for compatibility with older devices.

Also, many early IDE block mode BIOS implementations (in AMI WinBIOS's
especially) had serious bugs, applying the 'Master' block size to the 'slave',
instead of separately enquiring on the slave drive's abilities. Thus, the slave
would get corrupted if it supported a different (smaller or none) block size
than the master.


Symptoms

Random data corruption during reads and writes. 'Vanishing' partitions, boot
errors, inconsistently reproducible errors found by scandisk, NDD, etc, drive
works great in one machine but not in another. Inability to boot up or run
certain applications. Problems usually show up/get worse after a defrag (because
defrag sorts the data into continuous sectors - that way 'block mode' is most
likely to be used on a subsequent read). Prior to defrag, block mode may not be
used much since block mode can't be used if the reads are from non-sequential
sectors.


The solution

If a drive fails the block mode test, reduce or turn off block mode and re-test
the drive. If it still fails, reduce the PIO mode to 0 (IDE) or select SCSI-1
compatible settings and turn off disconnect (SCSI). One or both of these
adjustments should resolve the problem. If not, test the drive on it's own (if
part of a multi-drive set). Remember, the drive could just be plain faulty
too - this test relies on all sectors of track 0 head 0 being reliably
readable.






How to diagnose faulty motherboards using a POST card and DIAGS software.


Section A - getting power up.

Step 1.

Begin by configuring the motherboard with a CPU and a minimum amount of memory
chips. Remove ALL cards. Set all motherboard jumpers to suit the CPU & RAM
configuration. Insert POST card. Configure POST card Port address (80h, I/O,
Write). Connect speaker. Apply power.

Observe the power LED's. Are all 4 LED's LIT?

Yes -> Goto Section B
No -> Check PSU. PSU OK?

Yes -> Goto Step 2
No -> Replace PSU.


Step 2.

At this point the CPU, RAM or M/B may be shorted or open circuit. Remove the
RAM and re-test. If still faulty remove the CPU and re-test. If still faulty
then the mother board has an internal short and is (usually) written off. If
you're technically competent, from here you could look for shorts on expansion
bus fingers, shorted power filter capacitors, wrongly placed jumpers, damaged
chips etc. A quick way to tell if a chip is damaged is to feel it. If it burns
your finger, it's faulty! Open circuits can be found with a continuity tester
or ohms function of a multimeter. Test for 0 ohms or continuity between the
power pins on EACH expansion slot and the power supply connector. Often leaky
CMOS batteries destroy the +12v rail (which in many board designs runs right
under the battery) which stops the video card starting up (VGA requires +12v)
so always check for the leaky CMOS battery (see section later about this
phenomenon).

If the RAM fails, look for bent pins under RAM chips, broken pins, "loose" SIMM
Sockets etc. If RAM looks OK, replace it and re-test. If fault persists,
suspect shorted motherboard memory bus drivers. Replace motherboard.

If the CPU fails, ensure it's inserted the right way around, in the right
socket, ensure there are no bent pins etc. Often a CPU installed the wrong way
will short out the PSU causing the PSU not to start up ... but some power
supplies will start up anyhow, usually frying the CPU in the process...The
damage occurs within a few milliseconds - by the time you've reacted, the CPU
is well toasted. If everything checks OK, replace CPU and re-test. If fault
persists, suspect short in CPU interface. Replace motherboard.




Section B - getting a POST code up.

At this point you've cleared the power circuits of the motherboard.

Observe POST Indicators. Do POST Codes appear?

Yes -> Goto Section C
No -> Try other POST Addresses

Located a POST address that displays POST codes?

Yes -> Goto Section C
No -> Is the motherboard generating beep codes?

Yes -> Goto Section C
No -> Read on

At this point you've failed to find POST & Beep Codes.

At this point you may have a non-POST motherboard (very old boards like XT's
and early 286's usually don't have a POST port). To find out if the board's
alive, try monitoring port 70h, I/O, Write (286+ only). Accesses here indicate
that the BIOS is reading the CMOS and is therefore alive. If the CMOS is being
accessed then you can assume a non-POST board. In this case, you can do very
little else with a POST card alone. If you can't get the DIAGS support software
running then the motherboard is most likely faulty beyond repair.

For an XT, try monitoring port 63h, I/O, write. the BIOS should write 99h here
very soon after boot (it's the initialization word for the 8255 PPI chip). No
99h - motherboard is probably dead. In this case, you can do very little else
with a POST card alone. If you can't get DIAGS software running then the
motherboard is most likely faulty beyond repair.

If you can't see any accesses to port 70h/63h, the board may be failing to come
out of reset. Check reset jumper wiring. Try replacing keyboard controller chip
(286+) or 8255 (XT). If still no go, press reset briefly. If the board now
comes to life (remember to scan all POST addresses, 70h/63h again) then you
have a cold power-on fault. This may be due to your power supply missing "power
good" signal or a faulty motherboard. Assuming the motherboard and power supply
are known compatible, replace keyboard micro (286+), 8284, 8288 & 8255 (XT),
chipset (AT+)

A DIAGS card really comes into it's own here - by allowing you to monitor ANY
port for activity, you can fully test out ANY board, even those that don't make
POST codes - something many other POST cards can't claim.


Section C - Doing fault-finding with the aid of the POST Codes.

At this point you are receiving POST Codes and the motherboard is trying to
start up. From this point, fault finding is a matter of cross-referencing data
on beep and POST codes with a manufacturers manual for that BIOS.

Before we look at analyzing POST codes in detail, here are some notes on common
PC complaints that you should eliminate before investigating POST codes.

It is important to remember several things about the state of the motherboard
during the initial boot up state (before trying to boot the hard/floppy/ROM)
the following situations are true for most motherboards:

CPU In REAL mode (Except briefly in early POST & during RAM test in 286+)
All CACHE disabled
All BIOS shadowing disabled
BIOS Power-on defaults (most compatible settings) in use
Parity checking disabled
Power saving disabled (if present)
Non-turbo mode active (some boards)
Gate A20 off (Except when CPU is out of REAL mode)

Therefore faults in these areas will not effect the power on state; faults here
will only appear AFTER booting has begun. The PC that locks up immediately on
boot (before starting to load OS) usually has a fault in one of these areas...
and it's usually bad cache or wrong CPU type jumpers!


To diagnose crash-on-boot type problems.

1. Disable Cache. If pc works without cache, replace cache. If fault persists,
suspect fault in motherboard cache control circuits or jumpers - check jumpers
and if good, replace motherboard. Be aware of "fake cache" boards.

2. Load SETUP Defaults into CMOS Setup (if possible). If PC now works, incorrect
BIOS defaults were in use. This sometimes happens after a CPU Type change, or a
re-arrangement or addition of a PCI card. It is good policy to reload BIOS
defaults after any hardware changes - the BIOS changes it's defaults to suit
whatever hardware it has found that power-up so you will be reloading the right
settings for that particular configuration. Be aware of disabling PCI IRQ's
that are used by non-PnPISA devices.

3. Remove HDD's & preferably controller. Boot from floppy only. If floppy boot
is OK try a single, known good HDD & Controller. If OK, suspect HDD system.

4. Check jumpers. Today's modern motherboard have a host of jumpers for
defining exactly what type of CPU is present. It is important to tell the
motherboard if the CPU is an SX/DX/DX2/DX4, 3.xv or 5.0v, What brand, L1 cache
type, green features (-S series CPU's) etc are present. Crash on power saving
or CTRL-ALT-DEL operations are often due to incorrect jumpers.

5. Some recent motherboards disallow mixing of certain combinations of RAM
chips.. ensure the type(s) of RAM chips are in suitable combinations - a
mixture of EDO/SDRAM/DRAM may be a problem, as may mixing single and double
sided 72 pin simms, or DIMMs and SIMMs. Often the memory size detected may be
wrong in these cases. Some motherboards have jumpers to set the ram type
installed... check motherboard manuals to see if you need to change jumpers.


To diagnose corrupted screen type problems.

Corrupted screen images (usually in the form of garbage characters onscreen) is
almost always a faulty video card. Often, you may get intermittent "video
device not found" POST errors. Begin by replacing the video card. If problems
persist, suspect faulty expansion slot interface or motherboard - try another
slot and/or replace motherboard. Check for +12v present - a dark, almost
unreadable display may be the absence of +12v on that slot...


The leaky CMOS Battery fault... A modern nightmare?

CMOS batteries do, unfortunately, leak. Like all batteries their contents is
acidic and will eat right though your motherboard!! be sure to inspect the CMOS
battery for signs of leakage. If the circuits around the battery has any green
or white powdery material or green stains on it, you've got a leaky battery.

Don't confuse the green stain with that of the green solder mask which covers
many types of board. The solder mask is an even, green, semi-transparent
covering that is uniform across the entire board. The leaky battery produces a
powdery, blistered green substance that easily brushes off with the fingers.

The acid in the battery attacks the copper in the circuit board and component
legs, turning it into green copper oxide - a non-conductive powder. Very
terminal. Boards badly taken by acid are a write off. If caught early, however,
the board can be saved. Remove the dud battery. Wash the affected area in a
solution of baking soda and vinegar (proportions don't really matter, but 90%
vinegar to 10% soda works well. The mixture does fizz and bubble a LOT when
made up.) to neutralize the acid. Replace with a new battery. Failure to wash
the board usually results in future failure from ongoing acid corrosion. If
circuitry has been damaged and tracks have been corroded, careful patching can
sometimes save boards - but not always. Most boards are 4 or 6 layer meaning
that if a plate-thru or middle layer track is damaged, repair is usually
impossible.

Generally, only NiCd batteries fail in this manner... lithium types usually
just go flat, but don't leak. Ensure the replacement battery is the right type
- soldering a lithium battery in place of a NiCd will result in the motherboard
trying to recharge the lithium battery - which will damage the battery in a few
weeks, and may cause it to explode! The smell of burning lithium is very
distinct... I hope you never have to get to know it!


Analyzing POST Codes

POST codes were originally designed by IBM to help them fix faulty 286 boards.
Because IBM's 286 still used individual discrete ("Garden variety") logic
chips, it was hoped that with a detailed POST, the IBM technician could
nominate the exact faulty chip and replace it. This saved IBM about $1000 (in
potential sale value) for every board they were able to fix. In practice the
system worked well and before long, IBM technicians in the field were able to
fix a motherboard on site in as little as a few minutes. (The DMA controllers,
for one, were common problem parts.) IBM even socketed the more likely (read
expensive) candidates so that field repair was no harder than changing a CPU
chip.

In today's modern, highly integrated motherboards, it's unfortunately usually
a case of "faulty, REPLACE it" because individual parts are no longer
changeable. The evolution of tighter and tighter integration, surface mounted
componentry, and the quest to "make it cheaper" has resulted in motherboard
that are basically throw away, unservicable items. Manufacturers cannot justify
any sort of after sales or spare parts supply for something that they sell for
next to nothing, and requires such a massive technology investment to work on.

The only serviceable parts on modern motherboards are the keyboard BIOS, RAM,
ROM, CPU and cache. POST codes can help us find faults in these areas as well
as help us with a detailed fault report if the board is beyond our repair and
has to be returned for warranty replacement. It's much nicer to say "locks up
at POST code 39h" than "it don't !#$$^%^ work mate!!"

As well as implementing POST codes, some BIOS manufacturers have chosen to add
onscreen messages and BEEP codes to their fault-finding assistance system. BEEP
codes and onscreen messages are designed to assist users without POST boards,
but they are not always nearly as comprehensive as POST codes. Often a beep
code has an associated series of POST codes that go into more detail. There are
a few, rare motherboards which only produce beep codes but not POST codes.

Manufacturers use the POST codes in the following manner. The POST code is
displayed immediately BEFORE a test commences. The test then runs. Once the
test completes OK the POST code for the NEXT test is displayed. If your
motherboard locks up displaying a particular POST code then that particular
test has failed after starting but before finishing.

Once you've identified the area of the motherboard which is failing, you can
replace the associated parts until the POST no longer stops at that point. For
example, if an AMI BIOS stops at POST code 0Bh then the parity toggle failed.
Parity is associated with memory, so you would then replace the RAM and memory
controller chips as a starting point.



And a trick one to watch out for!

A disturbing trend has appeared recently in modern "Green" motherboards
containing many brands of BIOS. The normal, sequential outputting of POST codes
has been disturbed. These mystery boards output POST codes in the D0-DF range
BEFORE commencing at the "normal" 01 code. We have been unable to confirm with
BIOS manufacturers the exact nature of these early POST messages.

After much time, debugging effort and disassembly, we feel that these codes are
"extras" added in by the motherboard manufacturer to assist with the new green
power saving and CPU type options found on the latest generations of 486 &
Pentium motherboards. Motherboard manufacturers have been unable to supply any
information on these new codes. We feel that a crash at this point would tend
to indicate incorrect CPU, Cache or Green jumper settings.


How the BIOS manufacturers work.

When you buy a motherboard, the BIOS it carries is designed specifically for that
particular board. How busy those programmers AT AMI, Phoenix etc must be, you
say! They must program for dozens of new brands and models that are released
worldwide every month... They must have the ultimate set of manuals for
chipsets on the earth.

Not so.

The BIOS manufacturers sell to the motherboard manufacturers what we refer to
as the "core" code. This core is the complete, debugged, functional BIOS but
WITHOUT any code specific to the CHIPSET. The motherboard manufacturer then
pays a programmer (other than the BIOS manufacturer) to add the support for the
CHIPSET to this core. There are usually several "editions" of BIOS for sale,
the ones with more features being the more expensive. This is just another way
a cheap manufacturer can save a few dollars. He can buy a very old BIOS,
perhaps one without HDD autodetect, or perhaps without GUI interface, and save
a lot of money. He pays the price (in the retail arena) for not offering the
end-user the latest features.

The programmer then writes the required support routines and slots them into
predefined areas that the BIOS manufacturer has set aside and produces the
final, custom BIOS for that particular board. That's why you can see the same
version number BIOS on utterly different motherboards. They both started with
the same core but were developed to suit their target boards.

This is why your nice, new 486-100 motherboard may contain a text based bios
setup copyrighted 1992. AMI finished the "core" in 1992. The manufacturer has
no right (in fact he's usually bound legally not) to alter that copyright date
in any way. The motherboard manufacturer, however, can continue to add/edit his
CHIPSET support forever more. AMI simply takes a license fee for every BIOS
sold, so they don't really care if they're still making money from a 5 year old
BIOS. Other BIOS makers have similar arrangements.

This is also why the BIOS from one motherboard generally won't work in another.
The chipsets would have to be identical (or at least from the same family) for
there to be any hope at all of them even basically working. This is also why a
swapped BIOS can result in very obscure, intermittent bugs.

Most manufacturers won't go to the expense of updating regularly to a new core
BIOS because of the costs involved. Each new core not only requires the chipset
programmer to start over, it also involves a whole new outlay to buy the new
core and to start paying licensing fees on it. This is why some manufacturers
are still using ancient, featureless BIOS's on their newest motherboards.
They're penny-pinching scum.



The DIAGS software.

In the case of a booting PC that crashes, the DIAGS software can be a life
saver. Insert the special boot disk into the A: drive and boot the program. The
program is quite small and designed to execute even if the PC is in it's "death
throws". Assuming that the area of RAM that DOS and the program loads into is
stable, PC Diagnostics 95 should appear onscreen.

Failure to finish loading the software indicates a very sick machine. At this
point, refer to the earlier crash-on-boot section.

OK, so now you've got your DIAGS software up onscreen. Follow the instructions
for setting up the card switches and look for the test codes appearing on it.

Once you see the test codes, press any key and PC Diagnostics will proceed to
study your machine and identify the key components within. As each check is
made, progressive POST codes appear on the card.

After this initial identification, each part of the machine's hardware will be
available to be tested in detail. Again, each section has it's own POST code
displayed just before the test begins. Needless to say a 100% OK motherboard
should pass ALL tests.


Now, the hard part.

Failures to pass tests fall into several categories:

1. The test that consistently fails.
2. The test that consistently locks up the machine.
3. The test that randomly fails.
4. The test that randomly locks up the machine.
5. An unstable machine that seems to fail or lock up just about anywhere.

The easiest faults to fix are those which are stable and consistent. You can
follow the suggested remedies until the fault is cleared. Those which are
unstable are usually caused by general problems such as bad RAM or Cache, bad
power supply etc.

When the machine fails, note the POST code and consult the following remedy
guide. If you can't fix the machine by trying all the listed remedies, then you
can consider the motherboard faulty and replace it.

The most common faults are (again) bad RAM, bad CACHE and bad Power supply.
Make sure that you test with only known good items, preferably ones known to be
compatible; it's not unusual to hear of compatibility problems between two
given brands of equipment.




Here is the complete POST-card points fault finding list.




System Information Group

10 - Get BIOS Type function. Failure here is unusual and may indicate a
problem accessing the ROM BIOS.

11 - Determine BUS Type. Checks for MCA, EISA or ISA bus based motherboard.
Failure here is unusual and may indicate a bad ROM BIOS. Only BIOS
calls are made (No direct hardware accesses). False results could mean
incorrect motherboard BIOS installed, or badly written BIOS.

12 - Identify Processor. This is a complex set of tests that do many strange
things to your CPU. Failure here generally means a bad CPU. Incorrect
answers may mean a new, as yet unrecognized CPU is in use. Refer to list
of known hardware. Check M/B CPU type jumpers. A lock up here CAN be
caused by an incompatibility. See report at bottom of this file. To
try to overcome this, run DIAGS with the X parameter ie DIAGS X

13 - Identify NPX (Math coprocessor). This is again a complex set of tests
that check out the basic math coprocessor functionality. Failure here
is often a faulty NPX, but also a lot of very early edition motherboards
have faulty NPX interfaces. If the system runs OK with NPX removed,
consider a different brand NPX or do without.

14 - Analyse Processor & NPX data. Should never crash here. Only simple math
and logic involved; Suspect RAM fault or re-run and try to test beyond
this point. Perhaps a CPU or NPX DIAGS does not know about may cause a
logic fault - check compatibility list above.

15 - Get RAM Sizes. Tests base RAM size and (on AT+) extended RAM size.
Failure here could be bad RAM above 640k or address decoding errors.

16 - Identify serial ports. Should never crash. BIOS Calls Only.

17 - Identify parallel ports. Should never crash. BIOS Calls Only.

"missing" ports on the above lists usually means faulty, conflicting
or wrongly installed cards. DIAGS only tests cards listed here. Some
early BIOS's do not support COM3 and COM4 - DIAGS can pick these up and
lists them as 'NON-BIOS' ports.

18 - Identify video type. Crashes here could point to a bad video card.

19 - SoundBlaster Test. Looks for a Creative Labs or compatible Sound Blaster
type card. If one is found, certain later tests are adjusted to allow
for the hardware usage this card requires. You should remove the card
if present for absolute guaranteed testing success. False detection
indicates device in I/O port range 210h - 280h present (Network card?)
Remove other offending card also. Stubborn false detection may mean
faulty address decoder section, or M/B sound device (some Pentium's)

1A - Look for PCMCIA support. Uses BIOS support to check for PCMCIA slots.
No specific checks are made for devices installed on the slots - use
manufacturer's PCMCIA software to diagnose PCMCIA problems. (laptops)

1B - Look for Green power management support. Uses BIOS support to see if
power management exists. Power management may need to be disabled
temporarily to run the "burn in" tests of DIAGS reliably.

1C - Look for Plug 'n Play BIOS. Crashes here could indicate a BIOS that
fails on any sort of PnP O.S. or driver (Such as ICM).

1D - Look for Adlib series sound cards. Most SoundBlaster and other sound
cards have an Adlib compatible chip onboard. This test also identifies
OPL2 (2 operator) type chips from OPL3 (4 operator) type chips. OPL3
chips are found on Adlib gold, SB Pro II, and most newer cards.



CPU & NPX Test group

20 - CPU Type display. Repeats info same as code 12

21 - CPU flag tests. Checks that mathematic functions correctly set or clear
the various bits in the Flags register, as per design spec.

22 - CPU Register tests. Checks that all registers can accept any values
written to and read them, without corruption.

Replace immediately any CPU that fails #21 or #22.

23 - Cyrix ID & Cache Info. If the CPU is a Cyrix, then extra Cyrix-specific
information is output here.

24 - CPUID Info. displays the results of a CPUID call, if available.
CPUID is becoming increasingly popular - DIAGS now handles all known
variants of CPUID including AMD, Cyrix, UMC, NexGen as well as Intel.

25 - Intel CPU cache info. Tests internal cache status, and displays.

26 - 386DX stepping tests. Looks for several notorious bugs in the 386DX and
determines the stepping level from the presence of these bugs. Any 386DX
showing a stepping of earlier than B0 should be replaced as these chips
are very unreliable. Tests for the 32 bit multiply bug, the IBTS
instruction, protected mode bugs and more. Immediately replace any 386DX
which fails the multiply bug test - it will fail on any 32-bit programs 
Windows, DOOM, Quake, Win95, EMM386, etc etc.

27 - 386DX POPAD bug test. Although most 386DX bugs were discovered and fixed
within the first few months of 386DX production (the bugs were only ever
in genuine Intel 386DX-16's), this one slipped through and was never
fixed by AMD. Intel was rumored to have fixed this bug around early
1991, but I've never met a "fixed" 386DX yet. POPAD restores ALL general
32 bit registers from the stack. With the bug, EAX is corrupted if the
instruction AFTER POPAD references memory. This test is included for
curiosity purposes only; as it is a known bug, programmers have learned
to work around it (simply do a NOP after each POPAD). Some early 386
software may fail due to this bug IF it uses POPAD without the bug-fix.

28 - Early 486DX step test. Early 486DX's made before 486SX's were released
also had some strange problems. Intel introduced a new general purpose
instruction called CMPXCHG. The instruction itself functioned perfectly,
unfortunately however they decided to use the same opcode as IBTS (found
on very early 386DX's). This led to some software thinking it was running
on an early (ie faulty) 386DX and bombing out. Novell netware in
particular throws this one up. In later versions of the 486DX, Intel
switched CMPXCHG to a new, never before used opcode and all was well.

Problems now occure in that some compilers produce only the old opcode
for CMPXCHG or only the NEW opcode. Thus, some code fails on some CPU's
only. Early 486DX's are fairly rare (They were only made for a few
months) and the use of this instruction is fairly rare too, but it has
been known to knock Windows 3.1 dead.

As with the 386DX, only the very earliest 486DX's have this one (only
ever 33MHz units, only ever Intel brand) but it is more common than the
386DX bug and more mischievous so it is important to find these chips out.
We recommend they be replaced with later versions where possible.

29 - NPX Type display. Same as 13.

2A - Pentium FDIV bug check. The Pentium also had one rather infamous bug!
When the Pentium's internal NPX does an integer divide, it sometimes gets
the answer wrong. This test checks for this bug and reports the error.
This error is found in early 60, 66, 75 & 90MHz units. Intel will
exchange any faulty CPU for a non-faulty version at no charge - faulty
units should be replaced if the user uses ANY software that uses the
mathco. (Spreadsheets, CAD, Graphics, Windows, etc)






Motherboard Group

30 - XT 8259 Interrupt controller. Tests the ability to activate and
deactivate all channels of the controller. Replace 8259 IC if test fails.

31 - AT 8259 Interrupt controller. Tests second 8259 chip. Replace BOTH 8259
ICs. if test fails. (Yes, both of them... the second chains to the first
in hardware, thus faults in one can be hidden by this).

32 to 34 - Failure on all channels - replace timer clock crystal/oscillator.
Failure on one channel only - replace 8253. Failure on ch.2 only -
replace 8255, then 8253. On CHIPS 82C20x chipset, change 82C206.

35 - Speaker test. The speaker produces 5 short, sharp beeps.
If no sound is heard, first make sure speaker is plugged in
and test on another computer to verify speaker itself. If this fails,
replace 8255, then 8253, then 75477. On CHIPS 82C20X chipset, change
82C206. Some PC's have a tendency to have a very soft speaker... listen
carefully in a quiet room!

36 - RTC Battery bad. Test & replace RTC battery. If unsuccessful, test RTC
charging resistor and power steering diodes. To check charging,
remove battery and measure across battery terminals. You should see
approximately battery voltage or slightly higher. Applies to rechargeable
type batteries only. Ensure correct battery type in use.

Battery types information:

NiCad or NiCd - Rechargeable - usually 3.6v
Lithium or watch battery - Not Rechargeable - Usually 3.0v or 6.0v
NiMh or Nickel metal hydride - Rechargeable - usually 3.6v
Dry cell type - normal "torch" batteries. Non rechargeable. Usually
4 x AA size cell for 6.0v

External battery connector on M/B:

1 4
+v -v
o . o o

The . is the "missing" pin. Some motherboards have 4 pins with the middle
two pins jumpered together. Remove jumper to disable internal battery.
External batteries are always 3.6v or 6.0v Lithium or dry cell type;
never the rechargeable type!

37 - RTC Status A test. Failure here means that incorrect clock count
settings are in use - try reloading CMOS defaults in BIOS.

38 - RTC Status B test. Failure here means an internal clock error has
occurred or wrong settings are in use. Try reloading CMOS BIOS defaults.

39 - RTC CMOS valid status. If failed, means that CMOS setup contents are
invalid. Reprogram CMOS using machine's setup utility and save.

3A - RTC Count. Replace RTC clock crystal/oscillator. If unsuccessful, replace
RTC Battery then RTC Chip. Some motherboards also have a small trimmer
next to the crystal - adjust slightly.

3B - Display current RTC date & time. Should display a valid date and time.
Garbage values (like, say, 40-36-1923) indicates bad RTC chip or bad
motherboard.






Keyboard control group

40 - XT 8255 port A functionality. Replace 8255.

41 - XT 8255 port B functionality. Replace 8255.

42 - XT 8255 port C functionality. Replace 8255.

43 - 47 Assorted keyboard tests. Ensure keylock is in "keyboard working"
position. Try another keyboard. Try in non-turbo mode if possible. if
tests work in non-turbo mode, and K/B normally works OK, ignore.
There are a SMALL number of machines that fail some of these tests. If
the keyboard otherwise works, ignore these errors. This is due to
wide abuse of the IBM standard for keyboard controllers. Compaq in
particular are offenders. PS/2 systems may fail to respond to the
keyboard after these tests complete. If so, skip ths test in future.

48 - 4B Failure of LED's to lite. Many motherboards have a small fuse close
to the keyboard socket. This fuse blows sometimes if a keyboard is
plugged or unplugged with power on. The fuse is usually a micro type and
is about the size of a 1/4w resistor. Check and replace if blown. Try
another keyboard. Some keyboards are internally fused also. Dual-mode
XT/AT keyboards may have their mode select switch in the wrong position.
Auto-Sensing dual-mode keyboards may not be being initialized by the BIOS
to AT mode. Check that the keyboard installed option in the CMOS setup
is set to "Installed". One bad LED is usually a dry joint on that LED's
wires - disassemble keyboard and inspect soldering.

Tests 43-4b often fail on "not so compatible" machines, esp. Compaq's. If
the keyboard works normally outside DIAGS, ignore.

4C - Restore original LED status. Returns LED's to initial state.

4D - Awaiting ENTER key to be released. Please take your finger off ENTER!
If you aren't touching any keys, you may have pressed another key at a
critical time - press and release ENTER again. Failure to get past this
point may indicate a faulty K/B data port, or a faulty K/B. Pauses at
This point often happen when a K/B is generating "false" keystrokes at
random. If burn in mode can always be continued with a press of ENTER,
try unplugging the K/B. If this helps, suspect faulty K/B.


DMA group


50-53 Check DMA chip 1 XT Type page registers. Lockups and failures here,
check 74LS670 IC's. (Ch 0-3).

54-57 Check DMA chip 1 XT type base & current registers. (Ch 0-3)

58-5B Check DMA chip 2 AT Type page registers. (Ch4-7)

5C-5F Check DMA chip 2 AT type base & current registers. (CH 4-7)

DMA Tests are all very critical. Any failures, replace 8237 DMA chips.

Note that in an AT, the HDD doesn't use DMA, so a machine that boots up
from HDD but has faulty floppy drives may have a DMA fault. Always begin
by replacing drive, controller, cable and power supply, checking CMOS
setup before casting blame on DMA! Recent 486 M/B's with incorrect CPU
type jumpers have also been found to refuse to boot from floppy (usually
crashing shortly after "Starting MS-DOS..." message. Check CPU type
jumpers very carefully if replacing floppy & DMA components are
unsuccessful.


Devices that use DMA are as follows:

Device XT DMA AT DMA

RAM Refresh 0 -
Floppy 2 2
Sound Blaster 1 1,5
Scanners 3 3
AT-XT link - 4
XT HDD Cont 3 3
EPP Parallel port - 0,1,3
WD80x3 NIC 1 1

Some recent SCSI and ESDI controllers also support a new concept called bus
mastering DMA, which is when a DMA controller onboard the card itself performs
the transfer. A motherboard has to be specifically designed to work with these
types of cards. The average "success" rate is about 80% and the older the
board, the more chance it doesn't work. VESA motherboards with VESA version
1.x usually don't support bus mastering on the VESA bus. Bus mastering faults
usually result in either a locked up machine or corrupt data transfer at the
instant the controller is asked to move data to or from the attached device.

At these cards cannot be directly supported or tested by PC Diagnostics '95
your best chance is to try the manufacturers diagnostic, if any, or test in a
known bus master compatible system.

Note that bus mastering is an all or nothing prospect - it either works or it
doesn't. Intermittent problems will not be due to bus mastering compatibility
issues.

The Adaptec 1542CF is an example of a bus mastering ISA BUS card.





Base RAM tests

60-64 Writing test patterns to base RAM. Refer to onscreen pointer for
exact write address. Suspect faulty memory at displayed address in
case of crashes. RAM is tested in blocks of 1k so a block of addresses
may test bad in the case of a single faulty memory chip.

Some PC's use the last 1-2k for the EBDA (Esp. if using a new Pentium
with PnP or a bus mouse). If so, that top area of RAM is not tested to
avoid corrupting drivers loaded there. Also, many viruses live in the
top few k of memory (and don't always tell dos they are there). Try to
do a virus scan if you are suspicious about the use of the top few k of
RAM, or if the PC crashes when the top few K are tested.





Extended RAM tests

70-79 Writing test patterns to and reading from Extended memory. This test
involves the use of protected addressing mode so it is also a good
work out of the CPU. The 8042 reset CPU test, the CPU & NPX tests and
the base memory tests should all have been tried and passed before this
test is used; otherwise false results may occur.

Some motherboards will not support tests above 16Mb. If tests fail at the
16Mb point, try testing the machine with only some RAM Modules installed,
if possible.

If the modules all check out when tested individually, there may be either
a compatibility problem between the modules (if they're different brands or
batches or speeds) or the 16Mb limit problem.

Remember that on a Pentium Pro and a Pentium the memory bus is 64 bits wide (2
72 pin SIMM's or one DIMM in a bank), on a 486 and a 386DX, the memory bus is
32 bits wide (1 72 pin SIMM or 4 30 pin simms in a bank), on a 386SX or a 286,
the memory bus is 16 bits wide (2 30 pin SIMM's or 16/18 DRAM's (without/with
Parity) in a bank). each bank must be filled with matched, identical memory,
in terms of Brand, size, speed and type. Any variation between memory
WITHIN a bank is usually problematic. Often, different banks can be different,
however... that is very much chipset specific. Most Early Pentiums as well as
286/386/486's will work as long as all memory is the same speed. Newer
Pentiums usually allow any combinations at all, even mixing banks of EDO,
SDRAM and Fastpage (all at different speeds, too) all on the same board.





Cache RAM tests

80 - Check Cyrix cache status & display.

81 - Check Intel cache status & display.

82 - Time Caches average read speed and attempt to calculate size of CPU's
internal cache and external motherboard cache. These tests aim to
find the recent "fake cache" type motherboards as well as show how
caching is affected by the turbo button. Turbo often disables one
or both caches on many 486 & Pentium designs.

83 - Cache read test begin.

84 - Cache read test verify.

The cache read test attempts to check the cache by reading the same memory
region repeatedly and checksumming the read values. The checksum should be
identical EVERY time. Failure here could be faulty memory or faulty cache. If
the memory checks out OK under the memory tests, suspect faulty cache.

Often you can disable the caches in most M/B BIOS's CMOS setup screens. If
this test still fails with the external cache turned off, yet the memory tests
OK, you _may_ have a bad CPU (ie internal cache) or a bad motherboard chipset
in the cache department.

The CPU has to have it's internal cache invalidated (ie wiped out) as a result
of certain hardware actions such as DMA transfer TO memory (floppy reads), bus
mastering (Some Disk Controllers, Especially SCSI), I/O mapped devices
(Weitek coprocessor, ST-01, ST-02, TMC-950 SCSI controllers). If the M/B
chipset is faulty in that it fails to clear the CPU cache when it should, all
sorts of bizarre hardware faults may occur.

This was VERY common with retrofitting of Cyrix 486DLC CPU's to 386 M/B's
where the chipset didn't know how to invalidate the CPU cache after a DMA
cycle. The result: floppy drives would often appear to have mysterious data
errors on reading only (writes OK), and the usual diagnostics have drawn a
blank. Look for "internal cache" or similar setting in the BIOS - if absent,
suspect possible non-Cyrix Chipset or BIOS'd M/B... revert back to Intel or
AMD 386 CPU.. if fault goes away, Cyrix CPU cannot be used on that board.







Parallel ports group

90 - Check current parallel port I/O. Ensures all bits can be turned on and
off and read back correctly.

91 - Check current parallel EPP Compatible. Checks to see if the port supports
the new Enhanced Parallel Port functions.

92 - Check external loopback. Performs external loopback tests (requires
hardware loopback plug) to check control lines.

To make a loopback plug, get a 25 pin male plug an connct the following pins
together. This is a "standard" loopback plug and is the same as the system
that QAPlus, Checkit and others use so you can use loopback plugs you may
already own.

Pins to join together: 1-13, 2-15, 16-10, 17-11, 14-12.






Serial ports

A0 - Get current port chip type. Finds 8250, 80250A, 16450, 16550a, 16550af,
16552. 16550A (but not AF) type has bugs - replace where possible.
Usually found on early PS/2 systems (model 50 especially).

A1 - Set port up. Configures the port for IRQ tests. Sets baud rate.

A2 - Trigger IRQ. Attempts to generate an IRQ by transmitting a character.
ONE IRQ should be generated as a result. Failure here may mean the 
IRQ, once generated, upset another hardware device. It is VERY common
for IRQ 3 (which is the default for the port at 2F8) to conflict with
Novel network cards, causing this lockup. Reconfigure network card
to another, free IRQ.

A3 - Test internal loopback begin. Internal loopback verifies the chip is
working internally. Failure here, replace chip.

A4 - Perform external loopback test. Failure here indicates either faulty
or missing loopback plug, or faulty control lines on this port. Check
board to Serial port card fly-lead (if used), line driver chips on this
port (usually 1488 & 1489 or MAX232 IC). It is normal for this test to
fail if you don't have a loopback plug.

A5 - Perform Baud rate transmission/reception test. Failure indicates
inability to receive port's own transmitted data - look for faulty clock
crystal, or system stealing too much overhead causing lost characters.
the test is performed at a low baud rate only (2400) so even a 4.77MHz
XT with an early 8250 *should* be able to keep up.


*NOTE* IRQ's 8-15 are now supported by DIAGS (was not present in older
versions) - so (say) com3, IRQ 11 is a detectable setting now!


Serial loopback plug wiring: DB-25 port: 2-3, 4-5, 6-8-20-22.
DB-9 port: 3-2, 7-8, 6-1-4-9.







Disk Controllers

B0 - Test primary floppy. Controller installed & type check. Does not need
drives connected.

B1 - Test secondary floppy. Controller installed & type check. Does not need
drives connected.

The floppy controller tests now identify the type of controller chip
present. Here are the features of each type of chip:

Type 500k/s 1Mb/s 2Mb/s Tape FIFO
NEC D765 *2 Y N N N N
Intel 82072 Y Y N N N
Intel 82077 old Y N N N N
Intel 82077 Y Y N N Y
Intel 82077AA Y Y *1 Y Y
Intel 82078 Y Y *1 Y Y

500k/s - standard data transfer speed. All chips need to do this speed.
1Mb/s - faster rate for 2.88Mb floppies. (optional).
2Mb/s - faster rate primarily for fast tape drives. (optional).
Tape - Explicit support for tape drives; usually goes hand in hand with 2Mb/s
capability. 

FIFO - Controller contains a FIFO (Speeds up sequential floppy commands).
*1 - Depends heavily on the many clone chips out there. Some do, some
don't.
*2 - NEC D765 is the same as the Intel 8272 & 8272A, but the NEC part is
much more common in the field.


B2 - Primary AT IDE. Controller installed check. Requires an ATA drive to be
connected. ATAPI Drives won't work (IE tape drive, CD-ROM etc).

B3 - Secondary AT IDE. Controller installed check. Requires an ATA drive to be
connected. ATAPI Drives won't work (IE tape drive, CD-ROM etc).

B4 - CAM SCSI check. BIOS support check only. Known to crash on some verrrry
old 286 Award BIOS's. Simply skip this test group if so. Consider BIOS
upgrade if used with SCSI controller.

B5 - Future Domain SCSI check. BIOS Support check only. Known to crash on some
verrrrry old Wang PC's (Award BIOS..). Simply skip this test group if
so. Consider BIOS upgrade if used with SCSI controller.






Hard Disk Drives

C0 - Get number of HDD's from BIOS. Should always work as no physical access
to drives normally occurs.

C1 - Get parameters from BIOS for current drive (IE get CylxHDxSPT).

C2 - Reset HDC using BIOS. Failure here means drive or controller failure
or "hung" IDE drive.

C3 - Perform HDC RAM Diagnostic (XT). Failure indicates bad sector buffer
RAM in controller - replace controller. All disk reads and writes
will be unreliable with this fault & strong possibility of data loss
exists.

C4 - Perform Drive #0 diagnostic (XT). Failure depends on actual test
in controller BIOS (Varies by vendor). Check cables, verify drive was
actually low-level formatted with this controller (do not change
controllers without re-low level formatting drive).

C5 - Perform Drive #1 diagnostic (XT). Failure depends on actual test
in controller BIOS (Varies by vendor). Check cables, verify drive was
actually low-level formatted with this controller (do not change
controllers without re-low level formatting drive).

C6 - Recalibrate current drive (Move head to track 0 & verify). Failure
indicates faulty track 0 sensor, faulty drive or bad cable.

C7 - Perform random seek (No data read) on current drive. Failure to seek
correctly indicates either incorrect setup parameters, or a physical
fault with the drive. Cache controllers often ignore "seek only" commands
and simply answer back with OK immediately.

C8 - Perform random read (and implied seek) on current drive. Failure to read
correctly indicates either incorrect setup parameters, or a physical
fault with the drive. Cache controllers may not read from physical drive
if data is already present in cache.







Floppy Disk Drives

D0 - Reset Floppy drives using BIOS. Should never fail.

D1 - Start IRQ 6 test. IRQ 6 must work for FDC to operate properly. IRQ 6
failure results in other tests being aborted. Faulty IRQ 6 - replace
controller card, then first 8259 PIC.

D2 - Get Floppy drive A: type from CMOS.

D3 - Get floppy drive B: type from CMOS.

On XT, if the number of drives shown is wrong, check dipswitches on M/B.
On XT, there is no way to sense number of FDD's without using track 0
sensor, so no automatic check is possible; instead DIAGS 95 ALWAYS tries
to test two floppy drives on XT's. On some XT Turbo's, a faulty track 0
sensor in a drive will give an incorrect number of floppy drives
installed for this reason. Use the track 0 test to see which case is
causing the fault.

On AT, if number of drives is wrong, check CMOS.

NB: DIAGS 95 does not support more than 2 floppies on any type of machine
at this time.

D4 - Test Track 0 sensor, drive A:

D5 - Test Track 0 sensor, drive B:

Bad track 0 sensor both drives - change cable. One drive - check for dust
in optical sensor. Track 0 sensors work like this: there is a plastic arm
attached to the heads which moves with the head. At track 0, this plastic
arm moves into the middle of a sensor & blocks an IR light beam. dust in
the track 0 sensor can cause a "permanent" track 0 sense. blow dust from
sensor in this case.

D6 - Get write protect status, drive A:

D7 - Get write protect status, drive B:

Bad WP sensor both drives - change cable. One drive - check for dust
in optical sensor (5.25" drives) or bent microswitch lever (3.5" drives).

Failure on any floppy test should always be tackled be checking drives
have power, that data cable connectors are correct (drive A: at end of
cable AFTER twist, drive B: in center of cable before twist), and finally
by replacing FDC.

DIAGS 95 does not test the floppy changeline (changeline tells the PC's
BIOS that the user has removed a disk; present on all drives except
360K's, all XT drives, PS/2 drives). To test the changeline: boot DOS. do
a DIR on a disk, note contents of DIR carefully. Change to another disk
with a different set of files to the first disk, (in the same drive) and
do another DIR. Do NOT access the drive between changing disks. If DIR
now shows the contents of the second disk, changeline is OK. If you get
the contents of the first disk, changeline is faulty. Changeline is on
pin 34 of the floppy cable, so it is the first signal to be lost with a
loose cable, and the most susceptible to damage. Begin by changing
cables as a first remedy.


End of Codes Table.

Note : Additional information is available in diags.faq file (included within diags.zip).