I can only really think that the CPU will have to write start and end address of block to clear into a register. Then the MMU will clear that block, and likely send DTACK to CPU when clear is finished. Exactly. That wouldn't break any existing code (bar any miswrites to that previously not used reg...

exxos wrote: ↑Tue Sep 11, 2018 4:22 pmI don't know if that would break raster stuff still with a faster screen clear ?

It would have to be addressed in a new way to not break old code.

Yeah analogue is where I'm lacking all knowledge. Adding a fat ground wire is an immediate thing I can check of course.

Ringing backwards on VSYNC causing GLUE to trip up is actually the best explanation so far as to what can happen that causes _resets_ always

If troed has a diagnostic cart, might be worth running with that to see if any bad bits in RAM test show up before the reset.. I'm thinking bus loading issues when the FPGA is installed... Might also be worth running VSYNC via a 100R resistor as well... Yeah I have. Although if that was the problem...

exxos wrote: ↑Sun Sep 09, 2018 11:43 pm Very odd...

What board exactly are you using ? I can try and find same board here to try out..

C070243 REV.I (520STM)

Even if there's something different with my FPGA prototype compared to yours I still don't understand how ...

This is on a stock machine - the 520. Ah, so you have the reset problem with your doubleST AND a stock 520 ? Yes. On the 520 the clocks are generated by the FPGA, using the Shifter socket clock_out for the rest of the ICs. On the doubleST the clocks are generated by the GAL, for all ICs including t...

exxos wrote: ↑Sun Sep 09, 2018 9:54 pm Probably is a good idea to try on a stock machine as well.. I would assume it will work fine (as it does on my STFM).

This is on a stock machine - the 520.

(The video should be a standard .mov - but I'll recode to mp4 container as well)

Shot a video just to show what I mean with "spontaneous resets". This is without touching anything. Disregard the failed video mode at some resets, that's not relevant (unless it indicates something about what happens, I don't know) - it's the resets themselves that are of interest. https:...

This is a bad fix.. But it solves my problem.. Where ever that 16MHz is going (middle right pin of U2) it needs 100R in there.. (I've now reverted my FPGA to "stock" with the idea that if I solve what causes the resets on my 520 that might help in finding out why they happen on my doubleS...

If it's not fun, then don't do it.

*thumbs up*