superfury wrote on 2022-02-15, 21:16:

Is there a way to force Windows 95 to put the PCI controller into native PCI mode? […]
Show full quote

Is there a way to force Windows 95 to put the PCI controller into native PCI mode?

I want to use it to check if my PCI emulation with it's IRQ mapping and I/O port mapping is working correctly.
Afaik, the BIOS configuration is correctly setup for it (IRQ mapping for lane A to IRQs 10 and 5, which are the only ones available).
The ELCR is only affecting the PCI lines though (it's ignored for legacy IRQs, otherwise it will make the IDE controller that's in compatibility mode unable to boot because it's IRQs(14 and 15) are somehow incorrectly mapped to level-sensitive by the BIOS, causing an interrupt storm hanging the very same BIOS). So the BIOS seems to be fully ignoring said settings itself(using IRQs 14&15 instead of 10&5 when POSTing).

edit: I think I'm out of my depth here.

Have you checked if toggling the setting 'Plug and Play compatible OS' or 'PNP OS Installed' in the BIOS makes a difference?
On some computers I've used, it seems to determine whether IRQs etc. etc. are set by BIOS or if Windows is allowed to do it.

leonardo wrote on 2022-02-15, 22:22:

edit: I think I'm out of my depth here. […]
Show full quote

superfury wrote on 2022-02-15, 21:16:

Is there a way to force Windows 95 to put the PCI controller into native PCI mode? […]
Show full quote

Is there a way to force Windows 95 to put the PCI controller into native PCI mode?

I want to use it to check if my PCI emulation with it's IRQ mapping and I/O port mapping is working correctly.
Afaik, the BIOS configuration is correctly setup for it (IRQ mapping for lane A to IRQs 10 and 5, which are the only ones available).
The ELCR is only affecting the PCI lines though (it's ignored for legacy IRQs, otherwise it will make the IDE controller that's in compatibility mode unable to boot because it's IRQs(14 and 15) are somehow incorrectly mapped to level-sensitive by the BIOS, causing an interrupt storm hanging the very same BIOS). So the BIOS seems to be fully ignoring said settings itself(using IRQs 14&15 instead of 10&5 when POSTing).

edit: I think I'm out of my depth here.

Have you checked if toggling the setting 'Plug and Play compatible OS' or 'PNP OS Installed' in the BIOS makes a difference?
On some computers I've used, it seems to determine whether IRQs etc. etc. are set by BIOS or if Windows is allowed to do it.

Nope. All there is is the following:

During POST, I see it first setting the PIRQs to disabled, then register C6 to 02h(normal behaviour, PCI compatible, so using the ELCR inputs), ELCR 4D1 to 40h(IRQ 14), PIRQ0 to interrupt 14, ELCR 4D1 to IRQ14&15, PIRQ0 to interrupt 15, then continues to POST normally.

The machine I'm trying to emulate in this case is this machine: 80486 BIOS image collection .
Edit: Found a manual here: https://www.zida-bios.com/download-datasheets … -with-id-3.html
Page 23 mentions those "1st-3rd Available IRQ". I have them set to 10(1st), 5(2nd) and NA(3rd).
The BIOS seems to still ignore those settings completely and just use IRQ14, then IRQ14&15?
Edit: Hmmmm.... Could this be a CPU emulation bug at work here?

Just found a bug in the PCI IDE controller: the device and vendor IDs were swapped (found out by running hwdiag from the CD-ROM)... Whoops 😖

Anyone knows what can cause Windows to disable a PCI IDE device's primary&secondary channel with error 10?

Hmmmm.... What happens with the (alternative) status ports of an IDE drive when the CPU tries to read it while the PCI and motherboard have said controller disabled? Will it read 0xFF from the status register or 0x7F in that case(both PCI command register being cleared to remove it from I/O space and the motherboard having it removed from it's onboard devices)? Will the bus be floated entirely? Or will bit 7 still be kept at a low voltage(reading 0)?

OK, some progress!

After having redetected the i440fx hardware, an Execute Device/Drive diagnostic command bugfix and the NOIDE registry entry removed, the hard drive gets properly loaded with it's drivers 😁 No more error 10!

I also notice that on the i440fx, a "IRQ Holder for PCI Steering" is added, with the IRQ that's assigned in the BIOS in it 😁 Some surprise progress!
Don't know what happens when I add the primary slave back (it was temporarily removed from the system to simplify testing the new execute device diagnostic command).

Edit: OK. Now the DMA option is present on the hard disk at least, on to testing (I'll check and test the CD-ROM drives later)...
So far it looks fine. I'll see what a boot with DMA (which should be the PCI IDE busmastering that's now actually emulated) enabled does... Fingers crossed...
Edit: The issue of rebooting having the CD-ROM drives disappear for some reason remains...
Edit: I see a Read DMA command after proper documented initialization of the DMA controller...
Then the initial timeout for the read to take place from the drive...
DMA command bit 0 set...
PRDT loaded correctly...
Written to RAM...
Finishing the PRDT entry eventually, clearing status bit 0...
Hmmm... No more DMA after the first sector has been transferred using DMA... Perhaps na IRQ issue...
Edit: Indeed, the final interrupt after the sector(s) were read was missing for DMA(they weren't there for non-DMA transfers, which was still unadjusted).
Edit: The same for interrupts needing to be surpressed for reads from ATAPI device sectors, which were missing as well (they were issuing IRQs for each transferred sector).
Edit: The Read DMA and Write DMA seems to work from what I can see (didn't check with the Windows driver status yet). I see it transferring reads and writes using DMA now 😁
Edit: Just found some more bugs in DMA handling with the ATAPI drives (the error conditions not stopping DMA transfers, unused ATAPI read sector results, spin response pausing DMA transfers until ready, mode sense raising IRQs in DMA mode, various other ATAPI functions raising IRQs in DMA modes).

OK. Both hard disk and CD-ROM DMA seems to work now.
Although instead of on a 33MHz+ bus speed, it's running in a 1-byte-per-transfer(not block transfer) DMA controller timings atm(so 1/3 of 14.31818MHz(XT, which doesn't have PCI or it's DMA) or 1/2 of the CPU clock rate(on AT and up).

OK. Just seperated the PCI IDE DMA timing. It gets lower priority than the 8237A and the CPU.
It still runs like the DMA controller wrt the bus taking.
One difference is that it keeps primary/secondary priorities, giving control to the other controller as higher priority if both are requesting DMA. Sort of an adjusted flip-flop.
The flipflop will get stuck if it's running or pending to take the bus. It toggles if a transfer releases the bus. Getting a pending bus (DMA/CPU taken) makes it only time 1 of the cycles, since remaining cycles will be the same(no control). The 1 cycle delay for DMA is applied as well.
It still runs at 4.77MHz at a rate of 1 byte for each clock cycle(so up to ~4.77MB/s in single-channel mode). Although I can optionally increase that to 33MHz or 66MHz or the current bus clock depending on the architecture.

Just improved the PCI IDE DMA a bit. It will now emulate the cycle time and perform 16-bit transfers to/from memory during each cycle. The cycle time will be 4.77MHz for scanning cycles (no DMA running or a request has been made) and when it detects a request and handles it, the 16-bit transfer will tick in units of the specified memory timing (in nanoseconds). Block transfers are also supported now, although it will release the bus once the device lowers it's DMA request(this happens during DMA transfers because either the command is finished, new data is being read(in between sectors) or a command is aborted). Single word mode(HDDs only) will cause it to release the bus after each word transferred.

It's also compatible with the IPS clocking modes. The cycle-accurate modes are handled much like DMA(including the starting HLDA cycle), but after that happens and it gets a grant from the CPU it will start transferring one or more(in multiword mode) 16-bit data to/from memory with timing specified in ATA-1 and ATA/ATAPI-4 (the longest timing of those, which is the cycle timing).

Hmmm... Do all ATAPI commands support DMA transfers for their data port usage? From what I can find they do, as long as they use a data IN/OUT phase?

Edit: I've also fixed the DMA priority scheme a bit. There was a slight issue with missing parentheses when determining if it should check a DMA channel for the current cycle in the priority-based scheme. In this case, it would fire invalid DMA transfers when the other channel than the one being checked to tick is the one it's supposed to check. So if the primary DMA should be checked and the primary should be checked(and the channel was the last one active, which is during block transfer modes), it would fire the primary channel's transfer, ignoring the command register. The same would happen for the second DMA channel, where it would fire if the first channel wasn't responding and the command register bit was cleared.
Of course, it now properly only fires the DMA transfer if the channel's command register bit 0 is set.

The flipflop for priority changing was used properly, but it also wouldn't check the other channel that should fire during the same cycle if the priority was changed to the other channel.