I was looking at the ste combo schematic and found the clock dividers. Interestingly the reset lines are all tied ultimately to a test pin. I assume its there to allow the debug guys to start the machine from a known state each time. Doesn't help with the ST MMU, but just thought I would look anyway.
I have tried various delays on all the clocks. I used a LS04, so could flip clocks out of phase or use 2 inverters to add a delay. Basically nothing helped.
I did hook up the 161 to the MMU clock to rule out MMU wait states.. Well kinda,. But that still didn't work. It did shift the video a few pixels to the right and wrap around, but those issues I had years ago when doing the mod tests. It seems if the glue is slightly behind the MMU clock it causes shifts in the video.
So while we know the clocks shift on the MMU, I am thinking its not the main cause of issues. Most of the time it seems to be the DMA malfunctioning. So assuming the glue is causing the MMU to confuse what is accessing ram, ie CPU or DMA.
Of course is the MMU and GLUE have random startup states, and I introduce then clocks with the 161, there's no surprise things are going nuts. But again, running from the MMU clock into the 161 should really help solve some issues.
The one solution I can come up with, is to forget the 161 and just down clock the MMU clocks directly with their own flip flops. This doesn't work as a few ns causes the glue to skew the video. So my thought is to go via a flipflop to half the clocks, but then have a inverter to flip the clock out of phase, and add in a adjustable delay line, maybe 5ns steps to realign the clocks again. So the propagation delays are corrected.
As to if that would correct the issues I am skeptical, again as using the MMU clock to drive the 161 didn't help, and that clock would include the wake up states as a stock machine would. So I don't think its simply a clock sync issue.
I think its more as the MMU is running double speed, and the GLUE is still running 8mhz that the MMU may be thinking it can do a DMA cycle when it actually can't. It would be like the glue tells the MMU its got a DMA cycle, so it holds off the cpu and triggers the bus isolators to the cpu... Twice as fast.. Where the cpu may not have finished its cycle yet. I have seen some odd stuff with some graphics missing on boot so maybe that's a clue.
Another probably bad idea , to switch the MMU to stock speeds during any bus grant activity.. But not really a good option either. I mean the system works fine when it starts up OK, so its not like the system can't work that way.
Mostly just thinking out loud with all this. While there are multiple issues, if the DMA issue could be figured out, then that would be half the battle.
EDIT: I may check the phases of the 161 generated clock vs the GLUE generated clock to see if that is shifting in phase causing the issue...