rasteri wrote on 2024-04-28, 00:00:

So I'm having the same problem as you (interrupts not firing), except using your latest code that doesn't touch 21h doesn't seem […]
Show full quote

LSS10999 wrote on 2024-04-14, 16:04:

I've found the answer. Actually port 21h is being used for IRQ stuffs and should not be touched.

So I'm having the same problem as you (interrupts not firing), except using your latest code that doesn't touch 21h doesn't seem to help.

DMA is working great though.

Any ideas? Maybe I can set 21h to the same value as one of my other boards...

Which IRQ did you use for the sound card? If the IRQ in question is taken by at least one PCI IRQ line then the sound card cannot use it. No interrupt will be fired.

Also, did you check registers 60h and 68h on the LPC controller? You can use my PCICMD tool (part of LPCEXP).

1pcicmd 0 1f 0 60
2pcicmd 0 1f 0 68

Check if any of the bytes in the registers is 05h or 07h. 80h means unused and can be disregarded.

If you see both 05h and 07h you need to check which PCI device(s) are taking the IRQs in question.

I used RBPCI (PCICFG), though HWINFO can also be used. Run HWINFO before configuring the LPC controller and check IRQ assignments. If the IRQs in question are USED you need to look up the PCI device ID online for details, as HWINFO likely won't be able to outright tell you what it is, if it's too modern.

Whether or not you can work around this depends solely on the board's design. In my board's case IRQ7 is being used exclusively by the PIRQ line on which onboard audio is, so by disabling onboard I could free it without any side effect. IRQ5, on the other hand, is being used by the chipset USB3 controller (not the Asmedia one) and I don't want to disable it at the moment...

And another question... did those Chinese brand motherboards have BIOS options for managing IRQ/DMA assignments like old ones? If so, I wonder how such features are implemented and whether or not they are generally portable. Modern UEFI BIOSes don't offer such functions anymore so one can only use workarounds like disabling devices or letting the LPT port reserve it (if present).

LSS10999 wrote on 2024-04-28, 00:46:

And another question... did those Chinese brand motherboards have BIOS options for managing IRQ/DMA assignments like old ones?

I don't remember seeing anything like that. Can't really check now I've torn the PCH off 😁

Rasteri, congrat to finding LDRQ via GPIO toggling 😀
BTW delay function on dos platform may have defferent granularity, sometime it is 1ms sometimes 18.2ms, I don't know watcom implementation. BTW DJGPP uclock() that allows you make ~1us delay
https://www.delorie.com/djgpp/doc/libc/

LSS10999 wrote on 2024-04-28, 00:46:

did those Chinese brand motherboards have BIOS options for managing IRQ/DMA assignments like old ones? If so, I wonder how such features are implemented and whether or not they are generally portable. Modern UEFI BIOSes don't offer such functions anymore

I'm also curious how this is done. Very generally I think the magic is done by PnP enumarator code during POST. Every device should report a list of resources it can assign and what values are prefered and if it can be shared. Eg. device A says I can do IRQ 5, 6, 7, 8, 9 and 5 is prefered, device B says I can do IRQ 7, 9 and is 7 prefered. Enumerator then assigns non-conflicting IRQ 5 for device A and 7 for B. As more devices come it allocate all free IRQs and then would need to set IRQ sharing for devices that supports it to satisfy the requirement. If there is some legacy device that cannot change IRQ as needed or at least the IRQ reserve option it tells the enumerator to exclude specific IRQ. I don't know if this enumeration algo exists in 2 forms, one that can exlude legaxy IRQ and second that has this code removed. It may differ with SETUP user interface, even if the option is missing the code still may be there to allow exclude. If we have source code of BIOS it would be easier to inspect this.
Also I'm curious if this PnP enumeration routine can be run only once at POST or executed later. BIOS has a lot of code in modules that are temporarly unpacked to RAM and discarded after boot so no longer executable. But it seems that Win9x and Win2K/XP can do their own enumaration and they can assign the resources differently than BIOS did. As I have installed multiple OS on my system I observed that Win9x sometimes allocates some resources differently than WinXP and tdifferently than BIOS. So it gives me impression that it can be changed after boot but sorry I don't know any details how it's done.

RayeR wrote on 2024-04-28, 01:28:

I'm also curious how this is done. Very generally I think the magic is done by PnP enumarator code during POST. Every device should report a list of resources it can assign and what values are prefered and if it can be shared. Eg. device A says I can do IRQ 5, 6, 7, 8, 9 and 5 is prefered, device B says I can do IRQ 7, 9 and is 7 prefered. Enumerator then assigns non-conflicting IRQ 5 for device A and 7 for B. As more devices come it allocate all free IRQs and then would need to set IRQ sharing for devices that supports it to satisfy the requirement. If there is some legacy device that cannot change IRQ as needed or at least the IRQ reserve option it tells the enumerator to exclude specific IRQ. I don't know if this enumeration algo exists in 2 forms, one that can exlude legaxy IRQ and second that has this code removed. It may differ with SETUP user interface, even if the option is missing the code still may be there to allow exclude. If we have source code of BIOS it would be easier to inspect this.
Also I'm curious if this PnP enumeration routine can be run only once at POST or executed later. BIOS has a lot of code in modules that are temporarly unpacked to RAM and discarded after boot so no longer executable. But it seems that Win9x and Win2K/XP can do their own enumaration and they can assign the resources differently than BIOS did. As I have installed multiple OS on my system I observed that Win9x sometimes allocates some resources differently than WinXP and tdifferently than BIOS. So it gives me impression that it can be changed after boot but sorry I don't know any details how it's done.

The PIRQ routing registers I mentioned (60h/68h) can be modified after boot. However, I just don't know how to actually "apply" the modified PIRQ routing at this point. If OS kernels (e.g. Win9x) can do it, then I think it should be doable from DOS as well...

Ideally, if FreeDOS kernel can somehow be made APIC-aware then there would be less need to deal with legacy IRQs routed to PIRQ lines. I recall reading in the SBEMU thread that some very new motherboard's BIOSes leave IO APIC open to the extent that the onboard audio remains on APIC IRQs that SBEMU has to be adapted to handle such situations... (EDIT: After reading relevant posts there, it seems related programs/TSRs must also be APIC-aware for everything to work as desired...)

EDIT: Just tried disabling the USB 3 controllers, and unfortunately this does not result in a free IRQ5 -- another PIRQ line that previously used IRQ3 was instead given IRQ5 as a result. So no... on my motherboard I simply can't use IRQ5 for anything legacy at all...

EDIT 2: I noticed something when comparing the host controller register states of RUBY-9719VG2AR and my current X99M Killer/3.1, regarding the SIRQ_CNTL register (64h). Apparently, the former set SERIRQ to continuous mode (D0h) while the latter set it to quiet mode (90h). I modified the register from 90h to D0h and after a bit of fiddling in DIGPAK for a brief while the sound card was able to correctly play SFX there, and SBDIAG tests regarding IRQ (DMA/tada) start passing (DMA test keeps playing though a click can be heard between cycles, while tada test repeats the sound instead of just once). Sadly this didn't last too long as when I played Spear Resurrection, SFX still can't be played properly (cutting off) and after exiting the game the same broken behaviors came back in DIGPAK and SBDIAG tests, yet SERIRQ is still in continuous mode according to the aforementioned register.

LSS10999 wrote on 2024-04-28, 00:46:

[…]
Show full quote

Copy code to clipboard

1pcicmd 0 1f 0 60
2pcicmd 0 1f 0 68

I get 0A04800B and 03058080 respectively, so it looks like IRQ7 is free. I've always needed to use IRQ 7 with the disappointment, but I tried 2,3,5 and none of them worked either.

I've disabled quite literally every onboard device in the BIOS, but this board has a bunch of jumpers so I'll maybe investigate them. (I checked SIRQ and it's wired up fine)

EDIT : just tried a different soundcard (ALS100+ based) and it works! Maybe both my SB16s are broken...

Sb 16 prefer irq 5 don't they?

myne wrote on 2024-04-28, 13:43:

Sb 16 prefer irq 5 don't they?

Never had a problem running either of my SB16s on IRQ7. (except on this board, apparently)

rasteri wrote on 2024-04-28, 13:29:

I get 0A04800B and 03058080 respectively, so it looks like IRQ7 is free. I've always needed to use IRQ 7 with the disappointment […]
Show full quote

LSS10999 wrote on 2024-04-28, 00:46:

[…]
Show full quote

Copy code to clipboard

1pcicmd 0 1f 0 60
2pcicmd 0 1f 0 68

I get 0A04800B and 03058080 respectively, so it looks like IRQ7 is free. I've always needed to use IRQ 7 with the disappointment, but I tried 2,3,5 and none of them worked either.

I've disabled quite literally every onboard device in the BIOS, but this board has a bunch of jumpers so I'll maybe investigate them. (I checked SIRQ and it's wired up fine)

EDIT : just tried a different soundcard (ALS100+ based) and it works! Maybe both my SB16s are broken...

I think non-Creative cards perform a bit better when used with LPC-ISA bridges. On RUBY-9719VG2AR my SB16 (IRQ5) had a few similar issues like with dISAppointment, but not as severe. My ALS007-based card (also IRQ5) worked perfectly fine on RUBY, although a bit too quiet that I have to max out the volumes to reach the same level as my SB16 (it still sounds too quiet on NT 3.51, despite being bug-free).

myne wrote on 2024-04-28, 13:43:

Sb 16 prefer irq 5 don't they?

Both IRQ5 and 7 should do. The former is often preferred if the board has an actual LPT port, though it's still possible to use IRQ7 as long as you don't use both LPT and sound card at the same time.

Unfortunately on modern motherboards, it appears IRQ5 is being highly contested among PCI devices, that it's nearly impossible to free that IRQ even after disabling most if not all onboard devices that could be disabled.

On your board irq 3 was probably shared by more devices so as you freed irq 5 it moved one device from irq 3 to 5 to avoid sharing.
Maybe it would be possible to disable device taking irq 5 after boot by some control registers?

RayeR wrote on 2024-04-28, 20:06:

On your board irq 3 was probably shared by more devices so as you freed irq 5 it moved one device from irq 3 to 5 to avoid sharing.
Maybe it would be possible to disable device taking irq 5 after boot by some control registers?

On my motherboard, IRQ3 was taken by line E. USB3 controller which is using IRQ5 is on line D.

Disabling USB3 controller closes line D, but this changed IRQ assignments of other lines:
Line C: IRQ4 -> IRQ3
Line E: IRQ3 -> IRQ5

So most likely IRQs 3 and 5 are of higher priority, that the BIOS would aggressively try to assign them to a PIRQ line should they be available. These IRQs must be marked as reserved somehow to avoid PIRQ lines from taking them.

Actually IRQ4 was originally for onboard COM port which I disabled as I'm not using it. When IRQ4 is taken, line C would share IRQ with line A or B (11 or 10 respectively, didn't take note which).

Onboard audio, which took IRQ7, resides on line H which I think is of the least priority to the point that disabling it (closing the line in the process) had very little impact on the assignments of other PIRQ lines.

I looked at my BIOS' PCI IRQ routing table via AMIBCP before, but its contents discouraged me from actually editing:
- So many bitmaps had bits 5 and 7 set which means they can take IRQ5/7 if permitted.
- Many bitmaps also had bits 6 set, but BIOS refused to hand out that IRQ, even though the board doesn't have a real floppy disk controller (so it's actually free).

I wish there was a decent guide to understanding the various elements of bioses like how the acpi tables work.
I've modded a few bioses, but it's still mostly a mystery. You'd think that software every pc for 40+ years runs would have been picked apart to the point of almost every byte being thoroughly documented.
But I guess there's no real incentive to write down what is learned.

My best suggestion at this point is to get yourself a ch341a and play with the tables.
The ch341a is just incase it fails.

Hey, interestingly enough if I power the disappointment from my cheapo aliexpress PicoPSU clone, the DSP audio in DOOM drops out after about 30 seconds.

I should probe the PicoPSU and see how dirty the power is, heh.

Some updates...

I did some tests with dISAppointment on Windows XP and to my surprise it worked reasonably well, though can't be sure it's reliable enough.

Setting Sound Blaster 16 as preferred audio device and tested playing some games. Everything looked good for quite a while (at least for an hour I think), until the game froze for unknown reasons... probably due to the sound card as at that moment I wasn't able to get any more sound from the SB16, so I force closed the program and switched back to my PCIe sound card just to be safe.

The card and bridge did not fall off the bus at that time, however, as even during the hiccup, the card's MIDI (powered by WavetablePi) remained functional, and wave output from my SB16 eventually restored after a while. I did not test much afterwards, but I think it's good enough for now.

I think there's still issue with IRQ, or maybe specific to SB16. I previously modded my SB16 with a MCU containing patched DSP FW which corrected the hanging notes problem, though no noticeable differences in other aspects... I haven't tested the more recent 4.16-based patch yet. If time permits I'll try using my ALS007 on it for comparison, to see if these cards naturally work better than Creative ones.

EDIT: Have to take back a little bit. Turned out the old issue with the cable is striking back again... At one point the system did not detect my SB16, though the card started being able to be detected again after I reboot... then I just let the SB16 play some MIDI tracks for about 2-3 hours on WinXP and suddenly the card hung and the system once again stopped picking it up... (UPDATE: Yep... the bridge has indeed fallen off the bus... probably I need to touch the wires a bit to get it detected again... or make some new ones using IDC headers as suggested.)

EDIT 2: I eventually reseated the cable so the adapter is being detected again. This time I replaced my SB16 with ALS007 for a comparison, and got some interesting noticeable differences.
SBDIAG: No sound when testing non-DMA output. DMA/tada output works as expected (keeps playing, indicating IRQ is working), though the sound did stop after playing once during very first try (works as expected afterwards).
DIGPAK: Did not test SETD, but the already configured SFX driver (SB16) functions without issue (silence, cutoffs, etc.) compared to real SB16.
Spear Resurrection: SFX plays fine with no apparent cut-offs like with SB16. Much better.

Additionally, looks like 16-bit audio simply doesn't work when using only low DMA channel. On both SB16 and ALS007, when configuring 16-bit audio to use low DMA channel, 16-bit tests in respective programs (DIAGNOSE/ALCONFIG) would instead produce a loud screeching noise. 16-bit output only works for SB16 when using a high DMA (while ALS007 doesn't support high DMA anyway).

I haven't gotten anything that has good WSS capability and I'm not sure if WSS would work properly on my board, as my board happens to put its GPIO register access zone at 500h instead of 480h, which overlaps with the usual WSS I/O 530h, and this caused some tools such as AIDA16 to mistakenly assume the system has WSS installed. Need to test whether it's safe to disable or move the GPIO register access zone once we're done examining it, as well as whether WSS can work as expected after doing so.

@LSS10999
If you have some spare time, please try passing through the LPC controller to a VM and test it. As previously discussed, there is maybe no chance of using this in a VM, but I would like to try. On my own computer, which is a wildy different platform mind you, if I passed through the IOMMU group of the LPC controller it got detected in the VM too, thus I dont see any reason that it wouldnt work, but there is a strong chance that I am uninformed about some context here.

nakos1212 wrote on Yesterday, 18:55:

@LSS10999
If you have some spare time, please try passing through the LPC controller to a VM and test it. As previously discussed, there is maybe no chance of using this in a VM, but I would like to try. On my own computer, which is a wildy different platform mind you, if I passed through the IOMMU group of the LPC controller it got detected in the VM too, thus I dont see any reason that it wouldnt work, but there is a strong chance that I am uninformed about some context here.

Sorry but I'm not an expert in VM passthrough. Which chipset are you using?

If you're using a too modern Intel chipset (100 series and above) then there's little point to use this adapter as you won't be able to use DMA, since Intel removed it (along with 8237) from that point.

And AFAIK LPC bus was mainly used for SuperIO which is responsible for many legacy things such as PS/2, fan/temperature controls, and so on. I wonder what might happen if you pass through your host's LPC controller to the VM which may not have a BIOS/driver that fully understands how your SuperIO works/reports.