On Dec 26, 12:08, Ethan Dicks wrote:
> --- Gunther Schadow <gunther_at_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
Received on Wed Dec 26 2001 - 18:26:22 GMT