I copied literally thousands of files in 8Mhz and 32MHz mode. Which took ages. They just started to repeatedly fail. I sprayed the GAL with freezer spray and it did continue fine for a little while again. However it is very odd that the same problem happens in 8MHz mode.
I bypassed the first 8MHz buffer on the board again and repeated the tests and it failed in exactly the same way. So while I have been thinking the delay of the CPU clock might have been a issue, I'm half thinking otherwise now. The previous tests were done with old Pico firmware, so they could possibly not be valid now anyway. Because when I did the tests before, I jump it over the GAL and it made no odds.
I have copied several hundred files about with the GAL bypassed and so far its working..
Even though the GAL does get rather hot, it does not particularly have a hard life in the booster anyway. I use minimal stuff really. They even took out a bunch of 32MHz clocked DFF's to see if that would reduce the thermal aspects but was unsuccessful.
I'm starting to wonder now if may be the 32MHz clock itself to blame, because it basically has 2V negative undershoot. I wonder if this is causing the GAL to heat up and malfunction. I will see if I can investigate that aspect next.
The datasheet does say the input voltage can be -2.5V though.
GAL22V10 devices are designed with an on-board charge pump
to negatively bias the substrate. The negative bias is of sufficient
magnitude to prevent input undershoots from causing the circuitry
to latch. Additionally, outputs are designed with n-channel pullups
instead of the traditional p-channel pullups to eliminate any possibility of SCR induced latching.
