Help: I need to Get 2GB installed RAM working in Win98SE

[dencorso]

Hi, Multibooter:

1)On thinking about them, your numbers make sense: 1151-512 = 639 and 1024-512 = 512

So, simply omit the /MAX=xxxxxxxx from HIMEM.EXE command, and things should be solved!

Also, do try XMSDSK with and without the /T switch, and tell us what happens.

2) After setting the swapfile to RAMdrive z: with PagingDrive=Z: I got shutdown problems:

- Win98SE hangs after selecting either Shut Down, Restart or Restart in MS-DOS mode, with a blinking cursor on a black screen

- the selection Standby is not displayed in the Shut Down Windows menu anymore

xrayer possibly didn't notice, since the GeForce driver series 80 always has shutdown problems anyway with newer GeForce cards

This matter you'll have to investigate further once you solve the one above. This is fully unexplored land. But do tell me: if you put the swapfile elsewhere, do these problems again disappear?

3) I have seen in several system.ini files here the use of ConservativeSwapfileUsage=1. Does this really do anything under Win98SE? Microsoft only lists Windows 98 Standard Edition, NOT Windows Second Edition http://support.microsoft.com/kb/223294

If you look inside vmm.vxd v. 4.10.0 2226, you'll find ConservativeSwapfileUsage starting at file offset 5287C, so not only vmm.vxd knows about it, but pays attention to it on Win 98SE startup. So, work it does, but with the amount of memory you have, I recommend you use ConservativeSwapfileUsage=0 instead, as I do.

4) Has anybody tried any memory defragmentation software with 2GB RAM plus io.sys patched with w98iopat.exe, plus xmsdsk, plus swapfile location=ramdisk, with AGP vs PCI graphics card?

Also unexplored land. I'll sure be looking forward to hearing your findings about it.

Good luck!

[Multibooter]

Hi, Multibooter:

1)On thinking about them, your numbers make sense: 1151-512 = 639 and 1024-512 = 512

So, simply omit the /MAX=xxxxxxxx from HIMEM.EXE command, and things should be solved!

Also, do try XMSDSK with and without the /T switch, and tell us what happens.

Thanks dencorso,

removing the /MAX switch from himem.exe in config.sys solved the problem of the disappearing RAM.

config.sys with device=\...\himem.exe /NUMHANDLES=64 /VERBOSE is sufficient, /MAX is not needed

autoexec.bat WITH the /t parameter \...\xmsdsk.exe 655360 z: /t /y /c1 give RAM 1150MB and RAM drive 639MB

autoexec.bat WITHOUT the /t parameter \...\xmsdsk.exe 655360 z: /y /c1 give only RAM 512MB and RAM drive 639MB

The /t parameter is therefore necessary when 2GB of memory are installed.

[Multibooter]

2) After setting the swapfile to RAMdrive z: with PagingDrive=Z: I got shutdown problems:

- Win98SE hangs after selecting either Shut Down, Restart or Restart in MS-DOS mode, with a blinking cursor on a black screen

- the selection Standby is not displayed in the Shut Down Windows menu anymore

This matter you'll have to investigate further once you solve the one above. This is fully unexplored land. But do tell me: if you put the swapfile elsewhere, do these problems again disappear?

I have found no solution to the shutdown problems when the swap file is located on RAM drive Z:

There are NO shutdown problems when the swap file is located on another drive.

Software does not function properly when the swap file is on RAM drive Z:. For example, Sims2 when mounted on virtual Alcohol drive V: hangs after the logo comes up. On the other hand, when the swap file is located on a hard drive Sims2 functions as usual. I would therefore not recommend to put the swap file onto the RAM drive.

It is interesting to note that the memory defragmentation software Fast Defrag 2 http://www.amsn.ro/ gets confused by the memory between 1150MB & 2048MB. With 2GB of memory installed, it reports:

Total Physical Memory: 1150MB

Virtual Memory Size: 898MB (2048-1150=898!!) [actual size of win386.swp: 0 bytes]

BTW Performance - Virtual Memory - Hard Disk D [location of the swap file] is indicated as "D:\-9480MB" (negative sign!) even if the actual size is 130017MB =about 126GB. ScanDisk has a 127 GB limit, the ATA protocol a 137GB limit, is there any limitation of the Win98 swap file? Win98 has chosen by itself to use the D: partition (FAT32, 126GB) instead of the C: partition (FAT16, 1.99GB)

All the above questionmarks regarding the Win98 swap file would suggest that when using 2GBs of memory it's best not to enter unknown territory with the swap file, and under no circumstance put it onto a RAM drive.

Fast Defrag 2 seems to defrag memory ok with 2GB installed, although an annoying error msg "AMS specific__debuginteger function", displaying the value 10, comes up everytime after memory is deframented: displayed once when there is no RAM drive installed, displayed twice when there is a RAM drive Z: installed.

Did anybody find 2GB-memory-bugs in other Win98 software? It might be useful to set up a list of software running bug-free, and software which is buggy/unreliable with 2GB.

[RetroOS]

...ScanDisk has a 127 GB limit, the ATA protocol a 137GB limit...

Actually, the 36-bit 28-bit LBA ATA specification has a limit of under 128GB or under 137438953472 bytes...

It all depends who's selling the size!

Hard drive manufacturers use 10^9 (1000000000) bytes for each 'GB' since it 'looks' bigger to the buyer!

Everyone else uses 2^30 (1073741824) bytes per GB since computers are binary (2) based.

Originally 1KB was decided as 2^10 since it kind of looked like a base-10 number and was close to 1000 (1024).

Therefore 1MB was 2^20, 1GB was 2^30, and so on, not 10^3, 10^6, 10^9...

So, back to the original concept, 128GB or 137GB... Who's selling?

When you buy that 1TB disk, is it 1TB or is it actually 931GB?

Windows Explorer and every other piece of software will give the 'correct' base-2 sizes (converted to base-10 for us humans of course!).

The only ones who use base-10 '000' for computer storage calculations are storage hardware manufacturers!

Afterall, you don't go and buy a 537MB stick of RAM, you buy a 512MB stick.

When drive sizes were smaller, they could explain away the descrepancies by terms like "the format takes up space" and "Windows does not report all the space"...

But now, the descrepancy between the manufacturer size and the real size are getting noticable...

So, next time that sales person tries to pull a fast one on you about the formatting, just tell him that actually the labeled drive size is the "formatted" size, and that hard drive manufacturers need to catch up with the 80s (and then the 21st century!).

Edited May 13, 2008 by RetroOS

[dencorso]

Hi, Multibooter!

autoexec.bat WITH the /t parameter \...\xmsdsk.exe 655360 z: /t /y /c1 give RAM 1150MB and RAM drive 639MB

autoexec.bat WITHOUT the /t parameter \...\xmsdsk.exe 655360 z: /y /c1 give only RAM 512MB and RAM drive 639MB

The /t parameter is therefore necessary when 2GB of memory are installed.

Thanks for testing and reporting it. You rock!

[xrayer]

C:\OS\COMMAND\label K: scorpion

Thanks. I didn't know about this feature. But I disabled pagefile on ramdisk for stability reasons.

Sometimes I work with huge sound files in goldwave and 800MB of pagefile wasn't enough.

But I also had problems when copying a big file, say 600MB to ramdrive - in about 60% of progess

system falls to BSOD. I tied it again with different file size copied. For less about 400MB it didn't fail.

I didn't figure out the source of unstability so I disabled ramdisk and put page file back to HDD.

As I have quite fast SATA drive it's not problem.

[RetroOS]

...But I disabled pagefile on ramdisk for stability reasons.

...

That makes sense since XMSDSK is a DOS driver and as far as Windows is concerned, it is a Real Mode driver.

So... Windows will be switching between Protected and Real modes when ever the RAM drive is accessed...

This would cause real contention in the Windows kernel if the switching happened with paging...

The ideal option would be a RAM Drive VxD that could bypass VMM and access the addressable RAM outside of Windows control...

Dream on they say!

[dencorso]

ScanDisk has a 127 GB limit, the ATA protocol a 137GB limit, is there any limitation of the Win98 swap file? Win98 has chosen by itself to use the D: partition (FAT32, 126GB) instead of the C: partition (FAT16, 1.99GB)

It is actually the same limit in both cases 137 GB = 137000000000 / (1000*1000*1000) and 127 GB = 137000000000 / (1024*1024*1024)... To be less confusing we ought to say 137 GB = 127 GiB... But GiB arrived too late, I think, so almost nobody uses it. See "Binary Prefix" in the Wikipedia.

All the above questionmarks regarding the Win98 swap file would suggest that when using 2GBs of memory it's best not to enter unknown territory with the swap file, and under no circumstance put it onto a RAM drive.

Yes. That's my opinion too.

Fast Defrag 2 seems to defrag memory ok with 2GB installed, although an annoying error msg "AMS specific__debuginteger function", displaying the value 10, comes up everytime after memory is deframented: displayed once when there is no RAM drive installed, displayed twice when there is a RAM drive Z: installed.

You don't need very constant defragging with such a huge memory. I, with 1.5 GiB, use a command-line defragger, but only once in a while. You might find it useful. Download it here: Memdefrag

Did anybody find 2GB-memory-bugs in other Win98 software? It might be useful to set up a list of software running bug-free, and software which is buggy/unreliable with 2GB.

I think it's still too early to know. I know of about ten people using more than 1 GiB: RLoew, RetroOS, xRayeR, yourself, myself, eidenk, Offler, StarRiver and vick1111 are the names that come to my mind, right now. There may be some others I can't remember at the moment. And most of us have stepped over 1 GiB quite recently... So reports should begin appearing at any moment... in fact, you've just started it. Edited June 8, 2008 by dencorso

[Multibooter]

It is actually the same limit in both cases 137 GB = 137000000000 / (1000*1000*1000) and 127 GB = 137000000000 / (1024*1024*1024)... To be less confusing we ought to say 137 GB = 127 GiB... But GiB arrived too late, I think, so almost nobody uses it. See "Binary Prefix" in the Wikipedia.

You're right, I didn't read critically enough Mosaddique's otherwise excellent article "Working with large hard drives - the issues and the limits"

By the way, Win98 CAN access an EXTENDED partition >128GB (e.g. on a 750GB HDD an extended partition of 695.5GB, consisting of a 126GB FAT32 logical partition D: and an (invisible) logical 569.6GB NTSF partition E:). Also, the 128GB limit doesn't apply to USB HDDs.

[jaclaz]

Also, the 128GB limit doesn't apply to USB HDDs.

Really?

Can you elaborate on that?

jaclaz

[dencorso]

I can. The 128 GiB limit refers to using 28-bit LBA and is a BIOS limit, related only to the IDE a.k.a PATA motherboard interface. If your machine's BIOS supports 48-bit LBA, by using LLXX's patched ESDI_506.PDR (usually ver 4.10.0.2225) you don't suffer from it. See also 48bitlba.com for more on it. If, on the other hand, the BIOS doesn't support 48-bit LBA, then you have two options: get a BIOS update from the manufacturer's site (or buy one from e-Support, in case the manufacturer doesn't offer one anymore) or let the motherboard native adapters alone and install an add-on IDE card, say, from Promise, for instance. Now, as I said, that's a PATA only issue. SATA, USB and FireWire (IEEE1394) use completely different access interfaces, so there is no 128 GiB limit for them. HTH.

Another interesting place to visit is www.ata-atapi.com: they have lots of interesting info on PATA, SATA and SCSI.

Edited May 12, 2008 by dencorso

[jaclaz]

@dencorso

Thanks.

jaclaz

[RetroOS]

I can. The 128 GiB limit refers to using 32-bit LBA and is a BIOS limit...

dencorso, you mean 36-bit 28-bit LBA of course...

EDIT: hehe, thanks dencorso for counter-correcting me!

It is in fact 28-bit LBA addressing. 36 bits is needed to represent all the bytes, but is never used when accessing LBA blocks on the hard drive...

I'm confusing myself!

Edited May 13, 2008 by RetroOS

[dencorso]

@RetroOs:

Thanks for the heads up! I've now corrected my previous post.

Yet, I did mean 32-bit, because I was thinking about the size of the variable all Windows (both 9x/ME and NT/XP families) use to store the LBA sector address... But 2^32=4294967296 and, of course, 1 sector = 512 bytes, so this would mean the total number of addressable bytes would be 512*2^32=2199023255552 (= 2.2 TB or 2.0 TiB)... In fact, despite the fact that the variable width is 32 bits, only the first 28 bits are used in the 28-bit LBA, the upper four being always zero. This results in 512*2^28=137438953472 (= 137.4 GB or 128.0 GiB), because the 28-bit LBA adapter will only accept 28 bits... See: http://www.48bitlba.com/overview.htm.

Now, this has one interesting consequence: LLXX's fixed ESDI_506.PDR is coded to use the upper four bytes, but no more than that, so while 48-bit LBA potencially provides addressability to 144.1 PB (= 128.0 PiB), LLXX fix is still limited to 32 bits (as also is FAT32, see the wikipedia FAT32 entry ), providing addressability to no more than 2.2 TB (= 2.0 TiB)... That's what LLXX meant when she wrote "Addressing to 2048Gb is possible (limit of FAT32)" in post #1 of Enable48BitLBA-Break-the-137Gb-barrier. However, nowadays, that doesn't seem so huge to me as it did last year, and in fact we already do have a member (Marius '95) using one 1 TB HDD at the moment.

For more on FAT32 and related subjects, read that interesting document, by Shrishail Rana, that I've attached to a previous post (link).

Edited May 12, 2008 by dencorso

[rloew]

Now, as I said, that's a PATA only issue. SATA, USB and FireWire (IEEE1394) use completely different access interfaces, so there is no 128 GiB limit for them.

SATA uses nearly the same commands as PATA so it is subject to the same issues as PATA. Most SATA controllers come with their own drivers so 48-Bit LBA support depeds on the driver used. Being a newer standard, it is more likely that a SATA driver would support 48-Bit LBA but there are no guarantees expecially with older drivers.

Some motherboards with SATA built into their chipsets are compatable with the ESDI_506.PDR driver. If ESDI_506.PDR is used then there will be no support for 48-Bit LBA. In addition, the MSHDC.INF file will incorrectly configure some of these SATA drivers causing problems especially when IDE and SATA drives are used together.

Now, this has one interesting consequence: LLXX's fixed ESDI_506.PDR is coded to use the upper four bytes, but no more than that, so while 48-bit LBA potencially provides addressability to 144.1 PB (= 128.0 PiB), LLXX fix is still limited to 32 bits (as also is FAT32, see the wikipedia FAT32 entry ), providing addressability to no more than 2.2 TB (= 2.0 TiB)... That's what LLXX meant when she wrote "Addressing to 2048Gb is possible (limit of FAT32)" in post #1 of Enable48BitLBA-Break-the-137Gb-barrier. However, nowadays, that doesn't seem so huge to me as it did last year, and in fact we already do have a member (Marius '95) using one 1 TB HDD at the moment.

In anticipation of the 2TB limit being reached, I have developed true 48 Bit versions of my Patches and a couple of workarounds to enable Windows 98 to utilize up to 52TB.

Edited May 12, 2008 by rloew