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

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.

Awesome! Is there any reason to include a 32-bit version at all if the 16-bit version works?

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.

Just looking at what's cheap on ebay, the Asrock B450M has a TPM header without LDRQ, but there is a boardview available that shows LDRQ is routed to the super IO chip (NCT6779). Should be possible to mod.

LSS10999 wrote on 2023-04-01, 18:13:

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

hey actually, you could perhaps bodge an LPC connection by just soldering some wires directly to the CPU pins before it goes into the socket. This might be easier than digging them out of the superIO and will guarantee acess to LDRQ...

LDRQ is indeed one of the pins on socket AM4 processors...

EDIT : unfortunately gone by socket AM5

rasteri wrote on 2023-04-02, 11:58:

Awesome! Is there any reason to include a 32-bit version at all if the 16-bit version works?

I'm keeping the 32-bit version as it was done and tested first, since only the 32-bit compiler natively supports _inpd and _outpd.

Should point out that printf behaves very differently between the 16-bit and 32-bit compilers, which caused some values to be printed incorrectly in the 16-bit version (the I/O operations themselves were correct).

It took me a while to fix everything I could find and test. At this point the 16-bit version should work just like the 32-bit one.

rasteri wrote on 2023-04-02, 11:58:

Just looking at what's cheap on ebay, the Asrock B450M has a TPM header without LDRQ, but there is a boardview available that shows LDRQ is routed to the super IO chip (NCT6779). Should be possible to mod.

rasteri wrote on 2023-04-02, 15:39:

hey actually, you could perhaps bodge an LPC connection by just soldering some wires directly to the CPU pins before it goes into the socket. This might be easier than digging them out of the superIO and will guarantee acess to LDRQ...

LDRQ is indeed one of the pins on socket AM4 processors...

EDIT : unfortunately gone by socket AM5

Just looked at the socket information at WikiChip and can confirm there is one LDRQ# signal on AM4 and SP3 (as well as TR4, sTRX4, sWRX8). The signal is indeed not mentioned on AM5 and SP5, so that's the end of the line...

EDIT: I don't think it's possible to solder wires directly to the AM4 CPU pins as you won't be able to insert it afterwards.

I wonder if it's possible to make a socket adapter for at least AM4 similar to that of the Lin-Lin (for S370) to bring at least the LDRQ# out.

LSS10999 wrote on 2023-04-02, 17:03:

EDIT: I don't think it's possible to solder wires directly to the AM4 CPU pins as you won't be able to insert it afterwards.

I wonder if it's possible to make a socket adapter for at least AM4 similar to that of the Lin-Lin (for S370) to bring at least the LDRQ# out.

Do you think even 0.1mm or 0.2mm enamel-coated wire would be too thick to stop the CPU engaging with the socket? I don't have any AM4 computers so I don't have a good reference.

Modern processors have some extremely high frequencies coming out of the pins, I fear an interposer would introduce signal integrity issues.

rasteri wrote on 2023-04-02, 17:22:

LSS10999 wrote on 2023-04-02, 17:03:

EDIT: I don't think it's possible to solder wires directly to the AM4 CPU pins as you won't be able to insert it afterwards.

I wonder if it's possible to make a socket adapter for at least AM4 similar to that of the Lin-Lin (for S370) to bring at least the LDRQ# out.

Do you think even 0.1mm or 0.2mm enamel-coated wire would be too thick to stop the CPU engaging with the socket? I don't have any AM4 computers so I don't have a good reference.

Modern processors have some extremely high frequencies coming out of the pins, I fear an interposer would introduce signal integrity issues.

It might be possible to create a board in between the CPU and the motherboard that all it does is route out the desired pins(s) to somewhere more accessible by using an intermediary socket; Ofcourse it couldn't be too large nor could it be too far from the CPU lest interference and the inability to mount a CPU cooler without it breaking off may arise. There would then be problems of getting a hold of sockets and pins to create such a board, and as you said "interference".
This could be somewhat easier to do on AMD's Threadripper sockets in some ways due to them using a screw and plate mount design to hold the CPU in, thus allowing someone to use standoffs and/or slightly longer screws with a custom bracket to hold the adapter board in.

Edit: Largest problem with this idea is it would require more time and effort than it's probably worth, especially considering it likely wouldn't work due to interference.

Happyarch wrote on 2023-04-02, 20:21:

It might be possible to create a board in between the CPU and the motherboard that all it does is route out the desired pins(s) […]
Show full quote

rasteri wrote on 2023-04-02, 17:22:

LSS10999 wrote on 2023-04-02, 17:03:

EDIT: I don't think it's possible to solder wires directly to the AM4 CPU pins as you won't be able to insert it afterwards.

I wonder if it's possible to make a socket adapter for at least AM4 similar to that of the Lin-Lin (for S370) to bring at least the LDRQ# out.

Do you think even 0.1mm or 0.2mm enamel-coated wire would be too thick to stop the CPU engaging with the socket? I don't have any AM4 computers so I don't have a good reference.

Modern processors have some extremely high frequencies coming out of the pins, I fear an interposer would introduce signal integrity issues.

It might be possible to create a board in between the CPU and the motherboard that all it does is route out the desired pins(s) to somewhere more accessible by using an intermediary socket; Ofcourse it couldn't be too large nor could it be too far from the CPU lest interference and the inability to mount a CPU cooler without it breaking off may arise. There would then be problems of getting a hold of sockets and pins to create such a board, and as you said "interference".
This could be somewhat easier to do on AMD's Threadripper sockets in some ways due to them using a screw and plate mount design to hold the CPU in, thus allowing someone to use standoffs and/or slightly longer screws with a custom bracket to hold the adapter board in.

Edit: Largest problem with this idea is it would require more time and effort than it's probably worth, especially considering it likely wouldn't work due to interference.

If a board's boardview suggests the LDRQ# being routed to SuperIO then it's better off taking it from there (there's only one LDRQ# to use anyway). I don't think there are many boards of those chipsets actually providing stuffs that need DMA (FDC or ECP parallel ports) out of the SuperIO so it's usually safe to do so.

With recent boards, it is entirely possible for a board to not have a SuperIO at all, so the board won't even provide connections such as PS/2. On server boards, COM port is usually provided by a BMC so a dedicated SuperIO is not really a requirement, and BMC offers more options for out-of-band server management.

Happyarch wrote on 2023-04-02, 20:21:

It might be possible to create a board in between the CPU and the motherboard that all it does is route out the desired pins(s) to somewhere more accessible by using an intermediary socket; Ofcourse it couldn't be too large nor could it be too far from the CPU lest interference and the inability to mount a CPU cooler without it breaking off may arise. There would then be problems of getting a hold of sockets and pins to create such a board, and as you said "interference".
This could be somewhat easier to do on AMD's Threadripper sockets in some ways due to them using a screw and plate mount design to hold the CPU in, thus allowing someone to use standoffs and/or slightly longer screws with a custom bracket to hold the adapter board in.

One idea might be to use flat-flex PCBs - if the holes for the pins were small enough and through-hole plated they might be tight enough to make contact with the pins while still allowing the chip to mate with the socket.

LSS10999 wrote on 2023-03-24, 01:36:

Still, I wonder if it's possible to probe the LPC controller from Linux (though the controller itself is visible in /sys/devices). I've been looking for tools that could hopefully help me look into the controller but they've so far yielded no usable results... guess I still have to access it from DOS.

If you are talking about changing the values on the LPC controller on the southbridge you can use setpci from the PCI utils package
https://linux.die.net/man/8/setpci

To change the values on the lpc to isa bridge you can use the ioport package
https://manpages.debian.org/testing/ioport/outl.1.en.html

Lots of testing can be done straight from the command line this way.
(Hope this helps.)

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.

The datasheet of the F85226 states "The F85226 implemented full functions that described in the LPC I/F 1.1 specification and transfers all subtractive cycles from LPC bus to ISA interface for more ISA compatibility." which, according to the definition of "subtractive decoding" I've seen means: "if nobody else wants it, it must be for me."
So, the way I read it, everything that reaches the LPC bus is transferred to the ISA slots. The address decoders seem to only give you the ability of masking the addresses, which may need to be used for some devices (not that I can imagine which ones though).

Yes I guess so. If IO filter is default to 0, then disabled, all passed through (only that intel master bridge pass to LPC)...

I investigated LDRQ routing on my spare Gigabyte GA-P67A-D3-B3 MB. PCH P67 offers 2 signals LDRQ0 and LDRQ1. The LDRQ0 i routed to superIO chip ITE IT8728F and can be utilized only for LPT in ECP mode (floppy not used). The LDRQ1 is unused but fortunately routed to unpopulated R326 pull-up near the PCH and it's easy accessible to solder a wire. TPM pin 20, as I already mentioned, is routed to PCH signal SUSCLK via jumper R264. But closer look revealed that R264 is not a physical 0R resistor body but it's just a copper trace between 2 pads (small size 0402 or 0201). It would be need to be carefully cut in between. Trace from pin 20 to R264 pad is hidden somewhere in inner layer o below plastic fence of the header so I cannot cut it directly from the pin. But it's doable...

RayeR wrote on 2023-04-05, 00:07:

I investigated LDRQ routing on my spare Gigabyte GA-P67A-D3-B3 MB. PCH P67 offers 2 signals LDRQ0 and LDRQ1. The LDRQ0 i routed to superIO chip ITE IT8728F and can be utilized only for LPT in ECP mode (floppy not used). The LDRQ1 is unused but fortunately routed to unpopulated R326 pull-up near the PCH and it's easy accessible to solder a wire. TPM pin 20, as I already mentioned, is routed to PCH signal SUSCLK via jumper R264. But closer look revealed that R264 is not a physical 0R resistor body but it's just a copper trace between 2 pads (small size 0402 or 0201). It would be need to be carefully cut in between. Trace from pin 20 to R264 pad is hidden somewhere in inner layer o below plastic fence of the header so I cannot cut it directly from the pin. But it's doable...

Yeah my motherboard has a similar arrangement - I had the same idea about rewiring pin 20, I didn't realise that the resistor had been replaced by a trace though....

I had a look at my Asus P5Q, which has a TPM header without any LDRQ#. So, I looked for it.
The southbridge is a ICH10 and the LDRQ pins are respectively L6 and J3.

Fortunately, I have the boardview file.
LDRQ0# connects directly to the super io and there's no way I will consider lifting the trace as I want to continue to be able to use the Floppy drive.
So, I would need to use LDRQ1#

It looks like Asus, in its very clever "assness" decided to use the pin as a general GPIO to control something in one of the RAID controllers.
I guess I could still try to reconfigure the pin back to LDRQ1#, connect a wire to that resistor and hope for the best...
I don't really care about getting the RAID controller confused as I don't use it anyway so this would probably work.

The TPM connector is a convenient way to access the LPC bus but, it has proven not to be a universal solution.
So, now that we have started talking about soldering wires, going through datasheets, etc why not lift up the game a bit?
The LPC bus does not live only in the TPM connector. It is, actually, very common elsewhere.
Here is my idea:

This a block diagram of my MSI K7N2 delta aka 16570-10A, a socket 462 motherboard which has only 1 agp and 5 pci slots. (No ISA.)
It shows that the flash is a LPC device...

...which has all the required signals expect LDRQ.

This can be tapped with an adapter like this (or similar.) You remove the chip from the socket and insert this adaptor in it.
Then, there will be a small PCB on the top side of the adaptor where you can put the flash rom back on another socket and have pins ready to connect to the dISAppointment.

So, where are the LDRQs? LDRQ0# connects to the super io and ldrq1# only to the R399 pull up resistor. This would be the only soldering required.

I missed SERIRQ above, but it is also available on the board on R264, ready for soldering.

Yes, MBs mostly from P4 era used specific flash chip called FWH (FirmWare Hub), that was directly connected to LPC (later replaced by SPI flash). If such old MB doesn't have TPM, it would be a way how to access LPC but still wiring is needed for IRQ and DMA. But who would like to use such system? I still think that P4 was the worst CPU intel ever produced and if one can add ISA to newer, much better platform (C2D, Nehalem, Sandy...) why bother with such old crap...

In your case it would be probaly OK to disconnect LDRQ1 from RAID circuit as not needed. Reconfiguring pin from GPIO to LDRQ should be also possible via some internal registers, check the ICH10 datasheet...

EduBat wrote on 2023-04-05, 22:26:

The TPM connector is a convenient way to access the LPC bus but, it has proven not to be a universal solution. So, now that we […]
Show full quote

The TPM connector is a convenient way to access the LPC bus but, it has proven not to be a universal solution.
So, now that we have started talking about soldering wires, going through datasheets, etc why not lift up the game a bit?
The LPC bus does not live only in the TPM connector. It is, actually, very common elsewhere.
Here is my idea:
Soruth Bridge.png
This a block diagram of my MSI K7N2 delta aka 16570-10A, a socket 462 motherboard which has only 1 agp and 5 pci slots. (No ISA.)
It shows that the flash is a LPC device...
flash.png
...which has all the required signals expect LDRQ.
flash chip.png
This can be tapped with an adapter like this (or similar.) You remove the chip from the socket and insert this adaptor in it.
Then, there will be a small PCB on the top side of the adaptor where you can put the flash rom back on another socket and have pins ready to connect to the dISAppointment.
adaptor.png
So, where are the LDRQs? LDRQ0# connects to the super io and ldrq1# only to the R399 pull up resistor. This would be the only soldering required.
r399.png

I wonder if there are any good documentations on the nForce family chipsets, like where its LPC bridge resides and what kind of registers it has (that needs to be configured). I've googled about nForce (MCP) datasheets but found nothing useful. While it may not be difficult to locate the LPC controller, without any information about the registers (namely address decoders) it would be very difficult to figure out how to configure the controller.

Generally speaking, for AMD processors of that era (K7/K8) nForce is among the least retro-friendly ones, despite having better features/performance in some aspects. If you have a board with VIA chipset you don't really need dISAppointment as VIA has better support for using PCI sound cards with DOS.

I don't kdow about AMD but intel support is quite good, there are free datasheets of chipsets and processors. Yes, some critical infobis only under NDA only but still enouhg. Some year ago I just wanted to look at pinout of new AM socket but didn't find any cpu datasheet on AMD site so gave up, do they provide all techdoc only under NDA?

RayeR wrote on 2023-04-06, 11:46:

I don't kdow about AMD but intel support is quite good, there are free datasheets of chipsets and processors. Yes, some critical infobis only under NDA only but still enouhg. Some year ago I just wanted to look at pinout of new AM socket but didn't find any cpu datasheet on AMD site so gave up, do they provide all techdoc only under NDA?

wikichip has some, they look official too (include assembly notes etc)

https://en.wikichip.org/wiki/amd/packages/socket_am4

https://en.wikichip.org/wiki/amd/packages/socket_am5

There's no pin map for AM5 and Pin Description seems to be incomplete, no pin numbers. I don§t understand why AMD turned from open documentation to keep all secret.