I wonder whether it would work to just write a program to overwrite that second i/o region in PCI configuration space with 0x378. In fact, perhaps that's what the driver does.
Your motherboard presumably doesn't have a parallel port or you wouldn't go through all this? Perhaps even if it doesn't, it has a Super IO chip that does and that causes a problem. Actually, I've never looked into this issue of an ISA and PCI device both wanting to use the same I/O addr...
I wonder whether it would work to just write a program to overwrite that second i/o region in PCI configuration space with 0x378. In fact, perhaps that's what the driver does.
Your motherboard presumably doesn't have a parallel port or you wouldn't go through all this? Perhaps even if it doesn't, it has a Super IO chip that does and that causes a problem. Actually, I've never looked into this issue of an ISA and PCI device both wanting to use the same I/O addr...
My assembly language skill is zero, so I ended up using the scripting capabilities of DEBUG. I created a «debug.txt» file with your hack, and then added «debug < debug.txt» to autoexec.bat right after PATH. Far from elegant, but it works, and it's easy to edit.
Just by curiosity, I checked 40:08 with «d 40:08» «before» applying the hack «and» with no drivers and... there's nothing. 00 00, that's it. So, that got me thinking (and this is probably my two hours of sleep talking): Maybe I could use «e 40:0a 80 c0» to set LPT2 to c080, then use «e 40:08 78 03» to set LPT1 as 0378, and finally «mode lpt2=lpt1» to send everything from LPT2 to LPT1. So, if there's something hardcoded to 0378 like FastDoom, it could receiv... no, that won't work. Mode only supports redirection from LPT to COM. I need to go to bed.
wait a minute, VEN_10B5 is generic PLX Technology, and DEV_9050 is generic PCI9050. Something tells me your eeprom is bad/erased and card comes up as generic uninitialized PCI9050.
I think it needs the eeprom re-flashed too. In their archives it says the eeprom must be flashed if using driver v2 or newer.
Found these at various archives: http://web.archive.org/web/20000303181304/htt … 0/download.html
where it states the eeprom needs flashing. you can DL the eeprom.zip, make sure you read the readme.txt just below it.
and here is an original link to the card: http://web.archive.org/web/19980216045744/htt … /html/4006.html
Noted Inside the new driver PCMIO.inf it has these lines refering to :
"Enum\PCI\VEN_10B5&DEV_9050", in a few sections, then in the PCIPOT.inf it lists as
PCI4006LPTName="EXSYS PCI 4006 LPT Port"
PCI4006DeviceDesc="EXSYS PCI 4006"
Hate posting a reply and then have to edit it because it made no sense 😁 First computer was an IBM 3270 workstation with CGA monitor. Stuff: https://archive.org/details/@horun
Glad to see you managed to get the driver file which was PLX-Version_2.3.zip.
Just as FYI - PLX-Version_2.3.zip is totally the right driver even though exsys Italy mentions it's for EX-40032 card.
You could see here that PLX-Version_2.3.zip file is listed for EX-4006.
wait a minute, VEN_10B5 is generic PLX Technology, and DEV_9050 is generic PCI9050. Something tells me your eeprom is bad/erased and card comes up as generic uninitialized PCI9050.
Horunwrote on 2022-08-03, 22:13:I think it needs the eeprom re-flashed too. In their archives it says the eeprom must be flashed if using driver v2 or newer.
Fo […] Show full quote
I think it needs the eeprom re-flashed too. In their archives it says the eeprom must be flashed if using driver v2 or newer.
Found these at various archives: http://web.archive.org/web/20000303181304/htt … 0/download.html
where it states the eeprom needs flashing. you can DL the eeprom.zip, make sure you read the readme.txt just below it.
and here is an original link to the card: http://web.archive.org/web/19980216045744/htt … /html/4006.html
Noted Inside the new driver PCMIO.inf it has these lines refering to :
"Enum\PCI\VEN_10B5&DEV_9050", in a few sections, then in the PCIPOT.inf it lists as
PCI4006LPTName="EXSYS PCI 4006 LPT Port"
PCI4006DeviceDesc="EXSYS PCI 4006"
Per your recommendations, I explored the contents of eeprom.zip one more time. The readme file says it should be used with cards that have «only» the «4006» legend on the PCB, not the «4006-4» (the second picture on my first post shows it's 4006-4)... but I tried anyway, ran 4006.com, the update is successful... and the card keeps behaving the same way. The driver says that the port is 0378, but when you send something to that address, nothing happens. The port address remains somewhere else, the only thing that works is injecting that real address to 40:08 with the DEBUG hack. I'm convinced it's something with my motherboard and the typical «UEFI-not-legacy-but-emulated-kinda-sorta» stuff. My other motherboard is dead, so, this will have to do.
The most interesting part is... that one of the DOS drivers was inside the eeprom.zip file all this time. It's a variant of the 2.0 version labeled «Dolphin Peripherals». Makes sense, Sunix was a provider for both Exsys and Dolphin 25 +/- years ago. Sadly, using that driver changes nothing: The card is detected and the ports shows as 0378, but the DOS apps can't see it.
Glad to see you managed to get the driver file which was PLX-Version_2.3.zip.
Just as FYI - PLX-Version_2.3.zip is totally the right driver even though exsys Italy mentions it's for EX-40032 card.
You could see here that PLX-Version_2.3.zip file is listed for EX-4006.
Thanks! By far, it was the most complicated driver. In general, I have no issues locating them, but... this was something else.
Per your recommendations, I explored the contents of eeprom.zip one more time. The readme file says it should be used with cards that have «only» the «4006» legend on the PCB, not the «4006-4» (the second picture on my first post shows it's 4006-4)... but I tried anyway, ran 4006.com, the update is successful... and the card keeps behaving the same way. The driver says that the port is 0378, but when you send something to that address, nothing happens. The port address remains somewhere else, the only thing that works is injecting that real address to 40:08 with the DEBUG hack. I'm convinced it's something with my motherboard and the typical «UEFI-not-legacy-but-emulated-kinda-sorta» stuff. My other motherboard is dead, so, this will have to do.
The most interesting part is... that one of the DOS drivers was inside the eeprom.zip file all this time. It's a variant of the 2.0 version labeled «Dolphin Peripherals». Makes sense, Sunix was a provider for both Exsys and Dolphin 25 +/- years ago. Sadly, using that driver changes nothing: The card is detected and the ports shows as 0378, but the DOS apps can't see it.
What outputs for this card if you run lspci -vv after loading the driver instead of before?
Per your recommendations, I explored the contents of eeprom.zip one more time. The readme file says it should be used with cards that have «only» the «4006» legend on the PCB, not the «4006-4» (the second picture on my first post shows it's 4006-4)... but I tried anyway, ran 4006.com, the update is successful... and the card keeps behaving the same way. The driver says that the port is 0378, but when you send something to that address, nothing happens. The port address remains somewhere else, the only thing that works is injecting that real address to 40:08 with the DEBUG hack. I'm convinced it's something with my motherboard and the typical «UEFI-not-legacy-but-emulated-kinda-sorta» stuff. My other motherboard is dead, so, this will have to do.
The most interesting part is... that one of the DOS drivers was inside the eeprom.zip file all this time. It's a variant of the 2.0 version labeled «Dolphin Peripherals». Makes sense, Sunix was a provider for both Exsys and Dolphin 25 +/- years ago. Sadly, using that driver changes nothing: The card is detected and the ports shows as 0378, but the DOS apps can't see it.
What outputs for this card if you run lspci -vv after loading the driver instead of before?
Interesting, I guess we understand the IRQ b thing now. I guess indeed all the "driver" does is change things around in PCI configuration space to point it at 378h.
Perhaps your chipset just doesn't want to send i/o address 378h to the PCIe bus? Don't know. I think you'd have better luck patching things that are hardcoded to 378h...
Interesting, I guess we understand the IRQ b thing now. I guess indeed all the "driver" does is change things around in PCI configuration space to point it at 378h.
Perhaps your chipset just doesn't want to send i/o address 378h to the PCIe bus? Don't know. I think you'd have better luck patching things that are hardcoded to 378h...
I agree. This next image is lspci without drivers nor hacks. It really makes no sense: The only action of the driver is to change Region 4 from c080 to 0378. That should work... but it's not enough. It's my motherboard and that UEFI crap, I can feel it...
One more thing: If anyone wants to try lspci for MS-DOS, I downloaded it from here. I don't even know what Flashrom is, but the lspci build in the zip seems to work fine.
It really makes no sense: The only action of the driver is to change Region 4 from c080 to 0378. That should work... but it's not enough. It's my motherboard and that UEFI crap, I can feel it...
Modern PCIe motherboards with legacy PCI slots don't allow PCI cards to claim legacy I/O addresses, such as 378h. See this informative post by Kamerat for more details.
His link to the PDF document about the required "subtractive decode" feature is now dead, but you can still find the document here at the Internet Archive.
Last edited by digger on 2022-08-08, 21:41. Edited 1 time in total.
Modern PCIe motherboards with legacy PCI slots don't allow PCI cards to claim legacy I/O addresses, such as 378h. See this informative post by Kamerat for more details.
His link to the PDF document about the required "substractive decode" feature is now dead, but you can still find the document here at the Internet Archive.
Oooh, that's a big piece of the puzzle right there. The PDF also says the issue is inherent to PCI Express, so it will affect PCI Express-based LPT and COM cards as well. My strategy is clear then: I'll keep patching or applying the mod with DEBUG to access the port's real address. I also asked the FastDoom developer for a customizable address option on Covox selection, and he said yes.
Yeah I'll add fully customizable ports for the Disney Sound Source and the COVOX, didn't know that newer PCI Express based machines cannot use legacy I/O addresses. Maybe interesting to someone create a TSR to remap ports for those kind of systems.
Yeah I'll add fully customizable ports for the Disney Sound Source and the COVOX, didn't know that newer PCI Express based machines cannot use legacy I/O addresses. Maybe interesting to someone create a TSR to remap ports for those kind of systems.
Problem is that such a TSR still wouldn't work with protected mode games. (Something like that could maybe work if you were to implement such remapping in the DOS extender.)
Unlike the Covox Speech Thing and the OPL2LPT and OPL3LPT devics, the Disney Sound Source can be autodetected. For the DSS, ideally it would be best to look up the base I/O ports of any parallel port devices registered in the BIOS data area, and then iterate through those base I/O ports to try detect the DSS, and then pick the first port on which a DSS is detected. That way, all that people would have to do (at most) is load a tool like the aforementioned `prtadd /A`, and the rest would happen automatically and dynamically.
In the case of parallel port sound devices that cannot be autodetected, such as Covox and OPLxLPT, perhaps the retro DOS hobby/tinkering community could agree on some kind of standard DOS environment variable, in the same vein as the well-known `BLASTER` variable for Sound Blaster and compatible sound cards?
We could ask Peter De Wachter to add support for such environment variables to his OPL2LPT utilities.
So for instance something like these:
1REM Example for a parallel port LPT DAC at base I/O address 2EA0h, with type 1 being a Covox Speech Thing, type 2 meaning a Stereo-on-one variant, type 3 being a SiliconSoft SoundJR, etc: 2SET LPTDAC=A2EA0 T2
1REM Example for a parallel port FM synth at base I/O address 3EA0, with type 2 being an OPL2LPT and type 3 being an OPL3LPT: 2SET OPLXLPT=A3EA0 T3
The reason I'm proposing this is because recently I managed to successfully patch Duke Nukem 3D to output FM music on an OPL3LPT on a parallel port on a PCIe card on a non-standard port, but I had to look up the I/O address that was dynamically allocated to that parallel port, and then I had to patch the game with that custom I/O port hard-coded into the game. And since the custom I/O port could be different on each system, or even after a reconfiguration, that means that the game would stop working whenever that I/O port would change. Having the patch work with a customizable environment variable like this after a one-time patch would be more user-friendly.
The reason I'm proposing this is because recently I managed to successfully patch Duke Nukem 3D to output FM music on an OPL3LPT on a parallel port on a PCIe card on a non-standard port, but I had to look up the I/O address that was dynamically allocated to that parallel port, and then I had to patch the game with that custom I/O port hard-coded into the game. And since the custom I/O port could be different on each system, or even after a reconfiguration, that means that the game would stop working whenever that I/O port would change. Having the patch work with a customizable environment variable like this after a one-time patch would be more user-friendly.
What are other people's thoughts on this here?
Very similar to what I ended up doing, only the other way around. With jakethompson1's DEBUG hack, instead of patching one game and program at a time, i Just force the alternative address into to the LPT1 region to make my Covox work. And the addresses indeed change: On my previous motherboard it was a800, now it's c080. I don't have an OPL3LPT solution, but what you say sounds good.
No skin in the game as I don't have one of these sound devices and don't feel super strongly about it, but for consistency I'd make the env var or configuration menu or whatever speak in LPT1/LPT2/LPT3 language, and it's up to the user to get their BIOS data area set up correctly if it wasn't filled in by the BIOS due to the parallel port being PCI.
Very similar to what I ended up doing, only the other way around. With jakethompson1's DEBUG hack, instead of patching one game and program at a time, i Just force the alternative address into to the LPT1 region to make my Covox work. And the addresses indeed change: On my previous motherboard it was a800, now it's c080. I don't have an OPL3LPT solution, but what you say sounds good.
Ideally you'd have a utility that pulls the secondary IO range from the card and fills it in the BIOS data area without further user intervention. e.g. you'd use
(http://www.ctyme.com/intr/rb-2372.htm) to look up the card by vendor/device ID and
(http://www.ctyme.com/intr/rb-2376.htm) to read the address register to get the IO address range to fill into the BIOS data area.
If you're up for some assembly programming...
jakethompson1wrote on 2022-08-06, 06:45:Ideally you'd have a utility that pulls the secondary IO range from the card and fills it in the BIOS data area without further […] Show full quote
Ideally you'd have a utility that pulls the secondary IO range from the card and fills it in the BIOS data area without further user intervention. e.g. you'd use
(http://www.ctyme.com/intr/rb-2372.htm) to look up the card by vendor/device ID and
(http://www.ctyme.com/intr/rb-2376.htm) to read the address register to get the IO address range to fill into the BIOS data area.
If you're up for some assembly programming...
That's exactly what the aforementioned `prtadd` utility does, when you run it with the `/A` option. It just doesn't support the chipset on this particular card yet, apparently.
Thanks for sharing these links, though. That site is indeed a useful resource, and having an open source alternative for `prtadd` would be nice.
Ever more ideally, FreeDOS could be improved to have this functionality out-of-the-box. Perhaps we could submit a feature request for this.
![IMG_20220803_211200[1].jpg](./thumbs/49056_5ce7476942af73cbffaff733694112a4/IMG_20220803_211200%5B1%5D.jpg)
