rasteri wrote on 2024-04-11, 08:17:

weedeewee wrote on 2024-04-11, 07:16:

Is it this one ? https://www.youtube.com/watch?v=j58Fpm0uetI Machinist X99 PR9

Seems like the board in the video actually has a z97 chipset 😉

Yeah that's it. Maybe the z97 will be easier to get to work than the X99?

No idea if the z97 will be easier to work with, but it might well be that your 'x99' mainboard has a different chipset than the actual x99 and z97 chipsets.

myne wrote on 2024-04-11, 03:30:

We're talking about random no-name chinaboards maxing out at around $150 here.
What do YOU think is more likely?

We are also talking Shenzhen where you can get overnight 8-12 layer prototypes for _normal_ money. There is over 3000 universities in China with at least 1000 having good EE/Engineering and 200 having world class EE (thats how many participate in www.robomaster.com).

What I think happened is few students were assigned/organized themselves to make a board using recycled server chipsets/components and they did it using leaked documentation, reverse engineering and good old try it until it works.

myne wrote on 2024-04-11, 03:30:

2) They copy something that works, mod a few things here and there and call it a day.

How do you copy layout from huge ass server board with 12 dimm sockets into microATX? Its more of looking how it was done on other boards and doing similar thing than drag&drop.

You don't.
You grab one of these: https://asia.evga.com/products/product.aspx?p … 995-KR#images-5
Directly copy the CPU <> memory links, and rearrange the rest.

But Machinist X99 PR9 isnt "one of these" 😀 Ill stick to my guns unless you can find exact layout copy on name brand. Laying out DDR3 is not rocket science, it might have been 15 years ago, but now its mundane. Especially when you can spin prototypes overnight.
Here is David doing it on his own in Altium in ~40 hours over 10 years ago [DDR3 Interface PCB layout timelapse] https://www.youtube.com/watch?v=vC8wEP9r__w

Tried inspecting the LDRQ#1 line with a logic analyzer, but I wasn't able to capture anything promising... all I got was some messy captures of alternating highs and lows (appear as thick bars unless zoomed high enough).

Perhaps breadboard isn't a good idea and I'd better off use a splitter cable to hook the LDRQ1#... though I do have a feeling that the connection between the adapter to LDRQ1# was kind of delicate. I'm not sure how the LDRQ# line should behave during normal operation as well as when asserting, however...

Unfortunatelly I have my test setup disassembled and left at work, maybe during next week I could capture some scopes of working LDRQ. Or could Rasteri? I would expect some narrow low pulses ~1/10-1us with long period of 10-100ms during normal operation. In a test program it may be just a single low pulse...
Maybe some flip-flop with LED at output could be used to just capture the falling edge to leave LED light on...

yeah I'll hook my logic analyzer up at the weekend. I forget which of my boards uses LDRQ0 and which are LDRQ1 so I'll try and make sure LDRQ1 works

well this is cursed...

I didn't think 8-series chipsets could work with LGA2011-3 processors. My guess is machinist just populates the board with whatever PCH is available that day. 8/9 series appear to be pin-compatible.

I mean, if it works does it matter what chipset it has? Are there any disadvantages to running the 8 series?

probably a bit off-topic, but maybe you'll find this interesting 😀
https://github.com/nukeykt/LPC-Sound-Blaster
instead of building LPC-ISA adapter, I tried to directly implement sound blaster compatible 'dsp' over lpc bus using verilog.
I used z97 based asus rog maximus vii ranger, LDRQ1 was found using boardview and I wired it to TPM header. By default BIOS sets it as GPIO pin, but toggling some registers under DOS solved this issue (see attached LPC.C).

rasteri wrote on 2024-04-12, 19:32:

well this is cursed...

I didn't think 8-series chipsets could work with LGA2011-3 processors. My guess is machinist just populates the board with whatever PCH is available that day. 8/9 series appear to be pin-compatible.

I mean, if it works does it matter what chipset it has? Are there any disadvantages to running the 8 series?

AFAIK, the difference, if any, in this particular case is negligible.
Q87 was a business segment chipset, with Intel AMT and such, but it does not matter, as all of those chineese contraptions have crippled\hacked ME Region anyway.
Desktop PCH chip you get from those is a gamble. They use whatever they can get, even refurbished ones.
You can more or less identify the ones with a server PCH - C612 (by the number of SATA 6.0 ports available, usually 8 or more)

nukeykt wrote on 2024-04-12, 20:37:

instead of building LPC-ISA adapter, I tried to directly implement sound blaster compatible 'dsp' over lpc bus using verilog.

Nice, but the description is a bit short. What kind of FPGA you used?
Is it this dev board?
https://www.terasic.com.tw/cgi-bin/page/archi … English&No=1046

I prefer LPC2ISA bridge approach because:
1) freedom of choice of an ISA soundcard (I already have various ones) and not only soundcards
2) possible attachment of more than 1 ISA cards via passive ISA-tree adapter
3) the fintek bridge is probably much cheaper than FPGA that tend to be expansive...

It also have the same limitation with LDRQ. FPGA would be great to do some full legacy DMA emulation on new boards that completly dropped this legasy stuff off...

nukeykt wrote on 2024-04-12, 20:37:

probably a bit off-topic, but maybe you'll find this interesting :) https://github.com/nukeykt/LPC-Sound-Blaster instead of buil […]
Show full quote

probably a bit off-topic, but maybe you'll find this interesting 😀
https://github.com/nukeykt/LPC-Sound-Blaster
instead of building LPC-ISA adapter, I tried to directly implement sound blaster compatible 'dsp' over lpc bus using verilog.
I used z97 based asus rog maximus vii ranger, LDRQ1 was found using boardview and I wired it to TPM header. By default BIOS sets it as GPIO pin, but toggling some registers under DOS solved this issue (see attached LPC.C).

Interesting. This will open up more possibilities, such as installing into full ATX boards while inside a chassis, as well as adding more features depending on the FPGA used.

Did you implement just the Sound Blaster/Adlib parts? Apparently high-end ASUS boards of these generations have TPUs that would conflict with the Fintek bridge from what I tested with a X99-M WS, as they're also LPC devices.

Your Maximus VII Ranger also has TPUs. Since you got your LPC Sound Blaster working, I suppose the TPUs did not give you too much trouble.

On the other hand, was thinking about such a possibility when looking at PicoGUS. It may be better for newer systems, if it can be ported to LPC instead of ISA.

RayeR wrote on 2024-04-12, 22:06:

Nice, but the description is a bit short. What kind of FPGA you used?
Is it this dev board?
https://www.terasic.com.tw/cgi-bin/page/archi … English&No=1046

yea, terasic de10-nano (aka mister fpga). Cheaper devboards could be used as well, logic size is not that big

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

Did you implement just the Sound Blaster/Adlib parts? Apparently high-end ASUS boards of these generations have TPUs that would conflict with the Fintek bridge from what I tested with a X99-M WS, as they're also LPC devices.

Your Maximus VII Ranger also has TPUs. Since you got your LPC Sound Blaster working, I suppose the TPUs did not give you too much trouble.

yea, very bare-bones sb pro 2 with opl3 emulation.

only issue was GPIO setting, once I figured it out it just worked. What's TPU btw?

nukeykt wrote on 2024-04-13, 07:38:

yea, very bare-bones sb pro 2 with opl3 emulation.

only issue was GPIO setting, once I figured it out it just worked. What's TPU btw?

Something exclusive to ASUS, on very high end boards. It's responsible for some optional performance tuning (controllable by switches in some cases), as well as additional fan controls and sensors.

These chips are also on the LPC bus and appear to interfere with the Fintek bridge's functionality, as when I tried reading config values from the bridge on my X99-M WS, I was getting FF instead on a good amount of registers.

nukeykt wrote on 2024-04-13, 07:38:

yea, terasic de10-nano (aka mister fpga). Cheaper devboards could be used as well, logic size is not that big

Does the implementation use anything specific to Altera or Cyclone V? If not, probably any FPGA board would do as long as there's enough resources and exposed IOs...

nukeykt wrote on 2024-04-12, 20:37:

probably a bit off-topic, but maybe you'll find this interesting :) https://github.com/nukeykt/LPC-Sound-Blaster instead of buil […]
Show full quote

probably a bit off-topic, but maybe you'll find this interesting 😀
https://github.com/nukeykt/LPC-Sound-Blaster
instead of building LPC-ISA adapter, I tried to directly implement sound blaster compatible 'dsp' over lpc bus using verilog.
I used z97 based asus rog maximus vii ranger, LDRQ1 was found using boardview and I wired it to TPM header. By default BIOS sets it as GPIO pin, but toggling some registers under DOS solved this issue (see attached LPC.C).

Oh wow this is really awesome, I was planning on doing something similar using a fintek bridge and a CS4237 SBpro clone chip but this is even cooler.

You planning on taking it any further? I've been learning verilog on the ice40, maybe it could be ported to that. Then we could design a little board that looks like a TPM module but gives SBpro compatibility...

EDIT : Also just in general having the LPC interface logic in gateware means we can do some more in-depth investigations into stuff like port filtering etc

LSS10999 wrote on 2024-04-13, 09:55:

Does the implementation use anything specific to Altera or Cyclone V? If not, probably any FPGA board would do as long as there's enough resources and exposed IOs...

nope, It doesn't I think

rasteri wrote on 2024-04-13, 10:06:

You planning on taking it any further? I've been learning verilog on the ice40, maybe it could be ported to that. Then we could design a little board that looks like a TPM module but gives SBpro compatibility...

this was more like proof-of-concept, so likely no. Maybe someday I will try to emulate intel MCU and run SB DSP code as is, that would be fun project to try

nukeykt wrote on 2024-04-13, 10:27:

this was more like proof-of-concept, so likely no. Maybe someday I will try to emulate intel MCU and run SB DSP code as is, that would be fun project to try

That would be very interesting, 100% compatibility at the cost of more cells. There must surely already be 8052 implementations in RTL.

Hypothetically, do you think perhaps the soundblaster implementation from ao486 could be repurposed with a simple LPC layer?

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

On the other hand, was thinking about such a possibility when looking at PicoGUS. It may be better for newer systems, if it can be ported to LPC instead of ISA.

rasteri wrote on 2024-04-13, 10:06:

EDIT : Also just in general having the LPC interface logic in gateware means we can do some more in-depth investigations into stuff like port filtering etc

already posted pico LPC project somewhere above, fast serial busses are MUCH easier to implement than full ISA on pico

nukeykt wrote on 2024-04-13, 07:38:

only issue was GPIO setting

did you document somewhere location on PCB of GPIO you used on your Asus board?

rasz_pl wrote on 2024-04-13, 14:32:

did you document somewhere location on PCB of GPIO you used on your Asus board?

For all those Intel chipsets, LDRQ1# is multiplexed to GPIO23. How to configure that pin's functionality is already documented in their datasheets.

The location of LDRQ1# varies depending on board design. You need to find your board's boardview to locate it.

An update on my tests... I think I'm getting even more closer.

Turned out I indeed need to reset all DMA registers on my test system after configuring the host LPC bridge. Back then I omitted that part as it was never required for RUBY-9719VG2AR. Guess the boot-up states of the DMA registers are hit-or-miss when it comes to other motherboards.

However, it seems something has changed after doing so, as right now DIAGNOSE won't pass IRQ test no matter what, even after I disabled my onboard audio (IRQ7 was free according to HWINFO). As such, I cannot validate whether IRQ and DMA are working or not this way... Before adding DMA reset routines, IRQ test can be passed with IRQ7 when onboard audio is disabled.

Tests with DIGPAK, however, turn out more different. With DMA registers reset, when I configure my sound card through SETD, the test sound played fine for once then the program froze (CTRL-ALT-DEL still works). Previously it would freeze before generating any audio output, and further tests showed it has no problem with onboard audio enabled (which claims IRQ7 through its own PIRQ line) -- in both cases, I can hear the test sound for once then the program hangs and needs restart. Does this indicate a (partially) working DMA?