PDP8/A memory problems, what to do?

From: Ethan Dicks <erd_6502_at_yahoo.com>
Date: Wed Dec 26 14:08:37 2001

--- Gunther Schadow <gunther_at_aurora.regenstrief.org> wrote:
> after dishwashing I reassembled my "new" PDP8/A and it's
> working again...

Congrats!

> My first PDP-8 program is a memory test...

Good idea. I have a couple of quick routines I use as a basic
check-out, once I know I can read and write from/to field 0
reliably - one is an inchworm for blinkenlights (or a counter
for the -8/a)

> I have 3 16k words boards and one 8k word board. Two of
> the 16k boards are good but both seem to want to play the
> role of the lower fields 0 to 3.

There are jumpers to "fix" that, if you want to run with two
good 16K boards.

> The third 16k board
> plays the high fields 4 to 7, but it has a systematic
> error masking out bits 6 and 7. All data X I write into
> it is read as X AND 7717. The 8k board has a similar bit
> mask error, it's mask is 6777. Is this a fatal problem
> or can one fix it by cleaning some contacts or redo some
> crummy soldering?

Could be bad data bus drivers/receivers. You'd need to trace through
the circuits to see if it's bad data getting _to_ the core or coming
from the core.

> I assume the core mats are all fine,
> because they would not just lose a few columns of data
> bits, right? I also assume that others had to deal with
> similar issues, because apparently such errors are not
> uncommon. What's the trick?

Well... I doubt the core planes are bad, but I suppose it's possible.
I would suspect the bus buffers first, then, depending on the exact nature
of the problem there are failure modes of the inhibit drivers that could
whack your bits as they pass through a memory read cycle, but that's
not horribly likely.

The trick is to sit there with the schematics and generate write cycles
and read cycles through the front panel as your trace the flow of bits
through the memory.

The good news is that with known working and known not-working bits, you
can write 7777 to the core and watch a working cycle on one part of the
board and compare it to the non-working part.

I cannot help you with hex-wide core memory schematics. I don't even
think I _have_ any PDP-8/a core anymore (had some once; sold to a
3rd-party reseller like Newman or one of those DEC dealers in MN or
somewhere; all I have for -8 core is pre-OMNIBUS and a little -8/e
core)

It's not cool like core, but did anyone ever come up with a modern
battery-backed-up SRAM board? I'm thinking of discussions of a few
years ago and talk about a quad-width OMNIBUS board w/2x62256 SRAMs.
Cheap to make (not counting a 1 sq. ft PCB), but compared to what we
used to pay for RAM...) and made with modern components. It may have
all been discussion without even a schematic generated, but I had to
ask.

> (I did swap them into various backplane slots, just to
> make sure it's not just a gap in the data bus lines.

I wouldn't be so worried about gaps as much as dirty/corroded
backplane slots. Checking in a couple of different places is
a good plan, as is simply reseating the boards to wipe the
fingers/backplane sockets.

> ... BTW, does the OMNIBUS need something like grant
> continuity cards for intermittent empty slots?)

No. Empty slots are fine.

-ethan


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
Received on Wed Dec 26 2001 - 14:08:37 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:41 BST