A couple more tests, not much help though.
I swapped the 100R resistor in the CPU clock line to 68R. Now the rise and fall are a lot faster and now it only boots at all with the scope probe on the clock pin
So, I changed the CPU. This one gave 102% speed before it crashed out.. Oddly the same tests gave 99% on the previous CPU.
So then I changed the GAL which wouldn't work before, and now it boots fine and now shows a stable 100%. The GAL in question only really drives the CPU clock. So looking closer this GAL has 20ns delay the others which worked fine had 12ns delay.
How this looks to me is the 8mhz clock is causing speed variations. Clearly the load of the scope probe is having huge impact on whats going on. So its possible different CPUs are putting different loads on the 8mhz clock causing these variations in speeds. The scope probe isn't currently on the board and now it works with a different CPU.
It seems if the 8mhz clock is a few ns faster , the CPU runs faster and its more prone to crashing. A few ns slower and things are more stable and show 100% scores, not unstable 102%.
I will try and find a IMP MMU, I have a feeling the rise and fall times are a bit faster on those, which is why they generally suck , ironically
Put in the other CPU and now that is now also showing 100% scores! Stable in 16mhz and 8mhz!
Tried both CPU's at 16mhz, both done several tests and all solid 100% scores. Just changed the CPU for a 3rd one, its done 5 full benchmark passes and still 100% scores.
So it seems to be, that if the CPU clock is 100% in sync with the master 8mhz (aka stock machine) it of course is all happy. Up to somewhere around 10ns delay on the clock, something starts going a bit wonky where I then get random values which can be anything between 95% - 103%. Its never crashed like that, just random scores. So now delays from around 20ns it all seems happy again and get solid 100% scores.
So for whatever reason, something doesn't like the CPU being somewhere around 10-20ns out of sync with the master 8mhz clock. Pretty much should just say 15ns delay causes the issue
This probably explains why I had such varied results when I first did my 32mhz testing and it only worked with 1 particular GLUE chip. Any other GLUE chip an 32mhz either didn't work at all, or wasn't stable.
Still no idea why its doing that, but at least it seems to be related to the 8mhz clock sync with the CPU.
You do not have the required permissions to view the files attached to this post.