Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


tillewolle

HD + AC97 audio & beyond the 137GB/128GiB barrier

Recommended Posts

ACPI support in Windows 98 SE is unfinished and causes problems. APM does the same things as ACPI and actually works. This includes automatically shutting down without seeing the "You may now shutdown this computer" message, so there is no real loss of functionality by switching to APM, even on older hardware. This of course does not apply to newer operating systems :)

ACPI in 98SE is enabled by default if the BIOS date is later than 12/02/1999.

On 12/11/2019 at 7:04 PM, dencorso said:

Caveat emptor! That is *not* true. It has been discussed so many times, that the dead horse became minced meat. One does need either BHDD31 (which is based on the LLXX patch) or RLoew's patch that is now free. More info at the link in my signature and all around the 9x/ME forum.

Umm...I had Win98SE installed on a less than 137GB partition on my Toshiba P300 1TB HDD with MBR type, connected to the ASRock H110M-DVS R3.0 AHCI only motherboard.
The partition was put at the beginning (this is the important part) and made active. The rest of the space was filled with an NTFS partition, so two partitions in total, one FAT32 and one NTFS.

Win98SE in that case did not use the ESDI_506.PDR at all, and there was no sign of any data corruption, even before installing the AHCI driver.

Starman also says this is the case: https://thestarman.pcministry.com/asm/mbr/Limits.htm#137

Are you saying that ESDI_506.PDR file prevents Win98SE to install/boot/run when it detects a large drive, even if the Win98SE partition is within the limit?

From my experience with other hardware, the ESDI patch is required when the system hangs at initializing it (in BOOTLOG.TXT), OR you want to avoid the data corruption if you have a larger than 137GB partition.

But one has no correlation (IMO) with the other. We might have had a misunderstanding here I think.

Edited by MrMateczko

Share this post


Link to post
Share on other sites

If the disk is IDE, it'll always use ESDI_506.PDR. One can use any size of partition although I'm not sure whether IDE HDDs > 500 GB were ever produced. If the disk is SATA, and the mobo supports IDE compatibility mode, then both 137 GB and SATA patches must be applied. If the hdd is SATA and the controller uses AHCI mode, then RLoew's AHCI driver is required. A 137 GB FAT partition *at the begining* of an arbitrarily sized SATA disk  with the rest of the rest of it in an NTFS partition will work until one gives 9x/ME an NTFS driver, then it'll be corrupts the 1st time 9x/ME tries to access the NTFS partition. If one never gives an NTFS driver  to 9x/ME, there's no risk of corruption. But, in any case, without RLoew's AHCI driver, the ESDI_506.PDR will not be used in AHCI mode, so all access wil be in DOS 16-bit compatibility mode, slow as molasses. It can run, but it'll be like a 4-clinder car runing on one or two cylinders only: bad and sluggish. :wacko: Moreover, if one puts the 137 GB partition at the end of the HDD, instead of the beginning of it, then corruption will occur in unpatched systems, even in DOS 16-bit compatibility mode.

Share this post


Link to post
Share on other sites
2 hours ago, dencorso said:

If the disk is SATA, and the mobo supports IDE compatibility mode, then both 137 GB and SATA patches must be applied.

That is not true from my experience.

Sure, the 137GB patch is always required if you want a partition bigger than 137GB without data corruption.

But the SATA patch (not AHCI driver) is not always required, this varies between motherboards.
 

Going back on topic, @tillewolle if you encounter problems, apply the SATA patch from here:

https://archive.org/details/PTCHSATA

Share this post


Link to post
Share on other sites
2 hours ago, MrMateczko said:

That is not true from my experience.

Probably because you alway used a partition in the begining of the disk. Else (= a partition at the end of the disk), the 137 GB is required anyway, even if the partition is smaller than 137 GB... what counts is the number of bits necessary to represent the addresses correctly, not the size per se.

Share this post


Link to post
Share on other sites

Sigh, all that stuff about hard disk limits and probs I've been wondering about for years, but just can't get "system" stuff memorized. Too complicated and over my head and especially just way too much stuff, only for use once in a blue moon and a week later forgotten again :-( Finally awhile back, had the impression that even without all those updated system commands (scandisk etc) all is safe if simply no partition is bigger as 137GB. But now have read a few posts above, slightly shocked again, that it were a dead horse and not true, so back to square one. Sigh. And now this:

dencorso said:
> Moreover, if one puts the 137 GB partition at the end of the HDD, instead of the beginning of it,
> then corruption will occur in unpatched systems, even in DOS 16-bit compatibility mode.

Still riddling and trying to understand... so a new theory/guess:
could this perhaps mean that still everything is safe if all partitions are smaller as 137GB, just as long as the SYSTEM is in the first one??

Share this post


Link to post
Share on other sites

So to conclude:

137GB patch is required if you have a Win98SE partition that exists (in part or fully) beyond the first 137GB portion of the disk, regardless how big it is.

In other words, if Win98SE needs to access any data beyond the 137GB position, counting from the beginning, it is needed.

Yes, I always made 98SE partitions at the beginning of the disk. Seems like the easiest thing to avoid all problems.

Share this post


Link to post
Share on other sites
On 12/13/2019 at 1:03 AM, tillewolle said:

Install using the command "setup /p i" (note the spaces) from your 98 CD or from the folder on your HDD. This will force 98 to use the older APM standard rather than ACPI (ACPI causes many issues on newer systems not designed with Windows 9x in mind). Running automated setup from the CD just runs "setup" without the switches, and thus leaves ACPI enabled.

I tried this method a few times but I am not getting it to run.

Made a folder with the content of the win98se setup cd and added the ESDI_506.PDR

Burned on a regular CD-R with ImgBurn 2.5.8.0

format c:

On bootup I get the command prompt but I am not able to switch to D: to start setup /p i

 

Share this post


Link to post
Share on other sites

MrMateczko said:
> 137GB patch is required if you have a Win98SE partition that exists (in part or fully) beyond
> the first 137GB portion of the disk, regardless how big it is.
> In other words, if Win98SE needs to access any data beyond the 137GB position,
> counting from the beginning, it is needed.
> Yes, I always made 98SE partitions at the beginning of the disk. Seems like the easiest thing to avoid all problems.

https://msfn.org/board/topic/177106-running-vanilla-windows-98-in-2019/?do=findComment&comment=1174559
dencorso said:
> The so called 137 GB limit is due to the use of 28-bit LBA. With just 28 bits, the biggest number
> that can be represented is 1111 1111 1111 1111 1111 1111 1111 = 268,435,455
> so one can count from sector 0 to sector 268,435,455. Ala in all that gives a total of
> 268,435,456 x 512 bytes (512 being the lenght of one sector) = 137438953472 bytes~wich is ca. 137.4 GB or exactly 128 GiB.
> However, the system is interessed in addresses, so a partition starting right at the begining of the disk
> can have any of its sectors addressed using just 28 bits. But no sector beyond that point can be addressed at all.
> The solution is to patch the correct system file for it to use 48 bits, instead of 28, which is what both LLXX's and RLoew's patches actually do.

Thank you both. So it's hopeless on unpatched systems, all partitions TOGETHER must not be larger as 128/137, and the rest of larger disks remains unpartitioned, wasted space. Oh well.
I did have a look at those patches, but they consist of so many files, and come with notes that also this or that other stuff must be checked, and when starting to read up on that it involves yet more files, which have their own "and also check" notes, leading to yet more... yikes...feels like a too high suicide risk for a main system. All those system files seem so interconnected, creating so many landmines when conflicting, like above the warning to not install any NTFS driver. Or elsewhere a warning of not using MBR-restore tools after a certain update, etc. Too complicated :-(

At least am slowly getting an idea why most people claim that larger disks are working if partitioned, or that in mobile phones larger sd-cards are working, while only a few contradict: one of my rarely used USB backup disks, containing several 30GB partitions, has some weird "bug": partition #4 claims to be all empty, although it's half full. Can read and write fine, all works normal, except that the system claims that those 14GB content were only 60MB, and the whole partition still had 30GB empty space! So the probs with larger disks (or sd-cards) may only start when no space is left, yet the system doesn't realize it...

Share this post


Link to post
Share on other sites

Finally made it!

Just installed Win98SE without any LBA-patches on the 250GB drive. It just works.

Then I installed DirectX 9.0c.

ATI-Graphic-drivers.

Network drivers.

SP3 Updates.

KernelEx.

The recommended C-Media drivers.

Share this post


Link to post
Share on other sites

>  It just works

Until it writes past 137 or you scandisk in dos or...

If you don't want to patch the os, use 120 or smaller internally. Larger is okay externally, USB fw lan.

 

Share this post


Link to post
Share on other sites

I have these updated VXDs only; Ifsmgr; Nwlink; Vnetbios; Vredir; Vserver & Cdvsd. VXDs are not compatible between 98 and ME. I run Paragon NTFS for 98 and a 200GB IDE drive having XP on it is displayed and writable correctly. I have SCSI with 300GB drive Fat32 for games and have 2TB network drive all writable. The USB will need the SYS files updated. These are obtained from the SP for your OS UHCD.sys USBSTOR.sys USBHUB.sys USBPRINT.sys USBDB.sys & USBCCGP.sys, mine 4.90.3000.1, and from updated USB drivers from the manufacturer they should have a suffix of 11 from VIA the latest. You can copy over updated VXD and SYS files while off line or on line which will be effective next boot. Run the update for 48 bit drive access while on line. Then can do a 1:1 sector copy of your drive off line. Then boot up new copy to get MBR updated, do a disk check but it should be OK because it was a 1:1. Then with the drive off line, resize it. When running on line first time do a disc check to update the MBR and show new disc free space.

My KEX 4.5.1 build stopped playing a DVD after about a 20 minute interval with PowerDVD6 and KMP, later KEX builds had no problems with IDE DVD access. The USB DVD did not stop. I had updated Cdvsd.vxd but did not make any difference & have fixed this now, I had a 98SE update for ifmgr.vxd instead of 4.90.3000.*. The 98 driver also slowed down access times. Still has problem plays for about 30 minutes.

Edited by Goodmaneuver
changed vs 4.5.110 to 4.5.1

Share this post


Link to post
Share on other sites
3 hours ago, Goodmaneuver said:

I have these updated VXDs only; Ifsmgr; Vnetbios; Nwlink; Vnetbios; Vredir; Vserver & Cdvsd. VXDs are not compatible between 98 and ME.

That's all well and good, but how is this helpful to the OP?

And, that being said, many ME VXD's ARE compatible, but they must be patched (downversioned) in order to load under 98. And, once again that being said, there's no reason to start trying to transplant a bunch of ME VXD's to 98 just to be doing so or just because they have a newer version number. If it's not broken, don't fix it.

3 hours ago, Goodmaneuver said:

I run Paragon NTFS for 98 and 200GB IDE drive having XP on it is displayed and writable correctly.

How does 98 handle files larger than 4GB on the NTFS drive? Adding NTFS support to 9x unfortunately does NOT break the 4GB barrier. Unless someone has some good testing results to the contrary, this sounds like a situation ripe for causing data corruption.

4 hours ago, Goodmaneuver said:

...You can copy over updated VXD and SYS files while off line or on line which will be effective next boot. Run the update for 137 bit drive access while on line. Then can do a 1:1 sector copy of your drive off line. Then boot up new copy to get MBR updated, do a disk check but it should be OK because it was a 1:1. Then with the drive off line, resize it. When running on line first time do a disc check to update the MBR and show new disc free space....

Why would you create all this unnecessary work for yourself? :blink:

4 hours ago, Goodmaneuver said:

... My KEX 4.5.110 build stops playing a DVD after about a 20 minute interval with PowerDVD6 and KMP, later KEX builds no problems with IDE DVD access. The USB DVD does not stop. I have updated Cdvsd.vxd but did not make any difference.

Why do you need KEX to watch a DVD? :wacko:

Share this post


Link to post
Share on other sites

I have WinME operating system and 98 drivers are not compatible. Yes files greater than 4.3 GB can not be copied. It is a lot less work than reloading a fresh copy of Win98 and all of your programs. Of course no need for KEX for watching DVDs but I needed to discriminate between my builds of the OS. I have used my 2TB USB drive for games which was NTFS. Paragon NTFS for 98 is free and does not need KEX. I am just trying to help with the previous discussions. I do 1:1 copy first because if trying to resize all in one go will result in errors with WinME and any on-line drive copy is asking for trouble which can loose swap file support. I do not do drive copies anymore because the dates of files can change. Paragon Partition Manager 5.6 or just 6 is what it is sometimes called, is more suited to to 9x OS and reports more accurately. For example if you drive copy directly to a NTFS partition, the DOS 8 drive system files (sys c: from command) are located outside the partition most likely as were the NTFS ones. When viewing with 5.6 it does not show any free space but viewing with Disk Manager 8 it showed a bit of free space at the end of the drive. If this partition is resized to make use of this extra size the partition will no longer be bootable. BTW if drive copying over an NTFS partition with DISK Manager 8 then it has to be done twice to be successful. Some of the NTFS sys files must still remain as FarCry 1 full version worked this way where as only demo would work if drive sys c: was within the partition?
 

Edited by Goodmaneuver
typo

Share this post


Link to post
Share on other sites
On 12/16/2019 at 3:33 PM, jumper said:

>  It just works

Until it writes past 137 or you scandisk in dos or...

If you don't want to patch the os, use 120 or smaller internally. Larger is okay externally, USB fw lan.

 

So, easiest way to patch it afterwards?

Share this post


Link to post
Share on other sites
4 hours ago, tillewolle said:

So, easiest way to patch it afterwards

I don't think you have to worry, you installed SP3 updates already. To be sure you can compare the content of BHDD31.ZIP with your files in WINDOWS, \SYSTEM, \COMMAND and \IOSUBSYS. if your files are older, just run _INSTALL.BAT (after unzipping BHDD21.ZIP to some directory).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...