Probably clock timing issues. I have had similar problems like that before.Arne wrote:Yes. It's Stephan's patch with the 3 74xx ICs and I'm using the 2nd FF for generating 4MHz (MFP).exxos wrote:Assume the MMU is still running double speed there ?
This morning I switched the 520 on and got a perfect picture.![]()
But only one time. I was watching the memtest running as suddenly the picture scrambled again.
Switching on/off a dozen times didn't change anything. Used ice-spray to cool MMU/CPU down but to no avail.
I wasn't moving anything while the memtest ran - just watched. Okay, I didn't stop breathing...
I will order some IC's tomorrow and see if I can do some testing here. I think first step, is what you seem to have now. Just MMU running at 32mhz input. Though will need some attention on the 8mhz & 4mhz outputs as they will become 16mhz & 8mhz. What I will do is use some F74s to down the clock speeds back to proper speeds, then the only thing running faster the the MMU. I think they are about 12ns delay so should be fine. How I understand it, that should work, but give problems with video. But should be visible enough to try the floppy loading Gembench4.
Next step would be to cut the 8mhz line to the CPU and run at 16mhz constantly. If it boots (again with problem video) I can run GB4 and see if the RAM speeds boost in speed.
Both those tests seems impossible to work with what is currently known with the current booster projects. Though its possible if the MMU runs at double speed, its possible it could solve the 16mhz CPU problem. If both those tests work, then I can work on the DE patch.
Though if I understand correctly, you just have the MMU with 32mhz input ? CPU & GLUE have default stock speeds ? If that is the case, see if you can run GB4 and see what the scores are. You can save results to file with GB4. So if you make note of the keys to press you can save the results to file instead.