You'll basically have to give up the 3xx range to get 6xx and Exx ranges, that's just a limitation of how the range setting works. The ranges are at most 256 IO locations aligned into 256 location blocks. So one range can do stuff inside say 200...2FF but it cannot span 280...37F, you'd then need two ranges, 280...2FF and 300...37F. This is a huge limitation of the LPC to ISA bridges unfortunately. Both the southbridge must forward ranges to the LPC bus and then the LPC to ISA bridge itself must forward them and both got only 4x ranges with exactly the same limitatons. If there were 8 there wouldn't be any problems.

Ideal bridge would use PCI bus for IOs and LPC only for IRQ and DMA. This is something I plan to do in future but there are other projects I have to do first. It would also require actual modifications to the motherboard as there's no standard LPC bus connectors.

Tiido wrote:

You'll basically have to give up the 3xx range to get 6xx and Exx ranges, that's just a limitation of how the range setting works. The ranges are at most 256 IO locations aligned into 256 location blocks. So one range can do stuff inside say 200...2FF but it cannot span 280...37F, you'd then need two ranges, 280...2FF and 300...37F. This is a huge limitation of the LPC to ISA bridges unfortunately. Both the southbridge must forward ranges to the LPC bus and then the LPC to ISA bridge itself must forward them and both got only 4x ranges with exactly the same limitatons. If there were 8 there wouldn't be any problems.

Ideal bridge would use PCI bus for IOs and LPC only for IRQ and DMA. This is something I plan to do in future but there are other projects I have to do first. It would also require actual modifications to the motherboard as there's no standard LPC bus connectors.

Yeah, that's quite a limitation, which I think it's probably the reason why LPC/ISA bridges aren't used on industrial motherboards as additional configurations would be needed on the user side like this case. In turn, PCI/ISA bridges don't have this limitation, but lack DMA support, which breaks sound cards (and probably legacy compatibility on PCI ones), while keeping most industrial stuffs (often not using DMA) functional.

For now I'll see if CTCU allows me to move the 620 port to A20, which is already mapped by the bridge. Otherwise, I'll just use the card as SB16 anyway 😀 as only a select few supported games would be able to take advantage of the built-in wavetable. (If AWE64 Gold has a header for a wavetable daughterboard that'd be perfect, but sadly, it doesn't)

PCI will not give ISA style IRQs either, not without PC/PCI or dedicated chipset support. One can often route a PCI IRQ to a specific ISA IRQ if BIOS allows.

There are gameport cradle type of things where you can install some Waveblaster type card and use it as an external card, this might be worth looking into. Assuming gameport on the AWE64 is connected to MPU-401 and not the SB-MIDI stuff which nothing supports.

Tiido wrote:

PCI will not give ISA style IRQs either, not without PC/PCI or dedicated chipset support. One can often route a PCI IRQ to a specific ISA IRQ if BIOS allows.

There are gameport cradle type of things where you can install some Waveblaster type card and use it as an external card, this might be worth looking into. Assuming gameport on the AWE64 is connected to MPU-401 and not the SB-MIDI stuff which nothing supports.

As for PCI/ISA IRQ I'm not entirely sure as on a PCI/ISA bridge of a board with ICH6 or later, CTCM would be able to pass IRQ tests, only DMA tests would fail.

I'm not sure with how AWE64 Gold (maybe other variants) handles MIDI. While it has onboard RAM to load custom samples, AWEUTIL has its own issues. On the 865 motherboard I currently use, when I run AWEUTIL /EM:GM it'll fire a NMI error which I need to manually clear (ignore) to proceed,

Just got the system ready. While CTCM configured everything, the DIAGNOSE screen looked just like SB16 (without DRAM and AWE test). FM synth doesn't work, either. Nothing could be heard when testing Synthesized Music.

Somehow CTCU couldn't see the device resources (when I look at either audio, gameport or wavetable, it gave me a blank dialog). I'm still investigating the cause, though.

PCI/ISA bridges use several non PCI signals so that they could do IRQs, with purely PCI signals it is not possible to target any specific IRQ.

MIDI emulation on AWE is done via the NMI/system error IRQ. Each time there's a MIDI event the board will raise a system error that the TSR will then catch and act upon. Yamaha SW20PC does a similar thing except it uses a regular IRQ instead.

As far as I know, FM goes through the EMU8000 and will not be heard until it gets initialized and that would be impossible due to lack of certain IO access ranges.

Tiido wrote:

PCI/ISA bridges use several non PCI signals so that they could do IRQs, with purely PCI signals it is not possible to target any specific IRQ.

MIDI emulation on AWE is done via the NMI/system error IRQ. Each time there's a MIDI event the board will raise a system error that the TSR will then catch and act upon. Yamaha SW20PC does a similar thing except it uses a regular IRQ instead.

As far as I know, FM goes through the EMU8000 and will not be heard until it gets initialized and that would be impossible due to lack of certain IO access ranges.

So the NMI error I'm seeing is how the program worked... It wasn't really an error then.

And yeah, it seems there's definitely a need to initialize the EMU8000 to get even the FM working. But for some reasons, after using CTCM to initialize the sound card, the devices (Audio, Gameport, Wavetable) would be visible in CTCU, but the "Resources" table is blank and I couldn't really configure anything there. Is there another way to configure the resources than CTCU? (I saw some references about something called Intel Configuration Utility or something in the manual, though) UPDATE: So far I haven't been able to make CTCU functional.

An update bump (superseding the previous edits):

1. The address used by EMU8000 are (as in what I found in the OP):

1             Port Width Name
2             620h 32 Data0 (BASE + 000h) 
3             A20h 32/16 Data1 (BASE + 400h) 
4             A22h 16 Data2 (BASE + 402h) 
5             E20h 16 Data3 (BASE + 800h) 
6             E22h 16 Pointer (BASE + 802h)

In order to get it properly seen as an AWE64, not only all the 3 address ranges are required, the bit 1 of the mask must also be set for at least A00 and E00 ranges to ensure single-word transactions within those ranges work (especially the E00 range, in which the pointer resides). According to this programming guide:

All I/O transactions must be performed as word or “doubleword” I/O transactions; no byte I/O transactions are allowed. A “doubleword” I/O transaction consists of a transfer of the LS 16 bit word of data from the specified I/O address, followed immediately by a transfer of the MS 16 bits of data from the I/O address two bytes higher.

Most reads and writes of the EMU8000 begin by writing the Pointer register. The Pointer register is a word register whose LS five bits are the Channel Number (0-31), whose next 3 bits (bits 7-5) are the Register Number (0-7), and whose MS 8 bits are Don’t Care (but conventionally zero) for a write and are random (actually a VLSI test register) during reads.

Once the pointer register has been set to the appropriate Channel and Register Numbers, the corresponding EMU8000 register can be written or read at the appropriate Data I/O port. The EMU8000 makes use of the I/O WAIT function of the bus to prevent changing the Pointer Register before a previous write transaction is complete, and to allow for reading the data from the EMU8000 internal registers before allowing completion of a read transaction.

2. The sound card cannot be configured via CTCU (the resource configuration table is blank, and is prone to crashes). However, the default settings for CTCM (inside CTPNP.CFG) will work. Also, CTCM additionally needs access to the 270 range when configuring the card. Without it, CTCM will not succeed.
3. When proper ranges for EMU8000 and masks are properly set, DIAGNOSE will be able to pick the card as an actual AWE64 card, and offers to test the onboard memory and enables AWE test. Otherwise, only SB16 tests (8-bit, 16-bit, FM) will be visible, and FM cannot be heard in this state.
4. As a result of mapping the 600, A00 and E00 ranges, the 300 range (which MIDI and FM reside) is given up. As such, the argument /DMPU must be passed to the program to bypass MPU401 port setting so you can proceed to the actual tests.
5. Even after giving up the 300 range, FM can still be heard within DIAGNOSE, implying the FM doesn't necessarily need to be accessed through 0x388. However, I'm yet to find out where the FM synth is actually located in the system (DIAGNOSE never shows the address of the FM synth), as games supporting Adlib music usually hardcode the FM address as 0x388 and this will fail because the 300 range is not mapped, and a possible rerouting of 0x388 to the correct location is needed.

EDIT: I've been looking at what I/O 3B0-3BF could be used and it seems to be used by monochrome video modes. Does it matter much on modern VGA video cards? If this I/O range is not a problem (similar to EMM386's I=B000-B7FF), setting a mask of BFh on 300 range would allow both MIDI (330) and FM (388), while keeping essential ports such as LPT (378) and COM1 (3F8) functional since they are outside the mask. This would free a mapping slot that would hopefully be used to include ranges like 530 for WSS to function.

I have pretty much the same issue and have not yet been able to figure it out. AWE64 suddenly acts as SB16 card in driver installation. No memory test and no FM sound. My last effort was to enable memory parity error checking in BIOS which I thought would solve the issue after reading this thread (and others).
Hopefully you will find a solution. I'm about to give up...

bel667 wrote:

I have pretty much the same issue and have not yet been able to figure it out. AWE64 suddenly acts as SB16 card in driver installation. No memory test and no FM sound. My last effort was to enable memory parity error checking in BIOS which I thought would solve the issue after reading this thread (and others).
Hopefully you will find a solution. I'm about to give up...

AWE64 needs 620-623, A20-A23 and E20-E23 ranges. A20-A23, E20-E23 also needs to be able to do 16-bit transactions (especially E20 range, as E22 is a 16-bit pointer which is needed when accessing the EMU8000). If those conditions are not met, the card will behave like a SB16 but no FM sound can be heard, since it's part of EMU8000, and won't function if EMU8000 is not initialized properly. Some AWE32 cards might still work as a fully functional SB16 as they do have a physical FM chip on them instead of going through EMU8000.

NOTE: AWEUTIL /S is NOT required. In most cases CTCM is ENOUGH to get the card fully working under DOS if installed and configured properly.

From the tests I've conducted I can be sure that AWE64's FM isn't physically in 0x388, it's inside one of the EMU8000 ranges (most likely 0x620). However, to retain compatibility, the card accepts accesses to 0x388 and redirects the transactions to the EMU8000 at hardware level, and you can actually access FM using physical (EMU8000) address instead.

However, given my chipset and LPC bridge's limitation (only up to 4 I/O ranges can be mapped at a time), I'm unable to map the 0x300 range to the bridge. So in the end, no MIDI and FM for games. But FM is still functional when testing from DIAGNOSE, implying DIAGNOSE actually accessed the EMU8000 directly for FM, instead of from 0x388. I think if one can possibly redirect 0x388 accesses to 0x620 via software, the FM might work.