21 Jun
2004
21 Jun
'04
10:07 p.m.
On Jun 22, 2:04, Wai-Sun Chia wrote:
Hello list,
Just acquired a FPF-11, need to confirm cable layout for the
FPF-11/M8188 to the KDF11 processor:
The cable from what I've gathered is a straight cable from a 40-pin
BERG
to a 40-pin DIL connector.
Does this mean that:
BERG 1/A -> DIL 1
BERG 2/B -> DIL 2
: :
BERG 39/UU -> DIL 39
BERG 40/VV -> DIL 40
http://www.classiccmp.org/pipermail/cctalk/2003-October/028697.html
--
Pete Peter Turnbull
Network Manager
University of York
23 Jun
23 Jun
1:18 a.m.
New subject: PDP-8/E and PDP-8/M diff?
Just a quick one:
Apart from the chassis, the number of backplanes, and power supply, are
the 8/E and 8/M essentially the same?
Can boards/modules be swapped?
--
/wai-sun
9:43 a.m.
New subject: PDP-8/E and PDP-8/M diff?
The boards can be swapped. The only exception being the front
panel board. An 8/E front panel cannot be placed into a 8/M
or 8/F, since the necessary wires from the power supply that
drive the incandescent panel lamps is not present. However,
the front panel board from a 8/M or 8/F can be placed into
a 8/E if desired (Its a quick way to upgrade a 8/E to use LED's
instead of incandescent lamps).
If you're planning to gut an 8/M, I would be interested in
obtaining an empty chassis.
-Lawrence LeMay
Just a quick one:
Apart from the chassis, the number of backplanes, and power supply, are
the 8/E and 8/M essentially the same?
Can boards/modules be swapped?
--
/wai-sun
5:15 p.m.
New subject: PDP-8/E and PDP-8/M diff?
On Wed, Jun 23, 2004 at 01:43:52PM -0500, Lawrence LeMay wrote:
If you're planning to gut an 8/M, I would be
interested in
obtaining an empty chassis.
I'd be interested in an empty -8/f chassis as well... I already have
two KK8E board sets and several 4K and 8K core planes. An -8/m or
-8/f chassis would be the perfect place to put the second set.
-ethan
--
Ethan Dicks, A-130-S Current South Pole Weather at 24-Jun-2004 02:00 Z
South Pole Station
PSC 468 Box 400 Temp -80.4 F (-62.5 C) Windchill -112.9 F (-80.5 C)
APO AP 96598 Wind 7.3 kts Grid 087 Barometer 685.4 mb (10424. ft)
Ethan.Dicks(a)amanda.spole.gov http://penguincentral.com/penguincentral.html
24 Jun
24 Jun
5:48 p.m.
New subject: PDP-8/E and PDP-8/M diff?
Ethan Dicks wrote:
On Wed, Jun 23, 2004 at 01:43:52PM -0500, Lawrence
LeMay wrote:
Sorry guys. No such luck..
I just managed to acquire a empty 8/M chassis recently. A feat to say
the least.. PDP-8 parts seem to have all but dried up, and I'd expect it
to get worse.. :={
So now I'm on the lookout for 8E boards/module..
I was asking if I can use 8E boards in a 8M chassis with the H740 PSU.
All evidence so that it is possible, but the only thing is that the H740
lacks a 8VDC to drive the bulbs in the KC8E panel, right?
If that is the case, then it'd be a simple mod; I'll just whip up a 7808
via the 12VDC and feed it to the bulbs, should be workable..
If you're planning to gut an 8/M, I would be
interested in
obtaining an empty chassis.
I'd be interested in an empty -8/f chassis as well... I already have
two KK8E board sets and several 4K and 8K core planes. An -8/m or
-8/f chassis would be the perfect place to put the second set.
Ethan, would you be willing to part with 1 of your KK8E and perhaps 2 of
your MM8EJ? For a reasonable price of course, don't expect them to be
free.. :-)
--
/wai-sun
25 Jun
25 Jun
5:47 p.m.
New subject: PDP-8/E and PDP-8/M diff?
On Fri, Jun 25, 2004 at 10:48:49AM +0800, Wai-Sun Chia wrote:
Ethan, would you be willing to part with 1 of your
KK8E and perhaps 2 of
your MM8EJ? For a reasonable price of course, don't expect them to be
free.. :-)
I know I don't have a working KK8E, and I don't know about the memory. I
wouldn't be interested in selling anything until I get at least my -8/e
up and running. That won't be for a while - the next plane doesn't even
arrive for 4 months (and I'm not leaving for weeks after that).
Call it a year at least before I could even come close to giving you an
answer. I also have some PDP-8/a hardware to collect in Denver and KC
(at friends' houses). That'll be occupying a bunch of time right when I
get back.
-ethan
--
Ethan Dicks, A-130-S Current South Pole Weather at 26-Jun-2004 02:40 Z
South Pole Station
PSC 468 Box 400 Temp -79.8 F (-62.1 C) Windchill -114.4 F (-81.40 C)
APO AP 96598 Wind 8.4 kts Grid 068 Barometer 669.7 mb (11018 ft)
Ethan.Dicks(a)amanda.spole.gov http://penguincentral.com/penguincentral.html
24 Jun
24 Jun
5:53 p.m.
New subject: Core volatility
I have MM11-DP (16kW parity core) in my /04 which seems to have a little
problem.
Several locations which I've checked seems to be losing content (core is
supposed to be non-volatile). I've been debugging custom bootloaders
for the past week and it has since gone past annoying. It's like 3
locations out of 50 that are always reverting back to 000000 after a reboot.
Perhaps it's the driver logic to these 3 particular cores that are not
functioning properly? Or is it the cores itself?
--
/wai-sun
25 Jun
25 Jun
1:07 p.m.
New subject: Core volatility
>>>> "Wai-Sun" == Wai-Sun Chia
<waisun.chia(a)hp.com> writes:
Wai-Sun> I have MM11-DP (16kW parity core) in my /04 which seems to
Wai-Sun> have a little problem.
Wai-Sun> Several locations which I've checked seems to be losing
Wai-Sun> content (core is supposed to be non-volatile). I've been
Wai-Sun> debugging custom bootloaders for the past week and it has
Wai-Sun> since gone past annoying. It's like 3 locations out of 50
Wai-Sun> that are always reverting back to 000000 after a reboot.
Wai-Sun> Perhaps it's the driver logic to these 3 particular cores
Wai-Sun> that are not functioning properly? Or is it the cores
Wai-Sun> itself?
Or a bug in your program is clearing those three words?
It seems mighty peculiar for a hardware problem to consistently turn
three words to be all zero. (Then again, what was the original
contents? Losing one bit is possible -- losing many bits is
unlikely.)
Given how core works, if you can write it, then read it several times,
and it produces the right answers, it is REALLY unlikely that the bits
would just go away by themselves after that.
I can imagine some "bit rot" mechanisms, though it's a stretch -- but
those wouldn't work in nice whole-word patterns.
paul
26 Jun
26 Jun
8:02 a.m.
New subject: Core volatility
It's possible, but I'd be surprised if it were anything but software.
Many DG Nova programmers umm discovered a feature of locations (I think)
40 through 47, what we locally called the auto-excrement. The factory I
believe called them auto-increment and auto-decrement.
An indirect memory reference in this range Xcremented the value there
after reference. It was intended as an index-register-like feature, and
was a terrible place to put a return address stack.
tomj
Cores can die (intrinsic flaw, damage, overheat, etc) but it's
awwwwwwfully suspicious that all the bad bits are in the same word...
cores are manufactured in bit planes and wired into words, they have no
other relationship.
Core drivers could fail, but again all in the same words? Usually a
whole column will drop out and you'll see the Nth bit bad in some
largeish address range.
On Fri, 2004-06-25 at 15:07, Paul Koning wrote:
>>>> "Wai-Sun" == Wai-Sun Chia <waisun.chia(a)hp.com> writes:
Wai-Sun> I have MM11-DP (16kW parity core) in my /04 which seems to
Wai-Sun> have a little problem.
Wai-Sun> Several locations which I've checked seems to be losing
Wai-Sun> content (core is supposed to be non-volatile). I've been
Wai-Sun> debugging custom bootloaders for the past week and it has
Wai-Sun> since gone past annoying. It's like 3 locations out of 50
Wai-Sun> that are always reverting back to 000000 after a reboot.
Wai-Sun> Perhaps it's the driver logic to these 3 particular cores
Wai-Sun> that are not functioning properly? Or is it the cores
Wai-Sun> itself?
Or a bug in your program is clearing those three words?
It seems mighty peculiar for a hardware problem to consistently turn
three words to be all zero. (Then again, what was the original
contents? Losing one bit is possible -- losing many bits is
unlikely.)
Given how core works, if you can write it, then read it several times,
and it produces the right answers, it is REALLY unlikely that the bits
would just go away by themselves after that.
I can imagine some "bit rot" mechanisms, though it's a stretch -- but
those wouldn't work in nice whole-word patterns.
paul 
25 Jun
25 Jun
1:14 p.m.
New subject: Core volatility
I have MM11-DP (16kW parity core) in my /04 which seems to have a little
problem.
Several locations which I've checked seems to be losing content (core is
supposed to be non-volatile). I've been debugging custom bootloaders
Core is non-volatile, but readout is destructive (you read a core by
writing a 0 to it and seeing if there was a change in flux through the
core). One PDP11s (and on just about every other mini I've worked on) the
core memory hardware restores the old contents after a read (Actually, on
a PDP11 it's more compiicated than that. There's a particular type of
read cycle -- a DATIP cycle -- where the processor ias actually going to
do a read-modify-write to that location in core, and the next bus cycle
is going to be a write to the same location. The DATIP cycle tells the
core contol electronics not to waste time doing the restore since it's
going to be overwritten anyway)
for the past week and it has since gone past annoying.
It's like 3
locations out of 50 that are always reverting back to 000000 after a reboot.
Between reboots can you read that location as many times as you like? In
other words is the restoration circuit working correctly? (I would guess
it was, because it's common to all locations in the memory, but maybe
marginal drive currents can cause problems).
Perhaps it's the driver logic to these 3
particular cores that are not
functioning properly? Or is it the cores itself?
I can't think of any reason why particular locations should be getting
cleared by a reboot. Addressing is done by an XY matrix kind of scheme,
so a problem with the address drivers would normally affect an entire row
or column (And anyway, why would it only show on a reboot). Are you sure
no software is overwriting these locations?
-tony
1:16 p.m.
New subject: Core volatility
Core isn't non-volatile! The contents of core memory is destroyed
everytime you read it. The computer has to restore the contents after every
read. I don't know if this is handled in the read/write circuitry, the
controller or by the CPU but I expect that the read/write circuitry does
it. It sounds like whatever is supposed to be restoring the contents of
those locations is bad. If you can store both 1s and 0 in each location and
then read them back then it appears that the cores and the write circuits
and read circuits are all working. But somewhere in there is something that
feeds the read data back to the write circuits so that it can be restored,
I suspect that that's where your problem is. Let me know what you find
when you find out the source of the problem.
Joe
At 10:53 AM 6/25/04 +0800, you wrote:
I have MM11-DP (16kW parity core) in my /04 which seems to have a little
problem.
Several locations which I've checked seems to be losing content (core is
supposed to be non-volatile). I've been debugging custom bootloaders
for the past week and it has since gone past annoying. It's like 3
locations out of 50 that are always reverting back to 000000 after a reboot.
Perhaps it's the driver logic to these 3 particular cores that are not
functioning properly? Or is it the cores itself?
--
/wai-sun
26 Jun
26 Jun
8:08 a.m.
New subject: Core volatility
Run diagnostics overnight to check core. Diags of this vintage actually
do something.
On Fri, 2004-06-25 at 15:16, Joe R. wrote:
Core isn't non-volatile!
(Umm no, that's just the destructive-readout method, industrially proven
to be the cheapest way to handle core memory. There are other
non-destructive schemes but they cost too much to make.)
25 Jun
25 Jun
1:52 p.m.
New subject: Core volatility
With "after reboot" do you mean a power off, power
on cycle?
Core memory is critical while power off/on.
If power fails after the read cycle and before
the refreshing write cycle then the contents is lost.
So maybe you have problems with the power supply or
the power fail logic.
Just my 2c
Gerold
Wai-Sun Chia wrote:
I have MM11-DP (16kW parity core) in my /04 which
seems to have a little
problem.
Several locations which I've checked seems to be losing content (core is
supposed to be non-volatile). I've been debugging custom bootloaders
for the past week and it has since gone past annoying. It's like 3
locations out of 50 that are always reverting back to 000000 after a
reboot.
Perhaps it's the driver logic to these 3 particular cores that are not
functioning properly? Or is it the cores itself?
7365
days inactive
7369
days old
12 comments
9 participants
participants (9)
-
ard＠p850ug1.demon.co.uk -
dickset＠amanda.spole.gov -
gerold.pauler＠gmx.net -
lemay＠cs.umn.edu -
pete＠dunnington.u-net.com -
pkoning＠equallogic.com -
rigdonj＠cfl.rr.com -
tomj＠wps.com -
waisun.chia＠hp.com