weedeewee wrote on 2023-03-30, 06:19:

I remember asking this in another thread...

Has anyone who is playing around with these investigated whether any of the other address decoders ( RTC MC KBC ) can be re purposed to allow a few more port ranges ?

I wrote about the address decoders a few hours ago. Actually, programming the decoders on the Fintek bridge turned out to be unnecessary.

Programming the decoder ranges on the LPC controller is all you need. Sadly Intel's LPC controller doesn't offer more decoding options.

LSS10999 wrote on 2023-03-30, 03:22:

Recently I've been experimenting with the F85226 bridge on my RUBY-9719VG2AR and I noticed something. It appears I don't really have to program the generic address decoders (ADDR1-ADDR4) on the Fintek bridge side. I tweaked the program and purposedly omitted the code for programming the address decoders so that only the decoders on the Intel LPC controller gets programmed (all the address decoders on the Fintek bridge remain default, which is 0000H for the generic ones), yet my Sound Blaster 16 (with a MIDI daughterboard) can still be detected and initialized by UNISOUND and I get proper audio in games. I wonder what exactly the generic address decoders on the Fintek bridge were meant for.

RayeR wrote on 2023-03-29, 17:16:

Good work. what LDRQ did you steal? 0 or 1?
BTW need a schematic? This web is quite rich of GB leaked docs 😀

Yeah I used LDRQ1, as it wasn't wired to anything except a pullup resistor, just like on your board. Multiple LDRQ devices shouldn't be wired to the same pin as they're usually driven push-pull rather than being any kind of open-drain type arrangement. And I already had the schematic and boardview 😀

Also it would be good idea to test how long the LPC wires from TPM could be. I guess it's not designed to go out far from MB so it wouldn't like expose to noisy environment, crsosstalk and excessive capacitive load on the LPC bus (weak PCH line drivers). No idea how to detect errors on LPC and how system will behave when it happens, I would expect some random hangs...

Not sure. I'm using super long wires on the gigabyte and it seems to work (although oddly with Quake I get some really nasty distorted audio, I'll test it again on my other motherboard).

LSS10999 wrote on 2023-03-30, 03:22:

Recently I've been experimenting with the F85226 bridge on my RUBY-9719VG2AR and I noticed something. It appears I don't really have to program the generic address decoders (ADDR1-ADDR4) on the Fintek bridge side. I tweaked the program and purposedly omitted the code for programming the address decoders so that only the decoders on the Intel LPC controller gets programmed (all the address decoders on the Fintek bridge remain default, which is 0000H for the generic ones), yet my Sound Blaster 16 (with a MIDI daughterboard) can still be detected and initialized by UNISOUND and I get proper audio in games. I wonder what exactly the generic address decoders on the Fintek bridge were meant for.

Are you sure the decoders are actually zero? Maybe the Ruby's bios sets them to a different value.

rasteri wrote on 2023-03-30, 10:05:

LSS10999 wrote on 2023-03-30, 03:22:

Recently I've been experimenting with the F85226 bridge on my RUBY-9719VG2AR and I noticed something. It appears I don't really have to program the generic address decoders (ADDR1-ADDR4) on the Fintek bridge side. I tweaked the program and purposedly omitted the code for programming the address decoders so that only the decoders on the Intel LPC controller gets programmed (all the address decoders on the Fintek bridge remain default, which is 0000H for the generic ones), yet my Sound Blaster 16 (with a MIDI daughterboard) can still be detected and initialized by UNISOUND and I get proper audio in games. I wonder what exactly the generic address decoders on the Fintek bridge were meant for.

Are you sure the decoders are actually zero? Maybe the Ruby's bios sets them to a different value.

Yes. I printed out the F85226 decoder registers and they were indeed all zero for ADDR1-ADDR4.

Some other decoders (KB, MC, RTC, IOH) have default values. It seems whatever values set on those 8 decoders (ADDR1-4, KB, MC, RTC, IOH) on the Fintek bridge do not really matter. Only the values set on the Intel LPC controller matter.

LSS10999 wrote on 2023-03-30, 11:25:

Some other decoders (KB, MC, RTC, IOH) have default values. It seems whatever values set on those 8 decoders (ADDR1-4, KB, MC, RTC, IOH) on the Fintek bridge do not really matter. Only the values set on the Intel LPC controller matter.

Maybe the address decoders are just to lock it down to specific ranges, but by default it'll just pass everything through? I'll hook a logic analyzer up at some point and see exactly what's being forwarded

Hi rasteri,

It is a very interesting project. But what about making something similar for PCMCIA 16-bit slot? There are plenty of old laptops and palmtops that lack ISA or PCI slots but have PCMCIA slot.

doesnt pcmcia lack dma?

Is it possible to test the LDRQ with any software?
According to the boardview my Asrock X99 Extreme4/3.1 has the LDRQ#0 connected to the X99 chipset PCH and also the Super I/O chip: NUVOTON NCT6791D
But I'm not sure if there is a connection between them, obviously soldering a wire to the Super I/O chip is easy, but the PCH is a BGA chip so that is out of the question...
So I'd like to measure the Super I/O chip with a multimeter and then pulse the LDRQ#0 line to see if it works before soldering a wire there...

Per Hansson wrote on 2023-03-31, 17:36:

Is it possible to test the LDRQ with any software? According to the boardview my Asrock X99 Extreme4/3.1 has the LDRQ#0 connecte […]
Show full quote

Is it possible to test the LDRQ with any software?
According to the boardview my Asrock X99 Extreme4/3.1 has the LDRQ#0 connected to the X99 chipset PCH and also the Super I/O chip: NUVOTON NCT6791D
But I'm not sure if there is a connection between them, obviously soldering a wire to the Super I/O chip is easy, but the PCH is a BGA chip so that is out of the question...
So I'd like to measure the Super I/O chip with a multimeter and then pulse the LDRQ#0 line to see if it works before soldering a wire there...

LDRQ is an input on the PCH so the only way to make it pulse would be to generate an interrupt from the super IO chip. You'd need to write a program to poke at the Super IO's registers.

But If the boardview says that LDRQ is connected to the PCH and the Super IO chip why wouldn't you believe it?

Note that if you wanna use that LDRQ you'll have to disconnect it from super IO (by lifting a super IO pin) as multiple devices can't share one LDRQ line. Super IO only really needs DMA for stuff like floppy drive and parallel port so you probably don't need it

rasteri wrote on 2023-03-31, 17:43:

LDRQ is an input on the PCH so the only way to make it pulse would be to generate an interrupt from the super IO chip. You'd need to write a program to poke at the Super IO's registers.

I see, so no such software exists?

rasteri wrote on 2023-03-31, 17:43:

But If the boardview says that LDRQ is connected to the PCH and the Super IO chip why wouldn't you believe it?

The boardview does not show the traces, so it could be not connected at all for all I know...

rasteri wrote on 2023-03-31, 17:43:

Note that if you wanna use that LDRQ you'll have to disconnect it from super IO (by lifting a super IO pin) as multiple devices can't share one LDRQ line. Super IO only really needs DMA for stuff like floppy drive and parallel port so you probably don't need it

I still haven't got close enough but I can't see any trace from the Super I/O chip, so it might just not be routed then... 🙁

Per Hansson wrote on 2023-03-31, 18:01:

The boardview does not show the traces, so it could be not connected at all for all I know...

If the net names between the pads are exactly the same then they're almost certainly connected.

I still haven't got close enough but I can't see any trace from the Super I/O chip, so it might just not be routed then... 🙁

The trace could be going under the chip. I think there's a better than even chance that LDRQ really is routed to the PCH.

rasteri wrote on 2023-03-31, 17:43:

LDRQ is an input on the PCH so the only way to make it pulse would be to generate an interrupt from the super IO chip. You'd nee […]
Show full quote

Per Hansson wrote on 2023-03-31, 17:36:

Is it possible to test the LDRQ with any software? According to the boardview my Asrock X99 Extreme4/3.1 has the LDRQ#0 connecte […]
Show full quote

Is it possible to test the LDRQ with any software?
According to the boardview my Asrock X99 Extreme4/3.1 has the LDRQ#0 connected to the X99 chipset PCH and also the Super I/O chip: NUVOTON NCT6791D
But I'm not sure if there is a connection between them, obviously soldering a wire to the Super I/O chip is easy, but the PCH is a BGA chip so that is out of the question...
So I'd like to measure the Super I/O chip with a multimeter and then pulse the LDRQ#0 line to see if it works before soldering a wire there...

LDRQ is an input on the PCH so the only way to make it pulse would be to generate an interrupt from the super IO chip. You'd need to write a program to poke at the Super IO's registers.

But If the boardview says that LDRQ is connected to the PCH and the Super IO chip why wouldn't you believe it?

Note that if you wanna use that LDRQ you'll have to disconnect it from super IO (by lifting a super IO pin) as multiple devices can't share one LDRQ line. Super IO only really needs DMA for stuff like floppy drive and parallel port so you probably don't need it

The biggest problem being that the Super I/O chips by certain manufacturers(especially the ones made by ITE Inc), don't have their datasheets or pinouts online for some reason. So finding that pin could be difficult, not impossible, but certainly not easy.

Happyarch wrote on 2023-03-31, 18:33:

The biggest problem being that the Super I/O chips by certain manufacturers(especially the ones made by ITE Inc), don't have their datasheets or pinouts online for some reason. So finding that pin could be difficult, not impossible, but certainly not easy.

True. But the boardview and/or schematic should specify pinouts -and failing that, devices in the IT range have similar pinouts so if you can find a similar device's pinout that might help

Also beware that Gigabyte and afaik Asus use shifted pinout of superIO that doesn'r match the generic datasheet! Winbond/ITE produce special versions for this MB manufacturers. I was pretty wondered when doing my 1st PS/2 hack and found the pinout doesn't match. So better is to get motherboard schematic and look there, if avail...

> LSS10999
The IO decoders are chained, search for subtractive decoding. First the intel bridge need to be configured specific IO range from host to LPC, similar to PCIe to PCI bridge. Then Fintek may do further filtering what IO pass from LPC to ISA but if default setting is wide enough it may be not needed to be changed. But without proper config of intel bridge, which is master, you don't get anything...

>Rasteri
Can you be more specific about your super long wires? I think I would need about 10cm to get from TPM to slot placed at bottom of case on the left side. I woldn't rather exceed 20cm or so. Maybe ground wires between signal wires would help to reduce crosstalk...

RayeR wrote on 2023-03-31, 23:59:

> LSS10999
The IO decoders are chained, search for subtractive decoding. First the intel bridge need to be configured specific IO range from host to LPC, similar to PCIe to PCI bridge. Then Fintek may do further filtering what IO pass from LPC to ISA but if default setting is wide enough it may be not needed to be changed. But without proper config of intel bridge, which is master, you don't get anything...

The default settings for the four generic decoders were all zero. Other decodes (KBC/MC/RTC/IOH) were set to default.

1ADDR1 range: 0, mask: 0
2ADDR2 range: 0, mask: 0
3ADDR3 range: 0, mask: 0
4ADDR4 range: 0, mask: 0
5KBC range: 60, mask: 4
6MC range: 62, mask: 4
7RTC range: 70, mask: 1
8IOH range: 0, mask: FF

My Sound Blaster 16 with the MIDI daughterboard works fine, even without touching those decoders at all.

On the other hand, here are some configuration parameters RUBY-9719VG2AR set by default for Intel's LPC controller.

1LPC I/O Decode Range Config: 340D0000
2LPC Generic Decode Range 0 Config: 00FC0A01
3LPC Generic Decode Range 1 Config: 007C0281
4LPC Generic Decode Range 2 Config: 000C03E1
5LPC Generic Decode Range 3 Config: 001C04E1

So the default ranges were: A00-AFF, 280-2FF, 3E0-3EF, 4E0-4FF, which probably covers a good amount of industrial appliances.

PS: I suspect by modifying the decoder ranges to the way we use for sound cards... we may have broken the functionality of COM3 which usually resides in 3E8.

RayeR wrote on 2023-03-31, 23:59:

Also beware that Gigabyte and afaik Asus use shifted pinout of superIO that doesn'r match the generic datasheet! Winbond/ITE pro […]
Show full quote

Also beware that Gigabyte and afaik Asus use shifted pinout of superIO that doesn'r match the generic datasheet! Winbond/ITE produce special versions for this MB manufacturers. I was pretty wondered when doing my 1st PS/2 hack and found the pinout doesn't match. So better is to get motherboard schematic and look there, if avail...

> LSS10999
The IO decoders are chained, search for subtractive decoding. First the intel bridge need to be configured specific IO range from host to LPC, similar to PCIe to PCI bridge. Then Fintek may do further filtering what IO pass from LPC to ISA but if default setting is wide enough it may be not needed to be changed. But without proper config of intel bridge, which is master, you don't get anything...

>Rasteri
Can you be more specific about your super long wires? I think I would need about 10cm to get from TPM to slot placed at bottom of case on the left side. I woldn't rather exceed 20cm or so. Maybe ground wires between signal wires would help to reduce crosstalk...

Yeah, I noticed Asus and Gigabyte are imparticularly bad for this. I'm not terribly good at finding chip pin-outs anyway; so I have to wonder the difficulty to find the pins we need on chips with around 128 pins or more.
Mighten it be possible to guess parts of it, based on known pin-outs from other chips they are connected to, and/or the silkscreen markings? ¯\_(ツ)_/¯

rasteri wrote on 2023-03-28, 10:57:

RayeR wrote on 2023-03-28, 02:14:

LSS10999 wrote on 2023-03-26, 12:43:

By the way, it seems the executable I built with DJGPP (actually cross-compiled from Linux) doesn't run when JEMM386 is active. It outright pagefaults. Running in real mode (without JEMM386)

Hm, this must be some specific linux crosscompiler issue as I normally use DJGPP for my tools (native under DOS) and all runs fine under EMM/JEMM/QEMM386 as well as only himem and bare RM...

I have the version built directly from DOS here : https://github.com/rasteri/dISAppointment/blo … re/SAPPHISA.EXE - maybe that'll work better for @LSS10999 ?

I've refactored the reference configuration program here. Considering the issues I'm having with executables built with DJGPP, I'm now targeting Open Watcom 2.0.

https://github.com/lss4/lpcexp

Compiling it in 32-bit requires DOS4G(W) or DOS32A to run, though it works with JEMM386 loaded (in DOS32A's case, using the version from FreeDOS), without page fault. It's also possible to compile it in 16-bit, just that I have to write my own _outpd and _inpd routines as these are only available in 32-bit, and printf behaves differently from 32-bit that some changes in the formatting are required to make sure it outputs correctly in both 16-bit and 32-bit.

I've also included some code meant for AMD chipsets based on what I got from reading the register reference guides. Since I don't have a LPC-ISA bridge, I only tested the AMD LPC controller part. That part works on my X570 system, and I'm able to read and configure the registers for experiment.

It seems AMD's LPC controller is a little bit superior for this use case. It has a dedicated decode range register for many common appliances including sound cards, and three wide I/O range (512 bytes) decoders, which allows forwarding more stuffs than Intel's, that it might be easier to get WSS or AWE32/64 working there.

Don't know if there are any good AMD motherboards that could be ideal candidates for experimenting, with a compatible TPM header and also schematic for hints about how LDRQ# should be wired.

LSS10999 wrote on 2023-04-01, 14:38:

I've refactored the reference configuration program here. Considering the issues I'm having with executables built with DJGPP, I […]
Show full quote

rasteri wrote on 2023-03-28, 10:57:

RayeR wrote on 2023-03-28, 02:14:

Hm, this must be some specific linux crosscompiler issue as I normally use DJGPP for my tools (native under DOS) and all runs fine under EMM/JEMM/QEMM386 as well as only himem and bare RM...

I have the version built directly from DOS here : https://github.com/rasteri/dISAppointment/blo … re/SAPPHISA.EXE - maybe that'll work better for @LSS10999 ?

I've refactored the reference configuration program here. Considering the issues I'm having with executables built with DJGPP, I'm now targeting Open Watcom 2.0.

https://github.com/lss4/lpcexp

Compiling it in 32-bit requires DOS4G(W) or DOS32A to run, though it works with JEMM386 loaded (in DOS32A's case, using the version from FreeDOS), without page fault. It's also possible to compile it in 16-bit, just that I have to write my own _outpd and _inpd routines as these are only available in 32-bit, and printf behaves differently from 32-bit that some changes in the formatting are required to make sure it outputs correctly in both 16-bit and 32-bit.

I've also included some code meant for AMD chipsets based on what I got from reading the register reference guides. Since I don't have a LPC-ISA bridge, I only tested the AMD LPC controller part. That part works on my X570 system, and I'm able to read and configure the registers for experiment.

It seems AMD's LPC controller is a little bit superior for this use case. It has a dedicated decode range register for many common appliances including sound cards, and three wide I/O range (512 bytes) decoders, which allows forwarding more stuffs than Intel's, that it might be easier to get WSS or AWE32/64 working there.

Don't know if there are any good AMD motherboards that could be ideal candidates for experimenting, with a compatible TPM header and also schematic for hints about how LDRQ# should be wired.

Super Micro boards in my experience would be good candidates, they tend to have 20 pin TPM headers, although I should mention that on their more recent boards LDRQ# isn't labled, and instead there are pins labled as 'NC'; Now how true that actually is I've yet to see. For reference the pin-out listed here below in the image is for the header on the Super Micro M12SWA-TF. I suspect, although I could be wrong that some of those pins may be connected anyway.
Edit: I should mention while that board is AMD it's not x570, but rather a WRX80 board. I don't know if Super Micro makes any x570 boards, I'd have to check.

Happyarch wrote on 2023-04-01, 16:37:

LSS10999 wrote on 2023-04-01, 14:38:

I've refactored the reference configuration program here. Considering the issues I'm having with executables built with DJGPP, I […]
Show full quote

rasteri wrote on 2023-03-28, 10:57:

I have the version built directly from DOS here : https://github.com/rasteri/dISAppointment/blo … re/SAPPHISA.EXE - maybe that'll work better for @LSS10999 ?

I've refactored the reference configuration program here. Considering the issues I'm having with executables built with DJGPP, I'm now targeting Open Watcom 2.0.

https://github.com/lss4/lpcexp

Compiling it in 32-bit requires DOS4G(W) or DOS32A to run, though it works with JEMM386 loaded (in DOS32A's case, using the version from FreeDOS), without page fault. It's also possible to compile it in 16-bit, just that I have to write my own _outpd and _inpd routines as these are only available in 32-bit, and printf behaves differently from 32-bit that some changes in the formatting are required to make sure it outputs correctly in both 16-bit and 32-bit.

I've also included some code meant for AMD chipsets based on what I got from reading the register reference guides. Since I don't have a LPC-ISA bridge, I only tested the AMD LPC controller part. That part works on my X570 system, and I'm able to read and configure the registers for experiment.

It seems AMD's LPC controller is a little bit superior for this use case. It has a dedicated decode range register for many common appliances including sound cards, and three wide I/O range (512 bytes) decoders, which allows forwarding more stuffs than Intel's, that it might be easier to get WSS or AWE32/64 working there.

Don't know if there are any good AMD motherboards that could be ideal candidates for experimenting, with a compatible TPM header and also schematic for hints about how LDRQ# should be wired.

Super Micro boards in my experience would be good candidates, they tend to have 20 pin TPM headers, although I should mention that on their more recent boards LDRQ# isn't labled, and instead there are pins labled as 'NC'; Now how true that actually is I've yet to see. For reference the pin-out listed here below in the image is for the header on the Super Micro M12SWA-TF. I suspect, although I could be wrong that some of those pins may be connected anyway.
Edit: I should mention while that board is AMD it's not x570, but rather a WRX80 board. I don't know if Super Micro makes any x570 boards, I'd have to check.

The LPC controller resides in the CPU starting from Ryzen/EPYC. They all have the same vendor:device ID - 1022:790E.

From what I could find, some X370 boards may have 20-pin TPM headers. Boards further than that (X470 and onwards) usually don't. They either have fewer pins, or even have switched to eSPI instead of LPC for TPM.

Of course, most if not all boards would label potential LDRQ# pins as NC. It's only a matter of whether there are traces for connections between the pin in question and the LPC controller's LDRQ#, if the signal really exists.

RayeR wrote on 2023-03-31, 23:59:

Can you be more specific about your super long wires? I think I would need about 10cm to get from TPM to slot placed at bottom of case on the left side. I woldn't rather exceed 20cm or so. Maybe ground wires between signal wires would help to reduce crosstalk...

I'm using a mixed bag of random female-to-female dupont wires, some are 10cm some 20cm... It really doesn't seem to be that crucial.

It's only a 33MHz signal and the edge rates don't look very fast on a scope.