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 2025-12-16, 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 2025-12-16, 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).

You looked at this?

myne wrote on 2025-12-17, 05:43:

You looked at this?

Nope, have no experience with (modern) BIOS editing.
I'm completely okay with Asus behavior, coz I have working vibecoded bypass key - based ESS configuration utility, setting most of ESS1868/1869/1898 of mine to A220/I7/D1/M330.
Ultimately I have some ESS1688/688 cards which has SB Pro A220 I7 D1 mode by default.
PicoGUS has no issues also, having config port in 1Dx range.
Yamaha's YMF 719 has issues with FM in some titles (Wolf3D for example) and overall their sound quality worse than of ESS, I has two of them modded with proper low pass filters: ESS sounds better and has fantastic mixer utility, working with mixer at 220h - base.
Then most of SB16 (and all of mine) has hanging note issue, the only Creative's I have without this issue - AWE64 and AWE32 CT3900, but five decode ranges required for them: 2xx 3xx 6xx Axx and Exx (we have four available though).
This is why I ended up with ESS - best tolerance to 3.3V ISA of Fintek bridge, zero compatibility issues. Not the best sounding (PicoGUS has much better stage), bot okayish.

myne wrote on 2025-12-17, 05:43:

You looked at this?

AFAICT modern AMI UEFI BIOSes are too delicate to be modded, compared to older ones. In my X99M Killer/3.1's case, the only thing I succeeded was enabling a hidden Advanced menu. Modding other stuffs like updating microcode or option ROMs all resulted in being unable to POST (stuck at certain codes).

I did find the PIRQ table of the BIOS with AMIBCP but considering the past failures I did not dare touch. I wonder if it's somehow possible to route the PIRQ line that preferred IRQ5 to IRQ6, which should be available since the board doesn't have support for floppy drives.

Would an ISA bridge device indicate anything on modern X570 boards? I used "lspci" on Linux and ISA Bridge was among the listed devices.

RetroLizard wrote on 2025-12-27, 21:58:

Would an ISA bridge device indicate anything on modern X570 boards? I used "lspci" on Linux and ISA Bridge was among the listed devices.

AFAIK that ISA bridge (00:14.3) device existed since ATI 600-series (later became AMD since 700-series). Bolton FCH is the last to be independent (on the chipset) and with 2 LDRQ# signals.

Since Ryzen, that part is now integrated into CPU, but only 1 LDRQ# is exposed. Some ASUS boards seem to use a stripped-down SuperIO that doesn't use the LDRQ# so that signal can be used. For other boards, one would have to look for means to somehow isolate that signal from SuperIO, which can be very tricky.

The core issue, however, is that the CPU/chipset seems to claim most of the I/O ranges including 4E/4F so changes to registers according to the RPR/PPR of the chipset/CPU have very little effect and not too useful for sound cards. AMD 700 series southbridge's Register Reference document once had some mentions about how to make certain I/O ranges (including those from sound cards) to trigger SMI, but that particular document has since been pulled from the AMD website for some reasons. I do have a copy of it, however.

On the other hand, I did think about the possibility to leverage SinkClose vulnerability to install SBEMU/VSBHDA into Ring -2 (in which the functionality might be less restricted), but sadly I've since patched the BIOS of my X570 board past that point so that's not going to be too helpful for me for now... Don't know if that vulnerability can be utilized purely from FreeDOS, though.

Ah well. I still have older boards around for ISA cards, so it's not a big problem. Just curious.