Hi,

I am playing a little with feeding the DAC of my SoundBlaster card with
raw samples that I am trying to time accurately.

The "obvious" way to do such thing is to use DMA transfers and
let the SoundBlaster chip control the sampling. That's not what I am
doing for the moment. I use the SoundBlaster DAC directly and write 8
bit samples to it in real time. Yes, it is not CPU-efficient, does not
allow to play things in background, etc. but please indulge me and
consider this a thought exercise.

So here's the question: Is there any kind of timer available on the PC
that would allow to generate some 8 kHz samples? I mean, besides the
obvious PIT of course. Some hidden VGA register maybe? A way to abuse a
timer in the SoundBlaster or Adlib hardware? Some creative
polling of a port or keyboard controller?

So far, the timers I know about are those:
- VGA VSYNC (tied to screen's refresh rate, ie. 50-60 Hz or so)
- calibrated busy loop (meh)
- PIT (18.2 Hz default, changing it doesn't work under Windows)
- BIOS "system clock" (sourced by the PIT, really)
- TSC (requires a Pentium+ CPU)
- APIC (modern CPUs only)
- CMOS RTC clock (ports 0x70 & 0x71, fixed at 1024 Hz)*

Anything else?

Mateusz

*a pretty nice article about abusing the RTC clock here:
https://web.archive.org/web/20150514074601/http://www.nondot.org/sabre/os/files/MiscHW/CMOSTimer.html

On 08/17/2022 12:01 PM, Mateusz Viste wrote:
> Hi,
>
> I am playing a little with feeding the DAC of my SoundBlaster card with
> raw samples that I am trying to time accurately.
>
> The "obvious" way to do such thing is to use DMA transfers and
> let the SoundBlaster chip control the sampling. That's not what I am
> doing for the moment. I use the SoundBlaster DAC directly and write 8
> bit samples to it in real time. Yes, it is not CPU-efficient, does not
> allow to play things in background, etc. but please indulge me and
> consider this a thought exercise.
>
> So here's the question: Is there any kind of timer available on the PC
> that would allow to generate some 8 kHz samples? I mean, besides the
> obvious PIT of course. Some hidden VGA register maybe? A way to abuse a
> timer in the SoundBlaster or Adlib hardware? Some creative
> polling of a port or keyboard controller?
>
> So far, the timers I know about are those:
> - VGA VSYNC (tied to screen's refresh rate, ie. 50-60 Hz or so)
> - calibrated busy loop (meh)
> - PIT (18.2 Hz default, changing it doesn't work under Windows)
> - BIOS "system clock" (sourced by the PIT, really)
> - TSC (requires a Pentium+ CPU)
> - APIC (modern CPUs only)
> - CMOS RTC clock (ports 0x70 & 0x71, fixed at 1024 Hz)*
>
> Anything else?
>
> Mateusz
>
> *a pretty nice article about abusing the RTC clock here:
> https://web.archive.org/web/20150514074601/http://www.nondot.org/sabre/os/files/MiscHW/CMOSTimer.html
>
some have what they call a HPET, but Idunno if it's available on your specific box. or
in portspace.
https://en.wikipedia.org/wiki/High_Precision_Event_Timer

Mateusz Viste <mateusz@xyz.invalid> wrote:
>So here's the question: Is there any kind of timer available on the PC
>that would allow to generate some 8 kHz samples?

Yes, the PIT. You can't generate a 8000 kHz timer exactly, but you can
come close enough (8008 Hz).

> - PIT (18.2 Hz default, changing it doesn't work under Windows)

Changing it works just fine under Windows, as demonstrated by countless
MS-DOS games. Try Star Control 2 for example, it uses tracker based
music, mixed in real-time on the CPU on most soundcards. Probably a
lot like what you're trying to do.

One important thing do is to chain the original BIOS handler at the rate
it expects. The easest way to do this it add your PIT reload value
(149 for 8kHz if I've done my math correctly) to a 16-bit variable on
every interrupt and then call the old handler when it overflows.

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rridge@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca:11068/
db //

Mateusz Viste <mateusz@xyz.invalid> wrote:
> - PIT (18.2 Hz default, changing it doesn't work under Windows)

Ross Ridge <rridge@csclub.uwaterloo.ca> wrote:
>Changing it works just fine under Windows, as demonstrated by countless
>MS-DOS games.

Digging a little deaper, while Windows 9x does let MS-DOS applications
change the PIT timer interval, it doesn't let you set a timer frequency
faster than 1 kHz. Still this is probably your best bet if you want a
wide range of hardware support and don't mine sacrificing Windows support.

Otherwise, your next best option is the Pentium TSC, but in addition to
not working on earlier processors, using it on certain newer processors
can be tricky. You wouldn't have to worry about different cores of
a multi-core CPU keeping different counts, but it might break an CPUs
with dynamically changing frequencies and that don't support the newer
frequency invariant TSC.

Anything else is likey to not work on Windows and/or not as as wide of
a range of hardware as the PIT or TSC.

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rridge@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca:11068/
db //

2022-08-19 at 19:44 -0000, Ross Ridge wrote:
> Digging a little deaper, while Windows 9x does let MS-DOS applications
> change the PIT timer interval, it doesn't let you set a timer
> frequency faster than 1 kHz.

Not very useful for audio generation. :)

> Anything else is likey to not work on Windows and/or not as as wide of
> a range of hardware as the PIT or TSC.

Thanks, that's indeed what I think as well. I was silently hoping for
some exotic "under the hood" tricks like "reading port x or y takes
between 33-37 microseconds on all PCs" or something alike. Yes, wishful
thinking, I know.

I did some archaeology and it appears that so far whenever people
wanted or needed to generate real-time audio data on PCs, they were
simply resorting to PIT reprogramming.

I tested it and it works as expected, although results are quite
jittery due to the relatively poor precision of interrupts firing. DMA
transfers are vastly superior in this regard.

Mateusz

On Friday, August 19, 2022 at 1:16:09 PM UTC-7, Mateusz Viste wrote:
.....
> I did some archaeology and it appears that so far whenever people
> wanted or needed to generate real-time audio data on PCs, they were
> simply resorting to PIT reprogramming.
>
> I tested it and it works as expected, although results are quite
> jittery due to the relatively poor precision of interrupts firing. DMA
> transfers are vastly superior in this regard.

At one point I looked deeper into it and discovered that part of the
jitter was due to SMIs.

Alex