Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!bloom-beacon!oberon!cit-vax!elroy!ames!amdcad!sun!imagen!atari!portal!cup.portal.com!Isaac_K_Rabinovitch
From: Isaac_K_Rabinovitch@cup.portal.com.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Isn't Parity a Hardware Concept?
Message-ID: <811@cup.portal.com>
Date: Thu, 1-Oct-87 23:06:38 EDT
Article-I.D.: cup.811
Posted: Thu Oct  1 23:06:38 1987
Date-Received: Sun, 4-Oct-87 02:32:58 EDT
Distribution: world
Organization: The Portal System (TM)
Lines: 23
XPortal-User-Id: 1.1001.1472

Has anyone heard of an AT clone blowing up with a "PARITY ERROR" without
there being an actual hardware problem?  Can this result from software
accessing the hardware in a flaky manner?  I'd appreciate hearing from
people who have had similar problems.  I also appreciate hearing from
people who think that the idea is preposterous.

For those of you who like case histories, here's my specific problem.  I
recently bought a used Zenith 241 with a standard controller, a high density
floppy drive, and a double (360K) density floppy drive.  The system has
512K on the mother board, and an add-in card brings conventional memory
to 640K and adds 1 meg of extended (that is, nonLIMS) memory.

When I got the beast, there were parity problems with the extended memory,
but the integrator who sold it to me now claims to have replaced all the
bad chips.  The Zenith diagnostics seem to confirm his claim.

However, I still have troubles when I try to run Fastback (latest version).
Whenever Fastback tries to format a disk, I get ++++PARITY ERROR messages
and drop into the debugger.  Now Fastback is one of those programs that
goes off and does things its own way, so one's first thought is "another
cloneland compatibility problem, let's try some other software."  BUT.
A parity error generated by software?  Is that possible?  If not, then
I have a hardware problem that only Fastback collides with.