what do you want to do ?
what should the reprogrammed pit do ?
reprogramming the pit is quite simple actually.

Thanks in advance: writing a PC Speaker music player for ones who still have real good old DOS like me 🤣

Actually i could reprogram the PIT itself in any way: i know how that piece of hardware behaves. The trouble comes when i try to write a new INT 8 handler... It either not becomes active (so when i check still the old handler's segment & offset are at 0000:0020 - 0000:0023), or dies (the system randomly hangs - and not because of failures in the new int handler, it even happens when it just contains a far jump to the old handler). So somehow it can not "catch on" with the new handler - it is rather a PIC problem than PIT. I am confused since i studied a piece written for INT 09 too which worked nicely - and no matter if i did everything the same way, for me with INT 08 it did not succeed.

Of course this might be needed for many other purposes if 18.2Hz accuracy is not enough - and for games, or even FM music it is really not really enough.

Could you post the asm code (or hex dump/disassembly)
of your code?
When completely taking over int8 you have to care about
some things like incrementing the timer (0x40:0x6c) and
calling int1c and so on.

Ahh, i found my stupid fault...

When i hard - coded the jump instruction in the interrupt handler, i accidentally swapped the segment and the offset word, so no wonder that it messed up :p. I also missed the data segment during setting up the new vector in my first tries, that was why they failed.

Now i have a code what "plays" at around 10 seconds of some silent noise, somewhat like coming out from an old badly tuned radio not reminding to anything :p - i guess the file loading code is buggy somewhere and the poor thing just plays some randomly filled memory... Although the effect is not bad, it would sound good in some intro where such thing was needed 🤣

(Yes, i call the timer properly, that was why the hard - coded jump was especially needed for the old handler!)

Now the code's effect in addition to the noise is that the CPU can do anything during it: for me it now just fills the screen with garbage using the DOS INT 21 ah=02, but in the "final" form it will buffer the music during playing back. So it will work by first filling a 64Kb segment with the beginning of the WAV, then as the music plays, the CPU would check where is the music pointer, and pre - buffers the remaining of the music according to it. Or maybe do something else (too) 😀

EDIT:
I just finished a working piece. This does not prebuffer at all, just can load 64Kb of 11025Hz 8bit WAV and play it: supplied in "test.wav" in the same directory. Note that it WILL ONLY RUN IN PURE REAL DOS! Get a DOS boot disk and copy it on that 😀 The 1,3Kb COM will play the music, it is a short piece from "The lion sleeps tonight". I tested it on my P233, since it relies on the PIT it must work on anything faster. I think the minimal required CPU would be 12MHz, but i am not sure - so such old machines might crash...

Damn, i forgot about that bloody testing stuff... Anyway i rather leave it there if you wish to see that the thing really plays in the background, but those stupid DOS interrupts tend to disable the timer so they a little ruin the music's quality. The difference now is only that now a completely empty loop runs in the foreground what does nothing more but testing if the music player reached the end of the music and then exits. This one not contains the testing music, get it from my previous post's attachment.

Background preloading can be quite tricky as you have to
look for the indos-flag (supposedly you don't use direct disk
access...). Did you try it in dosbox btw.?

Only for real old DOS 😀 - even if it started without a crash i doubt that DOSBox would support 88KHz accuracy what this code asks for...

And actually the preloading will be in the foreground while the music plays in the background, so no such trouble 😀 - only with figuring out how the timer interrupt reacts to a disk access (Maybe DOS disables it so the music would suffer when loading too large chunks at once).

I would be curious about how this plays on laptop speakers which are not paper - based... Will this 88KHz be enough, or not... Some time before i could test such things on a laptop (not my codes then, just old pieces), 11KHz was horrible while ones which updated at 22KHz (i just guess...) were much better, but still very bad. At least i could experience big differences between the qualities...

Ahh, what a failure! It was so realistic 😀 The music was played nicely, then suddenly some noise like what might be caused if i smashed the radio in the wall with a baseball bat, and the system crashed 🤣

Now it works, it will buffer the music in 32Kb chunks, in this piece i included the source too. This is my second assembler code which did something 😀 (The first tweaked some VGA modes to 80 or 90Hz).

So you will need pure DOS, and a "test.wav" (rather raw data, it "plays back" the header too :p) of any size in the same directory to make the thing working... I think better to try from a HDD as accessing floppyes might be too slow... The WAV must have 11025Hz frequency, 8 bit depth, and must be in mono.

Bugs:
No exit! I tried to do, but for some reason now i could not figure out how the DOS interrupt reading the keyboard works... You have to listen what you started, or press CTRL + ALT + DEL.
Maybe files below 32Kb will crash the thing because of how the buffering routine works. Maybe not, i did not try. Except from these you can play anything less than 2Gb :p
Although i tried to eliminate the ticking happening when reading from the disk (DOS seems to disable the timer interrupts then), i did not succeed fully, truly i am not 100% sure that the code what i wrote to do this works... At least for me it seemed to make the effect less grave.

At least the music was enjoyable 🤣

(Note that this version works at 44KHz, it is smaller than the first because of this: half as much speaker state data needed to achieve this)

I consider this as "final version", maybe later i will use it up for certain things and modify - but now i not really have idea for that how could i make the actual playback better (Using XMS... But it is again an another subject needing an XMS handler...).

EDIT:
Just to make the thing a little more convient: Create for example a "speaker.bat" with this content:

1ren %1 test.wav
2pcspk
3ren test.wav %1

, and make sure that there is no "test.wav" in your current directory. Then "speaker music.raw" for example will start "music.raw" by temporary renaming it to "test.wav" (And renaming it back to "music.raw" when the program ends).

EDIT (2 days later) :

Burn all soundcards!! 🤣

I just found that stupic bug what still caused the "ticking" when preloadings happened among correcting a few other things - now everything is fine!

(It was that i set up the PIT improperly for sustaining the speaker in mid - state. Since usually the sustaining was "catched" here, it resulted an annoying tick)

🤣 - i had seen that a few ones actually thought the thing interesting, so i thought it good to put up my new idea: 22KHz with true 8bit depth! This actually pushes the PIT to the absolute limits, so i doubt that anything better can be made except with reliing on the CPU - although the current code can be easily switched to even 44KHz if needed.

This piece's improvement is that it implements a sort of speaker state dithering - so actually when the rate is at around 5KHz, it results in true 8bit sampling, while at 22KHz it uses only the usual at around 50 sound levels. Of course this is not this simple, the method how it works out the effect makes everything turning out nicely - maybe even better than how my crappy old XWave sound card works in 8bit mode 😜

If you are interested, there are three values what affect the sampling frequency altering which it can be switched between 11KHz, 22KHz, and 44KHz: all can be found in the routine mataining the music. One is the back - counter which affects how frequently a speaker state has to be processed, an another is which matains the BIOS clock's updating, and the third is the shifting at the speaker suspender (From this actually changing the first is enough, but you can guess what will be the result...).

Now i will really stop this as the subject is over - there is no way to make better playback using the PIT (Of course here i just talk about the playback itself, but not anything else like reading / buffering the music ect.) - if you are interested in this, you may visit my web page ( http://ruch.co.nr ) what i hope will get a new web space soon so i can update.
Or compete with me 🤣 - can you make something even better? 😁

How can you get a bit depth of greater than 1 bit on the PC Speaker? I thought it could only be "on" or "off".

You pulse the speaker faster than the speaker's cone can expand and contract. It sounds like grunge but it allows for digitzed sound.

I'm pretty sure that it's not practically possible to do better than 1-bit sampling unless you're making some massive assumptions about the speaker hardware.

I read more carefully what cheetah is saying though, and may be possible (as he says) to basically play at a higher sampling rate to simulate a greater bit depth at a lower rate. I can't quite imagine how that would work when limited to 1-bit sampling though.

In any case, I'd really like to see what the output wave looks like compared to the input wave.

I'm pretty sure that it's not practically possible to do better than 1-bit sampling unless you're making some massive assumptions about the speaker hardware.

Are you talking about the 8253 Programmable Interval Timer or the 3" PC Speaker cone? As the IBM PC cannot vary the volume of the speaker, so the methods of pulse code modulation (varying the amplitude of the signal) and delta modulation (comparing samples and processing amplitude change) shouldn't work, but those of pulse width modulation (varying the frequency of the signal) do work. If the programmers were able to accomplish this, they must have broken certain hardware assumptions.

Then i am just a nightmare? A stupid vision? 🤣 - download, and hear it before starting doubting 😜 (As i said pure DOS needed and any music converted to 22KHz 8bit mono RAW data - WinAmp can do this perfectly with it's disk writer plugin)

By the way it can work by that the PIT can switch between those two states withing such a short fractions of a second that the cone simply can not move away during that short period (44KHz). So this way actually the PIT "suspends" the cone in some mid - state from what with a lot of tweaking and some knowledge about how actually the sound "works" i have 217 in the program, what i then faked to be 256 (So that it flattens the top and the bottom of the waves, but it is actually not noticeable... Truly it well balances the effect of that the mid state of the speaker is the most "unstable").

Look in the source, and play a few musics with it... Of course you will need an appropriate PC without bloody NTFS junk so you can start in DOS and load a music from the HDD (floppy would be very crappy...). Or maybe try to create a bootable CD-RW on which you copy a "test.wav" and this program (I guess CD will be fast enough to work out the buffering).

A little more cleanup:
This happens to the speaker in 1/44000 sec when it is suspended in mid - state:
00000001111111
Keeping repeating this for longer will result the cone stucking in "0.5" state as those short periods are not enough for it to actually move in a noticeable manner. This is the basement of this program, the others... It would be a bit long to explain 😀

The cone. Everything you just said is the way I already understood it (except I didn't know the term "pulse width modulation") - the IBM PC hardware only lets you slam the speaker all the way to one position or all the way to an opposite position, and you'd need to actually know the responsiveness of the particular physical speaker in use (which varies greatly among different PCs - many of which even have smaller, cheaper, less power-hungry piezoelectric speakers now instead of cone-based ones) to be able to reliably intercept its movement before it reaches one of the extremes.

But Cheetah seems to be working around this by driving the speaker at a faster rate than the input data - perhaps simulating half volume my rapidly pulsing between none and full?

I guess this would work in even the most sensible paper based speakers as they usually tend to lose all their volume at around 15KHz - so 44KHz is way too much for them. It is not about the input rate, you not say too much by that i run it at faster rate as it must have to be ran with at least equal rate to it (Although the "faster rate" is really something in what i guess i was the first who ever tried). I chose especially 44KHz as it could be well worked out by the PIT while it fits to the traditional formats (11KHz, 22KHz and 44KHz). If the PC is able to do, it may even run in faster rates, but i doubt it would be necessary. I even heard 22KHz PC squakeries working on that old laptop (with piezo speaker) which sounded recognizable, although it was really ruined by that the 22KHz for it was still too long. I guess 44KHz would have been enough even for that to filter out the trouble.

EDIT: Just mentioning: "Losing the volume" means that the speaker's cone gets stuck in the mid state as it gets the impulses so fastly that it can not follow them anymore. If it happens usually at 15KHz (for the internal PC speakers), then 44KHz is even more than enough. For piezo speakers i do not know what is the limit as currently i not have that laptop - so i can not test it.
BTW on the family PC which is an 1 year old one, the program worked although a bit silently. I do not know what kind of speaker is inside - stupid guarantees and sealed cases 😜

These speaker hacks worked well on the 3" IBM PC's paper cone (large among PCs) but very poorly on the piezoelectric tweeter found in a laptop or on a motherboard. The more cone, the more detailed the reverberations. PCs used standard paper cones 1.5-2" in diameter, so such hacks would work reasonably well regardless of the specific clone or model as long as the system supported it (the hacks being timed to very low CPU speeds.)

Here are two pages that give samples of digitized music playing through the PC speaker:
http://www.oldskool.org/sound/pc
http://crossfire-designs.de/index.php?lang=en … undcards&page=3

Stop doubting, download it on your PVIII 6000GHz, and see that it works! (But before create a DOS partition 😜 ). This absolutely not relies on the CPU's speed, only on the PIT. And the PIT always works at somewhat around 1,2MHz.

Stupid bugs... Yesterday i did not notice it, but now i did, actually i completely ruined the poor second layer ditherizer's quality by updating it's counter in the wrong place. Fixed, also optimized, now it requies the same amount of CPU power like the original 11KHz version. Just to try i compiled it for 44KHz too, and it worked absolutely fine. (I also added comments to the two portions where the code has to be changed to switch between 11KHz, 22KHz and 44KHz)

BTW for the cones and speakers generate some music lasting for a hour, then at night start it, and open the window. If after a hour you will collect a few confused bats from all around of your floor, then i really could not work around the filtering out properly 😜

haha. Unfortunately I'm too lazy to set up a DOS partition to test your program. It does sound pretty neat though.

I did spend a lot of time playing with different programs that play digitzed sounds on the PC speaker back in the day:
- Axe of Rage (aka Barbarian II) had a digitally-mixed song at the beginning
- Once had a demo that looped a female singing
- One of the Dungeon Master games had a digitally-mixed song at the beginning
- Wizardry 6 and 7 used the PC Speaker for playback of digitized sounds
- Had some MOD (tracker music) players and editors that could use the PC Speaker for output
- Tried (and failed) to build a device that would digitize sound to a file on the PC that could then be played back via the PC Speaker. It came with some a sample recording of the author singing "Daisy Bell"