I'm hoping that someone here has some experience with PDP 8/e with the RK8E disk controller for RK05 disk drives.

The RK8E does not pass the Diskless Controller test in my system.

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.

Thanks in advance for any ideas as to what to do/try next,

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 "0001". 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 behave properly. 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 consistent. 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 tests. 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 request. 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, Rick Bensene

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