On Dec 26, 12:08, Ethan Dicks wrote:
--- Gunther Schadow
<gunther(a)aurora.regenstrief.org> wrote:
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 do that too. I also have a couple of very short toggle-in programs for
the console serial line, one of which echos what you type. The last item
I have that might be useful is a uploader that sends files, either plain
or papertape images, to the RIM or BIN loaders -- it's on Kevin
McQuiggin's page at
http://highgate.comm.sfu.ca/pdp8/software/new-send.c
> The third 16k board
> plays the high fields 4 to 7, but it has a systematic
> error masking out bits 6 and 7.
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.
I'd agree with that. It's more likely a logic problem than a core mat
problem.
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.
Yes, I've got one. It even has a connector to link to an interface in a
PC, so you can squirt (or suck) data in (or out) directly.
--
Pete Peter Turnbull
Network Manager
University of York