douglar wrote on 2024-10-20, 14:24:

Are you using your 20630 with the dos driver, a promise bios, or xub?

DOS driver package which I'm not 100% convinced of. I don't have a separate way to load code like on a modified NIC, and honestly, that stuff is too old for me - I'd like to fully test the hardware, and then either bin it or throw it in the general direction of eBay, depending on results. I'm more interested in systems that are a tad younger than me, not the same age or older 😁
(that being said, I also got a system with 8" floppies to test, so there's that...)

lti wrote on 2024-10-21, 04:33:

Based on the schematic, it just connects the PDIAG signal properly.
https://hackaday.io/project/186809-m2-sata-to … rse-engineering

My 2.5" adapter connects pin 46 of the chip directly to the IDE connector with no series resistor or pull-up. It doesn't seem to make any difference because the motherboard I'm using doesn't connect that pin at all (it's completely floating - verified with the schematic), and it still only uses UDMA2.

I tried out putting the 10K resistor at RH1 and a 1K resistor at R16 it didn't improve anything for the Promise 20630 VLB controller when loading the driver in DMA mode.

It's remarkable how far the generic bridges deviate from jmicron's intended spec.

douglar wrote on 2025-01-30, 02:24:

lti wrote on 2024-10-21, 04:33:

Based on the schematic, it just connects the PDIAG signal properly.
https://hackaday.io/project/186809-m2-sata-to … rse-engineering

My 2.5" adapter connects pin 46 of the chip directly to the IDE connector with no series resistor or pull-up. It doesn't seem to make any difference because the motherboard I'm using doesn't connect that pin at all (it's completely floating - verified with the schematic), and it still only uses UDMA2.

I tried out putting the 10K resistor at RH1 and a 1K resistor at R16 it didn't improve anything for the Promise 20630 VLB controller when loading the driver in DMA mode.

It's remarkable how far the generic bridges deviate from jmicron's intended spec.

R16 needs to be 100 ohm, not 1Kohm. Correct SMD value is 101.

So to be exact:
RH1 - 103
R16 - 101

Those are the correct SMD markings for the resistors.

PcBytes wrote on 2025-01-30, 11:20:

R16 needs to be 100 ohm, not 1Kohm. Correct SMD value is 101. […]
Show full quote

R16 needs to be 100 ohm, not 1Kohm. Correct SMD value is 101.

So to be exact:
RH1 - 103
R16 - 101

Those are the correct SMD markings for the resistors.

Thanks for catching that. Turns out my mistake was in typing, not in part selection. I did solder the correct parts into place.

Looking at https://hackaday.io/project/186809-m2-sata-to … rse-engineering

I addressed:

• R16 10K --> 100 or NC
• RH1 0 ohm link --> 10K

I see that there are 13 other variances to consider:

• R1 10K --> 12K 1% (123)
• R3 10K --> 47K (470)
• R6 300 --> 330 (331)
• R14 10M --> 1M (105)
• R15 10K --> NC or 0 (100 or 0)
• R17 300 --> 100 (aka 101)
• R18 10K --> 1K (aka 102)
• C5 100nF --> 1uF
• C6 (too low for my tester to measure) --> 5pF
• C7 (too low for my tester to measure) --> 33pF
• C12, CT6-CT7 10uF tantalum --> 22uF/16V tantalum
• CB9-CB10 10uF --> 100nF
• FB1-FB2 0 ohm link --> 100-450 ohm at 100MHz

I ordered one of the fancy Pinecil V3 mini soldering pens. This will be a good project for that.
I'll work through the rest as time allows.

Not sure how to read the values from surface mount capacitors yet.

douglar wrote on 2025-01-30, 13:31:

<snip> I see that there are 13 other variances to consider: […]
Show full quote

<snip>
I see that there are 13 other variances to consider:

• FB1-FB2 0 ohm link --> 100-450 ohm at 100MHz

@douglar - I have a question for you: Do you know what "at 100Mhz" means for FB1-FB2? When what specifically is at 100Mhz?

Thanks

mockingbird wrote on 2025-02-05, 19:58:

douglar wrote on 2025-01-30, 13:31:

<snip> I see that there are 13 other variances to consider: […]
Show full quote

<snip>
I see that there are 13 other variances to consider:

• FB1-FB2 0 ohm link --> 100-450 ohm at 100MHz

@douglar - I have a question for you: Do you know what "at 100Mhz" means for FB1-FB2? When what specifically is at 100Mhz?
Thanks

FBx = Ferrite Bead yes? So it's the measure of impedance where resistance changes according to the frequency. So they want 100-450 ohm resistance at 100Mhz.

douglar wrote on 2025-02-05, 20:13:

FBx = Ferrite Bead yes? So it's the measure of impedance where resistance changes according to the frequency. So they want 100-450 ohm resistance at 100Mhz.

Thanks 😀

douglar wrote on 2025-01-30, 02:24:

lti wrote on 2024-10-21, 04:33:

Based on the schematic, it just connects the PDIAG signal properly.
https://hackaday.io/project/186809-m2-sata-to … rse-engineering

My 2.5" adapter connects pin 46 of the chip directly to the IDE connector with no series resistor or pull-up. It doesn't seem to make any difference because the motherboard I'm using doesn't connect that pin at all (it's completely floating - verified with the schematic), and it still only uses UDMA2.

I tried out putting the 10K resistor at RH1 and a 1K resistor at R16 it didn't improve anything for the Promise 20630 VLB controller when loading the driver in DMA mode.

It's remarkable how far the generic bridges deviate from jmicron's intended spec.

I was digging into this the other night because I got one of those SATA M.2 to 44 pin IDEs to try in my Panasonic Toughbook.

Of course, it doesn't work*, but looking at these schematics including the forum post in Spanish, I can't see how these resistor changes would help anything with ISA or VLB. The only thing I can see it fixing is UDMA66 and higher controllers and the test for an 80-conductor cable. Did you try the other mismatched resistors/capacitors/etc. and did anything help? Any speculation on whether those MODE[1:0] straps, and the other FXDMA one (hardwire UDMA mode rather than obeying SET FEATURE command) help? What if the 25 MHz crystal were replaced with something slower?

I'm going to try and read those SCR registers that the JM20330 datasheet suggests exist, and maybe get an indication of exactly what error is occurring on the SATA side when an MWDMA or UDMA transaction fails, e.g. with PIIX3.

* it works in Linux if I pass libata.force=udma/100 (to override 133 or 150 or whatever it defaults to). However, I still can't boot from it. INT 13H successfully loads the MBR, but sets the carry flag, so the BIOS refuses to boot. I've got a CF adapter on the way to try instead.

jakethompson1 wrote on 2025-09-02, 02:21:

Of course, it doesn't work*, but looking at these schematics including the forum post in Spanish, I can't see how these resistor changes would help anything with ISA or VLB. The only thing I can see it fixing is UDMA66 and higher controllers and the test for an 80-conductor cable.

I don't see it affecting compatibility with old controllers either.

jakethompson1 wrote on 2025-09-02, 02:21:

Did you try the other mismatched resistors/capacitors/etc. and did anything help? Any speculation on whether those MODE[1:0] straps, and the other FXDMA one (hardwire UDMA mode rather than obeying SET FEATURE command) help?

I didn't notice the mismatched components, but I messed around with MODE and FXDMA. They didn't have any effect. I interpreted the FXDMA as making the JM20330 refuse to run at a DMA mode other than the maximum set by MODE, but it still gave me ATA33/UDMA2.

jakethompson1 wrote on 2025-09-02, 02:21:

I'm going to try and read those SCR registers that the JM20330 datasheet suggests exist, and maybe get an indication of exactly what error is occurring on the SATA side when an MWDMA or UDMA transaction fails, e.g. with PIIX3.

That would be interesting to see with VIA chipsets as well and compare with chipsets that don't have any obvious compatibility problems.