sdisla wrote: 16 Aug 2024 21:06
DSACK1
Well, that's better -- previously you reported DSACK1 was always low.
But I'm not enamoured with that trace. Unfortunately I don't have my Falcon on the desk else I'd be interested to see if my DSACK1 asserts for such a little time before pulling high too.
Anyway, we've established you've not got a problem with STERM or DSACK0 asserting when they oughtn't, so I think we're back to address lines and data lines.
Basically: A1 isn't counting up when it should be and A2 is counting like A1. There's also problem on the top data line, but that feels a bit secondary at the moment.
I'm not sure what more to recommend to you. You could try removing all the GALs in sockets from the front of the board (and the one up by the DSP) and probing AS/A1 again just in case one of those is pulling down the bus (but label them properly -- they need to go back in the right place!)
That's a bit of a 'well why not?' attempt, though. Just as they're socketed. I think we need to find a smoking gun on the address lines.
I know what I'd do next, but then I've got a lot of bits of half-built boards, logic analysers and bits and pieces lying around that make it easy: I'd run a wire from BGK and BR on the expansion header to ground, power on and check to see if CPUBGO is held low (one of the pins under the jumper on the expansion header) and if it were, assume the bus is quiescent and start injecting 0V onto each line and measuring the others.
BUT I don't want you to blow up your machine, so I'd just suggest you continue looking for cross-contamination between all address lines. Perhaps paying attention to the pull-up resistor packs, but that's just a guess.
Sorry, I think we may have gone beyond the ability to remotely debug now unless you stumble across a definitive short on the board.
BW