CrustyCeleron wrote on 2026-10-30, 20:54:

Had the LLM look at the Maxtor one. It seems to think there is not much difference between it and the promise one. _Except_ possibly memory handling - perhaps for Motherboard compatibility reasons?

Given that, I attach a version based on the Maxtor rom too! Have added your pflash.

Hmm, what's the point with the new version for v1.00.033, it's exactly the same as the version I posted except for offsets 0x28 and 0x29? I'd say it makes more sense to change the value at offset 0x29 rather than change 0x28 to nonzero. After all, 0x29 is what changes between PDC20375 and PDC20378 SATA BIOSes, so it's likely what Promise used to make the checksum match. Probably this doesn't matter, though.

I'll try that Maxtor BIOS sometimes during the weekend.

CrustyCeleron wrote on 2026-10-30, 19:59:

Also it'd be real nice if there was a 'See all BIOSes for this Chip' button.

That functionality exists, but the BIOS needs to be associated with the chips not the cards. Look at this chip from an earlier period .. https://theretroweb.com/chips/6393 Lots of vendors used that chip and the bios was good for all of them and so the bios was associated with the chip. But for this period of promise, each bios was generally only associated with a single card and that’s how things got sorted.

Hnng... pflash doesn't let you flash anything from HDD, only floppy...

Anyways, I didn't feel sleepy enough, so I tested the card on a P4 board, and it works fine. Both with modded V1.00.0.33 and Maxtor v1.00.0.50.3 BIOSes. 😀

Here's a version where offset 0x29 is modified instead of 0x28 to keep it as similar as possible to other SATA BIOSes. Also, I edited the AI produced .txt to make it a bit more informative. 😀

I’m just curious about this sentence:

"However, it looks like it's 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"

Is this the real, solid reason why (or so it seems to me) do you generally prefer the NON RAID Promise SATA150 controllers over the RAID capable Promise FastTrak S150 controllers?
Is it to avoid wasting conventional memory on machines that run DOS in real mode?
Did I understand that correctly?
I ask because I typically use my Promise FastTrak S150 TX4 controllers, but I also have a few Maxtor SATA150 cards (also known as Promise S150 TX2 Plus). If that is the case, I could start using these instead on my machines that run DOS in real mode (by which I mean booting directly into MS-DOS) or using the "Restart in MS-DOS mode" option.

Damiano.78 wrote on Yesterday, 10:58:

I’m just curious about this sentence: […]
Show full quote

I’m just curious about this sentence:

"However, it looks like it's 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"

Is this the real, solid reason why (or so it seems to me) do you generally prefer the NON RAID Promise SATA150 controllers over the RAID capable Promise FastTrak S150 controllers?
Is it to avoid wasting conventional memory on machines that run DOS in real mode?
Did I understand that correctly?
I ask because I typically use my Promise FastTrak S150 TX4 controllers, but I also have a few Maxtor SATA150 cards (also known as Promise S150 TX2 Plus). If that is the case, I could start using these instead on my machines that run DOS in real mode (by which I mean booting directly into MS-DOS) or using the "Restart in MS-DOS mode" option.

That's one reason, but another is that RAID is just a hindrance without any benefits in this use case. It can make the disk unreadable in other controllers, although apparently there's a way to avoid this with Promise controllers. Even regular HDDs are fast enough that RAID doesn't offer any meaningful performance increases, as bandwidth is limited by PCI bus anyways.

Thank you for your kind reply.
About that : "RAID is just a hindrance without any benefits in this use case" could you explain in more detail what you mean by "in this use case"? Do you mean for a strictly pure DOS use case, or for Windows 98SE as well?
About that: "apparently there's a way to avoid this with Promise controllers" Do you mean only when a raid array is created with only one hard disk drive in JDOB mode or also for example in a classic raid 0 striped array?
Could you briefly explain the negative effects of having a larger portion of conventional (or perhaps upper?) memory occupied by the BIOS of a Promise RAID controller when running in pure DOS? For instance, do you mean that some very old DOS games might fail to launch, perhaps returning some "insufficient memory" errors, or is that not the issue?

Damiano.78 wrote on Today, 08:54:

Thank you for your kind reply. About that : "RAID is just a hindrance without any benefits in this use case" could you explain i […]
Show full quote

Thank you for your kind reply.
About that : "RAID is just a hindrance without any benefits in this use case" could you explain in more detail what you mean by "in this use case"? Do you mean for a strictly pure DOS use case, or for Windows 98SE as well?
About that: "apparently there's a way to avoid this with Promise controllers" Do you mean only when a raid array is created with only one hard disk drive in JDOB mode or also for example in a classic raid 0 striped array?
Could you briefly explain the negative effects of having a larger portion of conventional (or perhaps upper?) memory occupied by the BIOS of a Promise RAID controller when running in pure DOS? For instance, do you mean that some very old DOS games might fail to launch, perhaps returning some "insufficient memory" errors, or is that not the issue?

I mean both for DOS and Win98SE. Any reasonably modern SATA SSD is fast enough that the PCI bus is the bottleneck, so you can't get any performance gains from RAID. Many hard disks manufactured after early 00s are also fast enough to bottleneck the PCI bus on sequential access. SATA SSDs are also reliable enough that mirroring isn't needed in retro PC use case.

And yes, if you want to be able to read the disk in another system or controller, you apparently need to use a specific setting in the RAID BIOS menu. On SATA controllers, you just plug the disk in and it works.

And that's exactly the problem with something using tens of kilobytes of conventional memory in DOS: It might not be possible to free enough of it for some games to run.

Ok, thank you for your explanation. Although I do wonder about this: let me say...if the RAID system was adopted by Promise and other manufacturers for standalone PCI controllers as a flagship solution for servers and high-performance PCs, it seems strange to think that the engineers back then wouldn't have considered the PCI bus bottleneck. I imagine that at the time, for instance around 2003 when Promise’s SATA 150 based RAID solutions were released, hard drives weren't yet fast enough for the PCI bus to be a limiting factor; therefore, setting them up in a RAID 0 array would have simply boosted overall performance. Or is there something else to take into account? Perhaps factors like average read/write access times, or the overall good responsiveness of a system running on a RAID 0 striped boot array?
I’m not necessarily a die hard proponent of RAID, but the topic is interesting, and I’d like to know if it’s truly worth converting my own Promise SATA 150 RAID controllers into their NON RAID versions as you did in this pleasant and interesting thread.
It is worth mentioning that in general I prefer to use classic hard disk drives in my retro builds instead of SSDs.