Andrew Collier wrote: > I think the only question it doesn't answer is what happens to the > 112 t-state difference between the number of t-states measured with > the screen off (119696) and the number that would be expected from > the timing characteristics of the screen display (119808).
Doesn't that just mean the real SAM framerate is ~50.08Hz instead of 50Hz? That's a difference of 6 seconds per day, so unlikely to be noticed by most programs. > Perhaps the SimCoupe source would show how those are accounted for? The display framerate and cycle counts aren't as tightly linked in SimCoupe, since it can vary the time between frames without affecting the emulation accuracy. I currently use a 20ms periodic timer to give a 50Hz approximation, though the accuracy of that is implementation/OS dependent. The difference does still cause some problems for the frame sync at normal speed. The sound code generates an exact number of samples matching the 50.08Hz rate, but the timer for the frame sync is still working at 50Hz rate. The sound slowly drifts from the emulation until and eventually needs to be corrected, often with a a small audible glitch - something I'll eventually avoid by using the sound buffer for seamless frame sync. > Another rather interesting prospect would be that you might be able > to literally improve the graphics by plugging in a mayhem > accelerator... Neat idea, and maybe as simple as plugging different instruction timings into Si's program. :-) Si
