The other component of runtime is cycle count. So:
runTime [seconds] = cycleCount / frequency (in appropriate units)
The frequency is pretty close, but my current approximation of the pipeline is not accurate so that the cycle count is higher in some cases and lower in others. Cycles can be broken down into:
cycleCount = instructionCount * average CPI (where CPI = cycles per instruction)
The instructionCount is likely the same unless the game changes behavior based on small differences in runTime. So the problem is the number of cycles it takes to process instructions is different. Let's call the sd2snes implementation of the gsu the gsu-r. The gsu-r is used to approximate a gsu-1 and gsu-2 by programming some number of cycles to fetch and execute an instruction. Most of the instructions are very simple when it comes to performance and take either 1 clock (gsu-2 cache hit), 2 clocks (gsu-1 cache hit), or memory clocks of latency (cache miss) @ 21.4 MHz. Multiplies take several clocks, but look to be a fixed amount for each type. Then there is the memory system with multiple caches, a prefetcher, and store/write buffering all of which operate, to some degree, in parallel with the execution. This is where the number of cycles gets tricky to match.
Making it faster is easy. But getting it to match is hard. A better approximation is still on the todo list.
---
I briefly looked at the menu and can see that some stuff the editor probably relies on got shifted to higher addresses. One fix would be to revert back to the old menu and use the cx4 speed option to control both the cx4 and gsu. Another option is updating the menu editor or shifting around where stuff gets compiled into the binary. I'm not looking to spend a lot of time on this so I may just hijack the cx4 speed option temporarily.
---
For those who are worried about their memory chips - don't be. The latency I added to read the ram should be hidden and not affect performance. Also, it could still be a bug in my code that is causing the timing problem. I don't have much visibility in that part of the sd2snes and just guessed at what the problem was. The resellers and board designers don't have control over this kind of stuff as long as they use the correct part number. It's differences in the manufacturing of the Micron chip itself and not the sd2snes.
