As far as I can tell there are only a few signals actually in play. But there are two failure modes:-
Mode 1; no write:
The DSP is meant to latch data on the rising edge of its chip select signal if RW is low, irregardless of the state of the CPU Clock (the CPU clock doesn't come near the DSP, and its own clock is, I believe outside of this process).
That CS signal is driven from the GALs by a combination of the address bus, the current state of AS and the state of AS in the *previous* cycle (this is, I think, the only clock depdenency and the source of the timing issues).
AS goes high (signalling when CS should dessert) once DSACK0 has been asserted, which is triggered from XDTACK from the motherboard, which is driven by almost exactly same logic as CS.
So, in total, the expansion interface lines involved in writing to the DSP are, I believe:
- XAS
- A[23:8]
- XRW
- XDTACK
- XCPUCLK
and the data bus - D[31:24] (8 bits).
I'm unconvinced by data bus instability as *any* successful write [even gibberish on the lines] should yield a change in the DSP registers.
Mode 2; partial success:
Certain combinations of delay time in the CPLD cause DMA2DSP and my sample ATARI.TOS program to pass but more complicated (eg. FRAC_DSP.PRG or BADMOOD) DSP demanding programs to fail.
Because of that odd old-AS dependency in the GALs, I've had to slow down access to the DSP (two consequtive cycles takes around 600ns instead of around 300). This could be the cause of it, but I suspect not as this technique did work in one of the previous boards.
I can get some builds where there is the occasional (once or twice per screen) failure in DMA2DSP suggesting it's not random (bus) noise, but related to the timing of the lines still.
I think we can probably again consider address bus noise unlikely as access to all other parts of the motherboard works, and I can scope the CS signal (which the address bus drives) clearly enough.
Again it seems to come down to timing, but timing of what? I can see the AS, CS, XDTACK, RW lines all appear clean, and, again, only CS, A and RW are meant to matter to the DSP, so something still remains unresolved.
This, or a variation on this (for the DSP) is probably worth doing as there are so few lines involved.Similarly using the scope on x1 slots next to capacitance onto various signals. And even using a fly lead with a 2.2K resistor on it to 5V then simply going across every CPU pin.
I can't rule it out, but I also can't see how it would only affect the DSP and how even gibberish is being ignored.It is quite possible you are just falling victim to a unstable bus. A slight bit of wrong capacitance or inductance in the wrong place and everything goes to crap.
Mmm. I don't have bus isolation, but I have delayed assertion of the motherboard copy of XAS until long after the CPU assertion of AS without joy. As mentioned above, I actually have to do this anyway because of the annoying GAL clock-based interference in the expansion port's communications.OTHO maybe designers did find such problems and do some elaborate workaround for it. For example when AS30 goes low, the bus is supposed to be stable. But maybe actually has not settled yet. In which case may be isolating the whole bus from the PLD internally ( not really sure if that is even possible) to unload a few pF from the bus, Then enable it several ns after AS30 goes low with the assumption it has actually settled at that point. I'm just thinking out loud really..
Certainly I can give that a go -- just because I can' see a mechanism for it to have an effect doesn't mean it's not worth trying!From years of upgrading these machines, changing the bus resistors is pretty much the root of all evil. At least for the ST series. As to if this is your problem or not.. I think it may be time to just bodge on some 2.2K's on the bus and see what happens. At least then you can rule out that problem.
Cheers,
BW.