Started digging into the broken BBC Master 128 I have. Previously I’d replaced a failed Video ULA, which at least got the right clock signals in the right places.
This time around I observed that the /IRQ input pin was stuck low on the CPU - ie, an interrupt was being generated. That signal appears on the 6850 (IC45 pin 7), the user 6522 VIA (IC6 pin21), the system 6522 VIA (IC8 pin 21), and the custom memory controller IC (IC20 pin 29).
I also noticed that A2 was behaving strangely, D4-D7 were behaving strangely, but D0-D3 were looking OK.
Chasing the stuck IRQ line, which should normally be high thanks to the pullup resistor, I yoinked the 6522 at IC6 - no change. The 6522 at IC8 - no change. The 6850 at IC45 - no change. Which leaves - crap - the memory controller at IC20, which is a custom Acorn chip which of course is no longer made and hasn’t been since forever.
But, as I write this, it occurred to me that it’s likely that the /IRQ pin might not be wedged low, but may be triggered as the result of a legitimate interrupt (from the memory controller, since it’s the only thing still connected to that pin), and that the CPU isn’t handling it because the CPU is faulty… I’m not sure what causes the memory controller to raise an interrupt, but I think I’ll have to hook up the logic analyser to see if /IRQ is always low, or just goes low briefly after /RST goes high.
Also, as far as I’m aware, the 6502 boots with interrupts masked, so it would be ignoring the /IRQ pin anyway!
The strange behaviour on D4-D7 also made me think of a RAM issue, since D0-D3 are serviced by 2 of the RAM IC’s, and D4-D7 are serviced by the other two. Poking around the RAM with the scope I noticed that /CAS was stuck high.
Replacing IC34 (74S00 - quad NAND) sorted the /CAS signal on IC17/IC23. It was replaced with a 74LS00, but I will have to order a 74S00 as I epxect the timing differences will be significant in this application (the LS is about 10ns slower IIRC).
At this point /CAS on IC18/IC26 was stuck high, but after removing those 4464’s it was still stuck high - I think this might actually be expected behaviour, so the 4464’s went back in.
I’m still not confident the RAM is good, but they weren’t what was pulling /CAS high. When I first got the machine the Video ULA had failed, resulting in no /RAS or /CAS activity, which I believe can be fatal to the 4464 DRAM IC’s (due to heating) if powered up for too long in that state.
I also observed no activity on the SYNC pin on the 65C12 (but there is activity on the RDY input), so there’s a chance the CPU is baked. Had I thought about the IRQ behaviour earlier, I probably would have pulled the CPU first :-(
So next up I’ll track down a new 65SC12P-2 CPU, and a fist full of 74x00 quad NAND IC’s - this machine uses at least the S, F, and LS variants and they each have different timing and fanout characteristics. I can’t imagine Acorn used 3 variants in the bill of materials for no reason…
