On 9/12/2015 10:08 AM, Charles wrote:
So, either
something is corrupting the bus, or the memory is bad.
Correct me if I'm wrong, but if I got this right, you wrote the boot
code by hand into memory, single-stepped it, and after a while, you had
bad contents in memory.
Now, execution here would only be reading from memory, and not writing
to it. Furthermore, this is MOS, so it does not get rewritten on reads.
That would, to me, suggest that the memory board is the problem.
Do you have any other memory board around?
Johnny
I mistyped while doing many things at once.
(It appears that the memory does NOT change while single stepping
through it by hand. Fortunately.)
See my update - reseating the ROMs fixed the boot corruption problem.
I am not sure if the 32K SRAM board actually reads and rewrites - it
does not do so internally, it's just SRAM and a couple of bus buffers.
Whether the 8/A memory cycle does rewrite each time or not, I don't know.
Now I've got yet another RL02 (maybe) problem to chase down...
-Charles
When Mos memory was added to the Microdata 1600, the read / write was
not modified, and provision had to be made for sequences in microcode
which expected a n 0xFF pattern in the memory during half cycle writes.
Not sure if that is relevant to the PDP8, but it was a problem with
introducing memories that didn't need rewrites, that all such had to be
tracked down and recoded.
Such residual logic to do writes or drive the bus during read operations
could mess up memory contents till CPU's were redesigned to use MOS
exclusively.
Since the problem sounds to be happening on boot, is is possible to halt
the processor at the end of the boot an read code and see if the
contents are corrupted then, and also at the end of the boot before
proceeding past the boostrap code in memory?
Hand modification of the disk contents to a halt at the first
instruction, then hand modify the end of the disk boot sector contents
to halt before jumping out of the boot code to continue on to the OS?
thanks
Jim