Posted by Trixter on May 6, 2014
This entry was posted on May 6, 2014 at 4:01 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
reenigne said
BIU-waiting-for-EU is 6 cycles per iteration for REP STOSW, not 9. I did some measurements with refresh enabled too – that works out at ~27.4 cycles per iteration total for REP STOSW and 38.4 cycles per iteration total for REP MOVSW with the default refresh period. That’s no so easy to break down into parts though, since the refresh IOs can overlap the BIU-waiting-for-EU cycles and the CGA wait state depends on everything else.
Trixter said
A few hours before you wrote your comment, I had corrected the source to read:
I will fine-tune it further based on your measurements with refresh enabled, thanks!
reenigne said
Also, why is maxCyclesPerFrame a thousand iterations of REP MOVSW rather than 79648? It seems like as written you’ll only be using about half of the available time in the frame.
Trixter said
It’s intentional:
Otherwise, there’s no time left over for hard drive accesses or soundcard DMA.
Because I’m keeping track of source FPS, and thanks to REP STOS, we will have several opportunities to burn more cycles than this. This is just the conservative value.
I’ve said too much!
Trixter said
I’ve since refined it to be total cycles per frame, /2, and then an additional 1% taken away so that I can inject the largest possible REP MOVSW including its setup cost.
This number can get adjusted further if I specifically want to steal more time for framerates significantly below 60Hz, such as the common target of 24. Which is likely.