VOGONS


Mystery LPT card with no drivers (I just can't learn)

Topic actions

Reply 40 of 60, by jakethompson1

User metadata
Rank Oldbie
Rank
Oldbie

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...

Reply 41 of 60, by Ethaniel

User metadata
Rank Newbie
Rank
Newbie
jakethompson1 wrote on 2022-08-03, 02:18:

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.

Reply 42 of 60, by rasz_pl

User metadata
Rank l33t
Rank
l33t

https://datasheetspdf.com/pdf-file/540195/PLX … ology/PCI9050/1

why not "just" reprogram PCI9050 and remap port address?

>The 4006A says: PCI\VEN_1409&DEV_7268&SUBSYS_01011409
>My card reports: PCI\VEN_10B5&DEV_9050&SUBSYS_4006D84D

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.

https://github.com/raszpl/FIC-486-GAC-2-Cache-Module for AT&T Globalyst
https://github.com/raszpl/386RC-16 memory board
https://github.com/raszpl/440BX Reference Design adapted to Kicad
https://github.com/raszpl/Zenith_ZBIOS MFM-300 Monitor

Reply 43 of 60, by Horun

User metadata
Rank l33t++
Rank
l33t++

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

Reply 44 of 60, by underthebridge

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 45 of 60, by Ethaniel

User metadata
Rank Newbie
Rank
Newbie
rasz_pl wrote on 2022-08-03, 12:15:
https://datasheetspdf.com/pdf-file/540195/PLX … ology/PCI9050/1 […]
Show full quote

https://datasheetspdf.com/pdf-file/540195/PLX … ology/PCI9050/1

why not "just" reprogram PCI9050 and remap port address?

>The 4006A says: PCI\VEN_1409&DEV_7268&SUBSYS_01011409
>My card reports: PCI\VEN_10B5&DEV_9050&SUBSYS_4006D84D

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.

Horun wrote 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.

Reply 46 of 60, by Ethaniel

User metadata
Rank Newbie
Rank
Newbie
underthebridge wrote on 2022-08-03, 22:13:

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.

Reply 47 of 60, by jakethompson1

User metadata
Rank Oldbie
Rank
Oldbie
Ethaniel wrote on 2022-08-03, 23:38:

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?

Reply 48 of 60, by Ethaniel

User metadata
Rank Newbie
Rank
Newbie
jakethompson1 wrote on 2022-08-03, 23:49:
Ethaniel wrote on 2022-08-03, 23:38:

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?

Good question, hope this helps.

The attachment IMG_20220803_211200[1].jpg is no longer available

Reply 49 of 60, by jakethompson1

User metadata
Rank Oldbie
Rank
Oldbie
Ethaniel wrote on 2022-08-04, 00:17:

Good question, hope this helps.

IMG_20220803_211200[1].jpg

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...

Reply 50 of 60, by Ethaniel

User metadata
Rank Newbie
Rank
Newbie
jakethompson1 wrote on 2022-08-04, 00:43:
Ethaniel wrote on 2022-08-04, 00:17:

Good question, hope this helps.

IMG_20220803_211200[1].jpg

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...

The attachment lspci.jpg is no longer available

Reply 51 of 60, by Ethaniel

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 52 of 60, by digger

User metadata
Rank Oldbie
Rank
Oldbie
Ethaniel wrote on 2022-08-04, 00:49:

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.

Reply 53 of 60, by Ethaniel

User metadata
Rank Newbie
Rank
Newbie
digger wrote on 2022-08-04, 09:22:

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.

Thank you!

Reply 54 of 60, by ViTi95

User metadata
Rank Oldbie
Rank
Oldbie

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.

https://www.youtube.com/@viti95

Reply 55 of 60, by digger

User metadata
Rank Oldbie
Rank
Oldbie
ViTi95 wrote on 2022-08-05, 09:47:

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:

REM 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:
SET LPTDAC=A2EA0 T2
REM 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:
SET 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.

What are other people's thoughts on this here?

Reply 56 of 60, by Ethaniel

User metadata
Rank Newbie
Rank
Newbie
digger wrote on 2022-08-05, 11:29:

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.

Reply 57 of 60, by jakethompson1

User metadata
Rank Oldbie
Rank
Oldbie
digger wrote on 2022-08-05, 11:29:

What are other people's thoughts on this here?

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.

Ethaniel wrote on 2022-08-06, 00:07:

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...

Reply 58 of 60, by digger

User metadata
Rank Oldbie
Rank
Oldbie
jakethompson1 wrote 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.

Reply 59 of 60, by baddin

User metadata
Rank Newbie
Rank
Newbie
Ethaniel wrote on 2022-08-06, 00:07:
digger wrote on 2022-08-05, 11:29:

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.

Hi, I wrote the PrtAdd utility and found this thread a few months ago.

The EX-4006-4 card mentioned uses a PLX9050 as a PCI to ISA bridge, like many other cards of that time, and I was curious about why it required a utility to update it before it could be used. Some time later I found a listing on eBay for a EX-4006 and bought it. The EX4006 differs from the EX4006-4 in that the 4006 has a ST78C34 and the 4006-4 has a SUN1688 but they both have the same vendor/device ID 10B5:9050 and subsys vendor/device ID D84D:4006.

The following tests were carried out on a PC that could access legacy addresses on the PCI bus.

Without using the Exsys DOS driver, the card could be detected on the PCI bus by PrtAdd but the parallel port could not be accessed using the PCI assigned address of D000.
Using the Exsys DOS driver the BIOS data area for COM1 was set to 0378 but the card could not be accessed at that address.

I would need to understand the configuration of the bridge chip so code was added to PrtAdd to dump the contents of the Local Configuration Registers of the PLX9050.

Here is the configuration before any drivers are used. The card address seems to be already set to 0278 which would be LPT2

Found ExSys parallel on bus 00 dev 0C func 0
PLX9XXX Local Configuration Registers
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00 00 00 00 00 00 00 00 00 F9 FF FF 0F 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 79 02 00 00
02 00 00 00 00 00 00 00 00 20 79 32 FC 20 79 32 FC
03 20 79 32 FC 20 79 32 FC 00 00 00 00 7D 02 00 00
04 00 00 00 00 00 00 00 00 00 00 00 00 09 00 00 00
05 DA 46 00 18 00 00 00 00 00 00 00 00 00 00 00 00
06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

PLX9XXX Local Address Space Range Registers
Reg 00 Invalid
Reg 04 Invalid
Reg 08 Range 00000008 IOSpace Yes
Reg 0C Invalid

PLX9XXX Local Base Address Registers
Reg 14 Invalid
Reg 18 Invalid
Reg 1C Addr 00000278 Enabled Yes
Reg 20 Invalid

PLX9XXX Chip Select Base Address Registers
Reg 3C Addr 00000278 Size 00000008 Enabled Yes
Reg 40 Invalid
Reg 44 Invalid
Reg 48 Invalid

BAR4 D000 size 0008
00 00 00 00 00 00 00 00

PAR port 1 D000 irq 3

Here is the configuration after the Exsys driver is used. The card address is still set to 0278 and the byte at offset 4C for IRQ configuration has changed from 09 to 49

PAR port 1 0378 irq 7, as LPT1
Found ExSys parallel on bus 00 dev 0C func 0
PLX9XXX Local Configuration Registers
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00 00 00 00 00 00 00 00 00 F9 FF FF 0F 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 79 02 00 00
02 00 00 00 00 00 00 00 00 20 79 32 FC 20 79 32 FC
03 20 79 32 FC 20 79 32 FC 00 00 00 00 7D 02 00 00
04 00 00 00 00 00 00 00 00 00 00 00 00 49 00 00 00
05 DA 46 00 18 00 00 00 00 00 00 00 00 00 00 00 00
06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

PLX9XXX Local Address Space Range Registers
Reg 00 Invalid
Reg 04 Invalid
Reg 08 Range 00000008 IOSpace Yes
Reg 0C Invalid

PLX9XXX Local Base Address Registers
Reg 14 Invalid
Reg 18 Invalid
Reg 1C Addr 00000278 Enabled Yes
Reg 20 Invalid

PLX9XXX Chip Select Base Address Registers
Reg 3C Addr 00000278 Size 00000008 Enabled Yes
Reg 40 Invalid
Reg 44 Invalid
Reg 48 Invalid

BAR4 0378 size 0008
00 00 00 00 00 00 00 00

PAR port 2 0378 irq 3, as LPT1

LPT1 0378 IRQ 7 x 0778 x


This is where I discovered a stupid error in the initial configuration in the EEPROM and the Exsys driver. I traced back from the chip select pin on the ST78C34 and found that it is connected to CS2, the configuration of which is at offset 44 not 3C. After I added code to PrtAdd to correct the configuration the card could be accessed at the original address or at a legacy address.

Here is the configuration after a modified PrtAdd is used and the ST78C34 registers can now be accessed.

Found ExSys parallel on bus 00 dev 0C func 0
PLX9XXX Local Configuration Registers
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00 00 00 00 00 00 00 00 00 F9 FF FF 0F 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 79 03 00 00
02 00 00 00 00 00 00 00 00 20 79 32 FC 20 79 32 FC
03 20 79 32 FC 20 79 32 FC 00 00 00 00 00 00 00 00
04 00 00 00 00 7D 03 00 00 00 00 00 00 49 00 00 00
05 DA 46 00 18 00 00 00 00 00 00 00 00 00 00 00 00
06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

PLX9XXX Local Address Space Range Registers
Reg 00 Invalid
Reg 04 Invalid
Reg 08 Range 00000008 IOSpace Yes
Reg 0C Invalid

PLX9XXX Local Base Address Registers
Reg 14 Invalid
Reg 18 Invalid
Reg 1C Addr 00000378 Enabled Yes
Reg 20 Invalid

PLX9XXX Chip Select Base Address Registers
Reg 3C Invalid
Reg 40 Invalid
Reg 44 Addr 00000378 Size 00000008 Enabled Yes
Reg 48 Invalid

BAR4 0378 size 0008
00 7F E0 80 00 7F E0 80

PAR port 1 0378 irq 3, as LPT1

LPT1 0378 IRQ 3 D000 x x


This new version 2.3.2 is included in the BBBD iso previously mentioned. I would be interested to know if you could try it on your EX-4006-4 if booted from DOS to see if it works in the same way. Type PRTADD /B > before.txt then PRTADD /A /B > after.txt and post the results. If your PC does not allow remapping to legacy addresses it will tell you.

Note that the internal registers of the PLX9050 are changed not the EEPROM.