Hi everyone - it's been a while!

A few weeks ago I came across Jeff Leyda's ICH2 PLAYER (at programmersheaven iirc, filename was 23237.zip)
AC97/HiDefAudio support has been on my FAMOS "To Do" List for a while, so I thought this would definitely be worth a look. Especially since the well-commented ASM source was provided (albeit MASM and the EXE is only 1640 bytes! Hopefully a quick start for AC97 support in FAMOS!

The only machine I have with AC97 is a 10-year-old Acer laptop but it has ICH4, not ICH2 which PLAYER assumes (and is well explained in Jeff's Readme.TXT). Close enough, shouldn't take long I thought...

Although it's a small program, I decided it would be quicker to hack the PLAYER.EXE binary, rather than doing a FASM conversion for DOS. (If I ever do a FASM conversion it will be a FFASM conversion in my FAMOS IDE. And of course I simply REFUSE to use MASM. I'd MUCH rather hack I've done a bit of hacking before - notably removing or replacing the INT 21h DOS functions in a variety of DOS games which now run happily in FAMOS.

Running Jeff's original code produced the message "Error: Unable to find intel ICH2 based audio device!"
So I started by changing Jeff's hard-coded PCI device number (2445H) with my laptop's ICH4 device number (24C5H), and PLAYER then ran without the "device error" message, but also without everything else - no music, not even so much as an aubible click from the speakers. But I was encouraged by the fact that pressing either shift key successfully returned to DOS. So at least it hadn't crashed!

I then read Jeff's docs more thoroughly, noting his comment in README.TXT:
"ONLY supports the ICH2 chip at the moment. Other ICHes (ICHi?) should be compatible with the the ICH2 but I don't have any to test...". No such luck Jeff! Then I focussed on this: "No volume adjusts are done by the codec. Your mixer and codec might default to muted and/or off when you boot into DOS. See the file codec.asm as to where you can change this easily."

Yes, that would be par for the course - OEM's ARE NOT THE PROGRAMMER'S FRIEND!! Why would they make an AUDIO codec default itself to a MUTED state??? That's a bit like making a video driver default to "no video"!! So I checked Jeff's source and he had kindly included the required code to un-mute the codecs and set the volume to maximum, but had left it commented out! Fortunately I could see an easy way to patch the required code into the existing 1640-byte binary footprint. (I noticed Jeff had implemented a 32-byte time delay routine based on TC1 dram refresh rollover, so I patched in an equivalent 16-byte routine using INT 15h/86h. And then squeezed the required code into the free 16 bytes).

....After which my Acer still remained stubbornly silent That was quite disappointing, but not altogether surprising. It has warned me that this is NOT going to be my hoped-for quick hack!

With nowhere else to go, I've had to bite the bullet and start downloading AC97 info from the net. Worse still, I had to RTFM's!! So before I knew it I had several PDF's totalling 1000 pages or so, including various Intel ICH datasheets, AC97 Programmer's Reference Manuals, AC97 Component Specifications etc. etc. (but still a small amount of material compared to all the USB stuff I accumulated a few years ago!)

Almost by chance I noticed a subtle difference in the PCI Audio Register specs between ICH2 and ICH4. ICH4 supports Base Address Registers (BARs) in MEMORY, whereas in previous versions BARs were IO-mapped ONLY! So there's an extra Configuration (CFG) Register in the ICH4 AC97 controller that doesn't exist in ICH2.

In true PROGRAMMER-UNFRIENDLY fashion, the "comments" about this register in the AC97 Programmer's Reference Manual are: "When cleared, the I/O space BARs at offset 10h and 14h become read-only registers. This is the default state for the I/O BARs." And sure enough the default value is shown as 00h. Which makes an OUTRIGHT LIE of the "backward compatibility" promised by Intel. To dispel any doubts about this, here is the proof:
The I/O BARs are defined at PCI configuration space offsets 10-17h.
The memory BARs are defined at PCI configuration space offsets 18-1Fh which didn't exist prior to ICH4, but are the ONLY registers which are fully functional by default in ICH4. The I/O BARs are "crippled" with read-only access, UNLESS SPECIFICALLY ENABLED via the CFG register!

So WHY did Intel do this? Any opinions?

To be continued.... when I have time (and one day I'll post my (hopefully working!) ICH4 version of PLAYER! I can't promise fasm source code, but I WILL fully document all the hacks I make.)

It's been some years since I've read any ICH* docs. From what I can remember, most of the legacy support is setup by the BIOS so that compatibility would be completely transparent, and if not needed/desired - completely discarded. Also, supporting both interfaces is likely not possible, or has other limitations. Everything changed to memory mapped registers as the IO space is too limited.

If a switch doesn't exist in the BIOS then it likely isn't configured, and so the configuration default to ICH4 and is left for the OS to configure.

Exactly. Of course Micro$oft have been told how to do the configuration for every individual machine, but this information is not available to the rest of us...

Also Intel claim full backward compatibility for all ICH's, but this appears to be an outright lie: Yeah right. The I/O BAR-Mem BAR issue proves that lie. BTW, Mem BARs were introduced to reduce access times according to the docs.

The linux drivers are open source if you need some code to look at to figure it out. Learning curve is very steep for such long winded docs.

You're right, especially when the docs often seem to be structured to be as difficult to read as possible Thanks, but unfortunately the linux sources will probably be even worse because firstly they are written in a foreign language (C ) and secondly they invariably contain a plethora of .INC files and .H files with a myriad of inane data definitions!

> A few weeks ago I came across Jeff Leyda's ICH2 PLAYER

Jeff tried to send me an updated version ... and lost it at that occasion

3 MiB

What is this? I must have the Download Doldrums! Avast didn't complain about this one, but Winzip says it is invalid or corrupted

neville, it appears that DOS386 is trying to bundle a bunch of different files together, and I'm not totally sure how (appears to be a .tar with .ZIPs inside, among others).

The real answer he's trying to give is that (for DOS) you're best off using something like Khusraw's modified WSS or latest (ALSA-inspired) Judas Player (now with HDA support).

Or maybe Mpxplay would give you the code you need, who knows, worth looking at, perhaps.

Thanks rugxulo. So I've just downloaded several versions of Judas (with source, hopefully asm!) I found at http://piotrkn22.republika.pl/judas/index.html which will be yet more happy reading for me when I get a chance. One of the versions is said to include AC97 and HDA support, while another has AC97 support but not HDA. So it will be interesting and hopefully it will help me with HDA support in FAMOS also.

It's a 100% valid (misnamed) TAR: