nakos1212 wrote on 2024-05-22, 15:01:

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

Just attempted experimenting it with VirtualBox but it was not successful. Turned out the functionality was removed since around 6.1 (mine is 7.0) due to it being "incomplete".

I'm not sure what hypervisor did you use to pass through just your host LPC controller. Did you use QEMU?

Normally a VM would virtualize a chipset of its own. I still have the question whether it's possible to somehow "replace" the VM's ISA bridge with the host's LPC controller, as I doubt two active ISA bridges (the virtualized one as well as the real one passed into the VM) would both function as expected. I don't know very much about the lower-level aspects of QEMU anyway.

If you don't have the debug card you may try just talking with your SuperIO (usually at 2Eh/2Fh) according to its datasheet, if available, to see if you can somehow reach it from inside the VM after passing the host LPC controller through.

On the other hand, the adapter apparently expects very strict electrical connectivity. Casually made cables won't cut it, as they'll likely come loose and break the functionality after a prolonged while.

Although I did manage to make a working IDC cable, it only lasted for about a week and now it coming loose again. I'm looking for some right materials to make one that'll hopefully stay working for a bit longer.

PS: I'm not sure how VMusic extpack performs. You may consider using it alongside VBox's own SB16 emulation to see how those emulations perform in overall. Actually, in some cases VBox's SB16 emulation does not suffer from certain bugs that existed on real hardware.

A notable example would be, with Windows NT 3.51, on real Sound Blaster 16/AWE hardware, I was unable to play any audio file past a certain bit rate (determined by sampling rate and bit-width), whereas VBox's SB16 emulation does not suffer from those same issues (all files played fine). I've already reproduced the issues in question on very different setups, such as CT2950 behind a LPC-ISA bridge, as well as an AWE64 Gold on a 865G/ICH5 based board. Logon/logoff sounds from Win2000/Me's "media" folder were notable examples, though interestingly the same files played fine with non-Creative sound cards (e.g. ALS007).

PPS: There are still some things I'm not informed. Firstly I wonder when ACS did become a thing, as my X99 board does not appear to offer that option. The BIOS was kind of crippled in overall, that even with the hidden "Advanced" menu unlocked I still don't get the option to bifurcate my second PCIe slot.

Additionally, when you did pass through your board's LPC controller, can you still access sensors like temperature and fan speed from your host, and were your system fans still operating as usual, if connected to the board instead of directly to PSU?

LSS10999 wrote on 2024-05-22, 16:44:

Just attempted experimenting it with VirtualBox but it was not successful. Turned out the functionality was removed since around […]
Show full quote

nakos1212 wrote on 2024-05-22, 15:01:

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

Just attempted experimenting it with VirtualBox but it was not successful. Turned out the functionality was removed since around 6.1 (mine is 7.0) due to it being "incomplete".

I'm not sure what hypervisor did you use to pass through just your host LPC controller. Did you use QEMU?

Normally a VM would virtualize a chipset of its own. I still have the question whether it's possible to somehow "replace" the VM's ISA bridge with the host's LPC controller, as I doubt two active ISA bridges (the virtualized one as well as the real one passed into the VM) would both function as expected. I don't know very much about the lower-level aspects of QEMU anyway.

If you don't have the debug card you may try just talking with your SuperIO (usually at 2Eh/2Fh) according to its datasheet, if available, to see if you can somehow reach it from inside the VM after passing the host LPC controller through.

On the other hand, the adapter apparently expects very strict electrical connectivity. Casually made cables won't cut it, as they'll likely come loose and break the functionality after a prolonged while.

Although I did manage to make a working IDC cable, it only lasted for about a week and now it coming loose again. I'm looking for some right materials to make one that'll hopefully stay working for a bit longer.

PS: I'm not sure how VMusic extpack performs. You may consider using it alongside VBox's own SB16 emulation to see how those emulations perform in overall. Actually, in some cases VBox's SB16 emulation does not suffer from certain bugs that existed on real hardware.

A notable example would be, with Windows NT 3.51, on real Sound Blaster 16/AWE hardware, I was unable to play any audio file past a certain bit rate (determined by sampling rate and bit-width), whereas VBox's SB16 emulation does not suffer from those same issues (all files played fine). I've already reproduced the issues in question on very different setups, such as CT2950 behind a LPC-ISA bridge, as well as an AWE64 Gold on a 865G/ICH5 based board. Logon/logoff sounds from Win2000/Me's "media" folder were notable examples, though interestingly the same files played fine with non-Creative sound cards (e.g. ALS007).

PPS: There are still some things I'm not informed. Firstly I wonder when ACS did become a thing, as my X99 board does not appear to offer that option. The BIOS was kind of crippled in overall, that even with the hidden "Advanced" menu unlocked I still don't get the option to bifurcate my second PCIe slot.

Additionally, when you did pass through your board's LPC controller, can you still access sensors like temperature and fan speed from your host, and were your system fans still operating as usual, if connected to the board instead of directly to PSU?

I'll try those points mentioned, thanks - there was no apparent change in fqn speed but mqabe thqt was coincidental.
I used QEMU KVM with virt-manager.

LSS10999 wrote on 2024-05-22, 16:44:

On the other hand, the adapter apparently expects very strict electrical connectivity. Casually made cables won't cut it, as they'll likely come loose and break the functionality after a prolonged while.

Although I did manage to make a working IDC cable, it only lasted for about a week and now it coming loose again. I'm looking for some right materials to make one that'll hopefully stay working for a bit longer.

It seems I've figured out the cause... turned out at least one of the actively used header joints were poorly soldered back then. Moving/reseating the cables also moved the header pins slightly so the loose ones might end up reconnected, but the connection will still break after a short while.

Initially I attempted "fixing" the custom IDC cable by trying to crimp the previously loose side, which I eventually succeeded and the cable now looks solid. Yet it did not fix the connectivity issue after I reconnected the cable to the adapter.

Feeling that nothing worked, I tried soldering all the necessary wires directly to the header joints to make a permanent connection, instead of using connectors, but wasn't successful as the adapter still couldn't be detected, so I removed them afterwards. During the process, the soldering on all the header joints were redone with the help of a good amount of flux.

After that I reconnected the IDC cable again, as I really don't have any better idea at that time. To my surprise, it worked fine without any issue. Will see how long it can last this time...

Guess I can never be too perfect when it comes to soldering, as this kind of issue was very sneaky, virtually unnoticeable when I initially inspected the soldering after assembly (with a magnifier), and only manifests after prolonged use.

I still use one ribbon cable with crimped pfl connectors and have no issues. Plugged and temoved few tens times...

No good. One week since the last time I redid the soldering on the 20-pin header, it stopped working again. Just like previous times, when the ISA sound card suddenly stopped working, and LPCFCHK stopped picking up the bridge chip.

Nothing else was changed. Will try redoing the soldering again when I have time, to see if this will let me keep running the adapter this way for another week, but I'm afraid the problem lies deeper than that.

maybe modify lpcfchk to repeatedly poll the bridge chip, then wiggle various pins to see what makes it fail/succeed?

My guess is there's a broken trace near the connector or something

rasteri wrote on 2024-06-03, 11:27:

maybe modify lpcfchk to repeatedly poll the bridge chip, then wiggle various pins to see what makes it fail/succeed?

My guess is there's a broken trace near the connector or something

No good... I tried soldering the header again, but it doesn't make any difference this time. Getting the adapter detected remained difficult.

Right now, it seems the only way to get the adapter detected is when there's a little force pulling the (20-pin) connector between the cable and dISAppointment upwards. I used a few cable ties to tie the cable to some nearby wires in order to let them pull the cable up a bit. It kind of works, but remains loose in general and will still fail at any moment... Guess I still need to make a better cable, and this won't be easy.

Considering the experiences I'm having with my own build I think there may be rooms for improvement regarding the LPC header. I think there's no need to be constrained to the original 2x10 TPM pinout on the dISAppointment side, as usually one only needs to bring out 9 signals from mobo's TPM header (regardless of form factor as long as it's LPC-based), plus LDRQ# which usually needs to be manually brought out using a wire, making it a total of 10 signals. How to get those signals reliably connected (and hopefully a bit more fault tolerant) is more important.

LSS10999 wrote on 2024-06-04, 12:33:

Considering the experiences I'm having with my own build I think there may be rooms for improvement regarding the LPC header.

I've always thought of 2.54mm headers as being among the most reliable connectors, they also have the advantage of not needing special tools to construct cables.

I'm open to suggestions though - what would you prefer, connector-wise?

rasteri wrote on 2024-06-04, 13:43:

LSS10999 wrote on 2024-06-04, 12:33:

Considering the experiences I'm having with my own build I think there may be rooms for improvement regarding the LPC header.

I've always thought of 2.54mm headers as being among the most reliable connectors, they also have the advantage of not needing special tools to construct cables.

I'm open to suggestions though - what would you prefer, connector-wise?

I do have some ideas at the moment, for reference.

1. Group all necessary signals to a 2x5 header.
Needed LPC signals on the standard 2x10 TPM pinout may not be mechanically ideal, as most of the signals are near 1. PCICLK while almost none on the other side (mainly just 16. SERIRQ and 20. LDRQ#).

On the other hand, I think Tiido's LPC2ISA design put all 9 LPC signals (minus GND) on a single line (1x9).

2. Consider using 2.0mm headers instead of 2.54mm.
Right now I'm thinking of getting some conversion boards that could enable me to convert the 2.54mm headers into 2.0mm, to see how it performs when using 2.0mm-2.0mm cables (for my motherboard's TPMS header) and a single 2.0mm-2.54mm cable (for LDRQ#).

I think this is worth trying, as so far the motherboard side, which uses a 2.0mm 2x9 TPMS header, doesn't appear to be directly responsible for any of the connectivity issue I've experienced so far.

LSS10999 wrote on 2024-06-04, 14:46:

2. Consider using 2.0mm headers instead of 2.54mm.
Right now I'm thinking of getting some conversion boards that could enable me to convert the 2.54mm headers into 2.0mm, to see how it performs when using 2.0mm-2.0mm cables (for my motherboard's TPMS header) and a single 2.0mm-2.54mm cable (for LDRQ#).

I think this is worth trying, as so far the motherboard side, which uses a 2.0mm 2x9 TPMS header, doesn't appear to be directly responsible for any of the connectivity issue I've experienced so far.

I just soldered a 2.54mm female to 2.0mm male conversion board, as well as made a new cable using mostly 2.0mm-2.0mm wires plus a single 2.0mm-2.54mm wire for LDRQ#. No difference. The adapter is not even responding anymore.

I ended up replacing the adapter with another v0.2 one I made earlier, and somehow, with the same new cable, everything is working again.

I used a F85226AF on that one. The soldering was not as good as the current one in overall, that I later on redid the soldering of a few resistor arrays (that looked bad in comparison). I also tried correcting the previously wrong orientation of the LEDs for negative rails but after rework only the -5V LED worked. I never got the -12V LED working... perhaps I broke it. The negative rails themselves are fine anyway, so the LED is just a cosmetic issue.

Will see how long this one can work without issues. Guess I was wrong all along. Maybe the F85226FG I used was indeed flawed.

Come to think of it, if the connection between the motherboard and the adapter was really that loose I would be having intermittent issues, rather than seeing the adapter working fine just to stop functioning all of a sudden and never recover. It may have been just a coincidence that wiggling the cable somehow succeeded in resetting its functionality.

LSS10999 wrote on 2024-06-09, 06:44:

Will see how long this one can work without issues. Guess I was wrong all along. Maybe the F85226FG I used was indeed flawed.

Come to think of it, if the connection between the motherboard and the adapter was really that loose I would be having intermittent issues, rather than seeing the adapter working fine just to stop functioning all of a sudden and never recover. It may have been just a coincidence that wiggling the cable somehow succeeded in resetting its functionality.

Glad you got it working. Sometimes just building a new board is the only way.

I bet if you transplant that FG onto a new board it would inexplicably start working too