Hmm 3 primary on same drive and Win98SE or DOS 7.1 has no issues ? Might be the beer but am sure I tried that and had horrid issues, yet making two in an extended partition worked fine. Probably am not thinking clearly but why 3 Primaries on same drive ?

Horun wrote on 2020-05-05, 03:40:

Hmm 3 primary on same drive and Win98SE or DOS 7.1 has no issues ? Might be the beer but am sure I tried that and had horrid issues, yet making two in an extended partition worked fine. Probably am not thinking clearly but why 3 Primaries on same drive ?

I have been running like that for years on a hard drive (before the SSD) with no issues (there can be up to 4 primary partitions on an MBR disk and as long as Windows 98 SE is on the first one, it's happy) . I never really asked myself the question as to why not, until now . Maybe I'm too used to running that way under Linux .
That being said, there was only test DATA in the second and third partitions, so I wiped them and created an extended partition and one 120GB logical drive in it, put some test data in it, ran TRIM and it corrupted the logical drive (actual wiped it from existence) , so I am pretty much certain the multiple primary partitions are not the issue .

fstrim does not seem to work (says operation not supported) under Linux on those FAT32 volumes . I don't know if it's because of a lack of FAT32 support or if t has something to do with the IDE to SATA adapter .

Apparently, Windows only knows how to trim NTFS volumes (correct me if I'm wrong) .

So short of finding a SATA interface card that works under Windows 98 SE and supports TRIM to TRIM.EXE , it will be pretty hard to determine where the fault lies .

Ok, Thanks. Back in the real Win98 days you could not create multi-primaries on one HD using anything from Microsoft included with their Win9x OS. Was just curious if that could be the issue.

Horun wrote on 2020-05-05, 04:26:

Ok, Thanks. Back in the real Win98 days you could not create multi-primaries on one HD using anything from Microsoft included with their Win9x OS. Was just curious if that could be the issue.

Windows' DOS 7.1 fdisk does not let you create them, but reads/writes them just fine .

On another note, I found an "affordable" FastTrak S150 TX2plus (55 Canadian dollars), so I guess I will find out whether the issue is the IDE to SATA adapter or not in a couple of days/weeks .

I found an ALi M5281 based SATA card in my scrap heap . TRIM.EXE does not like that one and one of the SATA ports on it is shot anyway .

I ordered a Startech PCI1PEX1 too . Maybe I can run a PCI Express AHCI SATA controller in a Pentium 3 under Windows 98 SE .

darry wrote on 2020-05-05, 06:37:

I ordered a Startech PCI1PEX1 too . Maybe I can run a PCI Express AHCI SATA controller in a Pentium 3 under Windows 98 SE .

Did some testing with an ASM1061 based controller in AHCI mode on an PLX based bridge some days ago. The systems (Pentium II 333 on an Abit LX6 and Penium III-S @1050MHz on an Intel SE440BX-2) wouldn't boot of the SSD unless I used Plop boot manager. I had troubles nothing but trouble trying to install Windows, but the Vertex 30GB SSD also acted up on an Adaptec AAR-1210SA running stock SiI 3512 firmware. A Crucial C300 64GB worked much better on the Adaptec card so maybe I'll also test that one on the ASM1061.

Kamerat wrote on 2020-05-05, 08:58:

darry wrote on 2020-05-05, 06:37:

I ordered a Startech PCI1PEX1 too . Maybe I can run a PCI Express AHCI SATA controller in a Pentium 3 under Windows 98 SE .

Did some testing with an ASM1061 based controller in AHCI mode on an PLX based bridge some days ago. The systems (Pentium II 333 on an Abit LX6 and Penium III-S @1050MHz on an Intel SE440BX-2) wouldn't boot of the SSD unless I used Plop boot manager. I had troubles nothing but trouble trying to install Windows, but the Vertex 30GB SSD also acted up on an Adaptec AAR-1210SA running stock SiI 3512 firmware. A Crucial C300 64GB worked much better on the Adaptec card so maybe I'll also test that one on the ASM1061.

The Startech adapter uses a Pericom chip, so I may have different luck . That said, I had not thought of the option ROM question. This machine would only have 1 drive, so I can't use a boot manager. As for cards to try, I have an ASM1061, which is AHCI, and two othe cards (Marvell and Jmicron based) which may or may not be AHCI; I will have to check .

This is getting expensive, but it is fun .

Well this is interesting.

If I create a second partition, whether primary or extended with a logical volume, using FreeDOS' FDISK 1.2.1 command , TRIM.EXE corrupts it when run on the first partition .
BUT
When I create a second primary partition extended partition with a logical volume using Windows 10 disk management tool (formatted to FAT32 using Easeus Partition Master, but I do not think the formatting tool matters), or create an extended partition with a FAT32 logical volume using EASEUS Partition Master, I am unable to corrupt anything with TRIM.EXE .

So FreeDOS FDISK does something in a way that TRIM.EXE does not like . Whether that's a bug in FreeDOS FDISK 1.2.1 and 1.3.1 BETA (tried both) or TRIM.EXE, I do not know .

EDIT: Creating a second FAT32 primary partition using Easeus Partition Master also works with TRIM.EXE without corruption .

Moral of the story : make sure you have backups when using TRIM.EXE (especially for the first time) .

EDIT2 : For the fun of it, I tried using Easeus Partition Master to FAT32 format partitions created with FreeDOS FDISK 1.3.1 . Easeus Partition Master said there were partition errors or anomalies (forgot exact wording) . Partition Master is by no means a reference in this matter, but still .

EDIT 3: Tried Freedos XFDISK . It's a BETA and it shows : it won't let me enter 6 digits in the partition size field (field is pre-populated with max value and leftmost digit cannot be changed) .

EDIT 4 : Linux fdisk (lubuntu-16.04.3) works well too . TRIM.EXE has no issues . I also just noticed that Primary partitions 2 and greater, when created in Windows 10 disk management console or Easeus Partition Master, are only visible in Windows 98 SE , not in DOS 7.1 (hidden flag is set) . All primary partitions created by Linux fdisk are visible in both DOS 7.1 and Windows 98SE and properly aligned as well .

I played around in Lubuntu 16.04 again and can confirm that the fstrim works on the ICH2 IDE port through an IDE to SATA adapter, but not for FAT32 partitions . I actually created an NTFS partition and ran fstrim successfully against it as a test .

While waiting for the PCI1PEX1 to arrive, I ran some tests on an X58 board (Supermicro X8SAX) with a few PCI Express SATA controllers :

Jmicron JMB363 with AHCI mode (with patch) and in NON RAID mode (original JMICRON BIOS)
ASM1061 (natively AHCI)
Marvell 88SE9230 (native AHCI)

TRIM.EXE under DOS did not work for any of those and did not work with the ICH10R onboard controller in AHCI mode either (ICH10R did work in IDE mode, though) .

Both the ASM1061 and Marvel 88SE9230 BIOSes occupied 10K of conventional RAM or less . The Jmicron one did not use any conventional memory at all .

I will not be running any other tests until I receive the PCI1PEX1 and the Promise Fasttrak S150 TX2 .

OK, so I ran some more tests anyway. It turns out that, at least on my board UMBPCI (3.89) and a Promise Ultra 133 TX2 are flaky together .
2 scenarios .
a) With an AGP Geforce FX 5900 as a primary video card, and while booting off the Ultra133 TX2, UMBPCI freezes the machine while loading (no matter what memory range I restrain it to; I've tried several between D800h and EBFFh which UMBCHK says are OK). No such issue with the same controller with a PCI Voodoo 3 as primary card .
b) With the Voodoo 3 as primary , still booting off the Ultra133 TX2 with UMBPCI loaded, I can get CTMOUSE 2.04 to freeze the system systematically at load time. This is while using a PS/2 mouse .

AFAIK, a PS/2 mouse does not use DMA and the 815 chipset has no issues with ISA DMA in UMBs anyway .

None of these issue can be reproduced when using the ICH2 controller (Promise controller removed) .

Tentative conclusion so far : UMBCHK and the equivalent routines in UMBPCI do not correctly ID upper memory addresses used by the Promise Ultra133 TX2 BIOS (and possibly the FX5900's VGA BIOS) at least on my board .

Next step will probably be to analyze the memory map using MSD.EXE with and without the Promise controller and with each of the video cards (4 scenarios) .

Maybe I should start a new thread for UMBPCI issues . That's assuming anybody's interested .

I got the PC1PEX1 .
I can't fit the Marvell card in it (PCIEX x2 card, adapter is x1).
When either ASM1061 or JMB363 is installed, floppy seeks at boot are faster than normal . Also Speedsys detects my 1400MHz as a 1600Mhz, so definite timing issues .
Both cards actually boot (option ROM works) .

The JMB363 corrupts the disk joyfully . The ASM1061 is slow (20MB/sec) .

So at least in my board, PCI1PEX1 is a dead end so far .

Oh, and TRIM.EXE does not work with either.

For anyone out there using a TRIM.EXE on an older (Pre-ICH) platform, are you able to run it successfully with an add-in controller?

I installed a Promise SATA150 TX2 card, and I'm getting this error when running trim:

Cannot Get Disk Info

Which the README describes as "BIOS does not report Drive Information".

It works fine with the Marvell SATA-IDE adapter though, connected to the on-board IDE.

Motherboard is an Asus P2B-S.

mockingbird wrote on 2021-09-01, 20:54:

For anyone out there using a TRIM.EXE on an older (Pre-ICH) platform, are you able to run it successfully with an add-in control […]
Show full quote

For anyone out there using a TRIM.EXE on an older (Pre-ICH) platform, are you able to run it successfully with an add-in controller?

I installed a Promise SATA150 TX2 card, and I'm getting this error when running trim:

Cannot Get Disk Info

Which the README describes as "BIOS does not report Drive Information".

It works fine with the Marvell SATA-IDE adapter though, connected to the on-board IDE.

Motherboard is an Asus P2B-S.

Trim.exe does work on a Promise Ultra133 TX2 + JMicron IDE to SATA converter . See Promise Ultra133 TX2 plus Jmicron JMD330 (IDE to SATA) under W98SE

I don't recall if I ever tried it when I had a working Promise SATA150 TX2 . Incidentally, Trim does not work on the SIL3114 based SATA controllers that I have tried .

darry wrote on 2021-09-01, 22:21:

Trim.exe does work on a Promise Ultra133 TX2 + JMicron IDE to SATA converter . See Promise Ultra133 TX2 plus Jmicron JMD330 (IDE to SATA) under W98SE

I don't recall if I ever tried it when I had a working Promise SATA150 TX2 . Incidentally, Trim does not work on the SIL3114 based SATA controllers that I have tried .

Confirmed... I just tested with the Ultra133 TX2 and the Marvell SATA to IDE adapter...

Let's clarify the terms here... The question of whether TRIM.EXE will work is two-fold:

1) Will the controller BIOS hook into the system BIOS in a way that is compatible with TRIM.EXE
2) If it hooks in correctly and is recognized by TRIM.EXE, will it then also pass the TRIM command through

I just tried the SIL0680 and ITE8212F, neither OpROM loaded on my P2B-S. I don't know, maybe there's something wrong with my board.

I could test this further with a different board, or perhaps even a much more modern board with PCI, but what would be the point. The newer boards have SATA and TRIM.EXE works fine with any ICH iteration AFAIK.

Ok, so the Ultra133 TX2 + Marvell adapter it is.

I also have an Ultra100 here, I may test that as well just for fun.

The ITE8212F was a no go, switched slots and the OpROM worked. So did the Ultra100. But the Ultra100 was also a no go. TRIM.EXE starts but then hangs on TRIM.

So the best combo is a Marvell adapter plus an Ultra133 TX2 card.

But although I get the "Done" message from TRIM.EXE, I haven't yet verified if it's not corrupting the disk. I'll report back.

Update:

The Ultra133 TX2 did not play nice with two different BX systems (motherboards). The card initializes fine and sees the drives (primary master mechanical HDD, primary slave marvell adapter), but it corrupts the data on the mechanical drives (not using trim or anything, it just corrupts data out of the blue).

Looking at very old internet posts, it seems this was a common issue with these cards.

So back to the on-board ports it is... UDMA2 should be enough for what this system is going to be used for. I may update the BIOS on the card some day and try again.