Timed Loops to Simulate Hertz

[Jacob Roman]

Hello. I am currently simulating a 6502 CPU to run at an exact rate of 1.789773 MHz, which is 1789773 cycles per second. With my current code of locking the framerate, I can almost do it, as my computer can do 5 times that in a loop, but it does 1789773 cycles every 1.12 seconds, a whole .12 seconds off. I am at work right now so I cant show my current code yet, but is there a way to lock the rate of a Do loop just right so it does 1789773 cycles every exact second, or any speed for that matter? Thanks in advance. Also I am using QueryPerformanceCounters and QueryPerformanceFrequency APIs to help lock the framerate at a given speed. Almost works.

[Niya]

I don't want to say it's impossible but my instinct is that it is impossible. I am assuming that you are running on Windows. Thing is, Windows is a pre-emptive multi-tasking operating system that is typically executing way more threads than it has cores. What this means is that the vast majority of threads are spending a lot of time not being executed and the entire process of time slicing is non-deterministic from the point of view of user mode applications. Quite frankly, I think it's a miracle you're only off by 1/10th of a second.

All of this is just me speculating though. Perhaps there is someone here that knows a lot better than me.

[Shaggy Hiker]

I agree with Niya, and I think you can see this by making a loop that does some random, but short and repetitive, garbage, and timing it over and over. For example, you could do something like this:

Private i As Double 'Cause, why NOT use a private i?

For x = 0 to 100000
  i = Math.sqr(x)
  i = i * x
  i = Math.sqr(x)
Next

That code might actually be TOO simple, but it gets the idea across: It should take the same amount of time every time, but if you time it, you find out that it will vary by small amounts most of the time, and occasionally by large amounts. That's because the OS will occasionally interrupt. In theory, it could also be lower level things interrupting, but it probably isn't.

EDIT: I have a vague memory that there is an external clock you could add that would give you a predictable pulse. That memory is from at least one, and quite likely two, decades back, so it may not be true anymore, if it ever was. Still, it's something you might look into.

[Jacob Roman]

What I have set up right now is a loop within the loop that helps lock the original loop at a certain speed. It does work but it almost works. You should be able to control the speed of the original loop. Should be home in about 3 hours or so to demonstrate this.

[dday9]

I have a managed game loop timer codebank submission here: https://www.vbforums.com/showthread....aged-Game-Loop (this was written 7 years ago, might qualify for optimization).

It also leverages QueryPerformanceCounters and QueryPerformanceFrequency, but the frequency is not a perfect 16.6ms elapse rate. It is usually off by a couple of couple hundreth to sometimes a full millisecond. I could never get it to consistently tick at 16.6ms and eventually gave up.

My conclusion was that this was a limitation of VB.NET being a higher level programming language and WinForm technology being antiquated. I could be completely wrong, but I do remember spending significant time on trying to get this resolve only to come up short.

Edit - Looking a little bit more, it seems as though QueryInteruptTimePrecise (documentation, only available Windows 10) may be more precise than QueryPerformanceCounters: https://docs.microsoft.com/en-us/win...on-time-stamps

[Niya]

My conclusion was that this was a limitation of VB.NET being a higher level programming language and WinForm technology being antiquated. I could be completely wrong, but I do remember spending significant time on trying to get this resolve only to come up short.

I wouldn't go this far yet. While, the .Net GC is unpredictable and can cause unpredictable stutters, I think the OS itself also has a major role to play in this. The OS has to share the CPU between your program and the other thousands of threads running at any one time on Windows. This process is also unpredictable and mostly outside of your control. The only control you do have is to tell the OS to give your threads higher priority but the OS doesn't have to honor that request as faithfully as you might want. It doesn't even have to honor it at all.

I'd even go as far as saying that being off by only a few milliseconds despite all this multi-tasking chaos is a testament to the superb software engineering skills of Microsoft and the engineering skills of modern CPU manufacturers.

[Delaney]

At work to achieve this kind of precision and frequency, we use specific electronic cards who have their own clock and timer because windows in not reliable under the ms.

[Jacob Roman]

Finally home. I made a demonstration project for you all to try out. Just need to figure out how to possibly match the speed with exact seconds. I understand that there are background tasks that could interrupt it, but if I could harness the "speed limit" of the loop, then I got this by the buttcheeks

Option Explicit On
Option Strict On
 
Imports System.Runtime.InteropServices
Imports System.Security
 
Public Class Form1
 
    <DllImport("kernel32.dll"), SuppressUnmanagedCodeSecurity()>
    Private Shared Function QueryPerformanceCounter(ByRef lpPerformanceCount As Long) As Boolean
    End Function
 
    <DllImport("kernel32.dll"), SuppressUnmanagedCodeSecurity()>
    Private Shared Function QueryPerformanceFrequency(ByRef lpPerformanceFreq As Long) As Boolean
    End Function
 
 
    Private loopy As Boolean
    Private ticks_per_second As Long
    Private cpu_clock_current_time As Long
    Private cpu_clock_last_time As Long
    Private Const CPU_CLOCK_SPEED_HZ As Integer = 1789773
    Private cycles As Integer
    Private cpucps As Double
    Private time As Single
    Private last_time As Single
 
 
    Private Function Get_Elapsed_Time() As Single
        Dim last_time As Long
        Dim current_time As Long
        Dim result As Single
 
        QueryPerformanceCounter(current_time)
        result = Convert.ToSingle(current_time - last_time) / Convert.ToSingle(ticks_per_second)
        QueryPerformanceCounter(last_time)
 
        Return result
    End Function
 
 
    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
 
        Show()
        QueryPerformanceFrequency(ticks_per_second)
        loopy = True
        last_time = Get_Elapsed_Time()
        Do While loopy = True
 
            Do
                QueryPerformanceCounter(cpu_clock_current_time)
                cpucps = Convert.ToDouble(ticks_per_second) / (Convert.ToDouble(cpu_clock_current_time - cpu_clock_last_time))
            Loop While (cpucps >= CPU_CLOCK_SPEED_HZ)
            QueryPerformanceCounter(cpu_clock_last_time)
            cycles += 1
            time = Get_Elapsed_Time() - last_time
 
            If (cycles >= CPU_CLOCK_SPEED_HZ) Then
                Label1.Text = Convert.ToString(cycles)
                Label4.Text = Convert.ToString(time) + " seconds"
                cycles = 0
                last_time = Get_Elapsed_Time()
            End If
            Application.DoEvents()
        Loop
    End Sub
 
    Private Sub Form1_Closed(sender As Object, e As EventArgs) Handles Me.Closed
        loopy = False
        Application.Exit()
    End Sub
End Class

[passel]

I didn't try the code or look at it in detail.

Just looking at the Get_Elapsed_Time function, the code doesn't seem to make sense.
You're subtracting last_time from current_time, but since last_time is declared local to the function, it will always be 0 when you do that subtraction.
Perhaps you want it to be Static, rather than Dim.

Also, when I don't want a clock or counter to drift, I don't read the clock/counter to get the value to put in the class level last_time. I base last_time on the last time the function should have run. Using the function to set last_time is going to include the time it takes for the function to run and the code that was run to get to the point of the function call.
What I do is read the clock/counter at the beginning of the code to establish a basetime, and then add specific deltas to the basetime for the next trigger point.

For example, assume you have a ticks per second of 3,553,232.
If you want to leave your inner loop every second, which you appear to do in this example, then you read the time to establish the base value, and you add the 3,553,232 to it.
When you reach that trigger point and exit your loop, you add 3,553,232 to the current base value to get the next trigger point. That way it doesn't matter how long the various function calls take to get the time, you are incrementing your trigger by a fixed amount each time so you don't accumulate small timing errors into your trigger points.

[Jacob Roman]

Don't think I gave up on this just yet folks

I honestly gotten a hell of a lot closer to my goal fiddling with the idea of setting a "speed limit" for loops at any iteration, even in the millions. I haven't ported this to VB.Net yet but I managed to pull it off in C++

#include <windows.h>
#include <math.h>
#include <iostream>
using namespace std;
 
int main()
{
    const int CPU_CLOCK_SPEED_HZ = 1789773;
    const double ONE_OVER_CPU_CLOCK_SPEED_HZ = 1.0 / CPU_CLOCK_SPEED_HZ;
    LARGE_INTEGER ticks;
    double one_over_ticks = 0.0;
    LARGE_INTEGER current_time;
    LARGE_INTEGER last_time;
    double time = 0.0;
    int hertz = 0;
    double result = 0.0;
    int x = 0;
    int cycles = 0;
 
    QueryPerformanceFrequency(&ticks);
    one_over_ticks = 1.0 / static_cast<double>(ticks.QuadPart);
    QueryPerformanceCounter(&last_time);
 
    do
    {
        hertz++;
        QueryPerformanceCounter(&current_time);
        time = static_cast<double>(current_time.QuadPart - last_time.QuadPart) * one_over_ticks;
        
    } while (time < 1.0);
 
    result = floor(static_cast<double>(hertz) * ONE_OVER_CPU_CLOCK_SPEED_HZ);
    hertz = 0;
    QueryPerformanceCounter(&last_time);
 
    while (1)
    {
        do
        {
            hertz++;
            x++;
        } while (x <= result);
 
        x = 0;
        cycles++;
 
        QueryPerformanceCounter(&current_time);
        time = static_cast<double>(current_time.QuadPart - last_time.QuadPart) * one_over_ticks;
 
        if (time >= 1.0)
        {
            cout << "hertz : " << hertz << endl;
            cout << "cycles: " << cycles << endl;
            cout << "goal  : " << CPU_CLOCK_SPEED_HZ << endl << endl;
            result = floor(static_cast<double>(hertz) * ONE_OVER_CPU_CLOCK_SPEED_HZ);
            hertz = 0;
            cycles = 0;
            QueryPerformanceCounter(&last_time);
        }
    };
 
 
    cout << result << endl;
 
    return 0;
}

I have been getting values for the variable cycles that nearly range around my goal of 1789773, which is quite an improvement from my old code. It basically has been averaging around 1780000. Sometimes it'll once in awhile overshoot to 1800000. But that all depends where the timer ends up once the one second ends. I'm pretty certain when it comes to CPU's such as 6502 processors which is what I am emulating, it is not consistently 1.78 MHz, but probably ranges around there and only averages 1.78 MHz. And if you play around with the CPU_CLOCK_SPEED_HZ with any value, such as 60 or 100, it does a solid job on trying to stick with it. Gotta goto bed right now, but tomorrow I will port this over to VB.Net and see if I get similar results. I'm actually pretty psyched that I've gotten closer.

[Shaggy Hiker]

My impression was that the timer in those early chips was a quartz crystal oscillator (might have the wrong crystal), which was very consistent. Not sure what is used, now, but it it's really just a crystal oscillator, there may not be much variation around the frequency at all. Oscillating systems don't seem to vary all that much.