Simple Question: Is it possible to "activate" line-input for AC97 (AD1885/i815e) under Dos? (I want to use LTP-Devices under plain Dos)

thx!

Should be possible. It would just be a matter of programming the right PCI registers.

The application already optionally does this for line-out when you specify the /v option on the command line.

However, if I understand the AC'97/ICHx standard correctly, this happens to be exactly the thing that differs per chip/code manufacturer and isn't necessarily universal. The same is definitely true for line-out. That's why many variants that are supposed to be compatible with this piece of software don't actually make any sound yet.

I've been looking at the Linux and FreeBSD drivers for many of these chipsets to glean some insights on device/manufacturer-specific quirks that might have to be applied.

Help with this is welcome, of course!

@dr.zeissler can you try running ich2player on your system and share the output here? Thanks.

No time this week, but should have some time next week. I have a new CPU I want to try on that Compaq SW400 board anyway... give the topic another kick in a week's time if I haven't posted anything.

digger wrote on 2020-11-02, 21:11:

@dr.zeissler can you try running ich2player on your system and share the output here? Thanks.

I don't think that will do anything I need. I don't need an audio player, I only need a mixer, but afaik this does not work for AC97 without SB-Emulation built-in.

I tried it on ICH4M - vendor 8086 device 24C5 rev03 (known to Windows as Analog Devices SoundMAX)

player /v pfm.wav

The file was 44KHz, 16-bit, mono. It played at double speed.

Hi, I have a Compaq N610c laptop with a 82801CAM/ICH3-M and a AD1886A codec.
I downloaded your code from github and tried compiling with with the Watcom Assembler and Linker in Freedos.
The owmake.bat file did not work, at first it complained that the linker line was too big. I fixed it by replacing the line with
wlink sys dos f *.obj
Then the linker complained that it could not find print16BitHexValue, this was because the bat file did not have ...
wasm printhex.asm
... anywhere.
After that, it created the exe file and played the espeak samples perfectly with the /v option... I mean, at maximum volume...
As the laptop does not have any way to control the volume in dos I then changed line 68 in codec.asm from xor ax, ax to mov ax,0808h which made the volume acceptable. A nice improvement would be to replace the /v option with a /x where x is a number between 1 and 9.
By the way, the code is great, super simple and very well commented. It was just what I was looking for to understand the whole AC97 stuff.
Many thanks to Jeff and to you.

All the thanks should go to Jeff Leyda. It's still mostly his code.

All I simply did was pushing it to GitHub, adding a few simple tweaks to enable it to work with more chipsets, adding some command-line arguments for volume control and unmuting, and figuring out how to assemble the code using the Open Watcom assembler.

Sorry for the batch file not initially working. I was developing in Linux myself, and basically ported my shellscript to a .BAT variant without actually testing the latter.

Thanks for helping me test the code! It's indeed fairly well structured and understandable. Much more so than most other DOS assembly sources that I've been toying with.

Feel free to offer pull requests with your improvements and suggestions! 🙂

Hi, I'm not a programmer by trade, but I learned assembler and C many years ago. I don't have a github account and besides doing a git clone here and there when needed to download stuff from the internet I don't know how to use it ... So, sorry, no pull requests...
But I'm more that happy to offer suggestions!

1) in player.asm between "call getSampleRate" and "call codecConfig" there's an excellent opportunity to put a "call print16BitHexValue" and printout the sample rate just read from the file

2) the datasheet of the AD1886A in my Compaq says this about bit0 of the Extended Audio Status and Control Register (Index 2Ah):

VAR Variable Rate Audio. VRA=1 enables Variable Rate Audio mode (sample rate control registers and SLOTREQ signalling

. The datasheet also states that the default value of the whole register is 0000h. I did a number of tests and concluded that without changing this bit to 1 I was unable to set the proper sample rate.
I ended up doing these changes in codec.asm, which did the trick:

codecConfig proc public
push ax
push dx

push ax

mov dx, ds:[NAMBAR] ; get mixer base address
add dx, CODEC_EXT_AUDIO_CTRL_REG ; register 2ah
in ax, dx
or ax, 1
out dx, ax ;

call delay1_4ms
call delay1_4ms
call delay1_4ms
call delay1_4ms

pop ax

mov dx, ds:[NAMBAR] ; get mixer base address
add dx, CODEC_PCM_FRONT_DACRATE_REG ; register 2ch
out dx, ax ; out sample rate


I don't have datasheets for other codecs but I suspect that setting this bit to 1 on other codecs will be harmless.
Can you all test?

Thanks for the patch, EduBat! 🙂

Two things:

• I'll have to take a look in the BSD and Linux sound driver sources for ICHx sound devices to verify that setting that extra bit won't break stuff for other devices. If there is conditional logic that only sets this bits for certain specific devices, that could be a sign that it indeed should only be done for some ICHx compatible devices.
• With the code block you inserted, have you noticed ax being pushed twice now? That seems wrongly redundant somehow. Or am I missing something?

Thanks again.

Hello,

No, it's not redundant, you just save ax twice because you need to reuse it.
All the codec registers are transparent to the ICHs, they just pass the values to the codec chips, so what is important here is to check the codec datasheets.
The VRA (Variable Rate Audio) bit is actually part of the AC97 specs: page 28 on revision 2.2 explains it well.
The way this is supposed to work is that you first read register 0x28 to discover the codec chip capabilities and then use register ox2a to set up the feature if available. As these are all optional capabilities, the specs (page 105) do not define default values so some codec chips have the VRA on and others have it off.
The good news is that if your codec chip is unable to do variable bit rates setting the bit to 1 will likely have no effect. If it is, then the program will now work for all bitrates regardless of the default at power on.
It would be nice to have more people report back what ICH / codec combination they have and if the program works for them.

Cheers,
EduBat

i tested it on my ich6 and it worked

dr.zeissler wrote on 2020-11-02, 10:21:

Simple Question: Is it possible to "activate" line-input for AC97 (AD1885/i815e) under Dos? (I want to use LTP-Devices under plain Dos)

thx!

Yes, it should be possible.
- Unzip the attached file anywhere on your drive
- run lspci -i pci.ids You will see a list of all the PCI devices and functions on your computer
- Take a note of the triplet in this format BB:DD.F associated with your audio device
- Now run lspci -vvs BB:DD.F where BB:DD.F comes from the earlier step. You will see a number after Region 0. Take note of this number. (example: in my case it is 4000)
- Now run the dos command debug. You will see a - prompt
- (I will use my example, adjust for your case) In the prompt type ow 4002 202 This will unmute your speakers if the BIOS left them muted
- Now type ow 400e 8 if you want to unmute your microphone an direct it to the speakers
- Or ow 4010 808 if you want to do the same for line in
- you can now type q enter to exit debug and can run your program which outputs to LPT

This is all done in the analog mixer domain of the codec.

(I compiled lspci following these instructions https://www.flashrom.org/DOS )

EduBat

Thx, I'll have a look next week....I am on vacation. Thx!

dr.zeissler wrote on 2021-08-15, 14:09:

Thx, I'll have a look next week....I am on vacation. Thx!

Please note that I used the debug command from FreeDOS. MS-DOS may have a different syntax for the Output port command.
Also, if the sound crackles/saturates the speakers, there are attenuation settings that can be tweaked.

EduBat

I just ran past this thread again, and was curious if the development had progressed any further. Probably the same as others here, I keep running in to machines that would be great for DOS use, except for the presence of AC97 sound “hardware”.

- Alex

Oh, I forgot about testing this...I dumped the machine and went for an ess-solo1-pci.

Nice to read that there is definitely demand for such a driver or emulator. 🙂

I haven't gotten around to working on this further lately. I've been juggling multipole retro programming hobbies on the side occasionally.

Let's see if I can find some time to pick up this project again in this fresh new year. I can't give any timetable, though.

Back on that thing. AD1885 Soundmax on I815e-Chipset on msdos. Checking some LPT Devives with that Line-IN.

Maybe I can help, I'm adding AC97 / HDA support to FastDoom using the codebase of the Judas library, and starting to learn how it works.