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

How do I order an ISA Disappointment board aka known as lpc to isa bridge.

You can use GERBER data from Rasteri's Github to manufacture the PCB e.g. in JLCPCB or other manuf. I have 4 PCBs left where are you from? We have quite high post taxes in our country esp. outside Europe.

Just a quick question regarding possible compatibility of newer chipsets/motherboards.

I have a B250 motherboard with a TPM header exposing LCLK, LRESET, PCIRST#, LFRAME# and LAD[3:0]. It also has an iTE super IO chip (surface mount) and lshw reports

1*-isa
2             description: ISA bridge
3             product: 200 Series PCH LPC Controller (B250)
4             vendor: Intel Corporation
5             physical id: 1f
6             bus info: pci@0000:00:1f.0
7             version: 00
8             width: 32 bits
9             clock: 33MHz
10             capabilities: isa bus_master
11             configuration: latency=0

Would it be possible to get LDRQ# from the super IO chip and make an ISA-adapter? If not why? I tried to follow the conversation but I'm not sure I understood where the magic line for too modern can be drawn.

GrafWasili wrote on 2024-08-11, 14:49:

Would it be possible to get LDRQ# from the super IO chip and make an ISA-adapter? If not why? I tried to follow the conversation but I'm not sure I understood where the magic line for too modern can be drawn.

Nah sorry. Newest chipset that can work is the 9-series. 100 onwards won't work.

rasteri wrote on 2024-08-11, 15:35:

Nah sorry. Newest chipset that can work is the 9-series. 100 onwards won't work.

i see thanks for your reply!

Slightly interesting datapoint - I'm currently trying to work with an Asus Q87M-E, and like the AMD boards it seems to filter some ports.

4E/4F seem to be allowed through, but I can't get any soundcards to work, nor even my ISA test card (so port 80 is filtered?)

The difference between this board and other ones I have is that it has PCI slots. So I'm guessing this is more subtractive decoding weirdness.

I haven't done any logic analyzer shenanigans yet but I've looked at it on a scope and it doesn't seem to be sending any frames at all when I try to send stuff to port 80. I can see lots of activity if I send to other ports.

rasteri wrote on 2024-08-18, 21:39:

Slightly interesting datapoint - I'm currently trying to work with an Asus Q87M-E, and like the AMD boards it seems to filter so […]
Show full quote

Slightly interesting datapoint - I'm currently trying to work with an Asus Q87M-E, and like the AMD boards it seems to filter some ports.

4E/4F seem to be allowed through, but I can't get any soundcards to work, nor even my ISA test card (so port 80 is filtered?)

The difference between this board and other ones I have is that it has PCI slots. So I'm guessing this is more subtractive decoding weirdness.

I haven't done any logic analyzer shenanigans yet but I've looked at it on a scope and it doesn't seem to be sending any frames at all when I try to send stuff to port 80. I can see lots of activity if I send to other ports.

Did port 80 work over LPC at power-on? Back then when I was testing on my FM2 board it worked briefly when the board powered up until the bit got disabled by BIOS, so I could see the very first few POST code.

A while ago I resumed some tests on AMD platforms, this time mainly on AM4 (B450), and unlike my FM2 board port 80 worked throughout the boot process (so that one's BIOS did not disable it). Yet still no significant progress made.

1. 4E/4F still doesn't work regardless of its bit state. The bit was turned on by default, though.
2. Turned out ISA PnP ports (279/A79) were not directly covered by the I/O registers. For that reason I additionally enabled port 278-27F (LPT2) in hope to cover 279, while I'm already covering A79 with a wide I/O starting with A00. Sadly this doesn't make any difference -- it still can't detect any PnP card.

For now the only thing can be proven is that dISAppointment itself does work with AMD chipsets, but it's yet to be of any good use as the chipsets aren't cooperative.

From the documentations I could find from AMD document hub I could not find anything related to I/O filtering, so I'm not sure where I should check next about things that could possibly interfere with normal LPC I/O. SPI-related registers? ROM? Or maybe SMI or PM registers?

I haven't figured out how to check SMI-related registers yet, though I did have code for accessing Power Management (PM) registers which appear to have some mentions about LPC (DMA).

LSS10999 wrote on 2024-08-19, 02:20:

Did port 80 work over LPC at power-on? Back then when I was testing on my FM2 board it worked briefly when the board powered up until the bit got disabled by BIOS, so I could see the very first few POST code.

Naw got nothing on my test card at all. Possibly the BIOS just doesn't send POST codes.

From the documentations I could find from AMD document hub I could not find anything related to I/O filtering, so I'm not sure where I should check next about things that could possibly interfere with normal LPC I/O. SPI-related registers? ROM? Or maybe SMI or PM registers?

I haven't figured out how to check SMI-related registers yet, though I did have code for accessing Power Management (PM) registers which appear to have some mentions about LPC (DMA).

Yeah, there must be a lot of virtual devices on the chipset that might be interfering. I no longer have an AMD motherboard to test but let us know if you find anything.

RayeR wrote on 2024-07-09, 00:08:

You can use GERBER data from Rasteri's Github to manufacture the PCB e.g. in JLCPCB or other manuf. I have 4 PCBs left where are you from? We have quite high post taxes in our country esp. outside Europe.

Lake Charles Louisiana USA