FPGA VAX update, now DIY TTL computers - test-drb@ccmp.vtda.org

3 Nov 2005

...

Subject: RE: FPGA VAX update, now DIY TTL computers
   From: "a.carlini at ntlworld.com" <arcarlini at iee.org>
   Date: Thu, 03 Nov 2005 19:08:04 +0000
     To: "'General Discussion: On-Topic and Off-Topic Posts'"	<cctalk
at classiccmp.org>

Allison wrote:

  Parity required an extra bit to stor the parity
so that it could be
 compared on read. That bit may or may not have been part of the data
 path logic.  
But on the memory chips, that bit must have been readable for the
system hardware to do its comparions. I guess that the memory could
send back a GO/NO_GO signal but supplying the parity bit must
be easier and cheaper? 
Actually the system does not have to see the parity bit.  Only the 
result of comparing the stored (at write time) parity in the 9th bit
with the result of the read parity hardware.  If there is a difference
there was a "hit".  So the rest of the system gets the data and the 
interrupt system sees the parity if there is a fail.  There is no need 
(in most if not all) to actually read and write the parity bit as that
is a memory subsystem task (hardware). PDP-11 Qbus ram is of the 
case where parity is stored as a 9th bit but is not directly accessable
by the CPU.  

In the extreme is the ECC ram where there are many bits per byte/word
to store a coded form of the data (hamming or other compression) so that
the ECC hardware can "repair" corrupted data.

...
 There was a spate of "fake parity" memory
around some time in
the 90s. Quite why it was cheaper to add a chip that always
supplied "correct" parity rather than simply using additional
memory was something that I never understood. But if you
end up with one these "fake parity" memories it may well
cause your 9-bit machine some issues!! 
If it were a real 9bitter it certainly would.  In the case of PCs
it was a matter of satisfying a motherboard configuration rather than
real "bits".  

Allison