xboxscene.org forums

Pages: 1 [2] 3 4 5

Author Topic: Breaking The 137 Gb Limit  (Read 633 times)

EvilWays

  • Archived User
  • Hero Member
  • *
  • Posts: 909
Breaking The 137 Gb Limit
« Reply #15 on: April 25, 2003, 11:39:00 AM »

So even if we crack the size limitation, are we still stuck at ATA33?
Logged

bobmckenzie

  • Archived User
  • Newbie
  • *
  • Posts: 10
Breaking The 137 Gb Limit
« Reply #16 on: April 25, 2003, 02:50:00 PM »

If I can convince somebody working on the BIOS/kernel to add this feature, then large hard drives (probably up to 2.2 tera-bytes) would be usable by the XBOX (at least from the IDE driver side of things).  

Of course, we might encounter some other limitations once the IDE driver is fixed, but there is no way to know until we try (everything I've read so far leads me to believe that FATX should be able to handle big hard drives).

But, we will always be stuck at a max of ATA33 transfer rates (as this is a limitation of the XBOX IDE host controller).
Logged

tcue3000

  • Archived User
  • Newbie
  • *
  • Posts: 3
Breaking The 137 Gb Limit
« Reply #17 on: April 30, 2003, 08:31:00 PM »

Is this post dead. Is there any update on larger hard drives working with the xbox.
Logged

bobmckenzie

  • Archived User
  • Newbie
  • *
  • Posts: 10
Breaking The 137 Gb Limit
« Reply #18 on: May 01, 2003, 06:07:00 AM »

Pretty much.  I have a 200 GB drive on order that I will play around with, but my development will be limited to Cromwell/Linux.  Hopefully somebody working on the MS BIOS/Kernel will step up eventually and implement this feature.
Logged

BenJeremy

  • Archived User
  • Hero Member
  • *
  • Posts: 5645
Breaking The 137 Gb Limit
« Reply #19 on: May 01, 2003, 06:23:00 AM »

QUOTE (bobmckenzie @ May 1 2003, 10:07 AM)
Pretty much.  I have a 200 GB drive on order that I will play around with, but my development will be limited to Cromwell/Linux.  Hopefully somebody working on the MS BIOS/Kernel will step up eventually and implement this feature.

Have a word with Ubergeek from Team Xecutor... once you get it working in Cromwell, I'm sure they would consider adding it to their own BIOS.
Logged

Videogamebuyer14

  • Archived User
  • Hero Member
  • *
  • Posts: 724
Breaking The 137 Gb Limit
« Reply #20 on: May 03, 2003, 06:10:00 AM »

However, isnt the mcpx chip the NVIDIA chip set just about 2 or 3 inches away from the lpc bus?
Logged

EvilWays

  • Archived User
  • Hero Member
  • *
  • Posts: 909
Breaking The 137 Gb Limit
« Reply #21 on: May 03, 2003, 05:42:00 PM »

QUOTE (Videogamebuyer14 @ May 3 2003, 03:10 PM)
However, isnt the mcpx chip the NVIDIA chip set just about 2 or 3 inches away from the lpc bus?

Umm...I don't have a clue where you're going with that. I assume you are talking about using an LPC device (modchip or something else) to override the MPCX chip.
Logged

Ubergeek

  • Archived User
  • Hero Member
  • *
  • Posts: 686
Breaking The 137 Gb Limit
« Reply #22 on: May 09, 2003, 06:35:00 AM »

we're looking at this now

great input Bob

and to everyone else who replied to the one half decent technical thread found on these forums - I totally hang me head in shame at some of the replies  tongue.gif
Logged

SupeRdUPErBlakE

  • Archived User
  • Hero Member
  • *
  • Posts: 787
Breaking The 137 Gb Limit
« Reply #23 on: May 09, 2003, 09:03:00 AM »

WRONG THREAD, LOL. rotfl.gif
Logged

Gamester17

  • Archived User
  • Full Member
  • *
  • Posts: 116
Breaking The 137 Gb Limit
« Reply #24 on: May 12, 2003, 05:18:00 AM »

A mod should pin this thread to encurage more devs to join the tech side of this  wink.gif
Logged

bobmckenzie

  • Archived User
  • Newbie
  • *
  • Posts: 10
Breaking The 137 Gb Limit
« Reply #25 on: May 14, 2003, 08:15:00 AM »

Not yet...  I got the drive, but got really busy (I moved).  I hope to try it out soon.
Logged

rjm2k

  • Archived User
  • Sr. Member
  • *
  • Posts: 253
Breaking The 137 Gb Limit
« Reply #26 on: May 14, 2003, 10:02:00 AM »

QUOTE (bobmckenzie @ May 1 2003, 02:07 PM)
Pretty much.  I have a 200 GB drive on order that I will play around with, but my development will be limited to Cromwell/Linux.  Hopefully somebody working on the MS BIOS/Kernel will step up eventually and implement this feature.

I'm curious as to why Cromwell would have been written with exactly the same limitation as the MS bios, are you sure this isn't a limitation of the hardware?
Logged

DJVASTVASTY2K

  • Archived User
  • Newbie
  • *
  • Posts: 10
Breaking The 137 Gb Limit
« Reply #27 on: May 17, 2003, 05:27:00 AM »

Hi Bob

I Think This Project Is GREAT, Most Probarbly The Best I Have Seen Since The Modchip Was Introduced.

I Been Doing Some Research And This Is What I Have Found, I Hope Theese Link Are Of Some Use M8.

Also i think this maybe a hardware problem as it says here a source from maxtor

http://www.maxtor.co...ive_enabler.htm

Maxtor's Big Drive Enabler is a one step executable that enables support for drives larger than 137 Gigabytes in Windows 2000 Service Pack 3 and XP Service Pack 1. This utility takes the guess work out of editing the Windows registry. The Big Drive Enabler fixes an operating system limitation.

This utility is needed anytime a Hard Disk Drive larger than 137 GB is connected to the motherboard's ATA bus, regardless of any system BIOS that supports 48-bit LBA."

Note: Failure to install the required service packs and install the Enable Big LBA patch can result in data loss when accessing the hard disk beyond 137 Gigabytes. For more information regarding Windows limitations and the 137 Gigabyte barrier please read Maxtor Knowledge Base Answer ID 960 and MS Knowledge Base Article 303013.

Linux SiS IDE ressource page

http://gyver.homeip.net/sis5513/

And Finally Some More Information Here

http://maxtor.custhe...ated=1016214655

I Have A Maxtor Plus 9, 120GB Hard Drive, So This Is Why I Have Chosen Maxtor Research.

The operating system only recognizes 128 GB or 137 GB of my large capacity drive.

Description: I have a drive that is larger than 137 GB but the operating system only recognizes 128 GB or 137 GB. How can I fix this?

Answer: Problem
The full capacity of ATA drives larger than 137GB is not recognized by the operating system.

Solution
Currently, there are three options to remedy the 137 Gigabyte barrier. Failure to implement one of the following installation options will result in data loss when trying to access the hard disk beyond 137 Gigabytes.

Installation Option 1.
Upgrade the operating system to either Windows 2000 with Service Pack 3 (or newer) or Windows XP with Service Pack 1 (or newer) and download the Maxtor Big Drive Enabler software patch. The Maxtor Big Drive Enabler, once executed, will update the Windows registry for large drive support.

Installation Option 2.
Download and install the Intel Application accelerator. The Intel Application Accelerator provides 48-Bit LBA compliant ATA/ATAPI controller drivers (IntelATA.mpd) and replaces the Windows 98/Me, 2000 and XP ATA controller drivers (ESDI_506.PDR). Intel is the only chipset manufacturer that we are aware of that offers a compatible controller driver for Windows .

http://www.intel.com...t/chipsets/iaa/

The Intel Application Accelerator only supports the following chipsets: 810, 810E, 810E2, 810L, 815, 815EP, 815G, 815EG, 815P, 820, 820E, 840, 845, 845E, 845G, 845GE, 845GL, 845GV, 845PE, 850, 850E, 860. The Intel Application Accelerator can be obtained at http://www.intel.com...t/chipsets/iaa/. If you have an unsupported chipset or do not want to upgrade the operating system then try the next solution.

Installation Option 3:
Attach the large hard drive to an add-in Ultra ATA PCI adapter card with a 48-Bit LBA compliant BIOS and controller driver. The adapter card bypasses the system BIOS and operating system’s controller driver and uses its own BIOS and controller driver.

Using an IDE ATA/ATAPI controller that has a 48-Bit LBA compatible controller driver will allow safe use of large drives beyond the previous limits of 137 GB capacity. Additional controllers that do not have 48-Bit compliant drivers cannot safely access drives larger than 137 GB. A compatible card such as the Maxtor Ultra ATA/133 PCI for Windows and Sonnet Tempo ATA/133 PCI Card for MACs can be purchased at http://www.maxstore.com (U.S. only) or at a local retailer.

http://www.maxstore....asp?sku=1856734
http://www.maxstore....asp?sku=2190259

Here Is A Guide To All Of The Above In An Adobe Acrobat .PDF Format

http://service.maxto...B_Solutions.pdf

Last But Not Least, Here Is Some Information From MS.

http://support.MS.co...kb;en-us;303013

MS Knowledge Base Article - 303013

SUMMARY: This article describes the Windows XP Service Pack 1 (SP1) 48-bit Logical Block Addressing (LBA) support for ATA Packet Interface (ATAPI) disk drives that can enable the capacity of your hard disk to exceed the current 137 gigabyte (GB) limit.

Note 48-bit LBA support is not enabled and therefore supported without Windows XP SP1. Windows XP Media Center Edition and Windows XP Tablet PC Edition already include SP1.

For additional information about the latest service pack for Windows XP, click the article number below to view the article in the MS Knowledge Base:

To determine if you have the latest ATAPI driver, verify that the version of Atapi.sys in your %systemroot%system32drivers folder is version 5.1.2600.1135 (or version 5.1.2600.1152 for Windows XP 64-Bit Edition) or later. To do this, follow these steps:

Click Start, and then click Search (or point to Search and then click For Files and Folders).
Type Atapi.sys, and then click Search.
If the Atapi.sys file in your %systemroot%system32drivers folder is not found, change your preferences for the Search Companion to search system and hidden folders and then repeat step 2. For additional information about how to search for hidden and system folders, click the following article number to view the article in the MS Knowledge Base:
302347 HOW TO: Search For Hidden Or System Files In Windows XP

In your %systemroot%System32Drivers folder, Right-click Atapi.sys, and then click Properties.
On the Version tab, note the file version.
If Atapi.sys is not version 5.1.2600.1135 (or version 5.1.2600.1152 for Windows XP 64-Bit Edition), obtain and install the hotfix described in MS Knowledge Base article 331958. For additional information about this hotfix, click the following article number to view the article in the MS Knowledge Base:
331958 Hard Disk May Become Corrupted When Entering Standby or Hibernation or When Writing a Memory Dump

By default, the original release of Windows XP Home Edition and Windows XP Professional do not have 48-bit LBA support enabled.

You must meet the following requirements to use 48-bit LBA ATAPI support:
You must have a 48-bit LBA compatible BIOS.
You must have a hard disk that has a capacity that is greater than 137 GB.
You must have Windows XP SP1 installed.
For the original release of Windows XP Home Edition or Windows XP Professional, 48-bit LBA could be enabled for testing purposes by setting a registry value, named EnableBigLba, to 1 in the following registry key:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesAtapiParameters

Warning Data corruption can occur you use this registry value to enable 48-bit LBA support in the original release of Windows XP Home Edition or Windows XP Professional, or if previous versions of Windows that do not support 48-bit LBA out of the box (for example, Windows 2000 or earlier) are installed on a disk partition that was previously created by a 48-bit aware operating system such as Windows XP SP1 that is larger or spans the current addressable limit of 137 GB.

Note: The preceding registry setting is ignored in Windows XP SP1 and later. If you attempt to enable the 48-bit LBA ATAPI support in the original release of Windows XP Home Edition or Windows XP Professional by editing the preceding registry setting and you did not meet the minimum requirements, you may observe the following behavior:
The registry value EnableBigLba is disabled. If you have a 48-bit compatible BIOS that can support a hard disk that has a capacity that is greater than 137 GB, only the first 137 GB of the hard disk are addressable. The rest of the hard disk is not used.
The registry value EnableBigLba is enabled, but you do not have a 48-bit LBA compatible BIOS and the capacity of the hard disk does not exceed 137 GB:

If you enable the 48-bit LBA ATAPI support by editing the registry setting, but you lack both a 48-bit LBA compatible BIOS and a hard disk that has a capacity that is greater than 137 GB, you have not changed the system. The hard disk continues to function as a standard hard disk.
The registry value EnableBigLba is enabled without a 48-bit LBA compatible BIOS, but you have a hard disk with a capacity that is larger than 137 GB.

If you enable 48-bit ATAPI support in the registry and you have a hard disk that has a capacity that is greater than 137 GB, but you do not have a 48-bit LBA compatible BIOS, only the first 137 GB of the hard disk are addressable. The remainder of the hard disk is not used.
To enable 48-bit LBA support by means of an unattended installation with the MS System Preparation (Sysprep) tool:
Copy the following text into MS Windows Notepad and save the text as the 48bitLba.inf file:[version]
signature="$CHICAGO$"
SetupClass=BASE


[DefaultInstall]
AddReg=48bitlba.Add.Reg

[48bitlba.Add.Reg]
HKLM,"SystemCurrentControlSetServicesAtapiParameters","EnableBigLba",0x10001,1
Create a file named Cmdlines.txt, which includes the following lines:

[Commands]
"rundll32 setupapi,InstallHinfSection DefaultInstall 128 .48BITLBA.INF"
Locate the SysprepI386 folder in the Sysprep image, and then create a $OEM$ subfolder in this folder.
Copy the 48bitlba.inf and Cmdlines.txt files into the SysprepI386$OEM$ folder.
In your Sysprep.inf file, add a key named InstallFilesPath to the [Unattended] section. This key must have the following value: InstallFilesPath = "C:sysprepi386"
To add the preceding settings to the Images folder, which had been created with the Riprep.exe program:
On the remote installation server that contains the Riprep image, create a SysprepI386$OEM$ folder in the following folder:

RemoteInstallSetupLanguageImagesRiprep_dir_nameI386Mirror1UserData

Note The word "Language" in the preceding path reads "English" for the English language, and "Riprep_dir_name" is the unique name that you selected for the Riprep image.
Copy the 48bitlba.inf and Cmdlines.txt files into the $OEM$ folder.
Modify the Riprep.sif file in the RemoteInstallSetupLanguageImagesRiprep_dir_nameI386TemplatesRiprep.sif folder (and any other template files for this Riprep image that you may have created), and then add the OemPreinstall and InstallFilesPath values so that they are set up as:

[Unattended]
OemPreinstall = "Yes"
InstallFilesPath = "C:sysprepi386"
Close, and then save the file.
OEMs have the ability to turn this support on by means of the MS Windows OEM Preinstallation Kit.

For more information, refer to the OEM Preinstallation Kit or the following MS Web site:
http://www.MS.com/oem

Last Reviewed: 5/16/2003
Keywords: kbAppCompatibility kbenv kbhowto kbWinXPsp1fix KB303013

Hope This Helps

Best Regards

Adam

Vast Gsm Team
Logged

DJVASTVASTY2K

  • Archived User
  • Newbie
  • *
  • Posts: 10
Breaking The 137 Gb Limit
« Reply #28 on: May 17, 2003, 08:31:00 AM »

Hi Bob

I Have Just Done Some More Research And Found Out That The Boot Code We Need Is Called "DDO"


DDO= Dynamic Drive Overlay

Hope This Helps Ya M8

Best Regards

Adam

Vast Gsm Team
Logged

desertboy

  • Archived User
  • Hero Member
  • *
  • Posts: 523
Breaking The 137 Gb Limit
« Reply #29 on: May 20, 2003, 05:07:00 AM »

QUOTE (DJVASTVASTY2K @ May 17 2003, 05:31 PM)
Hi Bob

I Have Just Done Some More Research And Found Out That The Boot Code We Need Is Called "DDO"


DDO= Dynamic Drive Overlay

Hope This Helps Ya M8

Best Regards

Adam

Vast Gsm Team

This is taxing my memory a bit but I remember hitting the 512meg limit (IDE 1.0 I think) years ago with my P90 required me to load a TSR on boot up that patched in support for larger drives. When I bought myself an 80gig last year I tried to put into my P2 333 which I quickly discovered the bios didn't support drives over 32gig. I had to download IBM disk manager which is a DDO and as far as I could tell it worked in an similar way to the TSR I used to have to use.

Maybe I'm wrong but I think when the computer autodetects the HD at boot up the HD reported itself as a 32gig then when the DDO loads (The first thing it did before booting windows or even loading himem.sys) it gives me access to 80 gig. If I booted from a floppy I could only see the 1st 32gig.

I think the way they work is to patch bios support for larger HD rather than controller support.

So if I'm right a DDO would do nothing that a simple patch in the bios wouldn't do



Logged
Pages: 1 [2] 3 4 5