FPGA VAX update, now DIY TTL computers

[Allison]

>
>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