> Are there any PCI cards that live at IO adress 378 so they are > compatible with DOS ?
I'd argue that the devil's in "subtle detail", and forecast hard cheese for you :-/ In order to decode the IOport window at 0x378 by a PCI card, this has to be supported by the chipset (probably south bridge) and the BIOS of the motherboard where you are trying this. In a PC compatible motherboard that has or pretends support for legacy ISA peripherals, the ISA address space is typically catered to by so-called "subtractive decode" = any IOport or IOmem address not decoded by some other PCI device, gets funneled by default down some "sinkhole of last resort", which tends to be the "PCI-to-ISA bridge" = a particular PCI device nowadays within the south bridge. In reality, for many years this has really been an LPC master interface, leading to one or two SuperIO chips. I believe that the latest chipsets still support this, only the bus is nowadays SPI-based (rather than the LPC). Historically, after the ISA proper was gone, the "path of subtractive decode for legacy devices" led through the VESA Local Bus, and maybe also to a particular PCI device for a relatively brief period of time... I'd say that in general, a PCI board claiming to positively decode some legacy ISA IO window, would have to reside on the same segment of the PCI bus, side by side, with the PCI-to-ISA bridge performing subtractive decode. Which you probably won't achieve in any modern chipset (say Intel 810 and later). Possibly Intel 440 or thereabouts would support it. We're speaking of a boundary somewhere halfway down the Pentium III era. (Except, see my note about PICMG setups below.) Unlike VGA boards, where the chipsets readily let PCI cards decode the legacy IO address ranges, and a dedicated VGA OPROM, I'm not aware that PCI legacy IO would have a dedicated PCI device class, which would get that same sort of exclusive recognition on part of the BIOSes and PCI bridge hardware... I've seen motherboards based on the late Cyrix/NS/AMD Geode, where the BIOS would typically allow you to map a few windows by hand, to a PCI/ISA bridge (often an IT8888 if memory serves). Meaning that the PCI/ISA bridge did not enjoy subtractive decode for some reason. Possibly this got claimed by LPC or something... I'm also aware that PICMG 1.0 CPU boards still exist, some of them based on relatively modern chipsets, still having an IT8888 PCI/ISA bridge chip, running a "default decode path" for the IO base 0..0x3FF to that particular PCI device, while at the same time having a SuperIO chip or two on board... not sure which way the subtractive decode is going in that case :-) There tends to be a single segment of legacy PCI in such systems, so if you can get "side by side" with that IT8888 PCI-to-ISA bridge, you stand a chance with that LPT card of yours. Note that there are also motherboard / PICMG 1.0 CPU boards, where the ISA is extracted using an LPC-to-ISA bridge. In such systems, arguably nothing on the PCI bus would be able to decode legacy ISA addresses - because subtractive decode would flow down the LPC route. The IO windows for PCI peripherals of any sort (are LPT cards special in any way?) are assigned dynamically by the BIOS at boot time (during the POST), using a top-down tree-style divide-and-conquer allocation approach, specifically evading the legacy ISA IO space. Further reading: https://ia802204.us.archive.org/16/items/33.-oxford-legacy-address-ran ges/33.Oxford_Legacy_Address_Ranges.pdf https://www.vogons.org/viewtopic.php?t=57053&start=40 You could try reconfiguring that BAR in your PCI LPT device after post, by accessing the PCI config space, yes it should be writeable, but... if you have subtractive decode routed away from your particular branch of the PCI tree, at some upstream fork point = bypassing your device, that's bad luck. Which is generally the case in modern PC chipsets. Yes it's true that if a particular PCI BAR in a particular device asks for a specific IO window (in the ISA window or elsewhere), that should work by virtue of "positive decode", i.e. by being more specific than the "default subtractive decode route". But you'd have to sit side by side with the PCI peripheral (like an LPC bridge) that sinks the subtractive decode. If you're separated by a PCI bridge, that's bad luck. I recall that there may be additional chipset-specific =proprietary configuration bits/flags (or maybe hardwired arrangements?), which allow/prevent/clobber the decoding of the 0..0x3FF IO adddress spaces by an arbitrary PCI device, or an upstream PCI-e/PCI bridge, or some such. I recall Rayer and Ruik debating one such case, but google can't seem to find it, possibly it was in a private e-mail thread. I can think of another way, or two: A) On bare metal, you'd need some TSR driver, that would side-step into 32bit territory, trap access to that legacy LPT IO window and do a background remap = in software, within the CPU. The driver would potentially tread on the toes of any other piece of software (EMM/HIMEM/DPMI) working with memory protection in 32bit mode. B) Use virtualization. Run your DOS and DOS apps in a guest VM, and let the hypervizor (VM host) do any emulation / remapping for you. Frank _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
