DOS ain't dead

We still face the question how to extend the sound support of DOS applications for new sound cards.

It is not so impossible how it looks in theory.
Theory says that every DOS application does a direct access to sound hardware.
It is true however the vast mojority of commercial games used some widely available sound libraries.

It was Miles Sound systém which later forked into libraries HMI and AIL (audio interface library).
Separately existed a sound library from Sierra/Dynamix


In all these cases it was a realmode drivers for basic interfacing with soundcard while most of code was hardware independent and was in the protected mode.

So in theory is possible to take out some driver, f.e. for GUS, and replace it with driver for f.e. SB Live!
The interface for Miles and for QuickPlayer with his SB Live drivers (by Ruslan Starodubov) are quite similar.

The problem and the question is: the modern hardware does not use much the I/O port access but extended memory mapping.
The extended memory is accessible from protected mode or from real mode with INT 15/87.
Is the INT 15/87 sufficient enough to provide adeqate access for soundcard hardware?

---
DOS-u-akbar!

> The problem and the question is: the modern hardware does not use much the
> I/O port access but extended memory mapping.
> The extended memory is accessible from protected mode or from real mode
> with INT 15/87.
> Is the INT 15/87 sufficient enough to provide adeqate access for soundcard
> hardware?

Based on my experience with HDA sound cards I can say that yes, it is enough. With INT 15/87 I was able access the cards' memory-mapped registers without any problems.

---
Glory to God for all things

In DJGPP I use DPMI function for physical memory mapping. If you have some DPMI wrappers in FPC you can use it too.

---
DOS gives me freedom to unlimited HW access.

> In DJGPP I use DPMI function for physical memory mapping. If you have some
> DPMI wrappers in FPC you can use it too.

Yes, you can use DPMI physical memory mapping functions, wrapped or not, but this will obviously work only under DPMI. If your program is intended to run in real mode OR V86 mode, use INT 15h/87h to access the memory mapped registers.

---
Glory to God for all things

> In DJGPP I use DPMI function for physical memory mapping. If you have some
> DPMI wrappers in FPC you can use it too.

In FPC I also can use the physical memory mapping. I use it for example for the LFB access or for ACPI.
However it is mapped into different segment than the default DS.

For accesing such mapped areas I have to use my own assembler wrappers. Like:
FarPokeB(segm:word;offs:dword;value:byte);assember;
asm
push es
mov ax,segm
mov es,ax
mov edi,offs
mov es:[edi],value
pop es
end;

Is possible to map it somehow into "main" address space to be able to use normal pascal code like this?

var dev_base:Pchar;
begin
dev_base:=Get_dev_base;
dev_base[offset]:=value;
...

I know that it is possible to extend the DS segment limit to reach the 4GB but I am not sure about compatibility with Win98, win XP, etc...

---
DOS-u-akbar!

> In FPC I also can use the physical memory mapping. I use it for example for
> the LFB access or for ACPI.
> However it is mapped into different segment than the default DS.
>
> For accesing such mapped areas I have to use my own assembler wrappers.
> Like:
> FarPokeB(segm:word;offs:dword;value:byte);assember;
> asm
> push es
> mov ax,segm
> mov es,ax
> mov edi,offs
> mov es:[edi],value
> pop es
> end;
>
> Is possible to map it somehow into "main" address space to be able to use
> normal pascal code like this?
>
> var dev_base:Pchar;
> begin
> dev_base:=Get_dev_base;
> dev_base[offset]:=value;
> ...
>
> I know that it is possible to extend the DS segment limit to reach the 4GB
> but I am not sure about compatibility with Win98, win XP, etc...

If you don't want to change the DS segment limit and DS is limited to your program's space, I think that your only choice is INT 31H/0508H, if the DPMI hosts supports it and if you can get the handle of the memory block which FPC allocates to your program. You can change the DS limit in both Win98 and Win XP (up to 0x7FFFFFFF under Win XP), but I don't know to which compatibility do you refer (for example under Win98 you can access the LFB, but trying to access the sound card's memory mapped registers usually doesn't work, while under Win XP you can not access even the LFB).

---
Glory to God for all things

Hello!

It's offtopic here, but you just mentioned your previous works on HDA chipsets. Only a few days ago I tried to find your MPLayer on the web, but it could not be found. All the links in this forum are dead and every public link on the web points to now non-existent targets. Are your old projects still available somewhere or you deleted them intentionally?

---
DOS isn't about why. It's about why not.

> Hello!
>
> It's offtopic here, but you just mentioned your previous works on HDA
> chipsets. Only a few days ago I tried to find your MPLayer on the web, but
> it could not be found. All the links in this forum are dead and every
> public link on the web points to now non-existent targets. Are your old
> projects still available somewhere or you deleted them intentionally?

RayeR still has a working link to Mplayer on his wonderful site:

http://rayer.g6.cz/download/download.htm

I never could get sound out of the latest version on my Lenovo laptop with HDA sound. Sound acts like it is playing but remains silent, I think the headphone vs onboard speaker subconfig is wrong, but I've no success either with Mpxplay on this laptop (i5 5500, with HDAUDIO\FUNC_01&VEN_14F1&DEV_510F&SUBSYS_17AA3810
sound card id).

> If you don't want to change the DS segment limit and DS is limited to your
> program's space, I think that your only choice is INT 31H/0508H, if the
> DPMI hosts supports it and if you can get the handle of the memory block
> which FPC allocates to your program. You can change the DS limit in both
> Win98 and Win XP (up to 0x7FFFFFFF under Win XP), but I don't know to which
> compatibility do you refer (for example under Win98 you can access the LFB,
> but trying to access the sound card's memory mapped registers usually
> doesn't work, while under Win XP you can not access even the LFB).

Freepascal uses an own version of a (probably very old) djgpp stub.asm.

See https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/go32v2/v2prt0.as?view=co

It seems it has some support for increasing the ds limit depending on __crt0_startup_flags, but I don't know how to set those.

/* Maybe set our DS limit to 4Gb in size if flag set */
testb $0x80, __crt0_startup_flags /* include/crt0.h */
jz 2f
movw $0xffff, %cx
movl %ecx, %edx
movw $0x0008, %ax /* reset alias limit to -1 */
int $0x31
movw %cs, %bx
movw $0x0008, %ax /* reset DS limit to -1 */
int $0x31
movw %ds, %bx
movw $0x0008, %ax /* reset DS limit to -1 */
int $0x31
lsl %ebx, %ebx /* Should be -1 */
incl %ebx
jz 2f
andb $0x7f, __crt0_startup_flags /* clear it if failure */
2:

> Freepascal uses an own version of a (probably very old) djgpp stub.asm.
>
> See
> https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/go32v2/v2prt0.as?view=co
>
> It seems it has some support for increasing the ds limit depending on
> __crt0_startup_flags, but I don't know how to set those.
>
> /* Maybe set our DS limit to 4Gb in size if flag set */
> testb $0x80, __crt0_startup_flags /* include/crt0.h */
> jz 2f
> movw $0xffff, %cx
> movl %ecx, %edx
> movw $0x0008, %ax /* reset alias limit to
> -1 */
> int $0x31
> movw %cs, %bx
> movw $0x0008, %ax /* reset DS limit to -1
> */
> int $0x31
> movw %ds, %bx
> movw $0x0008, %ax /* reset DS limit to -1
> */
> int $0x31
> lsl %ebx, %ebx /* Should be -1 */
> incl %ebx
> jz 2f
> andb $0x7f, __crt0_startup_flags /* clear it if failure
> */
> 2:

With DJGPP the flag is not set by default in __crt0_startup_flags (see crt0.S), normally you need to call __djgpp_nearptr_enable (see also nearptr.c).

---
Glory to God for all things

> With DJGPP the flag is not set by default in __crt0_startup_flags
> (see
> crt0.S),

Yes, and it does JZ after the test 0x80,,
16: testb $0x80, __crt0_startup_flags /* include/crt0.h */

But only if ax=8 int $31 followed by lsl returns -1 (and after incl ebx 0)

> normally you need to call
> __djgpp_nearptr_enable
> (see also
> nearptr.c).

These don't exist in normal Free Pascal programs. It is go32v2 only, not libc. But equivalents for the calls are probably in dpmi* and go32 units, just not as many of the symbolic constants.

But this is all 20 years ago for me

AFAIK, nearptr stuff (and CWSDPR0) originally were used for Quake 1 back in 1996. They wanted something moddable and used DJGPP (2.00 beta3 or whatever, unfinished) by cross-compiling atop quad-core Alphas, I think. (Who knows what rendering or whatever was required for levels or graphics.) Eventually, they just wrote wimpy QuakeC instead of trying to link with DJGPP itself. Doom source ports for DOS use DJGPP plus Allegro, though.

> AFAIK, nearptr stuff (and CWSDPR0) originally were used for Quake 1 back in
> 1996.

That's probably near the date of the move of v1 to v2 of FPC. But afaik dos mostly access the first mb via %fs.

> These don't exist in normal Free Pascal programs. It is go32v2 only, not
> libc. But equivalents for the calls are probably in dpmi* and go32 units,
> just not as many of the symbolic constants.
>
> But this is all 20 years ago for me


https://www.freepascal.org/docs-html/current/rtl/go32/fpcspecs.html

---
Glory to God for all things

> > AFAIK, nearptr stuff (and CWSDPR0) originally were used for Quake 1
> > back in 1996.
>
> That's probably near the date of the move of v1 to v2 of FPC. But afaik dos
> mostly access the first mb via %fs.

DJGPP 2.00 was released in 1996. It went "DPMI only" (since that's standard across Windows 3.x / NT, OS/2 2.1, Novell DOS 7) instead of always needing its own separate extender (GO32.EXE) with various kludges for whatever else (VCPI is ring 0, 386+ only and atop EMS). So even Quake came with standalone CWSDPMI r1 (!), only needed if no other DPMI host available, although Quake also needed some workarounds for buggy Win95.

> Yes, you can use DPMI physical memory mapping functions, wrapped or not,
> but this will obviously work only under DPMI. If your program is intended
> to run in real mode OR V86 mode, use INT 15h/87h to access the memory
> mapped registers.


Or maybe other possibility could be the DPMI assistance.
I can imagine this scenario:

1) Resident DPMI server
2) Hooked interrupt (or callback) processed in the protected mode
3) Realmode soundriver calls interrupt (or callback) which will be routed to resident DPMI routine

This mechanism should certainly work for new programs which will be aware of this situation.

But it is uncertain about old already compiled games.
I am not sure about possibility of persistent DPMI hook of interrupt/callback

---
DOS-u-akbar!

> Or maybe other possibility could be the DPMI assistance.
> I can imagine this scenario:
>
> 1) Resident DPMI server
> 2) Hooked interrupt (or callback) processed in the protected mode
> 3) Realmode soundriver calls interrupt (or callback) which will be routed
> to resident DPMI routine
>
> This mechanism should certainly work for new programs which will be aware
> of this situation.
>
> But it is uncertain about old already compiled games.
> I am not sure about possibility of persistent DPMI hook of
> interrupt/callback

Why would you want to complicate the things and try do that is something that I can't understand. If your program is a DPMI program, then use DPMI to access that memory, if your program is intended to run in real mode/V86 mode, then use INT 15h/87h. If you have a program which uses DPMI-based sound card drivers, then write a DPMI-based driver for it, if you have a program which uses real mode sound card drivers, then write a real mode driver for it and access the HDA's memory registers with INT 15h/87h, it works very well. Your problem is that you don't know how to use an already existing driver, or that you have no driver and want to write one? BTW, if I want to use the same driver with both real mode and DPMI programs, I would rather write a real mode one.

---
Glory to God for all things

i would like to modify the existing protect mode driver into real mode driver.

---
DOS-u-akbar!

> i would like to modify the existing protect mode driver into real mode
> driver.

Then please refer to concrete difficulties that you encounter on the way.

---
Glory to God for all things

To be more specific, in case of a HDA sound card, the only sound cards I have experience with that use MMIO, you have to find the device and get its memory base address by using INT 1Ah to call the PCI BIOS (see http://www.ctyme.com/intr/int-1A.htm), and then read and write the memory registers according to what you want to do, nothing more. For reading from/writing to the card's memory register to/from a memory address directly accesible to your program, you only need to set the correct values in the GDT that you pass to INT 15h/87h (see http://www.ctyme.com/intr/rb-1527.htm).

---
Glory to God for all things

BTW, if you have difficulties re: how the GDT you pass to INT 15h/87h should look in case of 32-bit linear addresses (the information in RBIL is incomplete), you may want to see e.g. this: http://my.execpc.com/~geezer/code/int1587.zip.

About HDA, see this: https://www.intel.com/content/dam/www/public/us/en...cations/high-definition-audio-specification.pdf

---
Glory to God for all things

> BTW, if you have difficulties re: how the GDT you pass to INT 15h/87h
> should look in case of 32-bit linear addresses (the information in RBIL is
> incomplete), you may want to see e.g. this:
> http://my.execpc.com/~geezer/code/int1587.zip.

I can use the INT 15h/87h. Two years ago I wrote this small example how to access linear frame buffer from real mode (turbo pascal source)
http://www.laaca.borec.cz/soubory/int8715.zip

---
DOS-u-akbar!

> I can use the INT 15h/87h. Two years ago I wrote this small example how to
> access linear frame buffer from real mode (turbo pascal source)
> http://www.laaca.borec.cz/soubory/int8715.zip

Then the most important task left to you is to convert the direct memory accesses of the protected mode program to INT 15h/87h accesses.

---
Glory to God for all things

Hello!

I tried the program immediately but forgot to answer. It works. With the WSS library, it behaves as you described, but with AU, it outputs sound both with the output jack and the internal speakers. Did you try that one or just WSS? Also do you know anything about this AU library? Could I somehow get the source of it?

---
DOS isn't about why. It's about why not.