It's hard to get precise delays as short as 1 ms on a PC.
Why do you think you need 1 ms delay?

Thanks for a respond, Azarien. It's not that I need exactly 1 ms, a close value will also do. And I will also be able to get any delay below that 50 ms.

Funny, I'm in a similar boat to you, in that I'm learning assembly, and was wondering how measure time relatively accurately. I found this article pretty helpful.

https://www.xtof.info/Timing-on-PC-familly-un … and-programming

My understanding is that the best approach might be to reprogram the CTC chip to have the IRQ0 timer go off at the desired interval. But also keep count and make sure you chain the interrupt to the standard DOS version roughly 18.2 times a second/every 55 ms, so DOS keeps proper time and continues doing all the things it expects to do 18 times a second.

This article was also helpful

https://wiki.osdev.org/Programmable_Interval_Timer

Thank you for your respond and for the links, Namrok. Yes, reprograming the timer is one of the options. One thing I did not like about it is that it messes up the time. So need to see further how to keep it updated correctly, guess this is what you meant by chaining the interrupt to keep proper time. On the other hand the programm runs just for seconds, I could just program the timer back to normal in the end and ignore the discrepancy.
Another thing I wnat to do for now is just to measure the simple loop timings and find the right value. Very straight forward and inflexible, yet easy 😀

Namrok wrote on 2022-09-26, 00:23:

Funny, I'm in a similar boat to you, in that I'm learning assembly, and was wondering how measure time relatively accurately. I […]
Show full quote

Funny, I'm in a similar boat to you, in that I'm learning assembly, and was wondering how measure time relatively accurately. I found this article pretty helpful.

https://www.xtof.info/Timing-on-PC-familly-un … and-programming

My understanding is that the best approach might be to reprogram the CTC chip to have the IRQ0 timer go off at the desired interval. But also keep count and make sure you chain the interrupt to the standard DOS version roughly 18.2 times a second/every 55 ms, so DOS keeps proper time and continues doing all the things it expects to do 18 times a second.

This article was also helpful

https://wiki.osdev.org/Programmable_Interval_Timer

You don't necessarily need to reprogram the PIT to use it for finer resolution, the first channel is normally running at ~1.2MHz already and you can read the current count from IO port 40h any time you want. The problem is that the channel mode is not configured the same on every PC so you'll probably want to detect the actual counter speed first (otherwise you can be off by a factor of 2 sometimes). That, and just being sure to deal with overflow properly and not to get the high and low bytes mixed up.

If your program doesn't need to run on anything less than a Pentium you can always use RDTSC.

Thanks for the info, bakemono. RDTSC is not an option, unfortunately, as I intend to use the program on a 486 eventually.
I'll look at how I can use the 40h port anyways. Should not be difficult to detrmine the count speed.

pit countdown timer is buggy in a lot of systems. if RDTSC is not an option your chances are low 🤣 (rdtsc is also unreliable if its a laptop and speeds up or down etc)... . normal irq0 is 18.2 ticks a second, or 1 IRQ firing every 52ms give or take.

so you can hook IRQ0, and read timer, while read timer() == what I read before..

or simpler, hook IRQ0, the moment it triggers, set a value. because you only need 1 irq trigger.

the PC timers are all crappy so your in the weeds, especially with such small fine grained timing.

bakemono wrote on 2022-09-26, 11:14:

The problem is that the channel mode is not configured the same on every PC so you'll probably want to detect the actual counter speed first (otherwise you can be off by a factor of 2 sometimes). That, and just being sure to deal with overflow properly and not to get the high and low bytes mixed up.

To do the stuff right, use the readback mode of the 8254 (so you need an AT at least), and capture status, low count and high count in that command. If the PIT is in square wave mode (mode 3), it will count in steps of two and toggle the output bit every time it expires. The status byte tells you the mode (so you know whether you need square wave "adjustment"), and it will also tell you whether the output is currently high or low. Armed with this knowledge, you should be able to read the PIC "good enough" for most general purpose applications without any need of reprogramming.

Thanks to everyone! Now I think I'm really armed with the knowledge 😉