Not at all ISA pins, but very specfic signals not found in any other context. There's a specific protocol implemented on these pins and it works along with PCI, they are not standalone signals.

SERIRQ from SBlink / PC/PCI is the signal that persisted into LPC era, but DMA request and grant signals were lost after ICH5.

myne wrote on 2025-12-03, 02:40:

on boards as "sblink" (soundblaster)

I think that's a common misconception. It's SideBand Link, no?

Tiido wrote on 2025-12-03, 15:46:

Not at all ISA pins, but very specfic signals not found in any other context. There's a specific protocol implemented on these pins and it works along with PCI, they are not standalone signals.

SERIRQ from SBlink / PC/PCI is the signal that persisted into LPC era, but DMA request and grant signals were lost after ICH5.

Okay, so I've been having a further read of the documents on it. If I'm reading this right:

A PCI bus device can be assigned/control the "legacy" SB IO addresses, an ISA bus isn't necessary:

PCI agents on the primary PCI bus segment always get first right of refusal in claiming cycles that emerge on the PCI bus before they are bridged to the ISA bus. Therefore a PCI audio agent can easily be designed to claim the legacy Sound Blaster compatible I/O references.

So here's a thought experiment:
Given that a modern computer doesn't have a PCI bus could one be added (via a bridge from PCIE?), and then control that new PCI bus ourselves to let us add PC/PCI or DDMA?. Onto that new bus, add in something like a CS4281 that can talk PC/PCI or DDMA to whatever controller we've used. The controller then handles any i8237-style IO stuff coming in via the PC/PCI pins into bus-mastered PCI cycles, which should then just be picked up by the bridge, who hands it over to PCIE.

DJNW wrote on 2025-12-03, 23:25:

So here's a thought experiment:
Given that a modern computer doesn't have a PCI bus could one be added (via a bridge from PCIE?), and then control that new PCI bus ourselves to let us add PC/PCI or DDMA?. Onto that new bus, add in something like a CS4281 that can talk PC/PCI or DDMA to whatever controller we've used. The controller then handles any i8237-style IO stuff coming in via the PC/PCI pins into bus-mastered PCI cycles, which should then just be picked up by the bridge, who hands it over to PCIE.

The hardest part of the Soundblaster emulation is the DMA, here's the sequence of "PCM play":
1. CPU programs the DMA controller (DMAC) with the RAM address and length.
2. CPU programs the SB DSP with playback mode (rate, format) and “start DMA” command.
3. DMA controller moves the data from RAM to the SB card automatically (chunk by chunk, the card is the master of the process).
The card only receives DMA cycles (data transfers from memory to the card buffer) — it does not fetch from memory like a bus master.
You have to have DMAC address range working as a DMAC in other words. And the very last working DMAC was in the 9-series Intel PCH's via LPC bus.
The DMAC still can be programmed within AGESA or Intel's SMM/ME which is not even under NDA, but proprietary closed source.

To emulate SB-compatible DMA, you must trap following port ranges:
00–0F (8-bit DMA control)
80–83 (8-bit DMA page)
89–8F (16-bit DMA page)
C0–DF (16-bit DMA control)

And you must then simulate:
DRQ/DACK handshake
Memory-to-device cycles
Auto-init wrap
FIFO refill timing for the card

This is exactly why Intel 100-series and later chipsets cannot natively support ISA DMA: none of these ports or signals exist anymore.
And those port ranges are glued to the PCH or firmware.

Actually, to make ISA DMA work on modern systems, we must not implement all the above, because two fortunate events have happened in the past.
First, some smart people have invented DDMA. Second, IT8888 chip designers have decided to implement a part of it. The most important - the slave part.

And that's why, yes, we need to do this:

vsharun wrote on 2025-12-04, 08:32:

To emulate SB-compatible DMA, you must trap following port ranges: 00–0F (8-bit DMA control) 80–83 (8-bit DMA page) 89–8F (16-bi […]
Show full quote

To emulate SB-compatible DMA, you must trap following port ranges:
00–0F (8-bit DMA control)
80–83 (8-bit DMA page)
89–8F (16-bit DMA page)
C0–DF (16-bit DMA control)

This is DDMA master part.

But we don't need to do this:

vsharun wrote on 2025-12-04, 08:32:

And you must then simulate: DRQ/DACK handshake Memory-to-device cycles Auto-init wrap FIFO refill timing for the card […]
Show full quote

And you must then simulate:
DRQ/DACK handshake
Memory-to-device cycles
Auto-init wrap
FIFO refill timing for the card

IT8888 can do it for us. It's DDMA slave part.

Yes, modern chipsets don't support DDMA master, but all DDMA master does is just port forwarding, and it can be done in software.
All the actual work is done by the slave, and the slave is in IT8888.
I have started a thread here at VOGONS, where I share some preliminary results.
Here's the link:
AWE32 and PicoGUS on a Core2Duo industrial motherboard

KYA wrote on 2025-12-06, 13:52:

Actually, to make ISA DMA work on modern systems, we must not implement all the above, because two fortunate events have happene […]
Show full quote

Actually, to make ISA DMA work on modern systems, we must not implement all the above, because two fortunate events have happened in the past.
First, some smart people have invented DDMA. Second, IT8888 chip designers have decided to implement a part of it. The most important - the slave part.

And that's why, yes, we need to do this:

vsharun wrote on 2025-12-04, 08:32:

To emulate SB-compatible DMA, you must trap following port ranges: 00–0F (8-bit DMA control) 80–83 (8-bit DMA page) 89–8F (16-bi […]
Show full quote

To emulate SB-compatible DMA, you must trap following port ranges:
00–0F (8-bit DMA control)
80–83 (8-bit DMA page)
89–8F (16-bit DMA page)
C0–DF (16-bit DMA control)

This is DDMA master part.

But we don't need to do this:

vsharun wrote on 2025-12-04, 08:32:

And you must then simulate: DRQ/DACK handshake Memory-to-device cycles Auto-init wrap FIFO refill timing for the card […]
Show full quote

And you must then simulate:
DRQ/DACK handshake
Memory-to-device cycles
Auto-init wrap
FIFO refill timing for the card

IT8888 can do it for us. It's DDMA slave part.

Yes, modern chipsets don't support DDMA master, but all DDMA master does is just port forwarding, and it can be done in software.
All the actual work is done by the slave, and the slave is in IT8888.
I have started a thread here at VOGONS, where I share some preliminary results.
Here's the link:
AWE32 and PicoGUS on a Core2Duo industrial motherboard

The whole Idea of the disAppointment project - run ISA Sound Blaster - compatibles in real mode. No virtualization.
BTW trapping ports may incur latency jitter which is quite well controlled with LPC/ISA bridge.
Gde to tak, tovarisch.

vsharun wrote on 2025-12-08, 10:27:

The whole Idea of the disAppointment project - run ISA Sound Blaster - compatibles in real mode. No virtualization.
BTW trapping ports may incur latency jitter which is quite well controlled with LPC/ISA bridge.
Gde to tak, tovarisch.

I agree.

Looked at a few more.

One thing that's not entirely relevant here, but I *think* the Realtek 8112 is just an Asus variant of the 8111.
The DeviceID is 8168 which is the same.
If anyone has an asus with 9x on it, I'd be curious whether it passes packets and remains stable with the standard 8111/8168 driver - possibly with some reg/inf tweaks.

Should probably note, the gigabyte G41 boards I kinda looked at but I didn't see a TPM header on any of them.
I didn't write down which, but don't be surprised if you're constantly disappointed.

The generally best brand for TPM header and accessible LDRQs to a resistor seems to be MSI.

myne wrote on Today, 06:04:

Should probably note, the gigabyte G41 boards I kinda looked at but I didn't see a TPM header on any of them.
I didn't write down which, but don't be surprised if you're constantly disappointed.

The generally best brand for TPM header and accessible LDRQs to a resistor seems to be MSI.

Well, I have two MSI's H61's and both has no LDRQ1 exposed.
I may say the best motherboards I have "converted" is:
1. Asrock's Z87M Pro4 (and close sibling, almost identical - B85M Pro4). Issues with W98 however (not important for me though)
2. Even better - Gigabyte's Z87M D3H (and sibling B85m D3H)
Both (four actually) has LDRQ1 exposed to a resistor.

But most love comes to Asus's Gryphon Z87 - despite lack of PCI support, only PCIe, no PS/2 ports, LMB misfiring with modern mices/keyboards, blocked upper port ranges for LPC (only non PnP cards working or the ones which may be initialized ini non-PnP way). Still love it, bough two with metal supporting frame. Maybe because at times Sabertoothes (Z77/Z170) was my main platforms at SandyBridge-Skylake era.

I wonder if the lack of pci is why the isa range is blocked?
BTW, in the lpc datasheet standard it does state that pnp isn't intended to work.

myne wrote on Today, 12:44:

I wonder if the lack of pci is why the isa range is blocked?
BTW, in the lpc datasheet standard it does state that pnp isn't intended to work.

Seems Asus trap those ports before LPC. The same behaviour I have with Z97M-Plus and Z87-C of Asus. But not for P5Q which I love also.
All of those Asuses has GPIO23 configured on pin, not LDRQ1 BTW. So you need lpcext utils to switch the mode (and loose some RAID functionality on P5Q, because this pin is landed here).