VOGONS


Reply 20 of 29, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

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!

Retro-Gamer 😀PowerMac 6100-66/Houdini 486/66 - G4 Cube 450/Rage128pro OS9.0.1 - Macintosh LC/Apple IIe Card OS6.0.8 - Acorn A4000 Archimedes - Unisys CWD 486/66 + Aztech Washington

Reply 21 of 29, by digger

User metadata
Rank Oldbie
Rank
Oldbie

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!

Reply 23 of 29, by dionb

User metadata
Rank l33t
Rank
l33t

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.

Reply 24 of 29, by dr.zeissler

User metadata
Rank l33t
Rank
l33t
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.

Retro-Gamer 😀PowerMac 6100-66/Houdini 486/66 - G4 Cube 450/Rage128pro OS9.0.1 - Macintosh LC/Apple IIe Card OS6.0.8 - Acorn A4000 Archimedes - Unisys CWD 486/66 + Aztech Washington

Reply 25 of 29, by bakemono

User metadata
Rank Member
Rank
Member

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.

new retro game on itch: https://90soft90.itch.io/glamorous-zombie-flakes

Reply 26 of 29, by EduBat

User metadata
Rank Newbie
Rank
Newbie

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.

http://edbatalha.info

Reply 27 of 29, by digger

User metadata
Rank Oldbie
Rank
Oldbie

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! 🙂

Reply 28 of 29, by EduBat

User metadata
Rank Newbie
Rank
Newbie

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?

Attachments

  • Filename
    PLRVRA.ZIP
    File size
    1.84 KiB
    Downloads
    4 downloads
    File license
    Public domain

http://edbatalha.info

Reply 29 of 29, by digger

User metadata
Rank Oldbie
Rank
Oldbie

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.