7ZX is a nice board with the blue pcb

sadly during that era they released many revisions and if you had revision 1.0 or 1.01 then you would be stuck with support up to an athlon xp 1800 i belive.

while if you had revision 5 you would end up havind support up to athlon xp 2400 or 2600.

that kind of sucked, the same thing happened with a SOYO board that depending on the revision you had more cpu support.

the board is also good for its universal agp, you could put a voodoo card for example.

computerguy08 wrote on 2021-09-14, 15:57:

That chip is just a backup BIOS, Gigabyte dubbed it "DualBIOS". […]
Show full quote

That chip is just a backup BIOS, Gigabyte dubbed it "DualBIOS".

You should be able to add an ISA slot, the resistor packs are there.
Same mod can be done to a 7ZXE.

EDIT: I was looking on the right side of the image, where you have another IC missing (that one is the 2nd BIOS 😜) ; only way to know is to try adding the slot and see if you have DMA and stuff.
EDIT 2: the VT82C686B should be able to do ISA by itself, without additional chips.

I added an ISA slot to my 7ZXE rev 2.1, but it doesn't quite work. BIOS does recognize the sound card correctly as an AWE64, so some functionality exists, but CTCM says wrong serial ID check sum. Running CTCM again results in a different vendor ID being shown. Diagnose.exe is able to play some digital audio, although a bit garbled, and wavetable is not detected at all. Any ideas where to look for the problem? I did try to double check solder joints and there was one I had forgotten to solder (data 10) but fixing that did not resolve the issue.

Consider using unisound to configure it instead? That should not give to shits about the vendor ID being "wrong".

wierd_w wrote on 2026-05-20, 20:53:

Consider using unisound to configure it instead? That should not give to shits about the vendor ID being "wrong".

Unisound doesn't detect it at all, so there must be some problems either with hardware or how BIOS handles ISA. Latter sounds more likely, as BIOS itself manages to detect AWE64 but somehow CTCM is unable to read same vendor ID two times in a row.

Apparently vendor ID is part of ISA PnP scheme, which sounds like quite a hack...

Anyhow, any write-transaction at that address gets all of the ISA-PnP cards' attentions. […]
Show full quote

Anyhow, any write-transaction at that address gets all of the ISA-PnP cards' attentions.

From there, there's a "key" sent to, again, all of the ISA-PnP cards; a specific sequence of bytes sent to that same address. This confirms to the cards [all of them] that the system wants to start configuring them.

But, now, how does it configure *only one* card? [And, actually, "card" is inappropriate, as multi-function cards need multiple configurations].

So we need a bit more background. Yes, each card [or function?] has a unique [UNIQUE] identifier, including a 32-bit manufacturer ID, and a 32-bit unique ID [so, say you have two identical cards, they can be separately-identified].

Alright, but now how you gonna select the first one to configure? Test every single possible ID of the 2million-squared? Nah, booting would take forever.

So, yes, more background; there is an address *also* for read-back. BUT: this one's at a different location. Otherwise, reading-back from the shared parallel-port status-register and PnP configuration-register address *will* get a response from the parallel-port [when installed, which was *usually*], which would cause bus-contention with the PnP cards' also responding.

But Wait! The parallel-ports other registers are all R/W, so we can't use them! And there could be *anything* at *any* address!

So, they've got a *range* of addresses to choose from, for read-back. But, no, there's not yet a way to set a unique read-back address for each PnP device. It gets crazier.

After the "key" unlocks configuration-mode on *all* the devices, it first searches for available devices, and requests their IDs. In that request, it tells the devices which address to respond at.

https://hackaday.io/project/167010-todays-ass … ow-thats-a-hack

Any ideas how to debug this? At the moment I don't have any other ISA cards to test this with. I haven't built a computer around the board yet, I'm just trying to verify that the slot works with a bootdisk that has some Creative tools on it, so obviously I haven't installed VIA's 4in1 driver package. Google search tells that the driver package is strongly recommended, but surely the chipset can't be quite *that* dysfunctional without it, right?

Based on image presumably uploaded by @computerguy08 to Retroweb, my board has the same passive component footprints populated, so that shouldn't be the problem.

https://theretroweb.com/motherboard/image/7zx … d2076084371.jpg

If the ISAPnP card is listed in the BIOS then the BIOS should be setting it up with the IRQ/DMA and you don't need CTCM and CTCU. You just need to check in the BIOS if it is actually getting assigned to A220 and IRQ 5 like it should be. You probably still need to run AWEUTIL /S to initialize the Wavetable though.

Microsoft stopped certifying any product with ISA slots for the Windows Logo testing in 2000 and one of the biggest reasons they gave for that decision was that ISA PnP is a dirty hack and a compatibility nightmare. That's probably why the slot footprint was still there but not populated.

onethirdxcubed wrote on 2026-05-22, 21:30:

If the ISAPnP card is listed in the BIOS then the BIOS should be setting it up with the IRQ/DMA and you don't need CTCM and CTCU. You just need to check in the BIOS if it is actually getting assigned to A220 and IRQ 5 like it should be. You probably still need to run AWEUTIL /S to initialize the Wavetable though.

This BIOS doesn't show IRQ/DMA assignments, though. So I tried using HWiNFO to show them, which is where things got weird. When "PnP OS Installed" was set to "Yes", AWE64 didn't get assigned to anything, as expected. However, when I turned that to "No", HWiNFO crashed whenever I tried to check either DMAs or IRQs...

Looks like I'll have to actually install Windows 98 on a drive to see if this works with VIA's 4in1 drivers installed.

onethirdxcubed wrote on 2026-05-22, 21:30:

Microsoft stopped certifying any product with ISA slots for the Windows Logo testing in 2000 and one of the biggest reasons they gave for that decision was that ISA PnP is a dirty hack and a compatibility nightmare. That's probably why the slot footprint was still there but not populated.

I guess that makes sense. It would still result in Gigabyte not caring about unused legacy features in BIOS, which could cause problems like this, I suppose.

Apparently ISA cards don't like being attached to a board that is outside chassis. There were weird crashes even in Windows, but they stopped when I installed the components into a chassis. I suppose that has something to do with ISA having only four ground pins, or something... now HWiNFO works fine as well.

That said, sound card still doesn't work, and BIOS assigns weird IRQs and DMAs to it, such as 10 and 6, respectively. Maybe there are some conflicts with integrated sound card on the motherboard, even though it should be disabled?

See if you have an option in BIOS to reserve certain IRQs and DMA channels for legacy devices. For DOS you want either PnP OS = "No" and setup the resources manually in the BIOS, or PnP OS ="Yes" and then run CTCM in your autoexec.bat

See here for more info on reserving IRQs. https://www.dosdays.co.uk/topics/plug_and_play.php
You may be able to access more BIOS settings by using Ctrl+F1, Gigabyte liked hiding things.
If you have an OEM BIOS on that motherboard you probably want to flash it to the stock Gigabyte one because OEMs often hide settings.

onethirdxcubed wrote on 2026-05-25, 21:21:

See if you have an option in BIOS to reserve certain IRQs and DMA channels for legacy devices. For DOS you want either PnP OS = […]
Show full quote

See if you have an option in BIOS to reserve certain IRQs and DMA channels for legacy devices. For DOS you want either PnP OS = "No" and setup the resources manually in the BIOS, or PnP OS ="Yes" and then run CTCM in your autoexec.bat

See here for more info on reserving IRQs. https://www.dosdays.co.uk/topics/plug_and_play.php
You may be able to access more BIOS settings by using Ctrl+F1, Gigabyte liked hiding things.
If you have an OEM BIOS on that motherboard you probably want to flash it to the stock Gigabyte one because OEMs often hide settings.

There were even no options for reserving DMA channels at all, they were all hidden, even though it's Gigabyte's own BIOS rather than an OEM one. Ctrl-F1 didn't help but I managed to unhide those settings with AMIBCP. It turned out that DMA 5 was reserved for "Legacy ISA" ie. not PnP ISA, and as such the sound card got assigned to weird DMAs. I set that to PnP, and then BIOS assigned IRQ 5 and DMAs 1 and 5 to it. However, Diagnose.exe says that DMA5 doesn't work. Also, CTCM still gets random Vendor IDs and Unisound doesn't detect anything. HWiNFO also crashes occasionally if run from real mode and "Skip BIOS PnP calls" is not set.

So I took a closer look at the board and it appears that DACK5 line doesn't have a pull-up resistor, and it's at 0V during operation. That might cause problems for an active-low line... It also appears that resistor net for address lines 20-23 is not populated, but I don't know whether that would cause problems as AWE64 doesn't even have contacts for those. Here's a picture of it before the ISA socket was installed:

It turned out that there were a couple of additional things that needed to be done to get AWE64 working. First, there were a couple of ICs missing. Luckily SN74F245 is a general purpose chip that is readily available from vendors like Digikey. These resistor nets needed to be removed and the chips soldered in.

Also, OSC pin, which provides 14.31818MHz clock on ISA bus was not connected. This needed to be connected with a 0Ω resistor.

There might be other issues for cards that use other IRQs or DMAs.