Per @DosFreak's instructions I want to address @BloodyCactus post where he states:

"xmsdsk. call it from autoexec bat and not config sys, to bypass compatability mode and warnings and stuff."

This idea intrigued me, so I spent the better part of the day playing around with XMSDSK until I realized you can't use it with more than a 700MB or so partition... Anything larger and Windows sees the partition and its nonexistent contents as gibberish, if Windows boots at all with it activated.

My system is a rather strange one. It's a Pentium 4 with 2GB of ECC SDRAM (supported by 845 Chipset and enabled in BIOS)... Until now I've just been wasting a good portion of that, using RLOEW's excellent LIMITMEM to shrink available memory to 256mb... Having only a 500-700mb ramdisk swap with XMSDSK when all that spare RAM was just sitting there did not sit well. This system is meant to be a "slow" Win98 system, DirectX7 and TNT2. I chose this platform because I wanted the updated ICH of the Pentium 4 platform for my SSD.

Luckily, I discovered that RLOEW had a much better solution... It's a three part process... First, you load his HIMEMEX.SYS before HIMEM.SYS in CONFIG.SYS with the /A switch (in my case, "/A:1C0000" - which is 1,835,008 or 1792MB in HEX). This allocated the spare RAM (in my case I only want 256MB available for Windows, and the remainder (1,792MB - or 1C0000 in HEX) for the RAMDISK. The allocation also has the same effect as LIMITMEM (which is no longer needed), not only making the majority of the RAM invisible to Windows during the boot process, thus negating the need for any patches or hacks, but also working in tandem with the next step, which is to assign that allocated memory by invoking RLOEW's RAMDSK32.COM from Autoexec.bat - in my case "RAMDSK32.COM X: 1835008" (RAMDSK32 takes the RAM number in kilobits. 1792 x 1024 = 1,835,008).

Then we proceed to copy PROTHOOK.VXD to C:\WINDOWS\SYSTEM, and to add the line "device=prothook.vxd" under [386Enh] in SYSTEM.INI and then you're able to set the swapfile in Windows to the new drive accordingly.

Windows will show the drive as being in compatibility mode, but that's unimportant. ATTO demonstrates that the performance is in fact quite good indeed:

I guess if you're using the earlier southbridge on the BX chipset and your storage device is stuck at 33MB/sec, then this is at least a good boost for the swap file, which should run at these higher rates regardless of the southbridge, because this speed is not related to the southbridge's IDE controller. But then again, you do need a *good* motherboard to properly handle that much RAM...