4 Jun
2012
4 Jun
'12
9:42 a.m.
I?ve completed a list of boards in the P800 haul:
CPU BOX 1 ? labeled P859
? CP7RA : 5111 199 62019 (P857R/A CPU for P858,P859)
? MCU3 : 5111 199 77442 (Paper tape, serial control unit (partially
populated))
? 2 x M128E : 5111 199 67592 (128Kx21 RAM)
? MCU2 : 5111 199 78181 (Line printer, card reader control unit)
? MTCU : 5111 199 72467 (Pertec 9 track magnetic tape control unit)
? 2 x M128ES : 5111 199 58622 (128Kx21 RAM)
? MCU3 : 5111 199 77444 (Paper tape, serial control unit (partially
populated))
? AMA-8A : 5111 199 75318 (Asynchronous line multiplexer)
? SLCU2 : 5111 199 69373 (Synchronous serial line control unit)
CPU BOX 2 ? labeled P859
? 2 x CP7RA : 5111 199 62019 (P857R/A CPU for P858,P859)
? M128E : 5111 199 67592 (128Kx21 RAM)
? MCU2 : 5111 199 78185 (Line printer, card reader control unit)
? MCU2 : 5111 199 78186 (Line printer, card reader control unit)
? MCU3 : 5111 199 77445 (Paper tape, serial control unit (partially
populated))
? BIGD : 5111 199 73289 (Big disk (40/80MB CDC) controller)
? BIGD2A : 5111 199 57852 (Big disk)
The weirdness of Box 2 is ? obviously ? a second CPU in the same box. This
can?t be right.
CPU BOX 3 ? labeled P859
? CP7R : 5111 199 67589 (P857R CPU for P858,P859)
? M128E : 5111 199 67593 (128Kx21 RAM)
? TIMER CARD : 4022 422 20091
? ? : 4522 107 62304
? CU-ADIOS : 8222 255 50942
Box 3 has three cards with part numbers in different series from the normal
5111 199 xxxxx
CPU BOX 4 ? unlabeled, P856 type M4M box
? 2 x CDD : 5111 199 78176
? CDD : 5111 199 78177
? CDD : 5111 199 78178
? 2 x MCU3 : 5111 199 78198 (Paper tape, serial control unit fully
populated))
? MMU : 5111 199 75183 (Memory Management Unit)
? GPC : 5111 199 79382 (Custom card)
Box 4 just looks wrong. I don?t know what the CDD cards are, but there
doesn?t appear to be a CPU or memory in there. However, there are P856 CPU?s
in the spare cards box, and I found references to the P856 being able to use
MOS memory as well as core, so all might not be lost here.
EXPANSION BOX ? E2 type (6 slots)
? BIGD2A : 5111 199 57852 (Big disk)
? MTCU : 5111 199 72467 (Pertec 9 track magnetic tape control unit)
? BIGD : 5111 199 59755 (Big disk (40/80MB CDC) controller)
? MTCU : 5111 199 72462 (Pertec 9 track magnetic tape control unit)
? 2 x MX : 5111 199 79335
CASSETTE BOX ? P833
? K7S2 : 5111 199 79329 (P833-152 Cassette Control Unit)
Combined with the spare M-format cards in the haul, the complete list of
boards is as follows:
? ? : 4522 107 62304
? AMA-8A : 5111 199 75318 (Asynchronous line multiplexer)
? BIGD : 5111 199 59755 (Big disk (40/80MB CDC) controller)
? BIGD : 5111 199 73289 (Big disk (40/80MB CDC) controller)
? 2 x BIGD2A : 5111 199 57852 (Big disk)
? 4 x CDD : 5111 199 7817X
? 2 x CP7R : 5111 199 67589 (P857R CPU for P858,P859)
? 3 x CP7RA : 5111 199 62019 (P857R/A CPU for P858,P859)
? CPB : 5111 199 74979 (P856 CPU)
? CPB : 5111 199 76227 (P856 CPU?)
? CPB / CP7B : 5111 199 63142 (P856 CPU?)
? CU-ADIOS : 8222 255 50942
? 4 x F1MB : 5111 199 6742X (modified for? 5.25" FDD)
? 3 x F1MB : 5111 199 67427 (8" Floppy disk controller)
? F1MBY : 5111 199 58742 (Floppy disk controller)
? FLDB : 5111 199 69667
? GPC : 5111 199 79382 (Custom card)
? 2 x IOP : 5111 199 73185 (I/O Processor)
? K7S2 : 5111 199 79329 (P833-152 Cassette Control Unit)
? 5 x M128E : 5111 199 6759X (128Kx21 RAM)
? 2 x M128ES : 5111 199 58622 (128Kx21 RAM)
? 3 x MCU2 : 5111 199 7818X (Line printer, card reader control unit)
? 5 x MCU3 : 5111 199 7744X (Paper tape, serial control unit (partially
populated))
? 2 x MCU3 : 5111 199 78198 (Paper tape, serial control unit fully
populated))
? MMU : 5111 199 75183 (Memory Management Unit)
? 3 x MTCU : 5111 199 7246X (Pertec 9 track magnetic tape control unit)
? 2 x MX : 5111 199 79335
? SLCU2 : 5111 199 69373 (Synchronous serial line control unit)
? TIMER CARD : 4022 422 20091
Looks like I should be able to get a few systems going with these parts.
There?s also a second box with spare cards, having different formats. Some
of these are double eurocard format, like those used in the P85xE systems.
There?s also a spare power supply for a P859 box, as well as a spare power
supply for a P856 box.
I?m interested in finding out more about the cards I couldn?t identify,
these are:
? ? : 4522 107 62304
? 4 x CDD : 5111 199 7817X
? FLDB : 5111 199 69667
? 2 x MX : 5111 199 79335
? TIMER CARD : 4022 422 20091
I?m hoping CDD means Cartridge Disc Drive, and that these are the
controllers for the X1215 disk drives.
The 2 8? floppy disk drives are CDC BR8A8A type, looks like they are 800KB
double sided, double density drives. They?re very dusty.
Cheers,
Camiel
4 Jun
4 Jun
noon
On 06/04/2012 03:42 PM, Camiel Vanderhoeven wrote:
I?ve completed a list of boards in the P800 haul:
Very nice haul indeed...
My P856 has one CPU PCB, and one 32kx16 core memory on a single PCB ( drivers, X & Y ,
sense all one one board )
Date code is 1980, the newest core memory I have.
? FLDB : 5111 199 69667
This is the 8" floppy drive interface, you should be able to run a 50-wire flatcable
directly to the drive.
Regards, Jos
5 Jun
5 Jun
5:07 a.m.
On Mon, 4 Jun 2012, Jos Dreesen wrote:
Yes, but attention! This is *not* the Shugart layout; instead it's CDC
proprietary. You need to build an adapter in order to attach standard
Shugart drives (I've built one for our FLDB). And the FLDB (at least ours)
is single-density FM only (26 spt. 128 bytes/sect.)
Christian
PS:
Still looking for a floppy based OS.
? FLDB : 5111
199 69667
This is the 8" floppy drive interface, you should be able to run a 50-wire
flatcable directly to the drive.
9:32 a.m.
On Tue, Jun 5, 2012 at 11:07 AM, Christian Corti
<cc at informatik.uni-stuttgart.de> wrote:
Yes, but attention! This is *not* the Shugart
layout; instead it's CDC
proprietary. You need to build an adapter in order to attach standard
Shugart drives (I've built one for our FLDB). And the FLDB (at least ours)
is single-density FM only (26 spt. 128 bytes/sect.)
Going through the manuals I have on CDC drives, I already noticed that
the 50-pin pinout is different from the SA800 standard. The exact type
of drive I have (BR8A8A is not mentioned, although various BR8Axx
models are.
So, it looks like I have four different types of floppydisk controller:
- FLDB (8", built around 2 2901 bit slices)
- F1MB (8", built around N8X300I + N8X330N)
- modified F1MB (5-1/4", built around N8X300I + N8X330N)
- F1MBY (8", built around N8X300I + N8X330N)
The F1MB is described in my manuals, it's a controller for CDC 9404 or
9406 flexible 8" disk drives. It also contains the logic to control a
system operator panel (SOP). The F1MBY appears to be the same
controller, but with out the SOP interface. Now I need to find out if
any of them are a good fit for the CDC BR8A8A disk drives that I got.
Does anyone have any documentation on the FLDB card?
Tony, are you sure that the controller you thought was for X1215
cartridge disc drives wasn't instead an F1MB 8" floppy controller?
Cheers,
Camiel
? FLDB : 5111 199 69667
This is the 8"
floppy drive interface, you should be able to run a 50-wire
flatcable directly to the drive. 
3:43 p.m.
Tony, are you sure that the controller you thought was
for X1215
cartridge disc drives wasn't instead an F1MB 8" floppy controller?
It's possible I guess. but...
This board was in my P854 when I got the machine. There was also the
nromal 2-board stack (each a dulbe eurocard) that was connected ot a pair
of CDC floppy drives. The board I think was an X1215 controller had a
cabel plguged into it ending in the right conenctor fo such a drive, and
the guy who gave me the machine said it had be used with an X1215.
-tony
3:22 p.m.
Still looking for a floppy based OS.
What, for the P800s?
THey'll take some finding, but I should have the OS for my P851 (this has
32K words of MOS memory, a termianl interface and an FDC). I will see
what I can dig out.
Incidentally the manaul for my FDC board came with the CDC drive serivce
manual spileld inside :-) I ahve 2 of the Philips floppy disk unts, each
with 2 drives installed.
-tony
6 Jun
6 Jun
4:26 a.m.
On Tue, Jun 5, 2012 at 9:22 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
I'll second that request. On the P859, I got the floppy drive going.
Using the FLDB interface card, set to the correct CU address, I can
elicit head movements on the 8" floppy drive by doing an IPL from
device 03. Of course, I have no floppies for the P800s, let alone
IPL'able ones. Most of the 8" media I have is RX01.
Btw, Tony, I just noticed you have P850 in your e-mail address. I take
it this is unintentional?
Camiel.
Still looking
for a floppy based OS.
What, for the P800s?
THey'll take some finding, but I should have the OS for my P851 (this has
32K words of MOS memory, a termianl interface and an FDC). I will see
what I can dig out.
9 Jun
9 Jun
3:17 p.m.
On Mon, Jun 4, 2012 at 3:42 PM, Camiel Vanderhoeven <iamcamiel at gmail.com> wrote:
I?ve completed a list of boards in the P800 haul:
I've placed photographs of all the different types of boards on
http://p800.wikispaces.com/Boards. I've still got a few boards that
are unidentified. I've also got a few IC's that I can't identify:
TERNET-1701
RTC REC0612
RTC REC0612A
RTC REC613P
Anyone heard of these?
I've also got some Philips boards (6U eurocard size) with 8080 and
8085 CPU's and a single 64-pin (row A+C) DIN 41612 connector. Cards
are labeled "CRB 1" (8080), 3 x "CRD 2" (8080), "CRK 1"
(8085). Any
idea what these are, anyone?
Camiel
10 Jun
10 Jun
3:33 a.m.
Thanks for the pics.
Any idea why a 16 bits system would have a 21 bit wide semiconductor memory. ?
The core memory boards for the same system are 32kx16 bit.
Jos
5:40 a.m.
On Sun, Jun 10, 2012 at 9:33 AM, Jos Dreesen <jdr_use at bluewin.ch> wrote:
Any idea why a 16 bits system would have a 21 bit wide
semiconductor memory.
?
The core memory boards for the same system are 32kx16 bit.
I'm certain that it uses 21 bits so it can correct single bit errors
and detect double-bit errors. This is known as the Hamming code. For
16 data bits, it requires 5 parity bits.
Camiel.
6 p.m.
Any idea why a 16 bits system would have a 21 bit
wide
semiconductor memory. ?
ECC? Is 21 bits enough to detect and correct any
signle-bit error? 
6:15 p.m.
On Jun 10, 2012, at 16:38, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
Seems excessive... I seem to recall you need log2(n) - 1 bits, which would be 3 bits
(32-bit ECC needs 4 bits).
- Dave
Any idea why a
16 bits system would have a 21 bit wide semiconductor memory. ?
ECC? Is 21 bits enough to detect and correct any signle-bit error? 
6:45 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org
[mailto:cctalk-bounces at classiccmp.org] On Behalf Of David Riley
Sent: 10 June 2012 23:15
To: General Discussion: On-Topic and Off-Topic Posts
Cc: cctalk at classiccmp.org
Subject: Re: P800 boards
On Jun 10, 2012, at 16:38, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
Seems excessive... I seem to recall you need log2(n) - 1
bits, which would be 3 bits (32-bit ECC needs 4 bits).
- Dave
Memory often uses Hamming Correction so it can correct single bit errors and
detect multiple bit errors. I believe in this case for 16 bits of data you
need 5 bits of parity... (2**m-1)
http://en.wikipedia.org/wiki/Hamming_code
Dave Wade G4UGM
Illegitimi Non Carborundum
> Any idea why a 16 bits system would have a 21
bit wide
semiconductor
memory. ?
ECC? Is 21 bits enough to detect and correct any signle-bit error?
11 Jun
11 Jun
3:21 p.m.
On Jun 10, 2012, at 16:38, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
Seems excessive... I seem to recall you need log2(n) - 1 bits, which
would be 3 bits (32-bit ECC needs 4 bits).
Doesn;t that assume the 'extra' bits are known to be correct. Those can be
in error too (even if the'real' data bits are correct),
-tony
Any idea
why a 16 bits system would have a 21 bit wide semiconductor memory. ?
ECC? Is 21 bits enough to detect and correct any signle-bit error?
5:43 p.m.
Seems
excessive... I seem to recall you need log2(n) - 1 bits, which
would be 3 bits (32-bit ECC needs 4 bits).
Doesn;t that assume the 'extra'
bits are known to be correct. Those
can be in error too (even if the'real' data bits are correct),
12 Jun
12 Jun
3:43 p.m.
Seems
excessive... I seem to recall you need log2(n) - 1 bits, which
would be 3 bits (32-bit ECC needs 4 bits).
Doesn;t that assume the 'extra'
bits are known to be correct. Those
can be in error too (even if the'real' data bits are correct), 
6:02 p.m.
On 12 Jun 2012 at 20:43, Tony Duell wrote:
No, it doesn't. See Wikipedia's Hamming code page (asking for
SECDED redirects to it) for a brief treatment of the subject, or any
of many more detailed treatments of coding theory for more.
I am missing something here... The OP says that adding 3 bits to a 16
bit word is enough to be able to correct any single-bit error.
I think he meant +1 instead of -1 in the equation. So 5 bits, not 3.
But I assumed that he'd just copied it wrong from memory or source.
--Chuck
Seems
excessive... I seem to recall you need log2(n) - 1 bits,
which would be 3 bits (32-bit ECC needs 4 bits).
Doesn;t that assume the
'extra' bits are known to be correct.
Those can be in error too (even if the'real' data bits are
correct),
10:04 p.m.
On Jun 12, 2012, at 6:02 PM, Chuck Guzis wrote:
On 12 Jun 2012 at 20:43, Tony Duell wrote:
I am missing something here... The OP says that adding 3 bits to a 16
bit word is enough to be able to correct any single-bit error.
I think he meant +1 instead of -1 in the equation. So 5 bits, not 3.
But I assumed that he'd just copied it wrong from memory or source.
Faulty memory, in this case. I suppose I could use some ECC in the
wetware myself. :-)
- Dave
> Seems excessive... I seem to recall you need
log2(n) - 1 bits,
> which would be 3 bits (32-bit ECC needs 4 bits).
Doesn;t that assume the 'extra' bits are known to be correct.
Those can be in error too (even if the'real' data bits are
correct),
No, it doesn't. See Wikipedia's Hamming code page (asking for
SECDED redirects to it) for a brief treatment of the subject, or any
of many more detailed treatments of coding theory for more.
13 Jun
13 Jun
midnight
On 12 Jun 2012 at 22:04, David Riley wrote:
Faulty memory, in this case. I suppose I could use
some ECC in the
wetware myself. :-)
As my wetware dries out and I slowly evolve into a gibbering idiot,
it gets harder to remember what I worked so hard to learn. BCH
codes, for example. I spent a lot of time on them--and now I can
barely remember what the BCH stands for.
As one longtime friend would say "Don't get old--you won't like it."
--Chuck
1:48 p.m.
[Number of bits required for SECDED]
I think he meant +1 instead of -1 in the equation. So
5 bits, not 3.
But I assumed that he'd just copied it wrong from memory or source.
OK, that makes a lot of sense, and I agree it's possible to do SECDED on
16 bit word with 5 'extra' bits, as indeed these Philips boards seem to
do. I couldn't see how to do it with onyl 3 extra bits, and indeed it
appears it can't be done.
It was not my intention to insult anyone, of course. But if somebody
posts something that I can't figure out, I will ask about it. Most of the
time I'll be the idiot for not being able to figure it out, but by having
it explained I'll learn something.
-tony
12 Jun
12 Jun
7:10 p.m.
On Jun 12, 2012, at 15:43, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
No, it doesn't. See Wikipedia's Hamming code page (asking for SECDED
redirects to it) for a brief treatment of the subject, or any of many
more detailed treatments of coding theory for more.
I am missing something here... The OP says that adding 3 bits to a 16 bit
word is enough to be able to correct any single-bit error.
Now, consider those 16 'real' data bits. If any single one is in error,
that generates a new 16 bit word, and each of these much give the same
output 16 bit word after error correction. So it would appear to me that
there have to at least 17 possible input words (the 'correct' one, and
the 16 wach with one bit fillped form the corrrect one) that give the
same 16 bit output -- that is what is meant by correcting single bit erorr.
And yet adding 3 bits only gives you 8 times as many possible data words,
which doesn't seem enough.
I'm not actually the OP, just a respondent. In any case, I'd note that I qualified
it with "if I recall correctly", which can be a pretty major qualifier. :-)
- Dave
Seems
excessive... I seem to recall you need log2(n) - 1 bits, which
would be 3 bits (32-bit ECC needs 4 bits).
Doesn;t that assume the 'extra'
bits are known to be correct. Those
can be in error too (even if the'real' data bits are correct),
11 Jun
11 Jun
6:02 p.m.
On 11 Jun 2012 at 20:21, Tony Duell wrote:
Doesn;t that assume the 'extra' bits are known
to be correct. Those
can be in error too (even if the'real' data bits are correct),
Not necessarily--they're included in the Hamming distance, so a
single error, even in the syndrome bits can be corrected.
A 21 bit word for a 16 bit word will detect all single-bit errors but
a pure Hamming SECDED would require 22 bits (4 SEC + 1 added parity).
However, there exist other codes with SECDED properties--Hsiao codes-
-that will allow for SECDED in (21:16). I believe that the popular
(72:64) SECDED code is a shortened Hamming code.
--Chuck
12 Jun
12 Jun
12:32 a.m.
On Tue, Jun 12, 2012 at 12:02 AM, Chuck Guzis <cclist at sydex.com> wrote:
Time to get the terminology and math straight. Please forgive me if I
sound pedantic:
(31,26) (26 data bits + 5 parity bits) is a Hamming code. We only need
16 data bits, so we use (21,16), which is called a truncated Hamming
code. It's capable of single-bit error correction, but not capable of
double-bit error detection (or, more precisely, a double-bit error is
seen as an error in a third bit, which then gets "corrected", so a
double-bit error gets turned into a triple-bit error!).
By adding an extra parity bit to the Hamming code, you get an extended
truncated Hamming code (22,16). Extended Hamming is a SECDED code.
Hsiao code is another SECDED code. It uses the same number of bits as
an extended truncated Hamming code, but is easier to implement in
silicon.
A (72,64) SECDED code could be extended truncated Hamming or Hsiao.
SECDED can not be done with less bits (unless you increase the word
size of course).
Here's an example of a (21,16) truncated Hamming code:
0 000 1111010 11010
---------------------
1 0 0 0 1 1 0 0 1 0 0 - p1
=00 00 11 10 10 - p2
= 1000 1010 10 - p3
= 11111010 - p4
= 111010 - p5
---------------=-----
100100011111010111010
Cheers,
Camiel
Doesn;t that
assume the 'extra' bits are known to be correct. Those
can be in error too (even if the'real' data bits are correct),
Not necessarily--they're included in the Hamming distance, so a
single error, even in the syndrome bits can be corrected.
A 21 bit word for a 16 bit word will detect all single-bit errors but
a pure Hamming SECDED would require 22 bits (4 SEC + 1 added parity).
?However, there exist other codes with SECDED properties--Hsiao codes-
-that will allow for SECDED in (21:16). ? ?I believe that the popular
(72:64) SECDED code is a shortened Hamming code.
12:50 a.m.
It might have a sound technical reason to provide error-correcting RAM,
but only Philips would ignore the financial consequences of having to provide an extra 30%
of memory for that functionality.
Jos
4:06 p.m.
It might have a sound technical reason to provide
error-correcting RAM,
but only Philips would ignore the financial consequences of having to
provide an extra 30% of memory for that functionality.
I beelive soem VAXen also had ECC (SECDED) RAM. And doubtless other
machines (Zilog S8000s?)
There are plenty of cases where it's worth spending more at the start to
have soemthing that works reliably, even if the PC seems to have
eliminated that idea.
-tony
6:24 p.m.
On Tue, Jun 12, 2012 at 4:06 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
I beelive soem VAXen also had ECC (SECDED) RAM.
Yes. At the very least, the KA730 (11/730 and 11/725) and KA750
(11/750) used 39-bit-wide main memory. The 11/750 could take either
256K boards that also worked in an 11/70, and the 1MB boards fit in
all 11/730s and most 11/750s (the earliest models needed an extra
refresh wire strung along the memory backplane and an upgraded memory
controller or else they could only take the 256KB boards). I never
owned/ran the last rev of the 11/750 that had yet another memory
controller and could take up to two 4MB boards, but I have no reason
to believe they were not also 39 bits wide.
In thousands of hours of running that variety of memory board (a
couple square feet of 4164s for the 1MB model) in several machines, I
think I only ever saw one or two hard failures (double-bit errors). I
think we saw less than one correctable error per year. It was not
frequent.
-ethan
7:55 p.m.
On Jun 12, 2012, at 16:06, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
Plenty of PCs support ECC RAM. Generally on the server/workstation side of things, but
I'd hardly call it uncommon.
Of course, "working reliably" does involve a lot more than just eliminating bit
errors from cosmic rays, I'll give you that one.
- Dave
It might have
a sound technical reason to provide error-correcting RAM,
but only Philips would ignore the financial consequences of having to
provide an extra 30% of memory for that functionality.
I beelive soem VAXen also had ECC (SECDED) RAM. And doubtless other
machines (Zilog S8000s?)
There are plenty of cases where it's worth spending more at the start to
have soemthing that works reliably, even if the PC seems to have
eliminated that idea.
10:48 p.m.
On 12 Jun 2012 at 19:55, David Riley wrote:
Of course, "working reliably" does involve a
lot more than just
eliminating bit errors from cosmic rays, I'll give you that one.
I thought it interesting that the CDC 6600/CYBER 70 series did not
have any memory error checking whatsoever (the old "Parity is for
farmers" quote), but that the CYBER 170 series had semiconductor
memory and SECDED.
From my recollection, if the old systems passed
deadstart
diagnostics, the chance of seeing a memory error that day was very
small.
Was early semiconductor memory less reliable than core? I don't
recall that part.
--Chuck
13 Jun
13 Jun
6:58 p.m.
On Tue, Jun 12, 2012 at 07:48:18PM -0700, Chuck Guzis wrote:
On 12 Jun 2012 at 19:55, David Riley wrote:
Well, from what I'm currently reading in "Dealers of Lightning", very
early semiconductor memory was quite a bit less reliable than core,
coupled with miserable yields. Presumably both improved reasonably
quickly. It had the advantage of being smaller, cheaper and faster,
though.
Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Of course, "working reliably" does
involve a lot more than just
eliminating bit errors from cosmic rays, I'll give you that one.
I thought it interesting that the CDC 6600/CYBER 70 series did not
have any memory error checking whatsoever (the old "Parity is for
farmers" quote), but that the CYBER 170 series had semiconductor
memory and SECDED.
From my recollection, if the old systems passed
deadstart
diagnostics, the chance of seeing a memory error that day was very
small.
Was early semiconductor memory less reliable than core? I don't
recall that part.
8:43 p.m.
On 14 Jun 2012 at 0:58, Alexander Schreiber wrote:
Well, from what I'm currently reading in
"Dealers of Lightning", very
early semiconductor memory was quite a bit less reliable than core,
coupled with miserable yields. Presumably both improved reasonably
quickly. It had the advantage of being smaller, cheaper and faster,
though.
Wasn't the commodity DRAM chip back then a 22-pin 0.400" wide 3-
supply device--2107? I think that almost everyone made them.
Not a nice beast, IIRC, slow and power-hungry, with an inconvenient
+12 chip enable.
--Chuck
9:12 p.m.
On Wed, 13 Jun 2012, Chuck Guzis wrote:
Date: Wed, 13 Jun 2012 17:43:37 -0700
From: Chuck Guzis <cclist at sydex.com>
Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Subject: Re: P800 boards
On 14 Jun 2012 at 0:58, Alexander Schreiber wrote:
And strangely enough, still available... (NTE2107)
Peter Wallace
Well, from what I'm currently reading in
"Dealers of Lightning", very
early semiconductor memory was quite a bit less reliable than core,
coupled with miserable yields. Presumably both improved reasonably
quickly. It had the advantage of being smaller, cheaper and faster,
though.
Wasn't the commodity DRAM chip back then a 22-pin 0.400" wide 3-
supply device--2107? I think that almost everyone made them.
Not a nice beast, IIRC, slow and power-hungry, with an inconvenient
+12 chip enable.
--Chuck
14 Jun
14 Jun
7:24 a.m.
Peter C. Wallace wrote:
On Wed, 13 Jun 2012, Chuck Guzis wrote:
..have 2 or 3 Boxes of the russian equivalent K565RU1A, ~ 100pcs
just in case someone needs them. Gold/Pink Ceramics.
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Date: Wed, 13 Jun 2012 17:43:37 -0700
From: Chuck Guzis <cclist at sydex.com>
Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: P800 boards
On 14 Jun 2012 at 0:58, Alexander Schreiber wrote:
And strangely enough, still available... (NTE2107)
Peter Wallace Well, from what I'm currently reading in
"Dealers of Lightning", very
early semiconductor memory was quite a bit less reliable than core,
coupled with miserable yields. Presumably both improved reasonably
quickly. It had the advantage of being smaller, cheaper and faster,
though.
Wasn't the commodity DRAM chip back then a 22-pin 0.400" wide 3-
supply device--2107? I think that almost everyone made them.
Not a nice beast, IIRC, slow and power-hungry, with an inconvenient
+12 chip enable.
--Chuck
4:24 p.m.
On 14 Jun 2012 at 0:58, Alexander Schreiber wrote:
4K bits IIRC. Wasn't there a TMS4096 that was much the same thing?
Well, from what I'm currently reading in
"Dealers of Lightning", very
early semiconductor memory was quite a bit less reliable than core,
coupled with miserable yields. Presumably both improved reasonably
quickly. It had the advantage of being smaller, cheaper and faster,
though.
Wasn't the commodity DRAM chip back then a 22-pin 0.400" wide 3-
supply device--2107? I think that almost everyone made them.
Not a nice beast, IIRC, slow and power-hungry, with an inconvenient
+12 chip enable.
I suspect it was regarded as a huch improvement over the 1103 IK*! DRAM.
That thing was PMOS and has 16V logic levels on all pins (address, data,
seelct, etc). Intel did make some level shifter ICs to go with it (3207
and 3208 I think), but from what I revall, they came out significantly
later than the RAM itself.
Oh, and the 1103 needed +16V and +19V power rails, not particularly
useful for anything else in the machine.
Mildly off-subject, but there was the 1103 and the 1103A. IIRC, the
former needed a 'precharge' signal before every operation (after the
address was stable), the latter didn't, but the Precharge pin on the 1103
became a no-conenct on the 1103A so you could substitute the foremr with
the latter with no problems.
-tony
13 Jun
13 Jun
2:03 p.m.
Plenty of PCs support ECC RAM. Generally on the
server/workstation
side of things, but I'd hardly call it uncommon.
While a machien designed as a server might well have the same
architecture as a PC, and be able to run the same software, I am not sure
I'd call it a PC :-)
-tony
12 Jun
12 Jun
1:39 a.m.
Hello P800 people :-)
Came to think of that I have a CPU board originating from a PTS 6800. It
might well be of use for p800*s. The 12NC number is 5111-199-72373. It also
says on the label : AMX 32:FA11665 0183.
O n the board is a core assembly 3256977-02, config 32Kx16, coretype
1380-10d, s/n 11976
We do have a P6800 in store at the danish IT museum, but I dont think we'll
ever get it running again, so I'm willing to part with the board for the
cost of P&P
/nico
----- Original Message -----
From: "Camiel Vanderhoeven" <iamcamiel at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Tuesday, June 12, 2012 6:32 AM
Subject: Re: P800 boards
On Tue, Jun 12, 2012 at 12:02 AM, Chuck Guzis <cclist at sydex.com> wrote:
Time to get the terminology and math straight. Please forgive me if I
sound pedantic:
(31,26) (26 data bits + 5 parity bits) is a Hamming code. We only need
16 data bits, so we use (21,16), which is called a truncated Hamming
code. It's capable of single-bit error correction, but not capable of
double-bit error detection (or, more precisely, a double-bit error is
seen as an error in a third bit, which then gets "corrected", so a
double-bit error gets turned into a triple-bit error!).
By adding an extra parity bit to the Hamming code, you get an extended
truncated Hamming code (22,16). Extended Hamming is a SECDED code.
Hsiao code is another SECDED code. It uses the same number of bits as
an extended truncated Hamming code, but is easier to implement in
silicon.
A (72,64) SECDED code could be extended truncated Hamming or Hsiao.
SECDED can not be done with less bits (unless you increase the word
size of course).
Here's an example of a (21,16) truncated Hamming code:
0 000 1111010 11010
---------------------
1 0 0 0 1 1 0 0 1 0 0 - p1
=00 00 11 10 10 - p2
= 1000 1010 10 - p3
= 11111010 - p4
= 111010 - p5
---------------=-----
100100011111010111010
Cheers,
Camiel
--
I am using the free version of SPAMfighter.
SPAMfighter has removed 386 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len
Do you have a slow PC? Try Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen
Doesn;t that
assume the 'extra' bits are known to be correct. Those
can be in error too (even if the'real' data bits are correct),
Not necessarily--they're included in the Hamming distance, so a
single error, even in the syndrome bits can be corrected.
A 21 bit word for a 16 bit word will detect all single-bit errors but
a pure Hamming SECDED would require 22 bits (4 SEC + 1 added parity).
However, there exist other codes with SECDED properties--Hsiao codes-
-that will allow for SECDED in (21:16). I believe that the popular
(72:64) SECDED code is a shortened Hamming code.
2:09 a.m.
On 12 Jun 2012 at 6:32, Camiel Vanderhoeven wrote:
Time to get the terminology and math straight. Please
forgive me if I
sound pedantic:
Your comments were welcome--my post contents were colored by the fog
of time. I've since gone back and read Hsiao's 1970 paper and
understand things a bit better. I suppose to be complete, one could
also mention other codes that have been devised since Hsiao and their
benefits and liabilities.
--Chuck
10 Jun
10 Jun
6:16 p.m.
On 10 Jun 2012, at 1:38 PM, Tony Duell wrote:
It's enough for SECDED; it meets the famous D + P + 1 <= 2^P test.
--
Dr. Christian Kennedy
chris at mainecoon.com AF6AP | DB00000692 | PG00029419
http://www.mainecoon.com PGP KeyID 108DAB97
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
"Mr. McKittrick, after careful consideration..."
Any idea why a
16 bits system would have a 21 bit wide semiconductor memory. ?
ECC? Is 21 bits enough to detect and correct any signle-bit error?
4462
days inactive
4472
days old
38 comments
14 participants
participants (14)
-
als＠thangorodrim.de -
ard＠p850ug1.demon.co.uk -
cc＠informatik.uni-stuttgart.de -
cclist＠sydex.com -
chris＠mainecoon.com -
dave.g4ugm＠gmail.com -
ethan.dicks＠gmail.com -
fraveydank＠gmail.com -
holm＠freibergnet.de -
iamcamiel＠gmail.com -
jdr_use＠bluewin.ch -
mouse＠Rodents-Montreal.ORG -
nico＠farumdata.dk -
pcw＠mesanet.com