manicgamer wrote on 2021-09-19, 12:26:
TheGreatCodeholio wrote on 2021-09-19, 12:15:
That's correct. As I understand it, DOSBox was initially developed on Windows where you generally don't write directly to the PC speaker anyway, especially on Windows NT/2000/XP/etc. where user-space isn't allowed to touch any I/O ports.
I understand the i/o port restriction in NT windows but it is still possible to access and send audio to the pc speaker without a soundcard installed using basic API calls. If DOSBOX had the function or option to directly output to the hardware speaker port then this would in theory open the doors to enable the emulated SB/GUS/Midi sound output through a PC speaker on PC's that have not soundcard or drivers that support a soundcard in DOS ? Maybe I'm not understanding this too well, but it sounds pretty simple to me as there is already a speaker driver available for Windows 3.1/95 that can send PCM/Wave audio to a PC speaker but it's not perfect and introduces a delay in processing.
As far as I know Microsoft provides one basic API call: MessageBeep. It makes a short "beep" (you've probably heard it at some point in your life, right?). That's all it can do. There are no other parameters. Beep. You can't talk to the PC speaker hardware, and Microsoft doesn't care, so that's all you get.
Windows 3.0 through ME, despite the protected mode environment, did not block I/O ports (though they did have device drivers to trap and virtualize some things so Windows and DOS applications "get along"). If DOSBox had been developed when Windows 95/98 was popular, it could have used outp() to port 0x61, sure. It probably could have also written directly to 388h/389h too. There were additional amusing quirks about Windows 95 as well: did you know NULL pointers are valid AND writeable in Windows 95? It took Microsoft until Windows 98 to at least make NULL pointers read-only so you properly crash if you write to it.
Back in the Windows 3.1 days, it was common for some code to just talk directly to I/O ports because Windows 3.1 was particularly minimal in what I/O ports it trapped and virtualized. It was also common for Windows 3.1 games to bypass Microsoft's API entirely if they wanted more than the basic beep. Some games like "Wargames" come to mind, and a few that I saw on Shovelware Diggers, that are able to make more than basic beeps. The PC speaker sound driver is also able to talk directly to hardware as well (I used to have that driver, in fact, before finally getting a sound card in the mid 1990s). You may have noticed from that driver as well that CLI and STI are perfectly valid from user-space, when the driver masks interrupts to play a sound without interrupts to garble it.
There's even a DPMI server deep down inside Windows 3.1/95/98/ME that you can call if you are running as 16-bit Windows code (the DPMI interrupt call crashes for some reason when called by Win32 code). You can use it to call anything you want in MS-DOS or the BIOS below, have fun. "CD player" type programs in Windows 3.1 for example are said to use DPMI to communicate with MSCDEX.EXE.
In fact, to see how much of Windows is just talking directly to hardware or calling MS-DOS or the BIOS from user-space, I suggest you download the Windows 3.1 DDK and see for yourself. Each driver is two parts: user-space code that just talks to things directly, and 386 "virtualization" drivers that selectively trap and emulate I/O ports and resources so that Windows and DOS applications get along with each other. Have fun.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.