LSS10999 wrote on 2024-04-01, 15:04:

Disabling the onboard audio allowed me to set IRQ7 for the sound card. However, it seems LDRQ1# I brought out is not working correctly, as DIAGNOSE currently gets stuck at DMA section, saying the DMA channels are not usable.

IIRC there's a register to switch LDRQ1 between a GPIO pin and LDRQ. I'll have a look through the manual.

If that doesn't work maybe lift LDRQ0 from the superIO and attach to that?

BTW I bought a generic X99 motherboard from aliexpress, maybe it has different BIOS options

rasteri wrote on 2024-04-01, 18:05:

BTW I bought a generic X99 motherboard from aliexpress, maybe it has different BIOS options

One of those generic X99 mainboards that are, these days, likely not to be an actual X99 chipset? 😁

rasteri wrote on 2024-04-01, 18:05:

IIRC there's a register to switch LDRQ1 between a GPIO pin and LDRQ. I'll have a look through the manual. […]
Show full quote

LSS10999 wrote on 2024-04-01, 15:04:

Disabling the onboard audio allowed me to set IRQ7 for the sound card. However, it seems LDRQ1# I brought out is not working correctly, as DIAGNOSE currently gets stuck at DMA section, saying the DMA channels are not usable.

IIRC there's a register to switch LDRQ1 between a GPIO pin and LDRQ. I'll have a look through the manual.

If that doesn't work maybe lift LDRQ0 from the superIO and attach to that?

BTW I bought a generic X99 motherboard from aliexpress, maybe it has different BIOS options

It's in the GPIO registers. You need to refer to the register 48h of the host LPC controller which sets the base address for those registers. In my case it's 500h.

(LATE EDIT: Just realized something. With GPIO registers placed in 500h this board cannot use WSS which usually resides in 530h, unless the game allows moving it to somewhere else. Don't know if it's possible to move the base address at this point. RUBY-9719VG2AR, on the other hand, places GPIO registers in 480h. Should be noted that due to the GPIO registers being in this range and accessible, some system information tools like AIDA16 would incorrectly suggest that my board has WSS installed, which is clearly not the case. I'm afraid this might end up confusing some WSS-capable games as well.)

I haven't checked all registers, only the first one (which contains the bit controlling whether LDRQ1# is GPIO23). However, in my case the corresponding bit (bit 23) is not set so LDRQ1# is indeed LDRQ1#.

I think I need to look for ways to actually probe/test the LDRQ1# signal to see if it's really working. Regardless, I'm considering taking off the heatsink (again) for an inspection when I have time...

EDIT: Don't know this part might be relevant. It was mentioned several pages ago...

myne wrote on 2023-04-26, 08:57:

Bus Master Device Mapping and START Fields
Bus Masters must have a unique START field. In the case of the PCH that supports two LPC bus masters, it drives 0010 for the START field for grants to Bus Master 0 (requested using LDRQ0#) and 0011 for grants to Bus Master 1 (requested using LDRQ1#.). Thus, no registers are needed to configure the START fields for a particular bus master.

I'm not sure if the Fintek bridge is automatically aware of which bus master it has been designated as, or something needs to be done to "tell" the bridge about it. I'm yet to find anything else related to this from the documentations...

LSS10999 wrote on 2024-04-01, 18:42:

I'm not sure if the Fintek bridge is automatically aware of which bus master it has been designated as, or something needs to be done to "tell" the bridge about it. I'm yet to find anything else related to this from the documentations...

Hey interestingly, the AF variant of the fintek chip appears to lack register 0x1C, or "Master Setting Register". It's marked as reserved so I'm not sure how useful that is though. Check page 23 of the attached.

It's also entirely missing the version register at 0x5C (So I guess that's why you're seeing differences), but it has some extra stuff at 0x53 to 0x55 (Frame waiting control and VDD0 voltage). I don't think I have any AF chips but it might be worth investigating...

EDIT : in fact yeah, the VDD0 register has stuff about disabling IRQs, so maybe that could be useful info

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

Hey interestingly, the AF variant of the fintek chip appears to lack register 0x1C, or "Master Setting Register". It's marked as […]
Show full quote

LSS10999 wrote on 2024-04-01, 18:42:

I'm not sure if the Fintek bridge is automatically aware of which bus master it has been designated as, or something needs to be done to "tell" the bridge about it. I'm yet to find anything else related to this from the documentations...

Hey interestingly, the AF variant of the fintek chip appears to lack register 0x1C, or "Master Setting Register". It's marked as reserved so I'm not sure how useful that is though. Check page 23 of the attached.

It's also entirely missing the version register at 0x5C (So I guess that's why you're seeing differences), but it has some extra stuff at 0x53 to 0x55 (Frame waiting control and VDD0 voltage). I don't think I have any AF chips but it might be worth investigating...

EDIT : in fact yeah, the VDD0 register has stuff about disabling IRQs, so maybe that could be useful info

I think RUBY-9719VG2AR also uses F85226FG, just I don't know which LDRQ# it uses, as I'm not seeing its boardview floating around.

The one I'm currently testing with my X99M board is a recently built one using F85226FG, not AF. I brought out my board's LDRQ1# with a thin wire but as far as DIAGNOSE goes DMA isn't working. IRQ can be set to 7 after disabling onboard HD audio, as it would claim it.

AFAIK the board isn't really using LDRQ1# nor had it configured as GPIO... I'll inspect the wire just in case, if other possible factors are ruled out.

And well... I'm afraid "stealing" LDRQ0# from SuperIO can be very tricky with the tools I currently have...

Just for a quick test try DMM with diode test on LDRQ1 (without TPM connected) if you see 0,6V junction Vdrop on your wire - if it is really connected somewhere on PCH.
Try to look in PCH datasheet if LDRQ input can read level from some status register or if it can be configured as input and then read the level for testing...

RayeR wrote on 2024-04-02, 14:11:

Just for a quick test try DMM with diode test on LDRQ1 (without TPM connected) if you see 0,6V junction Vdrop on your wire - if it is really connected somewhere on PCH.
Try to look in PCH datasheet if LDRQ input can read level from some status register or if it can be configured as input and then read the level for testing...

I'm not sure about the details. How should I connect the multimeter? I never actually tested a diode with it before...

Which test lead (COM or INPUT) should I put on the wire I brought out, and where should I put the other test lead on?

Simply connect DMM COM probe to LDRQ and INPUT probe at any GND on the board. It should show value in range of 0,5-0,7V. This is voltage drop over internal substrate diode of a silicon chip. Almost every digital input/output has 2 "hidden" internal diodes between GND and VCC. That diodes are in reverse polarity than normla signal so they don't affect the circuit functionality. If the display reading doesn't change after connection it means open circuit - the wire is actually not connected to PCH ball (or broken elsewhere). I use this testing quite often when searching a problem, if the reading value is near 0V it means a short to GND or damaged input/ouptut...

This picture explains better than words: https://www.researchgate.net/figure/a-ESD-pro … _fig7_332480346

Just to add - the diode measurement should be done with the power off.

RayeR wrote on 2024-04-02, 17:15:

Simply connect DMM COM probe to LDRQ and INPUT probe at any GND on the board. It should show value in range of 0,5-0,7V. This is voltage drop over internal substrate diode of a silicon chip. Almost every digital input/output has 2 "hidden" internal diodes between GND and VCC. That diodes are in reverse polarity than normla signal so they don't affect the circuit functionality. If the display reading doesn't change after connection it means open circuit - the wire is actually not connected to PCH ball (or broken elsewhere). I use this testing quite often when searching a problem, if the reading value is near 0V it means a short to GND or damaged input/ouptut...

This picture explains better than words: https://www.researchgate.net/figure/a-ESD-pro … _fig7_332480346

Just tested... I think it's connected. Following the instructions I get a reading of 0.574V in diode mode.

Since the LDRQ1# isn't configured as GPIO... I wonder if there's anything else I need to configure to make DMA working...

EDIT: There's a section about DMA-related registers, that I haven't found out how to access them... but a good amount of those registers are write-only.

LSS10999 wrote on 2024-04-03, 10:10:

Since the LDRQ1# isn't configured as GPIO...

You mean on Fintek side or PCH side? Can PCH configure this pin as GPI(O)?
Can you hook a scope on LDRQ to see if fintek assert it low during DMA test?

RayeR wrote on 2024-04-03, 11:14:

LSS10999 wrote on 2024-04-03, 10:10:

Since the LDRQ1# isn't configured as GPIO...

You mean on Fintek side or PCH side? Can PCH configure this pin as GPI(O)?
Can you hook a scope on LDRQ to see if fintek assert it low during DMA test?

The PCH side. LDRQ1# can be configured as GPIO23, but as for the value I read from the register that controls the pin's functionality, bit 23 was 0, so it's set to native mode (LDRQ1#), not GPIO23.

I don't have a good tool that can be used as a scope at the moment...

For what its worth, SETYMF doesn't use IRQ during its DMA based sound tests. Without IRQs it simply shows "IRQs fired : 0" on conclusion of a test, but if DMA works there will still be sound. If DMA doesn't there will just be silence but no freeze or anything, of course YMF71x cards only...

LSS10999 wrote on 2024-04-03, 11:17:

I don't have a good tool that can be used as a scope at the moment...

Maybe it would be enough to connect some high-bright green LED between LDRQ (cathode) and VDD (anode) via cca 470R and watch if it blink for a moment during test. LDRQ pulse from Fintek would be probably very short but still may be seen due to eye light integration.

LSS10999 wrote on 2024-04-02, 13:59:

I think RUBY-9719VG2AR also uses F85226FG, just I don't know which LDRQ# it uses, as I'm not seeing its boardview floating around.

https://theretroweb.com/motherboard/manual/ru … 89524497458.pdf
Pg 9. Confirmed.

No boardview, but the block diagram shows a TPM header on the LPC. Why not use that?

Seems odd to me that there are 3 devices on LPC but only 2x LDRQ's.
I was going to say figure out which one the 83627 UHG and TPM use and there's your answer, but it might not even have one or it's shared.

https://www.intel.com/content/dam/doc/datashe … 7-datasheet.pdf
Pg 62.

myne wrote on 2024-04-04, 04:01:

https://theretroweb.com/motherboard/manual/ru … 89524497458.pdf Pg 9. Confirmed. […]
Show full quote

LSS10999 wrote on 2024-04-02, 13:59:

I think RUBY-9719VG2AR also uses F85226FG, just I don't know which LDRQ# it uses, as I'm not seeing its boardview floating around.

https://theretroweb.com/motherboard/manual/ru … 89524497458.pdf
Pg 9. Confirmed.

No boardview, but the block diagram shows a TPM header on the LPC. Why not use that?

Seems odd to me that there are 3 devices on LPC but only 2x LDRQ's.
I was going to say figure out which one the 83627 UHG and TPM use and there's your answer, but it might not even have one or it's shared.

https://www.intel.com/content/dam/doc/datashe … 7-datasheet.pdf
Pg 62.

I was saying I'm not sure which exact LDRQ# that board uses for the ISA slot (behind F85226FG).

Normally LDRQ0# goes to SuperIO leaving LDRQ1# to be used by something else. Without boardview I cannot be sure if RUBY-9719VG2AR is really using LDRQ1#.

Right now I don't know if the bridge needs any configuration in order to know which bus master it is to the host so as to know which DMA message it should handle.

EDIT: I doubt RUBY-9719VG2AR ever touched the bridge after system startup... everything appears to be in its default values...

I opened the PCH heatsink again and took some pictures to compare with the boardview and can confirm I indeed soldered the wire to the right place... guess the only thing I could do is to get something that could at least tell me whether the Fintek bridge asserted LDRQ# when I test DMA channel...

PS: Apparently back then I ran HWINFO16 by mistake. The latest version of HWINFO indeed recognized my motherboard as well as the IRQ/DMA stuffs.

EDIT2: I just made LPCFCHK output pretty much all information I could get from the bridge... the output confirms my speculation. On both the test board with dISAppointment, and on RUBY-9719VG2AR, the bridge is in its default state. Everything is identical except GPIO states (which are read-only and perhaps change all the time).

Ruby definitely uses both LDRQs, one for SuperIO chip and one for ISA bridge. TPM connector has no LDRQ on it at all.

I just tested it with a breadboard and LED, but I'm not sure.

- Connected HDDLED+ (connects to +3V with a resistor in between) to the breadboard where LED+ is.
- Connected the LDRQ1# wire to the breadboard where LED- is, and through another wire to dISAppointment.

When I turned the system on, the LED lit for a brief while then off. Does this indicate a proper connection of LDRQ1# to the adapter?

After setting everything up as usual, I looked at the LED carefully when I started testing DMA channel, but nothing happened. The LED never ever lit during the process...

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

I just tested it with a breadboard and LED, but I'm not sure. […]
Show full quote

I just tested it with a breadboard and LED, but I'm not sure.

- Connected HDDLED+ (connects to +3V with a resistor in between) to the breadboard where LED+ is.
- Connected the LDRQ1# wire to the breadboard where LED- is, and through another wire to dISAppointment.

When I turned the system on, the LED lit for a brief while then off. Does this indicate a proper connection of LDRQ1# to the adapter?

After setting everything up as usual, I looked at the LED carefully when I started testing DMA channel, but nothing happened. The LED never ever lit during the process...

To be honest, given that it's a 33MHz bus I wouldn't really expect to see anything as the flashes would be so short.

Really you need a scope for this kind of thing

rasteri wrote on 2024-04-06, 16:34:

To be honest, given that it's a 33MHz bus I wouldn't really expect to see anything as the flashes would be so short.

Really you need a scope for this kind of thing

Perhaps... guess I'll have to rely on something really complex to look into this one.

The board has neither LPT nor floppy, so LDRQ# signals were never used at all in this board's case, despite wired/exposed in some ways. I think very few board vendors actually bothered using LDRQ# (be it 0 or 1)... so I'm really on my own...

On the other hand, I'm not sure if SERR# generation is required for LDRQ# to work... from what I could find about my board, the option switch for SERR# is hidden behind an even-more-advanced BIOS menu, but ASRock did an excellent job in preventing people from actually modding the BIOS, as while it's possible to use UBU to strip the security check (so Instant Flash will accept it), any actual modification to the BIOS content would make the board unable to boot, such as stuck at 94h and in some cases shuts itself down after a few seconds... Only vanilla BIOS can boot correctly.

LATE EDIT: I eventually managed to unlock the hidden Advanced menu via UEFI-Editor with the help of old and new UEFITool versions, while keeping the resulted BIOS bootable. However, I was not successful in other modifications... perhaps the tools available for modding Aptio BIOS right now are still imperfect, or that Aptio images are simply too delicate to be touched...