I'm currently experimenting with an ASUS Prime B450M-A which I've found its boardview somewhere. The board's SuperIO (IT8655E) is a very small one that do not have LDRQ#, so it is left unused and could be accessed from an unpopulated pull-up resistor pad according to its boardview, which makes it easier to bring it out by soldering a dupont wire there. However, it seems the boardview I got doesn't 100% reflect the actual board, as it has mentions of some additional parts that do not really exist.

I built a dISAppointment myself a while ago, but as I just tested with this motherboard, it doesn't appear to be working... my initialization program couldn't detect the F85226FG bridge after setting up the necessary parameters (got FFFFFFFF so nothing was found)... I did make an inspection on the adapter with a magnifier to ensure everything's soldered properly before... though I cannot be 100% sure. I wonder if there is any easy way to test whether the bridge chip is indeed functioning...

I'm using a small DC-ATX module which is connected to the main PSU's PCIe 6-pin connector using a 6-pin to 5525 converter cable, with the PSON header shorted using a jumper cap. I can confirm it's indeed supplying power to the adapter according to the voltage readings with a multimeter. As for the connection between the adapter to the board's TPM header, I have to use 2.0mm to 2.54mm dupont wires since the board's TPM header is 2.0mm in width.

I connected all the respective lines to the dISAppointment according to the board's TPM header definition, which seems to have all the lines other than LDRQ#, but I'm not sure which lines are really being used by a TPM, as it is indeed possible for the board to not really connect certain lines if it's not required for the TPM to function.

NOTE: It seems TPM_PD# (pin 13 on the board's TPM header, which I think should be mapped to PWRDN# on the adapter) is marked as NC on the boardview. Not sure if it's really needed, but if it is, should I be connecting it to a +3.3V in this case?

LSS10999 wrote on 2023-05-03, 08:17:

I built a dISAppointment myself a while ago, but as I just tested with this motherboard, it doesn't appear to be working... my initialization program couldn't detect the F85226FG bridge after setting up the necessary parameters (got FFFFFFFF so nothing was found)... I did make an inspection on the adapter with a magnifier to ensure everything's soldered properly before... though I cannot be 100% sure. I wonder if there is any easy way to test whether the bridge chip is indeed functioning...

As far as I know you're the first to try with an AMD motherboard so would you have an intel one you could check it on first to make sure the chip is working?

NOTE: It seems TPM_PD# (pin 13 on the board's TPM header, which I think should be mapped to PWRDN# on the adapter) is marked as NC on the boardview. Not sure if it's really needed, but if it is, should I be connecting it to a +3.3V in this case?

LPCPD should be pulled HIGH, so maybe connect it to 3.3v via a 10k (or so) resistor.

rasteri wrote on 2023-05-03, 11:22:

As far as I know you're the first to try with an AMD motherboard so would you have an intel one you could check it on first to make sure the chip is working?

I do have Intel boards that have TPM header... though I don't have one that I could get a boardview of. If it's just checking whether the chip works the LDRQ# signal may not be necessary at this point... so maybe I'll try if I have some time.

rasteri wrote on 2023-05-03, 11:22:

LPCPD should be pulled HIGH, so maybe connect it to 3.3v via a 10k (or so) resistor.

The motherboard's TPM header has a few pins mapped to +3V, which is not used at the moment. I wonder if these are already pulled up (so just connecting it to that pin will do), or that I need to put a discrete resistor between the connection.

Don't know if the SuperIO chip has a similar pin that I could refer to for connecting LPCPD#. Unfortunately, I could not find a datasheet for it (IT8655E). It seems this chip (in some cases IT8665E) can be found in other ASUS' Ryzen boards as well... perhaps a custom one?

PS: Configuring the LPC bridge on AMD boards is the same as on Intel, by accessing 4Eh/4Fh, which is already enabled on this board, according to the register values I read before configuring the LPC host controller...

LSS10999 wrote on 2023-05-03, 13:37:

If it's just checking whether the chip works the LDRQ# signal may not be necessary at this point... so maybe I'll try if I have some time.

Exactly, we just need a go/no-go test on the disappointment. No need for DMA yet.

The motherboard's TPM header has a few pins mapped to +3V, which is not used at the moment. I wonder if these are already pulled up (so just connecting it to that pin will do), or that I need to put a discrete resistor between the connection.

Connecting it directly will probably be fine, but resistors can avoid nasty surprises if you get something wrong. Particularly as the 3.3v rail might be several tens of amps. I think next revision of disappointment will need polyfuses...

Don't know if the SuperIO chip has a similar pin that I could refer to for connecting LPCPD#. Unfortunately, I could not find a datasheet for it (IT8655E). It seems this chip (in some cases IT8665E) can be found in other ASUS' Ryzen boards as well... perhaps a custom one?

Doesn't your boardview have net names?

rasteri wrote on 2023-05-03, 16:31:

Doesn't your boardview have net names?

Yes, it does. Just that I need related documentation to be sure which pin is supposed to be connected to LPC_PD#.

rasteri wrote on 2023-05-03, 16:31:

Connecting it directly will probably be fine, but resistors can avoid nasty surprises if you get something wrong. Particularly as the 3.3v rail might be several tens of amps. I think next revision of disappointment will need polyfuses...

I checked the boardview again... It seems this particular board doesn't really use the LPC_PD# line at all. The CPU pin in question is wired directly to +3VSB via a resistor. Will take a look at the board to see if that resistor is really there...

Anyway... guess I still have a long way to go... will first take an Intel board I have to see if the adapter is really working. Shouldn't be too difficult as the board I'd be using has a standard 20-pin TPM header so no mappings needed.

I think that someone as DREAMBLASTER should start to making this and sell it.

Otherwise it would stay like nice dead on arrival great product.

ruthan wrote on 2023-05-07, 19:33:

I think that someone as DREAMBLASTER should start to making this and sell it.

Otherwise it would stay like nice dead on arrival great product.

The problem isn't dISAppointment itself. It's that a motherboard must be designed with such a use case (ISA slot via LPC-ISA bridge) in mind to be able to fully utilize it. So far RUBY-9719VG2AR is the only board I know that is designed this way, with fully functional ISA DMA.

TPM port is merely a well-known medium for exposing the LPC bus, and it was never meant to wire the LDRQ# line for obvious reasons, since a real TPM device does not need nor want that connection. Not to mention with recent chipsets, TPM modules have transitioned to eSPI so the LPC bus can no longer be as easily accessed as before.

Technically you can use this adapter with any motherboard, but you'll definitely need to look for a boardview to know where the board's LDRQ# is, and the process may be easy or difficult depending on the board's design.

myne wrote on 2023-04-26, 10:46:

I might just add another note. Out of curiosity I compared a B365 board and a Z370. The 1/2/300 series aren't meant to have LDRQ […]
Show full quote

I might just add another note. Out of curiosity I compared a B365 board and a Z370.
The 1/2/300 series aren't meant to have LDRQ.

But... maybe the humans at Intel are human, and don't so much delete features as... stop documenting/supporting them.

And maybe board designers are lazy, and don't update their pin definitions when the basic chipset design is more or less an iterative evolution of the same thing rather than a revolutionary design.

So, this is the B365 and Z370 chipset with the Superio nets.

IF the above assumptions about human laziness are correct, then LDRQ#0 may still exist on both of those chipsets as GPP_A7 and logically, the same chipset straps documented in the 9 series chipset could enable it. In the 9 series chipset LDRQ#1 is configurable as GPIO instead. It might be possible that LDRQ#0 is missing but LDRQ#1 still works, and could be configured instead. Would that work?

Does this mean anything to anyone?

I wonder if anyone has a MS-98L9 V2.0 (or its boardview) could check where did that board wire the LDRQ# on the F85226 to. If it eventually traces to a GPIO that used to be a LDRQ# then this assumption is probably correct...

Hello, eyeballing this thread for a while. Just curious about Z170 chipset motherboards, coz they tend to have LDRQ in their specs sometimes:
Supermicros (MBD-C7Z170-OCE for example) with LDRQ# on pin 20 of the JTPM header
Shuttle SZ170R8 also has LPC header PIN 14=LDRQ0

Not sure Supermicro and Shuttle just copy-paste their documentation between products.
I saw C7Z170-OCE board on local sales for 50 Eur and curious is it worth it as a base board for my "fastest processor with ISA" project.

PS: seems most Supermicros have pin 20 of their JTPM header on X8-X10 mobos as LDRQ or "reserved". X10SLM-F for example.

I've been checking if I still have any usable Intel system to test this thing on... unfortunately my other systems that came with 1:1 identical TPM slots could not POST anymore for some reasons.

Eventually I got my ASRock B85M-ITX booted. However, I have a problem: When I connect the dISAppointment to the board, the board won't POST. If I disconnect the cable between the TPM port and dISAppointment's TPM header, the board POSTs. I tried connecting it after the system has booted: It won't hang right away, but when I try to initialize the LPC controller, the system hung.

Fortunately this board's boardview can be found. I checked the boardview and it seems every pin are correctly mapped. However, while it does have LPC_PD#, it's connected to two unpopulated resistor pads, with one to +3V and the other to +3VSB. This again raised the question whether LPC_PD# is really needed, at least for real TPM devices it appears not (or maybe it's done on-board).

EDIT: I forgot... it seems LPC_PD# is also connected to another resistor leading to SUS_STAT#, which is populated. Need to check what SUS_STAT# is being used for. So LPC_PD# is indeed needed, and per the chipset's datasheet that pin is indeed meant for LPC_PD# use cases.

I wonder what might be causing the hang/POST issue, as the system would not POST as long as the cable between TPM and dISAppointment is connected, even if I don't really power on the dISAppointment (with the DC-ATX module not connected to any power source). Maybe it's also responsible for my other systems' inability to POST...

And another question: Do I need to connect at least one GNDs between the TPM port and dISAppointment? And do I also need to connect at least one +3V or +3VSB between them?

EDIT: Just checked the schematic... the header on the dISAppointment side doesn't wire any 3.3V...

LSS10999 wrote on 2023-05-13, 05:45:

And another question: Do I need to connect at least one GNDs between the TPM port and dISAppointment? And do I also need to connect at least one +3V or +3VSB between them?

Yeah you'll want at least one ground. No 3.3v is needed though - it gets all the power it needs from the ATX connector.

rasteri wrote on 2023-05-14, 04:32:

Yeah you'll want at least one ground. No 3.3v is needed though - it gets all the power it needs from the ATX connector.

Tried this on my Prime B450M-A again, this time connected dISAppointment's PWRDN# to one of the motherboard TPM header's +3V with a 10k resistor in between. Still no avail. Most likely my unit isn't working. At least this board always boots unlike my Intel ones which would not boot as long as it's connected (whether dISAppointment itself is powered or not does not matter).

I wonder if the BIOS option of whether to use firmware TPM or discrete TPM played a role here... as the TPM header is connected to a separate LPCCLK. Will consider making my setup program look at a few more registers to see what's really going on.

On the other hand... I'm not certain about the F85226FG/F85226AF's orientation (it's on the other side of the PCB which was never shown), though I don't think I got that wrong according to the information in the PCB file as well as in the datasheet.

Will consider building another one when I have time, as I still have enough materials to do so, but considering the issues I'm facing there are plenty of rooms for improvement.

- Maybe some optional LED indicators for information like whether or not it's powered on or working. Right now for 5V/12V I can use a POST debug card that exposes such info, but for 3.3V, I'll have to use a multimeter.
- Alternatives to PWRDN# (or some other similar pins) in case the motherboard doesn't actually wire it (NC). For this purpose... maybe consider exposing a few optional +3.3V (with pull-up resistor) onboard?

LSS10999 wrote on 2023-06-17, 06:17:

On the other hand... I'm not certain about the F85226FG/F85226AF's orientation (it's on the other side of the PCB which was never shown), though I don't think I got that wrong according to the information in the PCB file as well as in the datasheet.

Yeah kicad's default pin marker isn't very clear, but there's a white line alongside pin 1. Next rev will make it more clear

- Maybe some optional LED indicators for information like whether or not it's powered on or working. Right now for 5V/12V I can use a POST debug card that exposes such info, but for 3.3V, I'll have to use a multimeter.
- Alternatives to PWRDN# (or some other similar pins) in case the motherboard doesn't actually wire it (NC). For this purpose... maybe consider exposing a few optional +3.3V (with pull-up resistor) onboard?

TBH, because PWRDN is never gonna be used under DOS I'll just stick a pullup resistor on it.

LEDs are a good idea though.

I've almost finished the second revision. New features :

• Smaller - should now fit in alongside Micro ATX/Mini ITX motherboards
• Moved holes to match case standoffs when installed as above
• Voltage indicator LEDs
• -5v power supply (Voltage Blaster-style)

I know people have requested I replace the ATX power connector with molex or SATA, but negative voltages are typically used for analog signals and I doubt my ability to design a quiet enough negative voltage converter circuit.

rasteri wrote on 2023-06-17, 17:38:

I've almost finished the second revision. New features : […]
Show full quote

I've almost finished the second revision. New features :

• Smaller - should now fit in alongside Micro ATX/Mini ITX motherboards
• Moved holes to match case standoffs when installed as above
• Voltage indicator LEDs
• -5v power supply (Voltage Blaster-style)

I know people have requested I replace the ATX power connector with molex or SATA, but negative voltages are typically used for analog signals and I doubt my ability to design a quiet enough negative voltage converter circuit.

Excellent, looking forward to it. Just a question: Is the PSON signal still exposed somewhere like in previous revision?

At present I'm using a DC12V-to-ATX24 adapter to power dISAppointment and the PSON signal needs to be shorted (with a jumper cap) to allow the adapter to supply power.

Maybe I really should be using an actual ATX splitter, though good quality ones tend to be thicker...

LSS10999 wrote on 2023-06-18, 03:32:

Excellent, looking forward to it. Just a question: Is the PSON signal still exposed somewhere like in previous revision?

At present I'm using a DC12V-to-ATX24 adapter to power dISAppointment and the PSON signal needs to be shorted (with a jumper cap) to allow the adapter to supply power.

Maybe I really should be using an actual ATX splitter, though good quality ones tend to be thicker...

Oh, no - I didn't think anyone would need it. I'll put it back in.

Hi, this is my first post, very interested in this project as I have an old i7-2600k system that I would like to use as a DOS gaming PC 🤣. It is installed on an Asus P8Z77-M, which fits nicely in a compact Lian Li MATX case.

Pin 20 on the TPM header appears to be connected to nothing, and Pin 18 (LDRQ#) on the Nuvoton LPC I/O Chip (NCT6779D) also appears to be connected to nothing. According to EduBat's post above, LDRQ1# is assigned to pin BA20 on the southbridge, which is connected to resistor SR83. Since all of the other pins on the TPM header besides pin 20 appear to have the correct pinout, I would suspect just a jumper wire between SR83 (which is unpopulated) and Pin 20 on the TPM header should be enough to get it working - the solder pad for SR83 is identified in the linked pic: http://alamone.net/sr83-spot.png

Since rasteri mentioned he's finished the v2 version of the board, I guess I'll wait until that's available before attempting to test it out. Let me know if you agree or think I made any errors.

alamone wrote on 2023-06-29, 07:43:

Since rasteri mentioned he's finished the v2 version of the board, I guess I'll wait until that's available before attempting to test it out. Let me know if you agree or think I made any errors.

Seems reasonable. I will order the new rev of the board for testing soon.

Been away on holiday but I finished up the design and have ordered it from PCBway. Assuming it works that'll be the first official release.

I also bought an AMD AM4 motherboard, hopefully we can get that working too!

Tried it on an ASUS Prime A320M-K. It boots but I get a lot of Fan/Temp errors and the keyboard doesn't work, so I suppose it must be interfering with the Super I/O.

I'll try moving it to the alternative port (0x2E) but most Super I/Os use 0x2E by default so I imagine that will just make things worse.

🤣 ignore all that, had the cable plugged in the wrong way round

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.

On this AM4 motherboard I'm having similar issues running DJGPP-compiled code that uses CWSDPR0 for ring-0 DPMI (e.g. sapphisa, quake) when even himem is loaded. I have to put DOS=NOAUTO in config.sys to stop windows 98 loading himem (IO.SYS apparently does this automatically).

But in any case, the fintek isn't being detected by your LPCEXP utility or by sapphisa. I'll need to double check I didn't fry the chip.