How can you have PCI functionality without the bus?

Perhaps using some kind of ISA-to-PCI adapter? Although I don't know if any exist.

Edit: OK. For the moment, I've added the PIIX as the host bus on non-i430fx PCI systems in UniPCemu. So that's on PCI 00:0.0. The PCI harddisk being moved to 0:1.0 and the PIIX harddisk emulation being disabled always(Always a single function device).
That way stuff like PIRQ routing and ELCR work at least.
APM registers are still emulated, but the APIC functionality of it is disabled in the non-i430fx-compatible architectures.

Hmmm... With the PIIX for PIRQ routing on the Compaq Deskpro 386 architecture implemented, somehow during a normal Windows 95 boot (not in safe mode), it ends up with an IRQ0 in the IRR(requesting it to trigger), but the ISR is also set(blocking it from happening), while the CPU is in HLT mode, waiting for an IRQ to trigger an interrupt?

superfury wrote on 2022-02-09, 07:21:

Is it possible to provide PCI functionality on a non-PCI ISA bus (e.g. Compaq Deskpro 386), as long as it has a 386 CPU or higher using an ISA card?

I have the PCI ports implemented on those, but currently there's no way to map PCI interrupts onto the interrupt controller, since such registers don't exist on it.

The 386 DX, with its 32-bit external data bus, is theoretically capable of interfacing with PCI. Folks have already successfully used 386 DXs on certain VLB 486 motherboards along with VLB peripherals. Whether anyone has tried using a 386 DX on a 486 PCI motherboard, I have no idea.

Could someone engineer some kind of interface chip to bridge a PCI bus onto ISA? No. The 24-bit address bus of ISA is the fundamental problem; PCI expects the full 32-bit address space. Are you instead asking if someone could use the 386 DX (not SX) local bus to talk to the address and data lines of PCI while using ISA to map the numbered IRQs of ISA onto the lettered IRQs A-D of PCI? That describes part of the job of the south bridge on a PCI motherboard, without the ISA part. The issue with putting that functionality on the ISA bus is that ISA is so slow compared to PCI, and even just implementing parity and IRQs there would still not be able to keep up with the demands of PCI.

Well, as you say the PIIX(3) is the PCI to ISA adapter and also manages the PCI IRQs to PIC mapping.

I've implemented the PIIX on the Compaq Deskpro 386's PCI bus (at 00:0.0, with 00:0.1 disabled(only enabled on the i430fx/i440fx/i450gx chipsets) and 00:1.0 being a normal PCI IDE controller instead of on the PIIX, mapping INTA# to PIRQ0/PIRQA on the PIIX). The PIIX is also modified on the Compaq Deskpro 386 to force reporting as a single-function device.
On the i430fx and compatible chipsets(i440fx) said PIIX is moved to the PCI IDE slot with 2 functions and the plain PCI IDE being removed from the PCI space(it's replaced by 00:1.1 instead on the PIIX). With those, 00:0.0 is the northbridge CPU host chip, which isn't present on the Compaq Deskpro 386.
In both cases, the 00:1 is mapped to slot 1, so INTA#=PIRQ0.

The issue with Windows 95 booting and hanging on interrupts might be a different bug altogether? I see that the ISR=IRR=01h, together with the shadow registers keeping parallel IRQ line state. Although on AT and up, the only parallel lines are the legacy ones(parallel line #0-Fh, depending on emulated device, 0 for most devices, fixed) and PCI mapped lines(PIRQ0-3 which map to parallel lines 10h-40h, in 10h increments (10h,2oh,30h and 40h) to facilitate proper remapping with the 4 PIRQ registers on the PIIX/PIIX3/SIO.A southbridges).

Edit: Just was thinking. osdev.org also mentions a 16-bit PCI addressing using I/O ports CF8 and C000h+. Isn't that ISA PNP, essentially PCI on ISA buses? PCI mechaniam #2 it calls it.
https://fd.lod.bz/rbil/ports/bios_expansion/p … .html#sect-9178

Edit: Just found a bug in the interrupt controller that made it perform some APIC (both IOAPIC and Local APIC) operations when it shouldn't (just use the PIC, as there is no Local APIC before Pentium chips (80(1/2/3/4)86) and no IOAPIC on non-i430fx emulated boards in UniPCemu(Compaq Deskpro 386, AT or XT)).

Just improved the PCI IDE controller a bit, at least on the non-i430fx motherboards (which is only on the Compaq Deskpro 386 boards, due to conflicting IDE controllers already implemented on the i430fx/i440fx/i450gx).

It's a PC87415 PCI-IDE controller.
That one is the only one I found easily with not much extra functionality that's not already implemented easily, while supporting UniPCemu's PCI IDE functionalities. It even has a few (timing registers ignored) extra features I implemented quite easily (INTA# masking, per-channel interrupt masking, per-channel INTA# on legacy mode and PCI BAR 2/3 'disabling' (UniPCemu handles that as using the legacy defaults instead)).

Edit: Just added a SiS 85C497 north/southbridge chip for the Compaq Deskpro 386 instead.
Although it just has the command register/status register(RO bits only so far) and INTA#-INTD# mapping, 8259 compatible ISA and PCI modes implemented. All other registers aren't handled at all (IDE stuff, SMI stuff, INIT stuff(doesn't apply to the Compaq Deskpro 386 and 486 chips).
So that's some bare bones of what's needed to get PCI interrupts working properly on the Compaq Deskpro 386 architectures.

Edit: Eventually converted the SiS 85C497 chipset into it's own architecture and removed it from the Compaq Deskpro 386 chipset.
Although it won't boot just yet it seems, eventually corrupting SS and ES with them containing segment FFFFh, which is in the middle of the BIOS ROM, which (at least for a stack) is invalid, since it's read-only memory.

OK. Eventually moved the SiS 85C497 to it's own motherboard. Running the Tomato 4DPS 1.0 from 80486 BIOS image collection (The post starting with #81), it seems to detect memory, setup PCI IRQs (when configured through the BIOS) and try to start to boot.

Edit: There's some weird problem with the ELCR registers, though.
Even though the PCI IDE card is in legacy mode (setup in the BIOS settings for IRQA though, on slot 1) at PCI 00:1.0, the BIOS somehow sets the IRQ to 14, with the IDE in edge-triggered legacy mode. So the IRQ is malfunctioning because it's diving IRQ14/15 like a legacy device, while the BIOS sets them up as IRQ14/15 being level triggered in the ELCR?
Edit: I see it assigning the INTA# to IRQ15, then IRQ14 and back to IRQ15?
Although I've setup the settings for IRQ10 and IRQ5 instead?

LightStruk wrote on 2022-02-09, 22:03:

Could someone engineer some kind of interface chip to bridge a PCI bus onto ISA? No. The 24-bit address bus of ISA is the fundamental problem; PCI expects the full 32-bit address space. Are you instead asking if someone could use the 386 DX (not SX) local bus to talk to the address and data lines of PCI while using ISA to map the numbered IRQs of ISA onto the lettered IRQs A-D of PCI? That describes part of the job of the south bridge on a PCI motherboard, without the ISA part. The issue with putting that functionality on the ISA bus is that ISA is so slow compared to PCI, and even just implementing parity and IRQs there would still not be able to keep up with the demands of PCI.

Um, but didn't the ISA bus (or rather, AT bus) used to be merely a socket/signal wire combination based on the 80286 front side bus?
Logically, in software, it could be extended to 32-Bit no problem, I suppose?
The early local buses found on 80386 mainboards are just that - proprietary, 32-Bit wide versions of ISA.
Since they were used for memory boards, mainly, I guess they missed a few special pins and hadn't all of the further i/o ports?
But aside from that, making a 32-Bit ISA, in software, at least, shouldn't be a problem? 😀

Jo22 wrote on 2022-02-17, 10:23:

Um, but didn't the ISA bus (or rather, AT bus) used to be merely a socket/signal wire combination based on the 80286 front side […]
Show full quote

LightStruk wrote on 2022-02-09, 22:03:

Could someone engineer some kind of interface chip to bridge a PCI bus onto ISA? No. The 24-bit address bus of ISA is the fundamental problem; PCI expects the full 32-bit address space. Are you instead asking if someone could use the 386 DX (not SX) local bus to talk to the address and data lines of PCI while using ISA to map the numbered IRQs of ISA onto the lettered IRQs A-D of PCI? That describes part of the job of the south bridge on a PCI motherboard, without the ISA part. The issue with putting that functionality on the ISA bus is that ISA is so slow compared to PCI, and even just implementing parity and IRQs there would still not be able to keep up with the demands of PCI.

Um, but didn't the ISA bus (or rather, AT bus) used to be merely a socket/signal wire combination based on the 80286 front side bus?
Logically, in software, it could be extended to 32-Bit no problem, I suppose?
The early local buses found on 80386 mainboards are just that - proprietary, 32-Bit wide versions of ISA.
Since they were used for memory boards, mainly, I guess they missed a few special pins and hadn't all of the further i/o ports?
But aside from that, making a 32-Bit ISA, in software, at least, shouldn't be a problem? 😀

That's exactly what I've done right now. I've implemented the 85C496/7 north/southbridge on the Compaq Deskpro 386, although stuff like BIOS flash ROM support being unimplemented and currently disabled(always disabled on Compaq BIOS ROMs). The same for the related memory mapping, to be Compaq only(the bridges have no effect on memory or ROMs).
Of course, I've added a duplicate with more complete emulation(the same code, it just haves some if-clauses to enable some more functionality on it's full emulation when not running on a Compaq architecture), which boots now(although the ELCR registers are modified to not affect legacy IRQ lines(parallel lines 0-15) while only affecting the PCI lines(parallel lines 16+, due to the BIOS setting the IRQ14/15 to level-triggering incorrectly on the legacy device while POSTing).

Edit: Thinking about it, EISA-to-PCI adapters should be possible in actual hardware? EISA is basically a 32-bit ISA?