So in the end I bought one of those aliexpress SSDs (they call them Kingspec but when you actually open them they're called Yansen with the red bar going across):

And look at this, it actually gives me UDMA6, this is very interesting because not even the Samsung 120GB HDD gave me that, it only went up to UDMA5, I'm wondering if this is another quirk of the bios when reading the SM2236 chip, but a good quirk. Having said that it's probably going to go down to UDMA5 once we get into Windows because of the Intel chipset never supporting ATA-133 except though SATA as far as I'm aware.

I was wanting to buy one of these SSDs from dosdude1 however they got back to me saying they had some problems with the SM2236 chips they were using (they are the same chips these chinese SSDs are using too), but I would have preferred one from there because they use 4 NAND chips and it performs slightly better, you can see more about it in this video:
https://www.youtube.com/watch?v=z27b40T6lLs

But anyway, I'm happy to finally have something working well now after months of trying all sorts of things.

Wow, thanks for recommending this Kingspec/Yansen PATA SSD 😀

I never found a new suitable PATA SSD (despite used ones) and ended up with using SATA SSDs and SATA->IDE converters.
In my DOS machine I never got TRIM working whereas in my Win98 machine it works with same SSD.

I will try that one in my next builds. Maybe TRIM is working out of the box and I don't need that SATA->IDE converters any more.
128GB is exactly what I need for DOS 7.10 and Win98.
No need to buy a larger SATA SSD (as 128GB is hard to get nowadays) and limit them to 128GB.

Perfect, thank you!

"Block mode not supported" Does that mean its UDMA6, but every single transfer is still only 512 bytes max? Afaik this is a big bottleneck as CPU is constantly hammered with interrupt to setup new transfers.

Hmm yeah didn't catch that, here is my ATTO results running under Windows 98SE, UDMA5:

So yeah it does go down to UDMA5 but that's an Intel thing which I don't think anyone has managed to modify the chipset driver, if that's even possible, probably not. Comparing it to the SATA to IDE adapter on my Thinkpad T42 for example, that had slightly better results, so if your board can use those adapters without any problems, its still the way to go, these SSDs are rather pricey, the 256GB one is over $100 for me. The main bottleneck is the lack of DRAM cache that the SATA adapters usually have, dosdude1 made this comment on that video above:

@dosdude1
1 year ago (edited)
What a coincidence that the KingSpec drive uses the same chips I decided on. If I had to guess, the only reason it's slower is due to it only having one NAND chip installed, whereas my drive has 4 (for 256GB). Also, the SATA/mSATA SSDs all have DRAM cache on them, which makes the random tests way faster (hence the much higher scores). Unfortunately the SM2236 doesn't support DRAM cache, so I couldn't implement that in my design. That red SATA to IDE adapter you're using is special, in that instead of the garbage JMicron JM20330 SATA-IDE bridge IC that all the other adapters use, it uses a Marvell 88SA8040 or 88SA8052, which are WAY better, and faster in most cases (as shown here). At the end of the day, though, the native IDE drives like mine, the KingSpec, and IDE DOM will be compatible with a much wider array of systems than ANY SATA to IDE adapter.

So yeah, unfortunately like I said, he's stopped making this at the moment, but perhaps there will be a chip that he can switch to that has DRAM cache that will greatly improve performance. Otherwise this seems to be working fine for me at the moment, played a few games, no slowdowns or stuttering etc.

I also read something interesting on reddit regarding my original problem, apparently the Thinkpad T43, has a Marvell chip built onto the motherboard itself, and if you use a SATA to IDE adapter, it basically is using 2 of those converting chips in succession, which results in UDMA2 limitation, and it maybe the same issue with these Gericom laptops. There is a SATA mod for the T43 allowing you to connect SATA directly and get the full SATA 150 speed, but I'm nowhere near skilled enough to even try that, if it even is the same problem.
https://mikejmoffitt.com/articles/0000-t43sata.html

AaronS wrote on 2024-10-18, 17:22:

Hmm yeah didn't catch that, here is my ATTO results running under Windows 98SE, UDMA5:
So yeah it does go down to UDMA5

Check CPU utilization during the test, like open task manager or something similar in another window. Its possible Block Mode is only relevant in PIO modes and wont matter in Windows.

crusher wrote on 2024-10-18, 06:23:

I will try that one in my next builds. Maybe TRIM is working out of the box and I don't need that SATA->IDE converters any more.
128GB is exactly what I need for DOS 7.10 and Win98.

The SM2236 product brief does not mention support for TRIM. Even SATA SSDs need the SATA controller in AHCI mode to support TRIM, it does not work in legacy mode.

Check CPU utilization during the test, like open task manager or something similar in another window. Its possible Block Mode is only relevant in PIO modes and wont matter in Windows.

https://youtu.be/_pCxwkRzTbg

The SM2236 product brief does not mention support for TRIM. Even SATA SSDs need the SATA controller in AHCI mode to support TRIM, it does not work in legacy mode.

My plan is to hook it up via a USB dongle to modern Windows every once in awhile and use the "optimize" tool, would this suffice?

am I seeing correctly 100% CPU utilization? 😳 that has to hurt compared to HDD

jtchip wrote on 2024-10-19, 00:43:

crusher wrote on 2024-10-18, 06:23:

I will try that one in my next builds. Maybe TRIM is working out of the box and I don't need that SATA->IDE converters any more.
128GB is exactly what I need for DOS 7.10 and Win98.

The SM2236 product brief does not mention support for TRIM. Even SATA SSDs need the SATA controller in AHCI mode to support TRIM, it does not work in legacy mode.

My understanding is that Trim support is more of a device /driver/ file system issue than a legacy vs AHCI mode issue. While trim and AHCI came out at about the same time, they don’t necessarily depend on each other. Trim is an ATA-8 / ACS2 command.

Seems to me that it is fairly likely that what you are seeing is that your OS has a filesystem driver that understands trim, and your AHCI driver supports trim, so you get trim when working in AHCI mode, but your legacy driver does not support trim, so you don’t see it when using the legacy mode driver.

Even if AHCI mode isn’t technically required to issue the trim command, in your use case it may be practically required, becuase your operating system won’t issue trim commands when the legacy mode device driver is in use. But honestly, if your device can work in AHCI mode, (and your os and your driver stack and sometimes you need support in your bios too) you are probably better using it in that mode for performance. Trim is just an added benefit. That might be why they never went back and refit the legacy driver for trim. The collection of users that could do trim but couldn’t do AHCI was pretty small.

Curiously, Compact flash devices that conform to CFv 6 can support trim on pata. Unfortunately it’s little more than just a fun piece of trivia, because like UDMA mode 7 and the rest of ATA-8, it was never supported over an IDE interface in Windows. Why? Becase by the time CFv6 came out, PC’s were already moving to NVMe instead.

rasz_pl wrote on 2024-10-19, 19:18:

am I seeing correctly 100% CPU utilization? 😳 that has to hurt compared to HDD

I went back and tested 2 HDDs (both UDMA5 in bios, tested with and without Multi-Sector Transfer), they all use 100% utilization with ATTO running. One minor downside to this bios is there is no way to disable Hyper Threading, to my understanding Win98 doesn't know what HT is so it only addresses the first thread anyway according to CPU-Z, but maybe something with that? I did notice the "Kernel Threads" in sys mon never goes over 50% which maybe also has something to do with it.

douglar wrote on 2024-10-19, 19:40:

My understanding is that Trim support is more of a device /driver/ file system issue than a legacy vs AHCI mode issue. While trim and AHCI came out at about the same time, they don’t necessarily depend on each other. Trim is an ATA-8 / ACS2 command.

Seems to me that it is fairly likely that what you are seeing is that your OS has a filesystem driver that understands trim, and your AHCI driver supports trim, so you get trim when working in AHCI mode, but your legacy driver does not support trim, so you don’t see it when using the legacy mode driver.

Even if AHCI mode isn’t technically required to issue the trim command, in your use case it may be practically required, becuase your operating system won’t issue trim commands when the legacy mode device driver is in use. But honestly, if your device can work in AHCI mode, (and your os and your driver stack and sometimes you need support in your bios too) you are probably better using it in that mode for performance. Trim is just an added benefit. That might be why they never went back and refit the legacy driver for trim. The collection of users that could do trim but couldn’t do AHCI was pretty small.

Thanks for the clarification. I know TRIM is an ATA command but that "TRIM requires AHCI" thing is somewhat pervasive that I'd assumed that something in legacy mode was blocking that command (much like some USB-SATA bridges do and some are fixable with updated firmware). I use Linux and I did a test it by setting a Socket AM2+ platform with SB700 to legacy mode and seeing if TRIM still works. To my surprise, it did but it turns out Linux still uses the AHCI driver despite the SATA controller being in legacy IDE mode (confirmed by lspci).

Perhaps AHCI simply provided a standardised interface so that operating systems only need to write one driver. Some non-AHCI controllers do support "AHCI features" like NCQ and hot-plug (VIA, for instance) but through a proprietary extension.

douglar wrote on 2024-10-19, 19:40:

Curiously, Compact flash devices that conform to CFv 6 can support trim on pata. Unfortunately it’s little more than just a fun piece of trivia, because like UDMA mode 7 and the rest of ATA-8, it was never supported over an IDE interface in Windows. Why? Becase by the time CFv6 came out, PC’s were already moving to NVMe instead.

In this case, the SM2236 does support CFv6 but doesn't claim to support TRIM, unlike some of Silicon Motion's SATA controller product briefs which do explicitly mention support e.g. SM2246 and SM2258[XT]. To be sure, someone needs to boot into Linux and run hdparm -I /dev/sdx (to check if the drive supports it) and lsblk -S (to check if the driver also supports it) to confirm.

Are there any DOS tools to trigger CFv6 trim?

rasz_pl wrote on 2024-10-20, 02:42:

Are there any DOS tools to trigger CFv6 trim?

RLOEWS is the only Trim tool im aware of for retro systems, unsure if it works in DOS

RLOEWS trim is a DOS program, it has to be run in DOS.

On the systems I've tried it it works great on the system that has SSD connected directly to SATA and is operating in IDE mode, but the on the system that had IDE to SATA adapter RLOEWS trim locked up the system.

Would be lovely to see is a DOS driver that manages to run a CF in memory mapped mode.

Seems conceivable that the memory mapped performance could approach caching ide controller speeds when reading out of the cache, ~ 4MB/s on a standard IDE, ~20MB/s on 33MHz VLB, but it would all depend on the guts of the CF.

Sorry for yet another bump to this thread and its kind of gone off on a tangent, but I hadn't really done anymore testing since my last post. Anyway something very interesting when using this SSD under Windows XP SP3 (installed using the WinXP+SP3 CD specifically), it actually operates at the full ATA-133 spec. Just a reminder that this is an Intel 848P + ICH5, which according to wiki, intel never supported ATA-133 unless running through IDE emulation mode with SATA (ICH5 being SATA compatible of course). However device manager, hwinfo and ATTO all show it now running at UDMA6:
https://imgur.com/a/uvaKJcn

I then tried Windows 2000 and that only gives ATA-100 just like Windows 98. Clearly XPs installation has some much newer drivers even for older chipsets. So since I have some time to mess with this again, does anyone know if any intel drivers got backported to Windows 98/ME that might give the same result there? The Intel Application Accelerator doesn't work at all on 848P/ICH5, not even the older 2.2.2 version.

if that is a microsoft driver, probably not. this is kind of an interesting find actually, because they're technically running the interface out of spec. 116 mb/s also seems a bit slow, certainly for an SSD, a quick search suggests at least 125 mb/s can be acheived from HDDs. see what number HD Tach 3.x gives, and you also might want to look at the CRC error rate in SMART, for instance. though XP also had the behavior of reverting to PIO after some CRC errors so you'd probably notice that anyway. if you have a promise ultra133 or something that should give you UDMA6 in win98, and you could compare whether it performs better in XP than your current setup.

this suggests IAA should support 848P, but it'd be surprising if that would unlock ATA-133, because they'd be contradicting their own spec sheet. there doesn't seem to be much info out there if intel not bothering to support ATA-133 on any chipset was simply to push everyone towards SATA or there were other reasons for it as well.

finally, what i don't get about this entire thread, you're already using a platform with SATA. what's the purpose of messing with all of those adapters when SATA SSDs are more plentiful, easier to use and should run faster even under legacy IDE mode?

These IDE SDDs are very similar to the ones dosdude1 was making, and the SM2236 chip they use doesn't support DRAM cache which is why the write speed is so slow. The readspeed is also slower than a SATA>IDE adapter using the marvell controller, under ATA-100 for example, those would get around 92-93MB/s in ATTO, but this IDE SSD gets only around 85MB/s. So for this particular SSD 116MB/s seems about right. Also this is a "desktop laptop" which despite having an ICH5 and SATA options in the bios (albeit hidden), there's only an IDE connector on the motherboard. I still suspect there is an additional SATA converter chip on the board somewhere, which would explain the initial problem with SATA>IDE adapters reverting to UDMA2, the Thinkpad T43 has this exact issue.

An IDE to mSATA enclosure has its own SATA to IDE bridge chip. Having two such chips in between the southbridge and the drive causes a number of problems, like detection and timeout issues, getting stuck in UDMA33 mode, etc.

https://www.reddit.com/r/thinkpad/comments/ki … omment/ggp12s3/

I can't confirm if this is the problem though, I have inspected the board thoroughly and haven't found any such chip but it might be there somewhere. It might be possible to SATA mod it which would be the best thing to do but I don't have the skill to do that.

see what number HD Tach 3.x gives

https://i.imgur.com/jJByRRv.png
115.2MB/s

this suggests IAA should support 848P, but it'd be surprising if that would unlock ATA-133, because they'd be contradicting their own spec sheet. there doesn't seem to be much info out there if intel not bothering to support ATA-133 on any chipset was simply to push everyone towards SATA or there were other reasons for it as well.

hmm yeah it does say its compatible, weirdly it refuses to install either 2.2.2 or 2.2.3:
https://imgur.com/a/aXFXI0i

The 848P has more in common with the 865 series than the 845 series I think, if that helps. There's also a RAID version which doesn't say its compatible but I could try that too if I can find it. Doesn't work as expected, only for ICH5R and above.

I decided to try the initial release of XP without any Service Packs, with that it is configured to ATA-100 / UDMA5.

I found these modified intel files on MSFN, I think they're just to make later chipsets work though:
https://msfn.org/board/topic/163405-slipstrea … et-inf-drivers/

There's two folders in the zip labelled ICH23456 and ICH789A, both contains MACHINE.INF, MACHINE2.INF and MSHDC.INF, I installed 98SE using both but neither bought the SSD up to the ATA-133 spec.

Checking the contents of the SP3 disc there is a MACHINE.INF and MSHDC.INF that were last modified sometime in 2003, no MACHINE2.INF though. I tried with these 2 files anyway but the 98SE installer fails, it probably does need MACHINE2.INF as well. Will keep experimenting.