[dencorso]

Multibooter, on Apr 29 2008, 01:13 AM, said:

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.

Quote

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.

Quote

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

Quote

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.

This post has been edited by dencorso: 07 June 2008 - 08:08 PM

[Multibooter]

dencorso, on May 3 2008, 04:34 PM, said:

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]

Multibooter, on May 9 2008, 10:33 AM, said:

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.

This post has been edited by dencorso: 11 May 2008 - 10:27 PM

[jaclaz]

@dencorso

Thanks.

jaclaz

[RetroOS]

dencorso, on May 11 2008, 11:16 AM, said:

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!

This post has been edited by RetroOS: 12 May 2008 - 08:03 PM

[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).

This post has been edited by dencorso: 12 May 2008 - 01:02 PM

[rloew]

Quote

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.

Quote

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.

This post has been edited by rloew: 12 May 2008 - 03:47 PM

[RetroOS]

rloew, on May 12 2008, 06:52 PM, said:

...
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.

Wouldn't it be great if they were free to home users...
Afterall, Windows 9x users are a dying breed...

[rloew]

Quote

Wouldn't it be great if they were free to home users

That might have been OK if I had a lot of business customers. So far all of my customers have been home users.

Quote

Afterall, Windows 9x users are a dying breed

Maybe, but then there would be no point in developing Windows 9x Patches. I could work on the 2TB limit in Windows XP and Vista instead.

[dencorso]

rloew, on May 12 2008, 03:52 AM, said:

Quote

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.

I stand corrected. Thanks, rloew!
What I had in mind is that, for motherboards having VIA chipsets (specificaly the 8237 southbridge or any other compatible with it), anyone using the viasraid type drivers (link) is safe because they implement 48-bit LBA correctly. As for USB and FireWire (IEEE1394), they really use completely different access interfaces.

[Multibooter]

rloew, on May 11 2008, 11:52 PM, said:

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.

The real limitation on disk/partition size under Win98 is the disk checking software which works under Win98 plus the number of free drive letters.

About 2 years ago I shelved V-Com's DiskFixer v6 because when checking a 250GB HDD I got "Error occurred accessing disk" followed by a phony msg "session cancelled by user", terminating after nearly completing the File Allocation Table check.

MS ScanDisk has a 127GB limit, beyond that it refuses with the misleading err msg: Not enough memory available.

Norton Disk Doctor 2004 works Ok under Win98 with 750GB disks with partitions up to a maximum of 240GB [=258.177.794.048 bytes; 240.5GB partition size results in a blue screen when running NDD]. NDD 2005 I don't care about because it has a problem with large fonts. Any other reliable disk checking software for 1TB HDDs under Win98?

The next major hurdle to overcome for Win98 aficionados is not that much 52TB of HDDs, but rather the 4GB FAT32 file size limit. About 2 years ago I looked at WriteDVD! Pro http://www.softarch....ts/wdvdpro.html but it didn't convince me. If I remember right, this software, or maybe it was another UDF/DVD-RAM software, could also format HDDs with UDF, which doesn't have the 4GB file size limit. Files >4GB are not uncommon with eMule, because of some inconsiderate uploaders. One possible solution to circumvent the 4GB file size limitation might be to set eMule's download directory to a 9.4GB DVD-RAM drive http://computers.search.ebay.com/DVD-RAM-9...ters-Networking but the heavy disk access during eMule downloads may damage the expensive DVD-RAM drive quickly. Maybe the SCSI drives don't need a special Win98 driver. Here a good link re FAT16/32, NTSF & UDF http://download.microsoft.com/download/5/b.../LocFileSys.doc The ideal solution might be to format a 64GB USB stick with UDF and use it for the download directory of eMule, but this is another project ...

This post has been edited by Multibooter: 23 May 2008 - 02:29 AM

[Multibooter]

xrayer, on May 2 2008, 03:43 PM, said:

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.

I have shelved xmsdsk, at least for the moment. It looks like HimemX, 2GB of memory, Win98 & xmsdsk don't get along well together.

After I ran a modded standalone version of the 250MB game PokemonPlayIt!2 (2001) on the xmsdsk RAM-disk, the Nvidia Display selection had disappeared from the menu of the Nvidia system tray icon. After checking with Norton Disk Doctor, it indicated an error in the Extended partition table. After verifying with Partition Table Doctor, I decided to wipe the 750GB disk and restored a backup. I never had an Extended partition table error before, I was just afraid that the logical NTSF partitions in the Extended partition might also have been affected.

This post has been edited by Multibooter: 14 May 2008 - 10:00 PM

[Cyberguy]

I'm not sure if this is still relevant in this topic but I run Win98 on a PC with 1.5gb of ram & 256mb video card without problems.
To do this do the following.

Basically, with 1 Gb or less of RAM in the PC go to Msconfig and in the advanced tab choose the option that lets you limit the amount of RAM Win98 will use.

Check the box and type 999 in the number box.
Then apply and close.
Reboot the machine. If all is okay then shutdown the machine, add your extra RAM and reboot.

Your PC should work fine from here on, no need for RAM disks etc. Changing Vcache is about the only thing I also did,
I set Vcache value to MaxFileCache=128000.

Of course the extra RAM is there for when I run XP etc. Win98 doesn't use it.

This post has been edited by Cyberguy: 19 May 2008 - 08:41 AM

[RetroOS]

Cyberguy, on May 20 2008, 02:39 AM, said:

I'm not sure if this is still relevant in this topic but I run Win98 on a PC with 1.5gb of ram & 256mb video card without problems.
...

Welcome to MSFN Cyberguy! - One of the few remaining Windows 9x outposts!
And, welcome to the over 1GB of RAM with Windows 98 world!
I dual boot with 98SE and XP.

See below for information I posted on how I got 1.5GB of RAM working and also got 1.125GB usable in Windows 98SE:

http://www.msfn.org/board/VCACHE-fix-attem...288#entry732288

[Multibooter]

Multibooter, on Apr 28 2008, 09:13 PM, said:

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.

The Advanced Troubleshooting Settings page of the MS System Configuration Utility msconfig.exe is problematic with 2GB of RAM:

If you make ANY changes on this page [e.g. about ScanDisk] & then click Apply - Ok:

If the entry "Limiting memory to (max.possible:) 999MB" was selected: this will cause a change in System.ini
- the previous entry for MaxPhysPage will be remmed out: ;Rem TShoot MaxPhysPage=48000
- a new entry will be put into System.ini, e.g. MaxPhysPage=3E6FF
- there is NO notification by the system about the change in available memory, RAM will be reduced to 999MB
and a week later you may ask yourself: "Why did the additional 250MB of RAM disappear?"

If the entry "Limiting memory to (max.possible:) 999MB" was NOT selected
- in System.ini the previous entry for MaxPhysPage=48000 will be deleted by the system
- you will not be able to boot into Win98 anymore [until you re-enter under DOS the value of MaxPhysPage in System.ini]

LIST OF SOFTWARE WITH ISSUES WHEN 2GB OF MEMORY ARE INSTALLED:
Fast Defrag v2.30 [by AMS] cannot use automatic memory cleanup because of 2 err msgs after each cleanup
msconfig.exe changes in Advanced Troubleshooting Settings either delete MaxPhysPage entry or replaces it with 999MB, without notification
xmsdsk [RAMdisk software] when using the RAMdisk for the swapfile; when running programs from RAMdisk (e.g. games)

This post has been edited by Multibooter: 23 May 2008 - 03:21 AM

[rloew]

Quote

LIST OF SOFTWARE WITH ISSUES WHEN 2GB OF MEMORY ARE INSTALLED:
Fast Defrag v2.30 [by AMS] cannot use automatic memory cleanup because of 2 err msgs after each cleanup
msconfig.exe changes in Advanced Troubleshooting Settings either delete MaxPhysPage entry or replaces it with 999MB, without notification
xmsdsk [RAMdisk software] when using the RAMdisk for the swapfile; when running programs from RAMdisk (e.g. games)

I tested Fast Defrag 2.3.1 (reports 2.3) with my Patch to see if the problem was memory or the MaxPhysPage workaround.
I did not get error messages but the Cleaning Command would not display it's wait message and would never complete when there was too much memory.
Between 1280MB and 1664MB it would work once. With 1664MB or more RAM, it would never work.
This indicates that Fast Defrag has a problem handling large amounts of RAM.

The other two Programs have problems when used as a workaround. These problems do not exist when using my Patch instead of a workaround.
The problems are not related to the amount of memory.
My Patch enables all RAM to be used so MaxPhysPage is not needed. This eliminates the issue with MSCONFIG.EXE
Since the Patch enables all RAM to be used, there is no reason to use XMSDSK for Swap since better performance would be obtained by disabling Swap entirely.

[Mijzelf]

Quote

I have developed true 48 Bit versions of my Patches and a couple of workarounds to enable Windows 98 to utilize up to 52TB.

Doesn't W9x use a 32 bit sectoraddress internally?

[rloew]

Quote

Doesn't W9x use a 32 bit sectoraddress internally?

Device Drivers such as IOS.VXD and ESDI_506.PDR use 64-Bit Sector Arguments. The Interrupt 13 Extensions (DOS) also use 64-Bit Sector Numbers.
The existing ESDI_506.PDR files, including LLXX's version and my High Capacity Disk Patch, ignore the upper 32 Bits.
I created versions of my High Capacity Disk Patch and BOOTMAN Overlay to use the additional 16 Bits supported by the 48-Bit LBA Protocol.

The IO.SYS and VFAT.VXD Filesystem Drivers use 32 Bits. I altered the way Logical Sector Numbers are mapped to Physical Sector Numbers. This allowed me to create Partitions of up to 2TB starting above the 2TB limit. 24 Partitions can be defined to provide a total space of 48TB.

It may be possible to redo Cluster mapping. If so, the size of a single Partition could be increased to at least 32TB using 256 Sectors per Cluster.
I have already developed Patches for IO.SYS and VFAT.VXD that support 256 Sectors per Cluster.

This post has been edited by rloew: 27 May 2008 - 11:40 PM

[vick1111]

Rloew Memory patch
_____________________

I have tried the memory patch of Rloew without success.
I have a windows98SE italian version.
It works only on english version?

CORRECTION
__________________
Ok after reading the post (following this one) of rloew I tried the demo patch again in the new version and it allowed me to see 2Gb of RAM on win98se. I started some programs in the 10 minutes and everythings seemed to work fine.

I am not buyng now this patch cause 1 GB of Ram is enough to cover all my memory needs for now in win98.

I encourage rloew to write some documentation about how he solved the problem. This documentation could be more valuable than the code in itself.


(Anyway I guess there can be a way of making monney out of it for him if he decide to give out code as open source. Any suggestion or comment? )

This post has been edited by vick1111: 29 May 2008 - 05:31 AM