You might want to pull the mos memory and get everything down to one
backplane. I don't know who made the mos, but it might be causing problems.
I've also seen the backplanes and the foam under them cause weird problems.
shorten the bus as much as possible and see if things work better.
On Thu, Feb 27, 2014 at 3:01 PM, David Humphries <david at hheng.plus.com>wrote:
----- Original Message ----- From: "Rick Bensene" <rickb at bensene.com>
To: "General Discussion: On-Topic and Off-Topic Posts" <
cctalk at classiccmp.org>
Sent: Wednesday, February 26, 2014 1:02 AM
Subject: PDP 8/e, RK8E Weirdness
I'm hoping that someone here has some experience with PDP 8/e with the
RK8E disk controller for RK05 disk drives.
The 8/e passes all of the CPU diagnostics with flying colors. Memory
also checks out good. There are two fields of 4K core, and 4 fields of
solid state memory.
The core fields are field 0 & 1. Memory testing on both of the core
memory fields shows no faults. The system runs very cleanly...I've got
OS8 V3D on floppy and it can run for hours on end with no problems.
I have a known good RK05 drive and a number of 16-sector packs for it
that are good. RK8E and drive were tested in another 8/e system
recently, and worked fine.
Cable between RK8E and drive has been ohmed out, and it's good. Signals
going across the cable look good and clean on the scope.
The RK8E does not pass the Diskless Controller test in my system.
This is the test that uses the maintenance mode features of the RK8E to
test the controller without actually touching the RK05 drive (drive is
powered on, but in LOAD (offline) state). It goes though most of the
test, but fails in the data break tests. In these tests, the data break
is only active for one cycle, where one word is transferred to/from the
controller and main memory. All of the tests of the RK8E data buffer
test out fine. So, it appears that something is amiss in the
single-cycle data break handing...either in the RK8E, or the CPU's
handing of data break requests.
All data transfers between the RK8E and the PDP 8 are done via single
cycle data break (DMA) operations.
If I use RKLFMT to format a pack, it goes completely through the "write"
portion of the formatting without a hitch, and gets through a lot of
reads, but fails partway through the verification pass. The formatter
writes the block number of each sector as the first two words of each
sector, and fills the rest of the words with zeroes. The verification
pass just checks these two words to make sure they match. If fails when
the first word (high order disk address) changes from "0000" to
Through all of the tests, there are NO CRC errors. Seeking cylinders
and sectors work fine. It's just the "data" part of disk blocks that
gets messed up.
Using the FUTIL utility, I can successfully read and write blocks all
over the disk. I can use the "SCAN" function of FUTIL to scan the entire
disk, and it completes successfully. Thus, every sector on the disk can
be "found" by the controller without problem.
The problem symptom is that the first word of every block is duplicated
across all of the blocks. All of the rest of the words in the blocks
Using FUTIL, I can read in a block, change any but the first word in the
block, and write it out, then read it back, and it's fine. I can do
this with words 1 through 255 of any of the blocks on the disk.
However, if I read in a block, change the first word (word 0) of the
block, and write it out, then read it back, the first word is as I set
it to be -- but, if I read any other block, the first word is always the
same as what I wrote out.
For example, if I read in block 7, and change word 0 of the block to be
"4567", then write it out, then read any other disk block, word zero
will ALWAYS be "4567". If I then read in block 275, and modify word 0
to be "1234", and write it out, and then read back ANY (including block
7) disk block, the first word will always be "1234". I've tried this
with all different bit patterns for in word zero, and it's always
To verify that this isn't an issue with FUTIL, I wrote some little
routines to read and write disk blocks, and the behavior is the same.
The other disk test that uses the drive goes through all of the seek
tests and writes out its test patterns, but fails on the read-back
I'm very stumped. The RK8E uses single-cycle data break (DMA) to take
data to/from the disk and transfer it directly to/from main memory
without processor intervention (other than initiating the conditions for
the DMA cycle). The RK8E signals the processor that it needs to do a
data transfer, the processor relinquishes control of the memory system,
and lets the RK8E place address and data on the memory address bus and
memory data bus to read/write the data from/to main memory. Each word
of the transfer of a 256 word disk block is done as a separate DMA
One might thing that there is a problem with the RK8E, but that is not
likely, as this RK8E was recently tested in another system and worked
fine, passing all of the diags.
It's more likely that there is something amiss in the data break logic
in the CPU, however, it seems odd that it would affect only the first
word of a DMA transfer, as the CPU doesn't really know whether a DMA
transfer is the first word or the last word. It just responds to DMA
requests asserted by the peripheral.
Does anyone out there have any ideas what I could do to track this down
further? The RK8E is the only data break device I have in the system,
everything else uses programmed data transfers, so I can't try with
another data break device and see if the behavior is consistent.
Thanks in advance for any ideas as to what to do/try next,
that sounds like the problem I had with my RK8E, It manifested its self by
the data break address reguster bieg set to 1 greater than it should have
been after a load and therefor bieng 1 out after that, I think this could
give the symtoms that you have.
The cause was a race hasard in the generation of the load pulse whivh
resulted in a spike after the pulse, the pulse would load the correct value
then the spike would incrument it !!. Examiniation of the drawings shoed
that there had been several ECO's in this area so I think this may have
been a long standing issue. As its a race ie a timing issue, its quite
conceverable that it did not show in another system, mine sometimes worked,
I corrected the problem by adding a 4747 latch, this cured it.
Now this was some time ago so I will have to look at ( and find) the
sparce notes I made at the time, I can also look at my RK8E set to see
exactly what I did.
Not that its very informative but there is a pic of the spike here
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2247 / Virus Database: 3705/6630 - Release Date: 02/27/14