DOS ain't dead

Someone dropped an interesting link into the Dr-DOS Wiki:

http://www.piotrkn22.republika.pl/judas/index.html



it works ^^^ with ICH-LDA (not visible in the shot but I can hear sound)

Anyone has ICH HDA to test (reportedly "in development") ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Someone dropped an interesting link into the Dr-DOS Wiki:
>
> http://www.piotrkn22.republika.pl/judas/index.html

Seems to be 3 years old and we missed it. I can try on my HDA/ACL888.
Hm, anal invaders, that must be cool tune :)

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

Unfortunatelly it doesn't work on HDA - not supported yet


-----------------------------------------------------------------------
Real mode DOS initializer for Intel ICH based AC97/HDA codecs.
Developement ver 2.0 (August 2007).
Written by Piotr Ulaszewski (PETERS).
-----------------------------------------------------------------------
Intel 82801G (ICH7) integrated High Definition Audio controller detected.
Error : High Definition Audio controllers not supported yet!


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

Talk about synchronicity! I was just about to post a question to the group asking if there is a utility similar to Laaca's LiveCD but for Intel chipsets. Amazing....

The only problem is... it doesn't seem to be working on my system! At least to play audio CDs.

ICHINIT seems to initialize ok:

-----------------------------------------------------------------------
Real mode DOS initializer for Intel ICH based AC97/HDA codecs.
Developement ver 2.0 (August 2007).
Written by Piotr Ulaszewski (PETERS).
-----------------------------------------------------------------------
Intel 82801DB (ICH4) integrated AC97 audio codec detected.
Mixer Base I/O port              : 0x1c00
Mixer Bus Master I/O port        : 0x18c0
Mixer Base memory address        : 0xc0000c00
Mixer Bus Master memory address  : 0xc0000800
Mixer Base virtual address       : 0x85808c00
Mixer Bus Master virtual address : 0x85c0c800
AC97  Interrupt Line             : IRQ 9/PIN B
Memory range, I/O range and Bus Master access enabled.
AC97 configured for memory mapped IO.
-----------------------------------------------------------------------
Unknown 3D Stereo Enhancement technology detected.
3D center adjustment not supported by hardware!
3D depth adjustment not supported by hardware!
Unknown Device initialization success.

Or *does* it? ("Unknown Device initialization success.")

The audio cable is connected properly between the back of the CD and DVD drives and the system board. My CD players show time elapsing after i click the "play" button, the drive spins up, and the activity light blinks. Speaker system is connected properly and powered on (for example, MPXPlay plays, and CDs play ok in Windoze 98SE). I hear a click in the speakers during ICHINIT. But no CD audio in pure DOS!

As the documentation requires: "Non-Plug-and-Play OS" set in BIOS and m/b audio enabled.

Am i doing something duhhh that i'm just not realizing? Can anybody suggest anything? Thanks....

- Doug B.

Oh yeh, the system: IBM NetVista M42, Pentium4 2.4ghz, i845G north, i801DB ICH4 south, CD and DVD drives are IDE.

> Am i doing something duhhh that i'm just not realizing? Can anybody
> suggest anything? Thanks....
>
> - Doug B.
>
> Oh yeh, the system: IBM NetVista M42, Pentium4 2.4ghz, i845G north, i801DB
> ICH4 south, CD and DVD drives are IDE.

Hi,
I made a very simple dos command line cd player with built in ac97, you can try that, to see if it works.
if not i maybe able to mod it to work.

http://www.dex-os.com/dos2x/ac97cdplayer.zip

If it works you should be able to come out and run any cd play.
If anyone want fasm code let me know.

> I made a very simple dos command line cd player with built in ac97, you can
> try that, to see if it works.
> if not i maybe able to mod it to work.
>
> http://www.dex-os.com/dos2x/ac97cdplayer.zip
>
> If it works you should be able to come out and run any cd play.
> If anyone want fasm code let me know.

Dex -

Thanks so much -- it WORKED!

And yes, after AC97CD.COM initialized it, all my other CD players worked as well.

It's good to once more be able to listen to CDs in DOS....

Thanks again!

- Doug

> Someone dropped an interesting link into the Dr-DOS Wiki:

I am Someone :)
I heavily modified AdvanceMAME 0.37ß16 and the ArcadeOS frontend, with many customizations for my MAME cabinet. I was looking forward to a good AC97/HDA sound driver for DOS, because I don't want to switch versions and redo the customizations.
During 2006, 2007 and 2008, Piotr helped me by getting JUDAS ported to DJGPP, so I could use his drivers in ArcadeOS / MAME. He is a very nice man, I sent him a donation and am still grateful to him.
I got it to work on AOS but couldn't on MAME, got stuck :(
At that time, he sent me an Alpha version with HDA support up to ICH10. I mirrored it here: LINK
If there's interest we could let him know of this thread, and maybe he resumes development to have a stable for Mplayer or something else :)

Cheers,
Marton

Edit: PS: Of course DOS ain't dead!!! Thanks Robert for letting me join in the forum and for keeping it alive! :)

> At that time, he sent me an Alpha version with HDA support up to ICH10. I
> mirrored it here:
> LINK
> If there's interest we could let him know of this thread, and maybe he
> resumes development to have a stable for Mplayer or something else :)

Nice, I'm going to test it. It would be nice to see it integrated in mplayer!

EDIT: Tested and it works (ICH7+ALC888)! but...
1) don't forget to unset old BLASTER env. var. because it tries to initialize your SB first - I had this var set bacause of partial working SB emu on SB live. So I unset it and it started. It's mentioned in readme.

2) the playback works well, smooth and good quality sound without any crackles, volume control works... Just one confusing thing is empty ioport/dma/irq value (see below, or is it due to HDA? even HDA should have some IO base and irq)

3) I tried it to compile under DJGPP 2.04/GCC 4.6.2 and it spit a lot of warnings and compiled binaries didn't work - it just blacken the screen and hangs.

4) I tried it to compile under Watcom C 11.0c and compiled binaries works fine. I think that it must got messed something with newer gcc and older may work - what version of GCC did you used? I'll try to clean up the warnings but maybe the problem is in asm part or its interconnection and then I'll be lost.

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

> Nice, I'm going to test it. It would be nice to see it integrated in
> mplayer!

Nice to see you got some results. I will let Piotr know about the forum.
I used DJGPP 2.03/GCC 2.95.3 to compile back then and had no problems.

-- Marton

> Nice to see you got some results. I will let Piotr know about the forum.
> I used DJGPP 2.03/GCC 2.95.3 to compile back then and had no problems.

I tracked the DJGPP compiler problem and found it got broken between GCC 4.0.1 and 4.1.2. Up to ver 4.0.1 it's playing OK. between 4.1.2 and 4.5.1 it is silent but don't crash/hang. And ver 4.6.x makes it crash/hang. It doesn't matter what djdev is used - both 2.03 and latest 2.04beta works.
I suspect that gcc made some advanced optimization with bad side effects. Maybe there's missing "volatile" attribute or such things, hard to trace...
I should try with -O0

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

Oh yes, I idiot should do it at the beginning instead of messing with gcc version packages. When I changed -O2 to -Os in MAKEFILE.DJ it works fine. New gcc is much more aggressive in opt. I also faced the same problem in my code and was unable to fix it on source level so I applied selective optimization for that problematic function via __attribute__((optimize(0))). As my problem function is not time critical I don't care it's not optimized but all the rest of code is. It would be good if someone will isolate such problem function in judas and make it selective-unoptimized this way.

Here I upload my slightly modified version that produce less warnings (some non-serious are suppresed) that is ready to compile by GCC 4.6.x

http://rayer.ic.cz/download/judas210.zip

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

> Oh yes, I idiot should do it at the beginning instead of messing with gcc
> version packages. When I changed -O2 to -Os in MAKEFILE.DJ it works fine.

This means it is doing something extra with -O2 but not -Os. And in fact they are (allegedly) very similar. Normally I would blindly guess something like -fno-strength-reduce or -fno-strict-aliasing (or whatever) would fix it, but I'm not sure here.

Anyways, GCC 4.6.2's online docs says this:


-Os
Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.
-Os disables the following optimization flags:

          -falign-functions  -falign-jumps  -falign-loops
          -falign-labels  -freorder-blocks  -freorder-blocks-and-partition
          -fprefetch-loop-arrays  -ftree-vect-loop-version


But it's true, a lot of code sometimes fails with different optimizations or different GCC versions, sadly. A lot is just regressions (as GCC is quite complex and presumably hard to maintain for a billion targets while also being optimizing). Sometimes it really is good to test with "older" (classic) GCCs, but that's not always possible (e.g. C++).

> New gcc is much more aggressive in opt. I also faced the same problem in my
> code and was unable to fix it on source level so I applied selective
> optimization for that problematic function via
> __attribute__((optimize(0))). As my problem function is not time
> critical I don't care it's not optimized but all the rest of code is.
> It would be good if someone will isolate such problem function in judas
> and make it selective-unoptimized this way.

Indeed, sounds good, but even that attribute (IIRC) only works with GCC 4.4.0 on up. But I guess once you isolate the function, you could snip it out into its own .c file and "gcc -O0" that separately. Presumably it's just some silly bug (yeah, it happens).

> Indeed, sounds good, but even that attribute (IIRC) only works with GCC
> 4.4.0 on up. But I guess once you isolate the function, you could snip it
> out into its own .c file and "gcc -O0" that separately. Presumably it's
> just some silly bug (yeah, it happens).

I think it may be done conditionally via preprocessor checking for GCC version but not sure, I neved did it.

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

> If anyone want fasm code let me know.

Dex, thanks for your generous offer -- i *would* be interested in the AC97CD code. With your permission, i'd like to re-assemble it, leaving out the keypress pauses and the CD player stuff -- that way, i could automatically run just the hardware initialization from my AUTOEXEC.BAT each bootup. (I wouldn't understand all the hardware-init code , but i could follow the overall program flow.) And i would certainly leave in your authorship credit.

- Doug B.

I contacted Piotr but unfortunately he said he can't work on this project any further... So we're on our own.
He will be uploading 2.10 to his website, though, to make it official :)

-- Marton

> I contacted Piotr but unfortunately he said he can't work on this project
> any further... So we're on our own.
> He will be uploading 2.10 to his website, though, to make it official :)

Fortunatelly it seems to work as it is now. Khusraw confirmed it works on ICH10. I hope adding new chipsets like 5x and 6x series will not be difficult (just new PCI ID) if HDA core left the same.

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

> > If anyone want fasm code let me know.
>
> Dex, thanks for your generous offer -- i *would* be interested in the
> AC97CD code. With your permission, i'd like to re-assemble it, leaving out
> the keypress pauses and the CD player stuff -- that way, i could
> automatically run just the hardware initialization from my AUTOEXEC.BAT
> each bootup. (I wouldn't understand all the hardware-init code , but
> i could follow the overall program flow.) And i would certainly leave in
> your authorship credit.
>
> - Doug B.

Sure you can
http://www.dex-os.com/dos2x/ac97code.zip
i included a strip ver called test.com for you to test (which i have not tested as i know longer have ac97 card)
If that does not work, i have include full code, so you can play around with it.
You can do what you want with code, it was done a very long time ago, when i first started coding.
Dex.

> Fortunatelly it seems to work as it is now. Khusraw confirmed it works on
> ICH10. I hope adding new chipsets like 5x and 6x series will not be
> difficult (just new PCI ID) if HDA core left the same.

I'd like to see it implemented in Mplayer, so I can get an idea for implementing it in my MAME build. I remember having problems updating the audio via judas_update(), couldn't make it work :(

> i included a strip ver called test.com for you to test (which i have
> not tested as i know longer have ac97 card)

Dex, the initialization-only TEST.COM works fine! It now has a permanent place in my AUTOEXEC.BAT -- i can listen to CDs again in DOS using all my favorite old players.

Sir, you are a gentleman and a scholar!

Many thanks again....

- Doug B.

Direct quote from Piotr:

---
Unfortunately due to other matters in real life and almost no time at all I won't be able to work on this project further. The website link below has 2 last versions of the Judas library. The 2.09 version and the 2.10 HDA version which is released to the public under the GNU/GPL license. The 2.10a test version I have sent you 3 years ago was not an official public release.

I decided to release the 2.10 under GNU/GPL becasue that HDA code was written after analyzing various HDA linux related sources, the drivers from ALSA project, the OSS sound system project. Although this code is different and pretty unique some similarities especially in the HDA nodes access strategy can be found. Considering I won't be able to work on this project further I think it will be best to end it like this.

http://www.piotrkn22.republika.pl/judas/index.html
Last version here is 2.09 - free, 2.10 HDA free too but under GNU/GPL license.
---

So that's it. HDA support is now official, and it is on the GNU/GPL...

Merry christmas for all!!

> So that's it. HDA support is now official, and it is on the GNU/GPL...
>
> Merry christmas for all!!

Okay, it's good news, but let's not be too overly happy. We don't want to give people false hope (i.e. it doesn't work for me on new 2010 machine w/ HDA, so it's best to say "incomplete, hopefully works for you").

> Okay, it's good news, but let's not be too overly happy. We don't want to
> give people false hope (i.e. it doesn't work for me on new 2010 machine w/
> HDA, so it's best to say "incomplete, hopefully works for you").

On what machine/chipset? It's obvious that software from 2008 doesn't recognize PCI PIDs of new chipsets. It needs to be added. I can do it and recompile it but I don't know if any further changes in HDA core are needed but you can test it. You can send me the PCI list by my
smb /pci >log

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

> > Okay, it's good news, but let's not be too overly happy. We don't want
> to
> > give people false hope (i.e. it doesn't work for me on new 2010 machine
> w/
> > HDA, so it's best to say "incomplete, hopefully works for you").
>
> On what machine/chipset? It's obvious that software from 2008 doesn't
> recognize PCI PIDs of new chipsets. It needs to be added. I can do it and
> recompile it but I don't know if any further changes in HDA core are needed
> but you can test it. You can send me the PCI list by my
> smb /pci >log

smblog.zip ... though I hold no expectations, esp. for new (annoyingly incompatible) hardware. I just don't want anybody getting their hopes dashed by thinking it works in all cases when it doesn't.

> ... though I hold no expectations, esp. for new (annoyingly incompatible)
> hardware. I just don't want anybody getting their hopes dashed by thinking
> it works in all cases when it doesn't.

Well, I added PCI IDs for intel 5 and 6 series, recompiled here:
http://rayer.g6.cz/download/judas210.zip
good luck!

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

Not all chips are made by Intel. I do not know for HDA but for the AC97 VIA and the other manufacturers made their versions a little bit different so an Intel driver would not run with their chips.

Only Intel's documentation is easy to get. So you end up retro-engineering for the other chips.

Georg

> Not all chips are made by Intel. I do not know for HDA but for the AC97 VIA
> and the other manufacturers made their versions a little bit different so
> an Intel driver would not run with their chips.

If I understand well, the HDA core is built in chipset e.g. intel or nvidia and it interface the external codec via I2S or similar bus that can be supplied from different manufacturers. My gigabyte MB uses Realtek ALC888 also chips from Analog Devices are common but it doesn't matter from programmers point of view. Important is the HDA core in chipset.

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

Yes, you can use codecs from different manufacturers but for the AC97 the programmer's interfaces also varied. As far as I learned that is also the case for HDA. That was one of the reasons I did not extend my AC97 driver to HDA.

Georg

> Yes, you can use codecs from different manufacturers but for the AC97 the
> programmer's interfaces also varied. As far as I learned that is also the
> case for HDA. That was one of the reasons I did not extend my AC97
> driver to HDA.

Hm, I thought that there's stnadard interface between chipset and codec also for programmer. How can programmer detect type of codec chip? It's not visible from PCI space.

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

The interface betweeen chipset and codec may be standard but that is not the interface you use to tell the chip to play your sound data. That interface differs for the chipsets.

Georg

> > Yes, you can use codecs from different manufacturers but for the AC97
> the
> > programmer's interfaces also varied. As far as I learned that is also
> the
> > case for HDA. That was one of the reasons I did not extend my AC97
> > driver to HDA.
>
> Hm, I thought that there's stnadard interface between chipset and codec
> also for programmer. How can programmer detect type of codec chip? It's not
> visible from PCI space.

georgpotthast(R) is right, i found the same problem when coding AC97 drivers for my OS.
Took me along time to get any ac97 VIA support in my OS.
Dex

> Well, I added PCI IDs for intel 5 and 6 series, recompiled here:
> http://rayer.g6.cz/download/judas210.zip
> good luck!

I also have a problem with the old version of judas identifying my HDA sound card. With this version I can get past the identification stage, and I can get the player to display bar graphs whilst playing an XM file, but with no sound. I have the following chip and configuration on my new Dell laptop:

Intel HD Audio with 92HD81.
HDA controller revision......: 05h
HDA controller register base.: 96930000h
Codec I/O base address.......: 0000h
IRQ..........................: 5 (05h)
Codec bus addr...............: 0
Devices Found mask...........: 09h
Codec Subsystem ID...........: 0429h
System ID....................: 0429h
Codec Device ID..............: 111D7605h

Note that this is an Intel chip with which Judas is expected to work. I have the same problem with getting Mpxplay to work. It behaves normally, doesn't crash, but the sound is muted. The sound drivers used in Mpxplay are ALSA drivers.

It is also interesting that Dell provides a DOS hardware testing program, which includes testing of the sound card and can produce very clean sounds. It is a pity that the code for their drivers is closed.

> It is also interesting that Dell provides a DOS hardware testing program,
> which includes testing of the sound card and can produce very clean sounds.
> It is a pity that the code for their drivers is closed.

Did you tried to run MPX od Judas after using Dell utility? May be it needs some more init step that BIOS didn't but the utility might did it. Maybe it's specific issue of this Dell machine/BIOS...

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

> georgpotthast(R) is right, i found the same problem when coding AC97
> drivers for my OS.
> Took me along time to get any ac97 VIA support in my OS.
> Dex

It seem's that MS was able to make unified driver, following text seems like some basic functions are common. Forget AC'97 now.

Microsoft* has chosen Intel HD Audio as the main architecture for their new Unified Audio Architecture* (UAA), which provides one driver that will support all Intel HD Audio controllers and codecs. While the Microsoft driver is expected to support basic Intel HD Audio functions, codec vendors are expected to differentiate their solutions by offering enhanced Intel HD audio solutions. The result is high-quality PC based audio that delivers a seamless convergence of digital entertainment between the PC and consumer electronic devices.

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

> > ... though I hold no expectations, esp. for new (annoyingly
> incompatible)
> > hardware. I just don't want anybody getting their hopes dashed by
> thinking
> > it works in all cases when it doesn't.
>
> Well, I added PCI IDs for intel 5 and 6 series, recompiled here:
> http://rayer.g6.cz/download/judas210.zip
> good luck!

This is your (DJGPP) compile of Judas 2.10c, to be precise, and it actually works (JP.EXE, ANAL.EXE). I'm quite surprised.

Though Mpxplay still doesn't work, even if run directly afterwards, just plays a lot of rough, noisy static.

> This is your (DJGPP) compile of Judas 2.10c, to be precise, and it
> actually works (JP.EXE, ANAL.EXE). I'm quite surprised.
>
> Though Mpxplay still doesn't work, even if run directly afterwards, just
> plays a lot of rough, noisy static.

Nice to hear it works, it was very easy to extend it. Maybe someone could tell the author to upload this version on official site.
Try to ask Attila if he have a look on judas sources and compare HD code...

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

> Nice to hear it works, it was very easy to extend it. Maybe someone could
> tell the author to upload this version on official site.

I did, author updated his page and added a "Contributions" area.
http://piotrkn22.republika.pl/judas/index.html

Quote from him:

I'm just updating the Judas section of my website with the contribution version. However I had to remove the ICHINIT folder which contains a buggy version of ICHINIT. As I remember this utility was not required to initialize HDA but the old AC97. Still it does not work on 3 of my laptops with ICH bridge and AC97 (ICH6). Only the old assembler version currently on my website does. If I have some time in the near future I will compare the 2 versions and update that utility. Still this program is not required to run if you use Judas - but a helper initialization code if things do not work normally. Also the current HDA code in Judas library is designed to work on systems using INTEL ICH southbridge. Some parts include code for other manufacturers but it was never tested.

best regards,
P.Ulaszewski

---

2 thumbs up!!

> Well, I added PCI IDs for intel 5 and 6 series, recompiled here:
> http://rayer.g6.cz/download/judas210.zip

COOL Tiny problem: WAV output seem to no longer work (and I don't have HDA to test).

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> COOL Tiny problem: WAV output seem to no longer work (and I don't have
> HDA to test).

JP.exe has messed WAV playback also in version 2.09f as I tested (incorrect format reported) so it's much older issue than I touched the files.
My latest minor update 2.10d includes PCI ID for intel series 7 HDA.
Also there's a good new that Khusraw was able to adopt judas HDA support into WSS library that makes further things easier...

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

> JP.exe has messed WAV playback also in version 2.09f as I tested (incorrect
> format reported) so it's much older issue than I touched the files.

I mean WAV output (input XM or MOD), not WAV input.

> My latest minor update 2.10d includes PCI ID for intel series 7 HDA.



> Also there's a good new that Khusraw was able to adopt judas HDA support
> into WSS library that makes further things easier...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > JP.exe has messed WAV playback also in version 2.09f as I tested
> (incorrect
> > format reported) so it's much older issue than I touched the files.
>
> I mean WAV output (input XM or MOD), not WAV input.

What wav output you mean? How can I try this? Anal invader use wav samples that plays OK.

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

> > > JP.exe has messed WAV playback also in version 2.09f as I tested
> > (incorrect
> > > format reported) so it's much older issue than I touched the files.
> >
> > I mean WAV output (input XM or MOD), not WAV input.
>
> What wav output you mean? How can I try this? Anal invader use wav samples
> that plays OK.

jP.EXE has an option to output the .MOD file to .WAV format (raw samples). This is specified by the -w option. Your new DGJPP compiles in ver 2.10c and 2.10d apparently break that feature:

ie:

JP <sample.MOD> -w A.WAV

is now broken, and immediately exits with s SIGSERVE error in your new compiled versions. The file A.WAV is created, only as a 44-byte file with header and 0 data. Is there any possibility of a fix, as it would be great to have the .WAV file writing capability and support for the other HDA Audio chipsets you enabled.

> is now broken, and immediately exits with s SIGSERVE error in your new
> compiled versions. The file A.WAV is created, only as a 44-byte file with
> header and 0 data. Is there any possibility of a fix, as it would be great
> to have the .WAV file writing capability and support for the other HDA
> Audio chipsets you enabled.

I didn't any other mods except adding new HDA PCI IDs. The problem is in new GCC/optimization. If you need it use older DJGPP GCC version. I don't have time to debug and fix Judas for new GCC.

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

I tried to link Judas library with my Freepascal units. I had problems with linking, than I solved it by changing by replacing different version of LIBGCC.A but although my unit compiles and is linked with Judas, it still does not work. It fails in initialization in judas_config function.
(returns 0).
Could you send me your working library files (LIBC.A, LIBGCC.A and so on) to try it once more?

---
DOS-u-akbar!

> I tried to link Judas library with my Freepascal units. I had problems with
> linking, than I solved it by changing by replacing different version of
> LIBGCC.A but although my unit compiles and is linked with Judas, it still
> does not work. It fails in initialization in judas_config function.
> (returns 0).
> Could you send me your working library files (LIBC.A, LIBGCC.A and so on)
> to try it once more?

I compiled Judas in DJGPP v2.04, libs are available on DJ's FTP - package DJDEV and GCC 4.6.x. Also here's last updated DJDEV package: http://sourceforge.net/projects/ffmpeg-x264-dos/files/
But maybe you'll be better with WSS library used in MPLAYER - it has some additional patches on HDA code and it's simplified to single C file :)

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

> I compiled Judas in DJGPP v2.04, libs are available on DJ's FTP - package
> DJDEV and GCC 4.6.x. Also here's last updated DJDEV package:
> http://sourceforge.net/projects/ffmpeg-x264-dos/files/
> But maybe you'll be better with WSS library used in MPLAYER - it has some
> additional patches on HDA code and it's simplified to single C file :)

IMO WSS is an excellent library, but it lacks module playing, sampling rate/format conversion etc., so if you don't want to write such code yourself or take it from elsewhere, Judas is the better choice.

---
Glory to God for all things

> My latest minor update 2.10d includes PCI ID for intel series 7 HDA.
> Also there's a good new that Khusraw was able to adopt judas HDA support
> into WSS library that makes further things easier...

Interesting. I downloaded 2.10c from http://www.piotrkn22.republika.pl/judas/index.html , and can't hear any sound. Khushraw's MPlayer with WSS, instead, works like a charm on my PC with HDA running FreeDOS. Will try version 2.10d...

Hello guys,

I was able to code a tool which is redirecting PC speaker sound to headphone. Now it's easy to capture the music of any DOS game or demo which using PC speaker.

The tool sets up the HDA mixers. To do the job the sources of WSS audio library and AC97 CDPlayer were great help.

Here is the link of Unmute DOS tool:
https://github.com/Kaproncai/Unmute

cheers, TomCat

Hello Tom!
Redirecting PC speaker into modern sound card is indeed extremely interresting.
I tried your utility on two computers but unfortunately in both cases it does not work properly.

In the first case is it an older machine with SoundBlaster Live! which is not HDA compliant but just AC97 compliant.
Your program says: "HDA mixer volume: 01F" and silently ends.
Maybe some additional error message would be needed...

In the second case is it notebook HP Pavilion dv6.
Now it writes much more output.
But in the result nothing happens and I can't hear any sound from PC speaker programs (like game Duck Tales)


Unmute - PCBEEP to headphone - Written by TomCat/Abaddon - v1.0/2017
--------------------------------------------------------------------
HDA mixer volume: 01F.
HDA device id: 293E, vendor id: 8086.
- i/o base found at DA100000, mapped to 00122000, selector: 0C7.
HDA codec id: 7603, vendor id: 111D.
- codec address found at 00000000, first widget id: 00A, last widget id: 027.
- BEEP generator widget id: 026 DISABLED.
- PC speaker widget id: 00D MUTED.
- PCBEEP widget not found.
HDA device id: AA38, vendor id: 1002.
- i/o base found at DA010000, mapped to 00122000, selector: 0CF.
HDA codec id: 0000, vendor id: 0000.
- codec address found at 00000000, first widget id: 002, last widget id: 002.
- BEEP generator widget id: 001 DISABLED.
- PCBEEP widget not found.

---
DOS-u-akbar!

Hi!

Dell Inspiron 15, Caldera DR-DOS 7.03 kernel Realtek HDA chipset. Your utility works properly. I had problems that after initializing my chipset as a sound card (MPXPlay, QuickView, HX.DOS 2.17+) it stops working as a PC speaker. Now it is at least partially solved, thanks :)

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

Perhaps this is useful for you, this is my hardware according to PLAYWAVE.EXE (HX.DOS)

IHD : Intel PCH (80861E20) -> Realtek (10EC0282) (max 192kHz/24bit/2ch)
IRQ : 10 at INT 0x72 installed

Also here is your program's output:

Unmute - PCBEEP to headphone - Written by TomCat/Abaddon - v1.0/2017
--------------------------------------------------------------------
HDA mixer volume: 01F.
HDA device id: 1E20, vendor id: 8086.
- i/o base found at C1610000, mapped to 0094C000, selector: 1A7.
HDA codec id: 0282, vendor id: 10EC.
- codec address found at 00000000, first widget id: 002, last widget id: 023.
- BEEP generator widget id: 001 DISABLED.
- PC speaker widget id: 014 MUTED.
- headphone widget id: 021 UNMUTED.
- PCBEEP widget id: 01D on 0B#4 0C#1 0D#1 0F#0 22#5 22#4 23#5 23#4 UNMUTED.
HDA codec id: 2806, vendor id: 8086.
- codec address found at 30000000, first widget id: 002, last widget id: 008.
- BEEP generator widget id: 001 DISABLED.
- PCBEEP widget not found.

I should have sent it yesterday but my experiments with Hungarian runic script to DOS bidi display screwed up SNIPPER.COM and I couldn't copy-paste anything. Also a similar utility redirecting everything to the internal laptop speakers would be also useful. Unfortunately HX.DOS 2.17+ only outputs to the lineout jack, so I always need externals devices for it. It's not "fully" featured. Also your beeper settings sounds better than my laptop's default, so it would be great if I could set it up to this beeping but to the built-in speakers.

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