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