Modding a Promise FastTrak S150 TX2 to a TX2plus was similarly unanswerered.

Have you tried looking through the RAID options to see if JBOD appears? If not, you might get away with a simple RAID0/Stripe array with only 1 disk as a member.

Perhaps crossflashing to a PDC20375 BIOS will work with pflash - a very quick check doesn't appear to show any obstacles in either the 371 or 375 pflash.exe. If there is, you could use a programmer or potentially modify pflash to overcome that if need be (remember to dump the bios first).

A bigger question is whether the respective BIOSes will be happy to boot given the differing PCI IDs, as there are checks inside them. Codex looked, and said the 20375 SATA BIOS is definitively looking for the PDC20375 chip in its routines. I am not sure of the effect of this. It nevertheless spat out a modified 375 SATA BIOS with a bunch of edits to make it look for a 371 instead. See attached.

Bare in mind this could brick your card. YMMV.

CrustyCeleron wrote on 2026-10-25, 13:49:

Modding a Promise FastTrak S150 TX2 to a TX2plus was similarly unanswerered.

Have you tried looking through the RAID options to see if JBOD appears? If not, you might get away with a simple RAID0/Stripe array with only 1 disk as a member.

I tried to look through options, but I didn't find JBOD anywhere. A RAID0/stripe with only one disk as a member might work, but then the disk probably wouldn't be readable in a normal controller.

CrustyCeleron wrote on 2026-10-25, 13:49:

Perhaps crossflashing to a PDC20375 BIOS will work with pflash - a very quick check doesn't appear to show any obstacles in either the 371 or 375 pflash.exe. If there is, you could use a programmer or potentially modify pflash to overcome that if need be (remember to dump the bios first).

A bigger question is whether the respective BIOSes will be happy to boot given the differing PCI IDs, as there are checks inside them. Codex looked, and said the 20375 SATA BIOS is definitively looking for the PDC20375 chip in its routines. I am not sure of the effect of this. It nevertheless spat out a modified 375 SATA BIOS with a bunch of edits to make it look for a 371 instead. See attached.

Bare in mind this could brick your card. YMMV.

Hmm, what's the "codex" you are talking about? I do have a programmer, so I could just solder the flash chip out and put a socket there in case it bricks the card...

Codex is just what I used to access ChatGPT.

I think with a programmer and soldering you have lots of valid tests you can do with much less risk. Though these PLCCs are faffy.

1. Dump your current BIOS. Keep it safe.

2. Try flashing a normal 375 BIOS using pflash. See if it complains. If it lets you, see if it boots (you may have to force the 375 driver in windows).

3. If it fails, or doesn't show evidence of its ROM during boot, try flashing the modified BIOS I gave you (not sure which driver to use in Windows in this case - suspect still the 375).

4. If all this fails. Try both with a programmer.

5. If they still fail. Restore the backup BIOS with the programmer.

This is my recollection for the basic level PCI cards that supported Windows 9x--

Looks like Promise went back to sharing controller chips in the S150 generation, so maybe?

1PDC Gen    Non-RAID Controller      RAID Controller             ROM Compatibility
2ATA33      PDC20246 Ultra (33)      PDC20246 FastTrak (33)      Compatible With Card Resistor Mod
3ATA66      PDC20262 Ultra66         PDC20262 FastTrak 66        Compatible With Card Resistor Mod
4ATA100     PDC20267 Ultra100        PDC20267 FastTrak 100       Compatible With Card Resistor Mod
5ATA100TX2  PDC20268 Ultra100 TX2    PDC20270 FastTrak 100TX2    Different Chip - Hacked BIOS Rom Required
6ATA133TX2  PDC20269 Ultra133 TX2    PDC20271 FastTrak TX2000    Different Chip - Hacked BIOS Rom Required
7S150TX2    PDC20371 Sata 150 TX2    PDC20371 FastTrak S150TX2   Maybe compatible with resistor mod?
8S150TX2+   PDC20375 Sata 150 TX2+   PDC20375 FastTrak S150TX2+  Maybe compatible with resistor mod?
9SataII150  PDC20575 Sata II 150 TX2+                            Don't know of a FastTrak version
10SataII300  PDC20775 Sata 300 TX2+   PDC20779 FastTrak TX2300    Different Chip - Probably not compatible 

Fortunately Promise is still in business and they have a full library of drivers on line back to the beginning of their PCI cards.

Here's a link to one of the articles showing a resistor mod, but usually they were going from the cheap card to the expensive card: https://www.tomshardware.com/reviews/fast-ine … sive,175-4.html

Are you sure you can't do JBOD with the FastTrak firmware? That seems surprising to me.

CrustyCeleron wrote on 2026-10-25, 17:01:

Codex is just what I used to access ChatGPT. […]
Show full quote

Codex is just what I used to access ChatGPT.

I think with a programmer and soldering you have lots of valid tests you can do with much less risk. Though these PLCCs are faffy.

1. Dump your current BIOS. Keep it safe.

2. Try flashing a normal 375 BIOS using pflash. See if it complains. If it lets you, see if it boots (you may have to force the 375 driver in windows).

3. If it fails, or doesn't show evidence of its ROM during boot, try flashing the modified BIOS I gave you (not sure which driver to use in Windows in this case - suspect still the 375).

4. If all this fails. Try both with a programmer.

5. If they still fail. Restore the backup BIOS with the programmer.

Unfortunately this didn't work. Pflash didn't let me flash normal 375 BIOS, so I tried flashing the modified BIOS. However, nothing happens when it is installed, there's no boot ROM screen during boot and disks are not recognized. Flashing back the normal 371 BIOS with pflash still worked, so at least I didn't need to start soldering.

Looks like somebody had managed to get a chinese clone using PDC20378 chips originally meant for Asus motherboards to work as non-RAID cards... but he doesn't mention whether he managed to cross-flash his genuine Fasttrak S150 TX2.

Re: Promise PCI controller OEM?

Anyways, I compared the modified 375 BIOS to original with a hex editor, and they seem to be almost completely different... so it looks like the AI hallucinated here.

EDIT: The linked post has a non-RAID BIOS for PDC20378 chip, and it's almost identical to unmodified 375 BIOS...

Mike_ wrote on Yesterday, 17:26:

Unfortunately this didn't work. Pflash didn't let me flash normal 375 BIOS, so I tried flashing the modified BIOS. However, noth […]
Show full quote

CrustyCeleron wrote on 2026-10-25, 17:01:

Codex is just what I used to access ChatGPT. […]
Show full quote

Codex is just what I used to access ChatGPT.

I think with a programmer and soldering you have lots of valid tests you can do with much less risk. Though these PLCCs are faffy.

1. Dump your current BIOS. Keep it safe.

2. Try flashing a normal 375 BIOS using pflash. See if it complains. If it lets you, see if it boots (you may have to force the 375 driver in windows).

3. If it fails, or doesn't show evidence of its ROM during boot, try flashing the modified BIOS I gave you (not sure which driver to use in Windows in this case - suspect still the 375).

4. If all this fails. Try both with a programmer.

5. If they still fail. Restore the backup BIOS with the programmer.

Unfortunately this didn't work. Pflash didn't let me flash normal 375 BIOS, so I tried flashing the modified BIOS. However, nothing happens when it is installed, there's no boot ROM screen during boot and disks are not recognized. Flashing back the normal 371 BIOS with pflash still worked, so at least I didn't need to start soldering.

Looks like somebody had managed to get a chinese clone using PDC20378 chips originally meant for Asus motherboards to work as non-RAID cards... but he doesn't mention whether he managed to cross-flash his genuine Fasttrak S150 TX2.

Re: Promise PCI controller OEM?

Anyways, I compared the modified 375 BIOS to original with a hex editor, and they seem to be almost completely different... so it looks like the AI hallucinated here.

EDIT: The linked post has a non-RAID BIOS for PDC20378 chip, and it's almost identical to unmodified 375 BIOS...

Looks like somebody had managed to get a chinese clone using PDC20378 chips originally meant for Asus motherboards to work as non-RAID cards... but he doesn't mention whether he managed to cross-flash his genuine Fasttrak S150 TX2

Yeah I saw that one awhile back. Slightly easier I think as possibly more things remained the same between the chipsets but have not checked to be sure. What is interesting therein is that pflash happily, well, flashed. Despite the differences in chipset. Yours does not. Why. There are a lot of pflash versions about, perhaps they are different.

Anyways, I compared the modified 375 BIOS to original with a hex editor, and they seem to be almost completely different... so it looks like the AI hallucinated here.

They're not very different to me - I was using the one from Promise's site as the source - https://www.promise.com/DownloadFile.aspx?Dow … oadFileUID=2963 (v1.00.0.24). Very little modification, essentially just the PCI numbers in case of any Controller ID checking. Look almost identical otherwise.

It is hard to see what is wrong without having a 371 to hand. But the 371 being 64KB (or 48KB filled) and the 375 being 16KB may play a part - pflash might not be writing to the right location. Using the same entry point. Or some other subtle difference. This feels right given you say no rom is displayed at boot - suggesting it isn't executed at all. Less likely, is that if you didn't zero-out/erase the existing ROM first, that there may be some reminant that is being detected/ran, but I doubt that.

Though I wonder why pflash accepted the modified 375 BIOS and not the original. I didn't think there was any verification - what was the error it gave for the original 375 bios rom?

The AI doesn't believe the 371 and 375 ROMs controller initialisations to be substantially different, nor that any realistic checks beyond the modifications occur. Only noting that PCI Bus Mastering isn't triggered anywhere during initialisation on the 375 BIOS whereas the 371 does.

So the only real theory I have is that pflash is writing the smaller code block somewhere unexpected (though I am unsure how much this should matter, depending on what code is left behind). Possibly, padding the 16KB ROM out to 64KB might ensure it lands in the right place and no errant remaining 371 BIOS is left. I'll give you a zero-ed out version to save you doing it yourself (would recommend erasing the BIOS first) - have also changed a Promise Checksum therein which may or may not have been a problem (0x0028 changed from 00 to 08 - change back if pflash doesn't like the ROM).

Also worth checking is reading the BIOS back after a reboot - see if the written and dumped files are the same (as that would indicate pflash may be interfering).

Beyond that, all I can suggest trying is prompting an LLM to compare the 371 BIOS to the 375 with a view of making it work, and then working through the suggested diagnostic steps.

Also. As another test, you could try erasing the BIOS entirely and not flashing a replacement. I vaguely recall some default into a form of basic mode for this (or I hallucinated it). It may not boot disks, but may allow you to use them in Windows at least. Not sure it is a victory so to speak but might at least amuse.

* https://www.promise.com/DownloadFile.aspx?Dow … oadFileUID=2963

CrustyCeleron wrote on Yesterday, 22:57:

Yeah I saw that one awhile back. Slightly easier I think as possibly more things remained the same between the chipsets but have not checked to be sure. What is interesting therein is that pflash happily, well, flashed. Despite the differences in chipset. Yours does not. Why. There are a lot of pflash versions about, perhaps they are different.

If I understood his post correctly, pflash didn't flash at all. He had to solder his flash chip out and socket it to use a programmer, which of course asks no questions. He also said that SATA 150 TX2plus BIOS from Promise's web site did not work at all, and he had to extract a BIOS for PDC20378 from an Asus motherboard BIOS.

CrustyCeleron wrote on Yesterday, 22:57:

They're not very different to me - I was using the one from Promise's site as the source - https://www.promise.com/DownloadFile.aspx?Dow … oadFileUID=2963 (v1.00.0.24). Very little modification, essentially just the PCI numbers in case of any Controller ID checking. Look almost identical otherwise.

That explains the difference - I was using newest BIOS, which is v1.00.0.33. v1.00.0.24 is some older version.

CrustyCeleron wrote on Yesterday, 22:57:

It is hard to see what is wrong without having a 371 to hand. But the 371 being 64KB (or 48KB filled) and the 375 being 16KB may play a part - pflash might not be writing to the right location. Using the same entry point. Or some other subtle difference. This feels right given you say no rom is displayed at boot - suggesting it isn't executed at all. Less likely, is that if you didn't zero-out/erase the existing ROM first, that there may be some reminant that is being detected/ran, but I doubt that.

Though I wonder why pflash accepted the modified 375 BIOS and not the original. I didn't think there was any verification - what was the error it gave for the original 375 bios rom?

The AI doesn't believe the 371 and 375 ROMs controller initialisations to be substantially different, nor that any realistic checks beyond the modifications occur. Only noting that PCI Bus Mastering isn't triggered anywhere during initialisation on the 375 BIOS whereas the 371 does.

It's unlikely that there are a lot of changes. There's no SATA BIOS for 371, but there were very few differences between PDC20375 and PDC20378, latter of which is RAID capable, so logically PDC20371 should be quite similar, as well.

Pflash said that controller is not found, so it sounds like it checks device ID, which is different between the chips.

CrustyCeleron wrote on Yesterday, 22:57:

So the only real theory I have is that pflash is writing the smaller code block somewhere unexpected (though I am unsure how muc […]
Show full quote

So the only real theory I have is that pflash is writing the smaller code block somewhere unexpected (though I am unsure how much this should matter, depending on what code is left behind). Possibly, padding the 16KB ROM out to 64KB might ensure it lands in the right place and no errant remaining 371 BIOS is left. I'll give you a zero-ed out version to save you doing it yourself (would recommend erasing the BIOS first) - have also changed a Promise Checksum therein which may or may not have been a problem (0x0028 changed from 00 to 08 - change back if pflash doesn't like the ROM).

Also worth checking is reading the BIOS back after a reboot - see if the written and dumped files are the same (as that would indicate pflash may be interfering).

Beyond that, all I can suggest trying is prompting an LLM to compare the 371 BIOS to the 375 with a view of making it work, and then working through the suggested diagnostic steps.

Also. As another test, you could try erasing the BIOS entirely and not flashing a replacement. I vaguely recall some default into a form of basic mode for this (or I hallucinated it). It may not boot disks, but may allow you to use them in Windows at least. Not sure it is a victory so to speak but might at least amuse.

Pflash doesn't let me dump anything at all - it just doesn't do anything if I use /s command parameter. I'd have to solder the flash chip out and socket it to properly check it with programmer.

I also tried to erase the BIOS with "pflash /e" command, as somebody else in that thread mentioned that it would then work as plain SATA controller. But for some reason this didn't work for me. Either there are some differences