Post by: bobmckenzie on April 19, 2003, 12:57:00 PM
Is the IDE driver in the BIOS? If it is located it in the BIOS it should not be too difficult to extend the IDE driver to support 48 bit addressing....
** POST MODIFIED WITH DETAILS BELOW **
48 bit addressing was purposely created to allow backward compatibility with old IDE host controllers (even with controllers older than "ATA-33"...) The actual hard drive contains the logic for handling 48 bit addressing, not the host controller!
You can refer to the ATA-6 or ATA-7 specifications (drafts can be found here) for specific details on how an IDE DRIVE handles 48 bit addresses:
http://www.t13.org/docs2002/d1410r3b.pdf
http://www.t13.org/docs2003/d1532v1r2a.pdf
You can also see that the ATA Host Adapter Standards spec does not contain any mention of 48-bit addressing (since it is handled in the drive):
http://www.t13.org/docs2002/d1510r1.pdf
** Things to keep in mind regarding ATA/IDE **
(Forgive the long post...I hope somebody finds this stuff interesting.)
* I use the ATA and IDE interchangably
* Terms such as ATA33/ATA66/ATA100/ATA133 are really just marketing terms that describe the maximum DMA transfer rate that a specific drive supports. This is also sometimes called UDMA33/UDMA66/UDMA100/UDMA133.
* The actual DMA transfer mode used by a PC (or in this case XBOX) will the the highest common mode supported by both the drive and the PC (in the XBOX's case this will be ATA33 as most drives you buy today will support better transfer rates than ATA33).
* "Typical" PC IDE Host controller's are not very intellegent. The only thing they really do is implement a scatter gather DMA engine. During boot the BIOS queries the drive and configures the Host and drive for the fastest transfer mode possible. This transfer mode is used for all future DMA commands issued to the disk drive.
* There are many features that are implemented in later ATA specs that do not require any changes to most host controllers (ATAPI, 48 bit LBA, SMART, etc.) These are all handled in the IDE driver.
* A command is issued to an IDE disk drive in a sequence that looks something like this:
1. LBA/Size request comes to IDE driver from somewhere (FS/OS/Upper level driver/etc)
2. IDE driver generates DMA scatter gather tables and configures PC host controller DMA engine (probably enables the DMA transfer here -- the host controller waits for signals from the IDE drive to begin transfer)
3. Commands to a IDE disk drive are issued through a defined set of registers that are actually located in the disk drive (as opposed to command packets which are used for things like SCSI, and 1394). (IDE ATAPI devices use a combination of registers and command packets.) The IDE driver programs these drive registers with the LBA and block size of the transfer (these are 8 bit registers with a total supported LBA range of 28 bits). With 48 bit addressing the driver essentially writes each register twice to give a total of 48 bits of addressing.
4. IDE driver writes to the command register of disk drive with the desired command (in this case a DMA read or DMA write). The disk drive initiates transfer with host controller when it is ready to transfer data.
4a. Some host controllers try to be smart (like caching the IDE registers and only writing them to the IDE disk drive when the command register is written). In reality this is not smart as it prevents new features from properly being implemented and can cause havok for IDE driver developers. I hope the XBOX hardware does not do this...
5. Eventually the command completes and an interrupt is generated. The IDE driver checks for errors, cleans up, and returns status.
It seems to me that step #3 is pretty easy to fix to support bigger drives in the XBOX (assuming the XBOX IDE controller works the same as most PC controllers). The big question is #1. Is the filesystem/os restricted to 28 bits of LBA. I'm hoping that it uses 32 bits (which would still allow us to use very large disk drives).
* I believe that support for 48 bit LBA was added to the Linux kernel around version 2.4.20. Even if large disks cannot be supported for standard XBOX applications, the XBOX Linux project should still be able to use > 137 GB HDDs (assuming the XBOX IDE controller does not try to be fancy).
** FYI: I took a look at the Cromwell BIOS ide driver source code. I don't see anything there that would lead me to believe that there is any hardware limitation in the XBOX for supporting the 48 bit LBA addressing (somebody just needs to write a little code). However, the Cromwell BIOS is using an "int" for the "block" (LBA) parameter so that would leave us with 31 bits of usable LBA address space (that's still a terabyte which is a lot better than 137 GB). Also, it looks like the XBOX linux kernel is using the off-the-shelf source for the IDE disk driver (it's not in their CVS repository), so that should already have support for > 137 gb HDDs.
This post has been edited by bobmckenzie: Apr 20 2003, 03:44 AM
Post by: EvilWays on April 19, 2003, 01:02:00 PM
Post by: bobmckenzie on April 19, 2003, 01:21:00 PM
Thanks for humoring me...
Post by: BenJeremy on April 19, 2003, 02:51:00 PM
I seriously doubt this will ever be messed with, as it would require a couple of things done (partition table still needs to be hacked out to support a larger drive, as well)
I'm still not aware of any ATA33 drives supporting the IDE addressing modes needed to support drives > 137GB, but you are free to post info here.
I would think, hoever, the best place to START would be with the Cromwell BIOS crew, to see if it can be done at all. That would be the best place to start.
This post has been edited by BenJeremy: Apr 19 2003, 09:52 PM
Post by: BenJeremy on April 19, 2003, 02:55:00 PM
If it's something you really want, post your research here, and give the BIOS developers a good base to work with. If you are a developer, you can use DUMPBIN to disassemble the xboxkrnl.exe file in Symbols of the XDK to get intimate details of what's happening in there.
Post by: bobmckenzie on April 19, 2003, 02:57:00 PM
Post by: bobmckenzie on April 20, 2003, 09:30:00 PM
The good news is that the Cromwell BIOS uses "unsigned long" to specify the block number (aka sector/LBA) and parition tables have 32 bits allocated for start and size of a partition. That means without any really messy hacking we should be able to address up to 32 bit LBA's (which is not as good as 48 bit, but still is much better than 28 bits).
Just an FYI. 32 bits of LBA will give us:
2^32 * 512 bytes = 2,199,023,255,552 bytes = 2.2 Terabytes (this of course is using disk drive manufacturer's "metric system" math for determining disk size)
We shouldn't hit this boundary until XBOX-2 comes out, so I'm not too worried about support larger drives for now.
I have no visability into the other BIOS's so I'm not sure how much work it will take to add this support into them. I'll continue with Cromwell and Linux (I've already sent out a preliminary hacked up version of the ide driver to the Cromwell team) and see how things go. If there is anyone active in BIOS development snooping around, drop me a line and I can give a dump on how to implement 48-bit LBA.
P.S. Things may go a lot faster if somebody wanted to donate a Xecuter 2 PRO for the effort (my cheapmod isn't really working out all that great for this type of development)... :P
This post has been edited by bobmckenzie: Apr 21 2003, 04:48 AM
Post by: razorrifh on April 21, 2003, 10:48:00 AM
might be useful to you
Post by: old engineer on April 21, 2003, 12:05:00 PM
It will be nice when you get there, although the "411gb Project" is a far easier route if you love using a screwdriver and a soldering iron!
:ph34r:
This post has been edited by old engineer: May 2 2003, 09:23 AM
Post by: bobmckenzie on April 21, 2003, 05:24:00 PM
This post has been edited by bobmckenzie: Apr 22 2003, 12:25 AM
Post by: t_rex on April 21, 2003, 04:53:00 PM
Basicially just a hard drive switch
Post by: EvilWays on April 21, 2003, 07:40:00 PM
I wonder if it's possible to get the Xbox IDE interface to do ATA66. I know in Windows 2000, the kernel itself won't do ATA66 without tweaking the registry...I wonder if that part of the interface is software/driver driven as well or if that's controlled in the MCPX chip.
Anyone know what's contained in the microcode in the MCPX chip? Could the code on the chip be flashed like on the TSOP (by bridging some points together perhaps)?
I was told that the IDE interface was controlled by the MCPX chip, so that's why I said what I did...learn something new every day...
This post has been edited by EvilWays: Apr 22 2003, 02:40 AM
Post by: bobmckenzie on April 23, 2003, 12:17:00 PM
Adding support for hard drives larger than 137 GB is actually very easy. The following guide should help those people developing in this area.
NOTE: All of the examples below can be changed to use 32-bit variables (instead of 64-bit). Even if only 32-bits of the 48-bit LBA is supported in XBOX software, this will still allow 2.2 Tera-byte hard drives!
There are two places in the IDE driver that need to be update to add support for 48-bit LBA addressing:
1. Initialization
2. Issuing Commands
Initialization:
During initialization the drive is issued an Identify Drive command to determine the capabilities of the drive. 48-bit LBA support is specified by bit 10 in word 83. If this bit is set, than the "real" size of the drive is given by the four words starting at word 100.
Sample code follows:
****************************************************************************
uint16_t drive_info[265];
uint64_t maxLba;
... Issue identify drive command and store in drive_info array
/* Check for drive support of 48-bit LBA */
if( drive_info[83] & 1ul<<10 ) {
/* 48-bit LBA supported */
maxLba = *((uint64_t*)&(drive_info[100]));
} else {
/* Only 28-bit LBA supported */
maxLba = *((uint32_t*)&(drive_info[60]));
}
****************************************************************************
2. There are some new commands supported by drives that support the 48-bit LBA feature. These commands are the same as the non-EXT flavors of the commands, except these commands support "double-pumping" some of the IDE registers in order to support 48-bit LBAs. The new commands include:
- FLUSH CACHE EXT (0xEA)
- READ DMA EXT (0x25)
- READ DMA QUEUED EXT (0x26)
- READ MULTIPLE EXT (0x29)
- READ NATIVE MAX ADDRESS EXT (0x27)
- READ SECTOR(S) EXT (0x24)
- READ VERIFY SECTOR(S) (0x42)
- SET MAX ADDRESS EXT (0x37)
- WRITE DMA EXT (0x35)
- WRITE DMA QUEUED EXT (0x36)
- WRITE MULTIPLE EXT (0x39)
- WRITE SECTOR(S) EXT (0x34)
Keep in mind that all of these commands work almost exactly the same as the non-EXT flavors, with the exception of having to double pump the regististers in order to communicate the 48-bit LBA. I will focus my example on the READ EXT command.
Here is some sample code that shows how to issue a read command (using standard read command). This code is from the Cromwell ide driver (with hacked support of 48-bit LBA).
****************************************************************************
int BootIdeReadSector(int nDriveIndex, void * pbBuffer, unsigned int block, int byte_offset, int n_bytes)
{
...
if( block >= 0x10000000 ) { /* 48-bit LBA access required for this block (a.k.a. LBA) */
/* This routine uses a max LBA of 32 bits (due to unsigned int data type used for block parameter) */
tsicp.m_bCountSectorExt = 0; /* Don't support read sizes greater than 512 sectors */
tsicp.m_wCylinderExt = 0; /* 47:32 */
tsicp.m_bSectorExt = (block >> 24) & 0xff; /* 31:24 */
tsicp.m_wCylinder = (block >> 8) & 0xffff; /* 23:8 */
tsicp.m_bSector = block & 0xff; /* 7:0 */
tsicp.m_bDrivehead = IDE_DH_DRIVE(nDriveIndex) | IDE_DH_LBA;
ideReadCommand = IDE_CMD_READ_SECTOR_EXT;
} else {
tsicp.m_bSector = block & 0xff; /* lower byte of block (lba) */
tsicp.m_wCylinder = (block >> 8) & 0xffff; /* middle 2 bytes of block (lba) */
tsicp.m_bDrivehead = IDE_DH_DEFAULT | /* set bits that must be on */
((block >> 24) & 0x0f) | /* lower nibble of byte 3 of block */
IDE_DH_DRIVE(nDriveIndex) |
IDE_DH_LBA;
ideReadCommand = IDE_CMD_READ_SECTOR;
}
BootIdeIssueAtaCommand(uIoBase, ideReadCommand, &tsicp);
....
}
int BootIdeIssueAtaCommand( unsigned uIoBase, ide_command_t command, tsIdeCommandParams * params )
{
int n;
IoInputByte(IDE_REG_STATUS(uIoBase));
n=BootIdeWaitNotBusy(uIoBase);
/* 48-bit LBA */
/* this won't hurt for non 48-bit LBA commands since we re-write these registers below */
IoOutputByte(IDE_REG_SECTOR_COUNT(uIoBase), params->m_bCountSectorExt);
IoOutputByte(IDE_REG_SECTOR_NUMBER(uIoBase), params->m_bSectorExt);
IoOutputByte(IDE_REG_CYLINDER_LSB(uIoBase), params->m_wCylinderExt & 0xFF);
IoOutputByte(IDE_REG_CYLINDER_MSB(uIoBase), (params->m_wCylinderExt >> 8));
IoOutputByte(IDE_REG_SECTOR_COUNT(uIoBase), params->m_bCountSector);
IoOutputByte(IDE_REG_SECTOR_NUMBER(uIoBase), params->m_bSector);
IoOutputByte(IDE_REG_CYLINDER_LSB(uIoBase), params->m_wCylinder & 0xFF);
IoOutputByte(IDE_REG_CYLINDER_MSB(uIoBase), (params->m_wCylinder >> 8));
IoOutputByte(IDE_REG_DRIVEHEAD(uIoBase), params->m_bDrivehead);
IoOutputByte(IDE_REG_COMMAND(uIoBase), command);
Delay();
n=BootIdeWaitNotBusy(uIoBase);
return 0;
}
****************************************************************************
The actual ATA specification that gives the details for the 48-bit LBA feature can be found here:
http://www.t13.org/docs2002/d1410r3b.pdf
Post by: desertboy on April 25, 2003, 11:07:00 AM
This post has been edited by desertboy: Apr 25 2003, 06:09 PM
Post by: SupeRdUPErBlakE on April 25, 2003, 11:15:00 AM
Post by: EvilWays on April 25, 2003, 11:39:00 AM
Post by: bobmckenzie on April 25, 2003, 02:50:00 PM
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).
Post by: tcue3000 on April 30, 2003, 08:31:00 PM
Post by: bobmckenzie on May 01, 2003, 06:07:00 AM
Post by: BenJeremy 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.
Post by: Videogamebuyer14 on May 03, 2003, 06:10:00 AM
Post by: EvilWays 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.
Post by: Ubergeek on May 09, 2003, 06:35:00 AM
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
Post by: SupeRdUPErBlakE on May 09, 2003, 09:03:00 AM
Post by: Gamester17 on May 12, 2003, 05:18:00 AM
Post by: bobmckenzie on May 14, 2003, 08:15:00 AM
Post by: rjm2k 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?
Post by: DJVASTVASTY2K on May 17, 2003, 05:27:00 AM
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 systems 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
Post by: DJVASTVASTY2K on May 17, 2003, 08:31:00 AM
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
Post by: desertboy 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
Post by: dankydoo on May 20, 2003, 10:26:00 AM
Post by: EvilWays on May 22, 2003, 04:51:00 PM
Post by: Deezle on May 26, 2003, 02:26:00 AM
Greetz,
Deezle
Post by: EvilWays on May 26, 2003, 08:13:00 AM
Post by: Biznaz on May 31, 2003, 04:24:00 AM
Post by: Jse on June 05, 2003, 04:53:00 PM
Post by: Heet on June 05, 2003, 07:21:00 PM
Post by: juan23 on June 06, 2003, 11:31:00 AM
Post by: SupeRdUPErBlakE on June 16, 2003, 08:52:00 AM
Post by: Heet on June 16, 2003, 10:31:00 AM
Post by: Arcann on June 16, 2003, 02:27:00 PM
Post by: SupeRdUPErBlakE on June 20, 2003, 07:54:00 AM
Post by: grug on June 21, 2003, 02:41:00 AM
| QUOTE (EvilWays @ Apr 25 2003, 08:39 PM) |
| So even if we crack the size limitation, are we still stuck at ATA33? |
Even, if you assume, by some miracle, someone managed to incorporate ATA/66 or 100 or whatever into the IDE controller, we'd still be stuck at ATA/33. An ATA channel will only run as fast as the slowest device on it. ie, if you have an ATA/33 device (eg DVD-ROM) and an ATA/100 device (Hard drive), the hard drive will only run at 33.
Now since the Xbox only has one channel, and thats shared by both the hard drive and DVD-ROM, and the DVD-ROM in the Xbox is only ATA/33, we'll never see higher speeds anyway, unless you disconnected the drive. Although I have heard of one manufacturer of PC DVD-ROMs (Pioneer maybe?) that increased the speed to ATA/66 for this reason.
Post by: X-ace on June 21, 2003, 05:33:00 AM
| QUOTE (grug @ Jun 21 2003, 10:41 AM) | ||
we'd still be stuck at ATA/33. |
I'd take the size increase without the speed any day.
keep up the good work.
Post by: AlexsWeiner on June 28, 2003, 06:29:00 AM
Post by: kingofthexbox on July 05, 2003, 02:08:00 PM
Post by: LzAkNw on July 10, 2003, 03:50:00 AM
Post by: splash911 on July 22, 2003, 07:45:00 AM
It would be great to have a bit of updates on his work.
Post by: vexorg on July 26, 2003, 10:15:00 PM
Post by: EvilWays on July 27, 2003, 09:16:00 PM
Post by: Gamester17 on July 28, 2003, 02:05:00 AM
Post by: Carnavore on August 13, 2003, 06:36:00 AM
| QUOTE |
| An interesting article, written by Maxtor. BREAKING THE 137 GIGABYTE STORAGE BARRIER (written and copyright by Maxtor) This appendix provides information about the 137GB storage barrier. It discusses the history, cause and the solution to overcome this barrier. A.1Breaking the 137-Gigabyte Storage Barrier Capacity Barriers have been a fact of the personal computer world since its beginnings in the early 1980s. At least 10 different capacity barriers have occurred in the storage industry over the last 15 years. The most notable barriers seen previously have been at 528 megabytes and then at 8.4 gigabytes. The most recent barrier, which will be surmounted in 2001, is the 137-gigabyte limit or a single ATA drive. The first ATA devices to exceed 137 gigabytes will be four-platter hard disk drives with 40 gigabytes per platter, yielding 160 gigabytes per drive. These drives will be available in the second half of 2001. Later in the same year, capacity will continue to grow to 60 gigabytes per platter, and a three-disk, 180-gigabyte device will be available and shipping. The ANSI NCITS T13 Technical Committee (also known as the ANSI ATA committee) has broken this barrier by incorporating a proposal from Maxtor into the ATA/ATAPI-6 draft standard that defines a method for 48-bit addressing on a single drive, giving more than 144 petabytes (144,000 gigabytes) of storage. In addition, the proposal from Maxtor that was incorporated into ATA/ATAPI-6 defines a method for extending the maximum amount of data that can be transferred per command for ATA devices from 256 sectors (about 131 kilobytes) to 65,536 sectors (about 33 megabytes). This new method is particularly useful for applications that use extremely large files, such as those for A/V or multimedia. The following sections will describe issues surrounding the 137-gigabyte barrier and the solution for breaking it. A.1.1History Many of the barriers in the past resulted from BIOS and operating system issues caused by failure to anticipate the remarkable increases in Breaking the 137GB Storage BarrierA-2Maxtor DiamondMax Plus9 60/80/120/160/200GB AT device storage capacity by the people who designed hard disk structures, access routines, and operating systems many years ago. They thought, Who will ever have xxx much storage? In some cases, the barriers were caused by hardware or software bugs not found until hard disks had grown in size beyond a certain point where the bugs would occur. Past barriers often frustrated people trying to add a new hard disk to an older system when they discovered that not all of the designed capacity of the hard disk was accessible. This inability to access the entire drive is referred to as a capacity barrier and it has been seen and overcome many times in the computer and disk drive industry. The 137-gigabyte barrier is the result of the original design specification for the ATA interface that provided only 28 bits of address for data. This specification means a hard disk can have a maximum of 268,435,456 sectors of 512 bytes of data which puts the ATA interface maximum at 137.4 gigabytes. A.1.2Solving the 137-Gigabyte Capacity Barrier As described earlier, the issue causing the 137-gigabyte barrier is the 28-bit addressing method of the original ATA specification. A change to expand this method was required to provide more address bits for the interface, allowing significant growth for many years to come. A critical issue in expanding the addressing capability was maintaining compatibility with the existing installed base of products.A new ATA standard, ATA/ATAPI-6, has been in the works for some time, and the latest draft of this standard resolves this issue by increasing the maximum number of bits used for addressing from 28 to 48. This solution increases the maximum capacity of an ATA device to 144 petabytes while maintaining compatibility with current ATA products. A.1.3How is the Extension Implemented? The 48-bit Address feature set provides a method to address devices with capacities up to approximately 144 petabytes by increasing the number of bits used to specify logical block addresses (LBAs) from 28 to 48. The feature set also provides a method to increase the number of sectors that can be transferred by a single command from 256 to 65,536 by increasing the number of bits specifying sector count to 16 bits. New commands specific to this feature set have been defined so that devices can implement the new feature set in addition to previously defined commands. Devices implementing the 48-bit Address feature set commands will also implement commands that use 28-bit addressing in order to maintain interoperability with older system components. In addition, 8-bit and 48-bit commands may be intermixed. The 48-bit Address feature set operates in LBA addressing only. Support of the 48-bit Address feature set is indicated in the IDENTIFY DEVICE response data. In a device implementing the 48-bit Address feature set, the registers used for addressing are, in fact, a two-byte deep FIFO. Each time one of these registers is written, the new content written is placed into the most recently written location and the previous content of the register is moved to previous content location. A host may read the previous content of the registers by first setting a bit in the Device Control register to 1 and then reading the desired register. A.1.4What Do the Drives Need to Meet the Spec? The challenge to drive manufacturers is to develop and implement new interface chips on drives that can accept and decode the new 48-bit addressing scheme. Many functions of decoding the commands sent to and from the drive are automated in the silicon of the drive interface ASIC, and this is where drive manufacturers must update their designs. Maxtor is the leader in development efforts and is the first to deliver a product with the capacity and drive technology to deliver greater than 137 gigabytes of capacity.Breaking the 137GB Storage BarrierA-4Maxtor DiamondMax Plus9 60/80/120/160/200GB AT A.1.5What Else is involved? Effort is required from OS vendors to increase storage device addressing up to 48 bits or more. This increase will be a significant challenge for many OS vendors that have 32-bit code models. Adapting to 48-bit commands will be easy, but most vendors will stop filling data at the 32-bit boundary and pad the upper 16 bits with zeros, leaving that space empty. The BIOS companies will also have to perform some work to recognize the increased capacity of the devices attached to the bus and allow the extended 48-bit commands to pass on to the devices. Boot partitions will also be an issue for the capacity of the drive if the BIOS does not recognize the 48-bit addressing scheme at or before the system boots the OS from the hard drive. Independent software driver efforts for legacy operating systems (Windows NT 4, Windows 98, and so on) will need to be implemented to allow higher-capacity devices to work on installed systems and recognize the maximum available capacity of the drive over the 137-gigabyte limit. A.1.6What is the Next Barrier? While it is true that the ATA/ATAPI-6 standard defines a method to provide a total capacity for a device of 144 petabytes, the next limit will be imposed not by the ATA devices but by many of the popular operating systems in use today. This limit will be at 2.2 terabytes (2,200 gigabytes). This barrier exists because many of todays operating systems are based on 32-bit addressing. These operating systems include many flavors of Linux, Mac OS 9.x, and Windows 95, 98, ME, NT 4, 2000, and XP (Windows XP/64-bit also has the limit because of leveraged 32-bit code).This barrier could be real as early as 2004 if current hard drive capacity rate increases continue along the same growth trends. Appendix A: Terminology BIOS: (an acronym for Basic Input/Output System design): The BIOS processes and redirects all data as it is being accessed and stored. FAT: (an acronym for File Allocation Table): The FAT tells the computer where data has been stored on the hard drive. CHS: (an acronym for Cylinders, Heads, and Sectors): The basic layout components of a hard drive. INT 13h & INT 13h extensions: protocols used for accessing data on hard drives. Appendix B: Big Numbers 131 kilobytes =131,000 bytes a little more than 30 pages of text 33 megabytes =33,000,000 bytesmore than 8,000 pages of text or 25 300-page books 137 gigabytes =137,000,000,000 bytes more than 100,000 books, or the contents of a good library 2.2 terabytes = 2,200,000,000,000 bytes almost 2,000,000 books, or the about content of the Library of Congress 144 petabytes = 144,000,000,000,000,000 bytes120 billion books - (more than all that man has written) 9.4 zettabytes = 9,400,000,000,000,000,000,000 bytes |
Post by: KDragon on August 21, 2003, 03:10:00 PM
Post by: juan23 on August 22, 2003, 11:56:00 AM
Post by: Deezle on August 24, 2003, 12:06:00 PM
| QUOTE (oz_paulb @ Aug 24 2003, 09:28 PM) |
| I started another thread asking about current status on >137GB support (didn't know about this one). I'm willing to do the work to add this to the kernel, but don't want to be duplicating efforts. If anyone else has already started adding this code to the MS kernel, please let me know before I get started. If you just haven't had time to finish, maybe I could pick up where you left off. - Paulb |
Could you, please, post a link to this thread?! I would really like to follow it.
Greetz,
Deezle
Post by: oz_paulb on August 26, 2003, 09:47:00 PM
Hey -
I've got some great news - I have the MS Xbox KERNEL reading/writing an LBA48 drive using the LBA48 commands (meaning: drives > 137GB will be possible)!
The KERNEL recognizes that it's an LBA48 drive at startup time, and sets the drive size accordingly (I'm using a 200GB drive, and it's reading the size correctly).
The KERNEL read/write functions are now using LBA48 commands, and they work!
Now, I've not tried reading/writing past the LBA28 limit on the disk, but there's no reason it won't work - the only possible issue was whether/not the LBA48 commands/command-structure would work.
I've got to clean up the error checking, and finalize a couple more routines. Then, I'll write a test app that creates a bunch of unique files on the F: partition, and goes back/verifies they all are still unique (to confirm nothing 'wraps' and overwrites back to the beginning).
I've also got a simple 'partition table' mechanism, so there can be up to 8 partitions on the drive. The main reason for this is to allow for other operating systems (like Linux) to co-exist with the Xbox (usually, the Xbox uses up the entire remainder of the drive for F:, leaving nothing for Linux).
I hope to have this all finished up in the next couple of days (depends on my 'real' job, and how busy I am there). I just wanted to give an update, since I think people are interested in this.
I'll update this thread when I've got more news.
- Paulb
Post by: elduderino1234 on August 26, 2003, 10:22:00 PM
Post by: Gamester17 on August 28, 2003, 01:52:00 AM
Post by: Jynks on September 07, 2003, 10:36:00 PM
http://411gb.50megs.com/411gb.htm
Post by: Deezle on September 07, 2003, 11:37:00 PM
| QUOTE (Jynks @ Sep 8 2003, 08:36 AM) |
| Here is a tutorial for haviong 411GB of drive data on the Xbox... it is very good and clear... http://411gb.50megs.com/411gb.htm |
But only a fool wants to do this since it's possible to patch the kernel! Look here:
Lba48 Support Released (beta)!
Greetz,
Deezle
Post by: Jynks on September 08, 2003, 02:14:00 AM
Post by: BenJeremy on September 08, 2003, 02:56:00 AM
| QUOTE (Jynks @ Sep 8 2003, 06:14 AM) |
| I do not know, using beta software over a simple hardware switch? Also this 411 project gives you the ability to swap drives with an IDE switch. Handy for storing all those dvix films and TV shows. They chew up space fast. |
It's not really beta.... lots of people are using the LBA48 patch now. The switch sucks when a more elegant solution now exists.
I'm going to close this thread. The final word was oz_paulb's LBA48 patch.