I had it looping on memory test for about an hour last night and it ran fine at 40 MHz. So I think the CPU can actually run at this speed without issues. However I was still getting intermittent crashes during ROM access.
So today I added in a extra 10k resistor pack onto the address bus. When the diagnostic cartridge is in place it no longer triggers the ROM error. However, it was still crashing on ROM test pretty much all the time, and intermittently during mostly VDI text tests.
So next I added in a extra 10k onto the databus, and currently (now I am just going to jinx this
) 5 full test loops on GB6. Before it would only do one or two without crashing.
So currently the address bus has 4.7K (stock) + 2.2K + 10K = 1.3K.
The databus has 10K (stock) + 2.2K + 10K = 3.3K.
- IMG_2419.JPG (60.18 KiB) Viewed 4909 times
EDIT:
OK it crashed on loop 6
So I will remove the 10k the databus and use a 4.7K this time.
10K (stock) +2.2K +4.7K = 1.3K
EDIT2:
I still have some stability issues seems
so I have gone back to the start and removed the ROM chip select line ,so the ROM runs at 8 MHz. This ran for about half an hour so I seen this is now stable, which it wasn't before. So obviously changing the resistor packs as improved things a little bit least.
So I have gone back to adding in some DTACK delays onto the ROM access... And now it seems looking a very slow loop of drawing and clearing these pixel line is one of the tests...
- c1.jpg (59.02 KiB) Viewed 4898 times
Overall the benchmark figures are slower than the 35 MHz tests which is actually stable.. So I'm not sure what I am missing with all this
I'm starting to wonder if the ROM chip select signal is falsely going low due to some noise on the bus, or simply a glitch in the GLUE logic. It would only have to go low for a few ns to switch the booster into high-speed which could be causing the random lock-ups. So likely later I will try running the ROM chip select line through a couple of delays so that any glitches should be ignored..
Currently I have disabled the reset code in the GAL. Normally when you press reset button it forces the GAL to 8 MHz mode. With this removed, I had trouble getting the machine to boot up, but now it is looping through all the tests again and we shall see what happens this time.. I'm thinking possibly even the reset line would glitch just enough to throw the booster into switching speeds when it's not supposed to be. Of course this should not actually matter as the switching should go to 8 MHz anyway.. But as this is a reset for a FF , then it could be possible it could glitch the CPU clock... But leave no stone unturned as they say...
EDIT3:
So reset is not a issue..
I also currently have about 50ns delay on DTACK and ROM_CS.. Still it is not stable..
I would basically think that the ROM chip itself not fast enough.. I know the timings were very tight when I was doing 32 MHz. So maxing out at 35 MHz makes sense.. 40 MHz simply pushes it over the edge... But this should be counteracted by slowing down DTACK giving the ROM more time to settle before CPU reads the bus ... But this does not seem to be working, and I have checked that the delays are there.. I think if anything is now working worse now ROM_CS is delayed..
So I will one do the changes and go back to the best working code.. But how it looks, I do not think 40 MHz is simply going to work for some reason
Anything could possibly be is that the CPU can run for short bursts at 40 MHz, but with the ROM in the mix as well, the CPU runs at 40 MHz more times, so maybe this simply pushes the CPU over the edge.. I guess I could take out /AS from the equations and only run the CPU faster when accessing ROM to prove this or not...
EDIT4:
So only running the ROM at 40 MHz also fails
It could be similar noise problems as I found with the DMA circuit. Whereas accessing the DMA directly causes no issue, but when mixing in ROM access, it creates noise and ground bounces all over the place and then causes a issue. Also testing the ROM on its own will also test perfectly well.
So I suspect this problem I now have could likely be similar issue. Of course investigating this would take a phenomenal amount of time where I don't think it is worth investigating. I will do some more tests tomorrow but then I think I will call it a day and trying to get the CPU to run at 40 MHz. I will likely just backtrack to 35MHz or 38MHz on the final design to play it safe.