Ongoing debug of RL8A controller
charlesmorris800 at centurytel.net
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
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