VOGONS


Reply 500 of 569, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
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).

pcicmd 0 1f 0 60
pcicmd 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).

Reply 501 of 569, by rasteri

User metadata
Rank Oldbie
Rank
Oldbie
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 😁

Reply 502 of 569, by RayeR

User metadata
Rank Oldbie
Rank
Oldbie

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.

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 8GB DDR3, 128GB SSD, GTX970(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo + LPC2ISA

Reply 503 of 569, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 504 of 569, by rasteri

User metadata
Rank Oldbie
Rank
Oldbie
LSS10999 wrote on 2024-04-28, 00:46:
[…]
Show full quote
pcicmd 0 1f 0 60
pcicmd 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...

Reply 506 of 569, by rasteri

User metadata
Rank Oldbie
Rank
Oldbie
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)

Reply 507 of 569, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
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
pcicmd 0 1f 0 60
pcicmd 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.

Reply 508 of 569, by RayeR

User metadata
Rank Oldbie
Rank
Oldbie

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?

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 8GB DDR3, 128GB SSD, GTX970(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo + LPC2ISA

Reply 509 of 569, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
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).

Last edited by LSS10999 on 2024-04-29, 13:44. Edited 1 time in total.

Reply 510 of 569, by myne

User metadata
Rank Oldbie
Rank
Oldbie

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.

Things I built:
Mechwarrior 2 installer for Windows 10/11 Re: A comprehensive guide to install and play MechWarrior 2 on new versions on Windows.
Dos+Windows 3.11 auto-install iso template (for vmware)
Script to backup Win9x\ME drivers from a working install

Reply 511 of 569, by rasteri

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 512 of 569, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie

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.

PS: Again, regarding on how to use ISA sound cards behind dISAppointment outside DOS

I first booted to DOS without loading anything else except setting up the LPC controller and other necessary configs, like UNISOUND. Then I launched GRUB4DOS with necessary configuration to load NTLDR (or other boot loaders if desired) and the OSes from this point on will be able to utilize the sound card just fine. The DOS part can be automated through a custom startup option in CONFIG.SYS/AUTOEXEC.BAT, and running UNISOUND before booting to actual OS ensures proper functionality of the sound card even if the OS does not support ISA PnP.

Reply 513 of 569, by nakos1212

User metadata
Rank Newbie
Rank
Newbie

@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.

Reply 514 of 569, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
nakos1212 wrote on 2024-05-11, 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.

Reply 515 of 569, by nakos1212

User metadata
Rank Newbie
Rank
Newbie
LSS10999 wrote on 2024-05-12, 05:04:
Sorry but I'm not an expert in VM passthrough. Which chipset are you using? […]
Show full quote
nakos1212 wrote on 2024-05-11, 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.

I have a Z87 chipset.
What I did essentially is basically the same as some PCI/GPU passthrough, I just passed through the IOMMU group deecriptor of the group that had the LPC controller in it instead of my GPU. - theoretically every dma-capable device can be passed through by the IOMMU to a VM.
This would help me a lot as if I could hodt my 98/DOS system in a VM, I could use a single computer for all my computing needs instead of using a separate desktop, server and retro desktop, which would be far more expensive.
So if you have the time, please test it out.
There are good tutorials on e.g ArchWiki that basically applies for every distro but of course with minot differencee in this case (not using iommu=pt bracusr that only shows pci devices, not a gpu but an isa bridge / lpc controller, etc.)

Reply 516 of 569, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
nakos1212 wrote on 2024-05-12, 12:01:
I have a Z87 chipset. What I did essentially is basically the same as some PCI/GPU passthrough, I just passed through the IOMMU […]
Show full quote

I have a Z87 chipset.
What I did essentially is basically the same as some PCI/GPU passthrough, I just passed through the IOMMU group deecriptor of the group that had the LPC controller in it instead of my GPU. - theoretically every dma-capable device can be passed through by the IOMMU to a VM.
This would help me a lot as if I could hodt my 98/DOS system in a VM, I could use a single computer for all my computing needs instead of using a separate desktop, server and retro desktop, which would be far more expensive.
So if you have the time, please test it out.
There are good tutorials on e.g ArchWiki that basically applies for every distro but of course with minot differencee in this case (not using iommu=pt bracusr that only shows pci devices, not a gpu but an isa bridge / lpc controller, etc.)

I'm afraid this might be... a little complicated. I just checked the article on ArchWiki as well as a few other places about IOMMU passthrough, and could confirm that the host LPC controller indeed resides in its own IOMMU group but it's not the only thing in that group. You will also be passing through your IDE/SATA controllers into VM as well as a few other devices, since they're all Bus 0 Device 1F, just different functions, and the IOMMU group covers Bus 0 Device 1F as a whole.

And per ArchWiki, iommu=pt "will prevent Linux from touching devices which cannot be passed through", yet without using that parameter, you succeeded in letting the VM recognize the host's LPC controller by passing through that IOMMU group in question. So I wonder if you somehow have managed to keep other devices in the group (like SATA controller) in host without passing them along. It may not be an issue if you're using a NVMe drive instead of SATA, however, as it definitely would be in a different group... For that reason I doubt I would be able to test as I've several SATA drives installed there, and I boot Linux from one of them.

So how does the VM's system layout look like after passing through your host's LPC controller? The problem would be whether the virtualized system would even be able to honor your host's passed-through LPC controller instead of the virtualized ISA bridge when it comes to legacy address ranges. For this part it's not difficult to confirm, if your motherboard has a debug code output (or LPC-based debug card header), after passing through the host LPC controller into the VM, see if you could make it show the value you wrote into Port 80h from inside the VM.

Reply 517 of 569, by nakos1212

User metadata
Rank Newbie
Rank
Newbie
LSS10999 wrote on 2024-05-12, 14:05:
I'm afraid this might be... a little complicated. I just checked the article on ArchWiki as well as a few other places about IOM […]
Show full quote
nakos1212 wrote on 2024-05-12, 12:01:
I have a Z87 chipset. What I did essentially is basically the same as some PCI/GPU passthrough, I just passed through the IOMMU […]
Show full quote

I have a Z87 chipset.
What I did essentially is basically the same as some PCI/GPU passthrough, I just passed through the IOMMU group deecriptor of the group that had the LPC controller in it instead of my GPU. - theoretically every dma-capable device can be passed through by the IOMMU to a VM.
This would help me a lot as if I could hodt my 98/DOS system in a VM, I could use a single computer for all my computing needs instead of using a separate desktop, server and retro desktop, which would be far more expensive.
So if you have the time, please test it out.
There are good tutorials on e.g ArchWiki that basically applies for every distro but of course with minot differencee in this case (not using iommu=pt bracusr that only shows pci devices, not a gpu but an isa bridge / lpc controller, etc.)

I'm afraid this might be... a little complicated. I just checked the article on ArchWiki as well as a few other places about IOMMU passthrough, and could confirm that the host LPC controller indeed resides in its own IOMMU group but it's not the only thing in that group. You will also be passing through your IDE/SATA controllers into VM as well as a few other devices, since they're all Bus 0 Device 1F, just different functions, and the IOMMU group covers Bus 0 Device 1F as a whole.

And per ArchWiki, iommu=pt "will prevent Linux from touching devices which cannot be passed through", yet without using that parameter, you succeeded in letting the VM recognize the host's LPC controller by passing through that IOMMU group in question. So I wonder if you somehow have managed to keep other devices in the group (like SATA controller) in host without passing them along. It may not be an issue if you're using a NVMe drive instead of SATA, however, as it definitely would be in a different group... For that reason I doubt I would be able to test as I've several SATA drives installed there, and I boot Linux from one of them.

So how does the VM's system layout look like after passing through your host's LPC controller? The problem would be whether the virtualized system would even be able to honor your host's passed-through LPC controller instead of the virtualized ISA bridge when it comes to legacy address ranges. For this part it's not difficult to confirm, if your motherboard has a debug code output (or LPC-based debug card header), after passing through the host LPC controller into the VM, see if you could make it show the value you wrote into Port 80h from inside the VM.

I had my LPC controller in IOMMU group 9 with an SMBUS controller and nothing more. I"ll order a debug card that can be connected to a TPM and look at the output.
If this could work anyhow, I wouldnt mind forking out for e.g a dedicated SATA adapter if it gets messed up.
There is also the possibility of ACS if your cpu supports it (there is a good chance), and with that you can split IOMMU groups.

Reply 518 of 569, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie

A little update about some further tests.

Looks like regular 2.54mm 2x10 dupont connectors are indeed a bad idea for something like dISAppointment. One need to use long enough header pins to ensure the connection is tight enough so it won't move around easily leading to sudden failures. 2.00mm headers (for some motherboard vendors and models) are a bit better due to them being smaller with less excess height that they're more likely to be held firmly once connected. As such, I decided to make a specialized IDC cable for the 2.54mm side, using long enough 2.0mm-2.54mm dupont wires as base and after like 5-6 failed attempts I finally made a working one. So far it's working okay, just that the IDC connector I'm using is a bit too tight now that I won't be able to remove the cable without breaking it after plugging it into the header on the adapter...

I flashed the new 4.16-based patched DSP FW for my CT2950 and so far I haven't found any noticeable difference. Not sure how different the new cable's connection is compared to my previous ones signal-wise, but the card's behaviors appear to have become more consistent with my old RUBY-9719VG2AR in some aspects though still a bit worse.

I'm still not sure about WSS. I need to either disable GPIO register access to free up 500h range for LPC (which includes 530h), or move WSS address to elsewhere like 604h.

I've tried setting up a 82C929-based sound card (non-PnP) and was not successful. The setup program could not properly initialize the card for SB mode despite everything's been correctly set up. I also tried initializing WSS at F40h (since it can be covered by the same decoding register meant for decoding the card's MC register ranges, the F80-F9F range), but the system would freeze right after finishing initializing the card in WSS mode.

EDIT: Surprisingly, despite issues with setup programs, some games do work correctly with my CT2950, or at least comparable to the behavior observed on RUBY-9719VG2AR.
Terminal Velocity: This game uses DIGPAK, but it works without any issue. No hangs or apparent sound cut-offs observed.
Tyrian 2000: Sound hangs during menu and plays slower than expected while in-game. Same goes to RUBY-9719VG2AR.

EDIT 2 (about a week later): Guess the new cable I made can still become loose after prolonged use, as it stopped working again... the wires I used to make the cable were probably too thick that I wasn't able to crimp the side with more wires (precisely pins 1-3) completely to the end, so the IDC connector was left in a slightly unbalanced state, despite the resulted cable was confirmed usable when I initially tested it with a multimeter... maybe I need to use wires with correct thickness for the purpose...

Reply 519 of 569, by nakos1212

User metadata
Rank Newbie
Rank
Newbie
LSS10999 wrote on 2024-05-17, 07:36:
A little update about some further tests. […]
Show full quote

A little update about some further tests.

Looks like regular 2.54mm 2x10 dupont connectors are indeed a bad idea for something like dISAppointment. One need to use long enough header pins to ensure the connection is tight enough so it won't move around easily leading to sudden failures. 2.00mm headers (for some motherboard vendors and models) are a bit better due to them being smaller with less excess height that they're more likely to be held firmly once connected. As such, I decided to make a specialized IDC cable for the 2.54mm side, using long enough 2.0mm-2.54mm dupont wires as base and after like 5-6 failed attempts I finally made a working one. So far it's working okay, just that the IDC connector I'm using is a bit too tight now that I won't be able to remove the cable without breaking it after plugging it into the header on the adapter...

I flashed the new 4.16-based patched DSP FW for my CT2950 and so far I haven't found any noticeable difference. Not sure how different the new cable's connection is compared to my previous ones signal-wise, but the card's behaviors appear to have become more consistent with my old RUBY-9719VG2AR in some aspects though still a bit worse.

I'm still not sure about WSS. I need to either disable GPIO register access to free up 500h range for LPC (which includes 530h), or move WSS address to elsewhere like 604h.

I've tried setting up a 82C929-based sound card (non-PnP) and was not successful. The setup program could not properly initialize the card for SB mode despite everything's been correctly set up. I also tried initializing WSS at F40h (since it can be covered by the same decoding register meant for decoding the card's MC register ranges, the F80-F9F range), but the system would freeze right after finishing initializing the card in WSS mode.

EDIT: Surprisingly, despite issues with setup programs, some games do work correctly with my CT2950, or at least comparable to the behavior observed on RUBY-9719VG2AR.
Terminal Velocity: This game uses DIGPAK, but it works without any issue. No hangs or apparent sound cut-offs observed.
Tyrian 2000: Sound hangs during menu and plays slower than expected while in-game. Same goes to RUBY-9719VG2AR.

EDIT 2 (about a week later): Guess the new cable I made can still become loose after prolonged use, as it stopped working again... the wires I used to make the cable were probably too thick that I wasn't able to crimp the side with more wires (precisely pins 1-3) completely to the end, so the IDC connector was left in a slightly unbalanced state, despite the resulted cable was confirmed usable when I initially tested it with a multimeter... maybe I need to use wires with correct thickness for the purpose...

Did you have the chance to test out my idea? Sorry for the ping, just that I want to buy a new PC and the outcome of this VM experiment heavily influence my parts of choice. My debug cards sadly didnt arrive yet, possibly good old customs...