Well it's presumably down to the PnP protocol. The ISA PnP specification is written by two old friends, messrs Intel and Microsoft and is at http://www.osdever.net/documents/PNP-ISA-v1.0a.pdf
Quote:

Page 10: Isolation Protocol (cont.)
The key element of this mechanism is that each card contains a unique number, referred to as the serial identifier for the rest of the discussion. The serial identifier is a 72 -bit unique, non-zero, number composed of two, 32-bit fields and an 8-bit checksum. The first 32-bit field is a vendor identifier. The other 32 bits can be any value, for example, a serial number, part of a LAN address, or a static number, as long as there will never be two cards in a single system with the same 64 bit number.

The manufacturer of my cards could have put any number instead of the ff ff ff ff but chose to make them all the same. I presume this is burnt into a rom somewhere and I can't change it. Therefore I presume that no system with two or more identical ISA PnP cards will work. I wish I had known this. I had just assumed that the PnP software was clever enough to do something in this case (which it isn't) or the card manufacturer is sensible enough to give the cards unique IDs.

If I am wrong, someone please say. But if I am right this should be a warning to others.

One way around this might be, if there is a program to do so, to pre-set the cards for fixed IRQs and memory addresses. That way would basically 'disable' PnP and might allow them to work.

yes, but I have no idea how. Ideally the card would have jumpers for PnP identifiers but it doesn't.

there is a rom chip on the card (a 93C66) and I contemplated unsoldering it, reading it and programming a replacement, replacing the bad bytes. But there is no guarantee I'd be able to find them (they might be programmed in rather than as an obvious look-up table), And the rest of it is hard enough on its own.

My current plan is to try to get a similar card from a different manufacturer.

I can't believe that I never heard of this problem before. Presumably I am the first person ever to try to use two identical cards in the same computer... even that is hard to believe

The configuration program is likely DOS-based, so you'd need to either boot in dos (likely 'raw' ms-dos, with no himem/emm386) or move the cards one at a time to a machine with dos.

Part of the problem with changing the PnP identifier is that it might work like PnP/PCI device IDs. Changing them might cause the card to be misidentified if the driver expects them to have a specific serial number (which would be rather dumb, but you never know).

This post links to a driver CD that might have the DOS and Windows drivers for the MED3700

An alternative might be here. Either the PnP Configuration Manager or the ISA Configuration Utility might do the trick, but you'd probably need to do the configuration with only one card in the system at a time.

With some luck the PnP configuration manager might have the necessary options to change the serial number too.

edit: more information here

Thanks .. well my "simple" solution of getting another similar card from a completely different manufacturer didn't work.. I was sure it would and the money it cost would easily be paid back in time saved. But the card I chose (the PHILIPS PCA750AF card) didn't work because .. it identifies in exactly the same way as 0f ff ff ff ff 00 08 a8 65. It *looks* completely different.

so that forces me to look into the murky world of running non-free msdos drivers on a linux computer, and I am struggling to know where to start with this. Perhaps I can run enough of dos to do the job off a single 1.44M floppy? I can't think of anything else right now. And I don't want to port all my other code to dos at this stage.

alternatively I have to reverse engineer the drivers you linked, and there's no guarantee they work or do the job either.

I did try dual booting the computer to linux/freedos this didn't work.. something wrong with freedos and it couldn't read my hard drive (nor my cdrom).

what I don't understand about your idea (changing the PnP identifier one card at a time) is that it requires the card to have nonvolatile memory (eeprom?) and the appropriate hw/sw to write to this. Was that common in those days? I thought writing to eeproms required special voltages, like 25V or something.

R

rwkaye wrote:

what I don't understand about your idea (changing the PnP identifier one card at a time) is that it requires the card to have nonvolatile memory (eeprom?) and the appropriate hw/sw to write to this. Was that common in those days? I thought writing to eeproms required special voltages, like 25V or something.

That 93C66 is the microwire bus eeprom, containing the PNP IDs. Depending on model it should work with 5V or 3.3V. There might even be tools to reprogram it already. I recall some AMD interwave cards (GUS PNP) came with few different configurations and tool to program them.

rwkaye wrote:

so that forces me to look into the murky world of running non-free msdos drivers on a linux computer, and I am struggling to know where to start with this. Perhaps I can run enough of dos to do the job off a single 1.44M floppy? I can't think of anything else right now. And I don't want to port all my other code to dos at this stage.

You could probably boot the necessary DOS bit entirely off a floppy. A number of PnP cards did have a built-in eeprom / flash rom that would hold both its PnP identifier as well as 'fixed' IRQ/DMA/address information set up through the configuration program (PnP ISA network cards were a good example). If the configuration program for those sound cards is similar, all you really need is bare minimum DOS bootdisk (io.sys, config.sys, command.com) along with the actual configuration program.

rwkaye wrote:

what I don't understand about your idea (changing the PnP identifier one card at a time) is that it requires the card to have nonvolatile memory (eeprom?) and the appropriate hw/sw to write to this. Was that common in those days? I thought writing to eeproms required special voltages, like 25V or something.

AFAIK most PnP cards I've worked with had at least some form of non-volatile memory in them to 'hold' a resource (irq/dma/address) configuration when unpowered; either as a separate eeprom, built-in the PnP controller or just in programming a CPLD.

With the configuration program, you don't change the PnP ID as much as tell the card to not act in PnP mode at all and just use what resources you tell it to use.

You need to do that with just one card present in the system at a time because, since they have the same IDs, the program would either detect both cards and try to program both of them with the same configuration or just crap out.