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 2026-10-26, 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 2026-10-26, 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 2026-10-26, 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 2026-10-26, 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 2026-10-26, 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 in chips, or it was some fluke.

Have you tried actually making a single disk raid and see if the disk is readable afterwards on another controller? I always thought that's how the non-raid was implemented on these cards.

CrustyCeleron wrote on 2026-10-26, 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 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).

The new file actually works! It shows up during boot, and drive attached to is detected. Speedsys and Sandra drive benchmark also confirm that it's actually working at DMA speeds. 😀 I was a bit sceptical about using AI for this stuff, but looks like it worked better than expected.

Curiously, S150 TX2 drivers don't work after updating the BIOS, you still need to use Fasttrak TX2 drivers. Not that this matters.

Also, I tried a quick & dirty hexedit trick to change device IDs from v1.00.0.33 BIOS (by comparing it to PDC20378 SATA BIOS), and it won't show up during boot with that BIOS. Looks like there really is a checksum validation.

konc wrote on Yesterday, 08:57:

Have you tried actually making a single disk raid and see if the disk is readable afterwards on another controller? I always thought that's how the non-raid was implemented on these cards.

I tried that, and against my expectations it's actually readable in another PC. However, it looks like its a bit of a memory hog in Fasttrak mode as it uses 48kB of conventional and upper memory. With S150 BIOS it uses just 18kB of memory, which is not a big deal.

Mike_ wrote on Yesterday, 07:14:

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.

Hmm. Frankly. I have lost coherence trying to reread that post again this year. I am not sure what has been grabbed from where to put in what 😁. Though I did make a raid 378 clone into a TX2 sata so I must've understood at some point. Oh well!

Though I think the nuance is likely PCI/Controller IDs in the BIOSes, and getting the right codepath for the respective flash chips in use. In theory, we could modify pflash to ask the user which flash is present, and which Promise Controller. And then have it trust us blindly.

Mike_ wrote on Yesterday, 07:14:

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

Thanks! This helps verify the theory - it reads the BIOS file and matches it to the device ID, like you say. We could make it ignore that heh, as above, but it is likely unwise.

Mike_ wrote on Yesterday, 07:14:

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

Mike_ wrote on Yesterday, 16:52:

The new file actually works! It shows up during boot, and drive attached to is detected. Speedsys and Sandra drive benchmark also confirm that it's actually working at DMA speeds. 😀 I was a bit sceptical about using AI for this stuff, but looks like it worked better than expected.

Great news! Do you also get PCI Bus Mastering, curiously?

I have performed similar mods to the .33 from the Promise website direct. It has an additional ID check which had to be modfied (now 6, from 5). See attached if you'd like to try it 😀. I am not sure what Promise has changed between versions.

Mike_ wrote on Yesterday, 16:52:

Curiously, S150 TX2 drivers don't work after updating the BIOS, you still need to use Fasttrak TX2 drivers. Not that this matters.

Yes, this sounds familiar. The BIOS doesn't change the PCI Device IDs. In theory, you can edit the INIs to target different vendor+device IDs. I don't recall which way around it is supposed to go (editing the sata drivers, or the raid ones).

CrustyCeleron wrote on Yesterday, 21:34:

Great news! Do you also get PCI Bus Mastering, curiously?

I have performed similar mods to the .33 from the Promise website direct. It has an additional ID check which had to be modfied (now 6, from 5). See attached if you'd like to try it 😀. I am not sure what Promise has changed between versions.

Yes, it said "IDE Bus Master Enabled" on the BIOS screen during POST.

I was also playing around with chatgpt last night, and I also managed to get some kind of working version. It looks like padding the file with zeros isn't needed, instead in the working version of v1.00.0.24 there was another change at offset 0x28, which changed from 0x00 to 0x08. Chatgpt said that there's some code in pflash that sums through offsets 0x20-0x29 plus an initial 0x29, and if checksum (x mod 256) of that is nonzero, it sets a flag. Now that I check it, this is true for PDC20371 RAID BIOS and PDC20378 SATA BIOS - those have a different value at offset 0x29. After changing 0x28 to value 0x08, it started to work. It might be that check doesn't exist in firmware itself, so the dumb hexedit version could have worked if I had bruteforced it on the chip with a programmer.

Now that I think about it, it's probably better to change the value at offset 0x29 instead, as that is changed between BIOSes for different versions of Promise chips.

I think the new change you added at offset 0x3864 is not needed. It's 0x75 even in SATA BIOS for PDC20378, and according to chatgpt it's probably a pointer to error string "Promise Controller is not found!" at 0x3375. 0x3371 would point at end of another error string.

Here's a list of changes, the BIOS is attached.

1Offsets     PDC20375 SATA BIOS  PDC20378 SATA BIOS      Modded BIOS     Description
20x08        0x56                0xE7                    0x62            Change to keep file's 8bit checksum at zero
30x20,0x24   0x75                0x73                    0x71            Change device IDs from 0x3375 to 0x3371
40x29        0xBD                0xC1                    0xC5            Keep checksum of offsets 0x20-0x29 the same
50x1182      0x75                0x73                    0x71            Change device IDs from 0x3375 to 0x3371
60x3849      0x75                0x73                    0x71        
70x3EA9      0x75                0x73                    0x71