Ongoing debug of RL8A controller

Charles charlesmorris800 at
Fri Sep 4 13:24:05 CDT 2015

I still can't get my RL8A (M8433 RL01/02 disk controller card) working again 
in my 8/A system. It won't boot from the RL02 any more.

In my backplane I found it to be mechanically sensitive (AJRLAC diskless 
controller test would show errors always involving bits 4-7 being 
unexpectedly 0's), and when the card was flexed gently the errors would 
increase dramatically during the test. No visible bad/missing solder joints 
or broken traces.
Recently I sent the card to a list member who tried it in his system. He 
could boot OS/8, but when attempting to open a file with EDIT the system 
would crash. This behavior was repeatable and did not occur with his 

I now have SerialDisk running via Omni-USB, emulating two RK05 drives from 
my laptop, booting OS/8. This works perfectly - until I put the RL8A in the 
Then the system won't boot and also corrupts the first part of the boot 
loader that resides at 0020-0045.
However, only the first 7 instructions at 0020-0027 are mangled, and all 
seven words have their most significant six bits set to 0 (for example, 7240 
becomes 0040).

The selects to the various 8234's (open-collector drivers to the data bus) 
are working properly in a scope loop. Figured I was on the right track with 
a bad 8234.
I physically disconnected the middle 4 bits of the DATA0..11 bus (at the 
extender card rather than hack up the board)... system still won't boot, 
still corrupting locations as described.
Next, I disconnected the entire data bus, all 12 bits, same problem! So 
whatever is the trouble it's NOT an 8234 pulling on some of DATA0..11 as I 

I am starting to think there is a defect with the DMA (aka Data Break) 
facility on either this card OR even the CPU itself...  everything else in
the system is programmed I/O, not DMA.

Obviously something is pulling down the memory-data bus when it shouldn't 
be, and writing zeroes over the upper six bits of some words, but on this 
controller card there are only inputs from the memory data bus MD0..11. It 
has its own memory address registers for DMA which drive the MA0..11 lines.
I checked the various signals coming out of the card and (at least 
statically) none of them are in the "wrong" state...

Any thoughts on testing the DMA facility?

More information about the cctech mailing list