I just received my DE10-nano board (no SDRAM yet - a few days from now...), and examined the results of this test.
The issues demonstrated could be considered "edge cases" which may not often appear in games, but could cause lockups and other issues which could otherwise be difficult to diagnose (for example, an interrupt could be missed). I also don't have a dev environment set up yet, but will also get that set up soon.
Note that the webpage (https://www.chrismcovell.com/CPUTest/
) is based on the July version of the core; some improvements have already made it into the September version.
My results show (remember, these are DDR3-based for the time being, and "run from RAM (not ROM)" ):
1) The VSYNC timing appears to have been corrected, as the indent on the top line looks appropriate in the 201909 version of the core.
2) The right edge is still wrong by 2 characters.
3) Every timing test at every level shows a gentle slope leftward as the tests progress down the screen. About 1 pixel per line, which equates to about 2 cycles per test. This does not imply a problem with the opcodes involved with the test, but rather something which occurs once per test. I suspect it's the update to the 6260 palette generator, which seems too fast (~2 cycles as I mentioned). I would suggest writing a new test for this (or, given time, I will do so).
4) Opcode 'CSL' is egregiously fast. Does this even implement slow CPU-speed, I wonder ?
5) Opcodes ST0, ST1, ST2 take longer than they should. Probably 1 cycle more than they should. Not sure whether this is on the opcode side, or the write-to-VRAM side.
6) For some strange reason, TDD operations take longer than any other transfer operation. That was unexpected.
7) The vertical interface line (between opcodes) shakes a little even on normal systems, because the VRAM clock and the CPU clock don't always line up and wait states occur. In the case of MiSTer, this shakes tremendously, and by greater magnitudes toward the bottom of the screen; perhaps this is due to the fact that the DDR3 is being used by both the CPU and the video circuitry. Ideally, these memories should not be on a shared bus, so I will assume that DDR3 may never reach a level of perfection that the SDRAM should (unless the 2 DDR3 chips can be addressed separately ?)
I will test again when I get the SDRAM board working.
If somebody else is working on this, I am happy to help - otherwise I will eventually fix the above issues myself (but my schedule will not be fast).