Print

[dmsdude90]

when will this probably be done

[Spency234]

This is the coolest thing I've heard in a loong time when it comes to xbox hacking!  There will always be sceptics... just don't let them hold ya down!!
Thank You

[crumb]

QUOTE (oz_paulb @ Aug 28 2003, 06:08 PM)

QUOTE Franz says that this will not work, because all LBA48 HDs don't support PIO or UDMA2 (which is the highest the Xbox kernel can do) any more, their native mode is UDMA5. Only very few HDs, those with a special compatibility mode will also do slower modes. The Xbox kernel does not have UDMA5, so it will not work. Now, this is something I could believe - that newer drives are using a new method of DMA'ing in hardware and have stopped doing it 'the old way' (PIO/UDMA2) on the assumption that you've purchased a > 137GB drive, so you must have a newer system.

On a thread on the XboxHacker.net Forums Bob M. and I were having a discussion about this topic.  IIRC T13's ATA/ATAPI-6 standard (the only standard with 48-bit LBA addressing) "uses" UDMA5.  However, Bob M. said there wasn't a requirement in the standard to use UDMA5.

1. UDMA3 and up require 80-wire cables between IDE devices.  It seems likely that the hard drive manufacturers wouldn't want to "cripple" their drives when an 80-wire cable wouldn't be available.

2. They also probably understand that large hard drives (i.e. their future market) can be supported on legacy systems by modifying BIOSes to older ATA chipsets.  I doubt the home user is going to modify their PC's BIOS to access larger hard drives, but large company installations might take the time and effort, especially if there are people already producing documents on how to modify the BIOSes and how to possibly automate that task.

3. The hard drive manufacturers also must use more logic on their IDE chipsets if they are going to shut off speeds below UDMA5 in 48-bit LBA addressing.  That would increase the cost in die space and engineering time.

In conclusion, my guess is that all of those factors will lead to most if not all 48-bit LBA drives supporting speeds below UDMA5.

[dmsdude90]

that is extremly interesting how think we r getting closer to our goal

[oz_paulb]

QUOTE (crumb @ Aug 28 2003, 08:35 PM)

QUOTE (oz_paulb @ Aug 28 2003, 06:08 PM) QUOTE Franz says that this will not work, because all LBA48 HDs don't support PIO or UDMA2 (which is the highest the Xbox kernel can do) any more, their native mode is UDMA5. Only very few HDs, those with a special compatibility mode will also do slower modes. The Xbox kernel does not have UDMA5, so it will not work. Now, this is something I could believe - that newer drives are using a new method of DMA'ing in hardware and have stopped doing it 'the old way' (PIO/UDMA2) on the assumption that you've purchased a > 137GB drive, so you must have a newer system. On a thread on the XboxHacker.net Forums Bob M. and I were having a discussion about this topic.  IIRC T13's ATA/ATAPI-6 standard (the only standard with 48-bit LBA addressing) "uses" UDMA5.  However, Bob M. said there wasn't a requirement in the standard to use UDMA5. 1. UDMA3 and up require 80-wire cables between IDE devices.  It seems likely that the hard drive manufacturers wouldn't want to "cripple" their drives when an 80-wire cable wouldn't be available. 2. They also probably understand that large hard drives (i.e. their future market) can be supported on legacy systems by modifying BIOSes to older ATA chipsets.  I doubt the home user is going to modify their PC's BIOS to access larger hard drives, but large company installations might take the time and effort, especially if there are people already producing documents on how to modify the BIOSes and how to possibly automate that task. 3. The hard drive manufacturers also must use more logic on their IDE chipsets if they are going to shut off speeds below UDMA5 in 48-bit LBA addressing.  That would increase the cost in die space and engineering time. In conclusion, my guess is that all of those factors will lead to most if not all 48-bit LBA drives supporting speeds below UDMA5.

A quick web search found these pages:

  http://www.wdc.com/en/library/ata/index.asp

QUOTE

Ultra ATA/100 hard drives are 100 percent backwards compatible with Ultra ATA/66, Ultra ATA/33 and DMA, and with existing EIDE/IDE hard drives, CD-ROM drives and host systems.

  http://www.redneck-puters.com/help/ata.shtml

QUOTE

4. I don't have a system that supports Ultra ATA/100, can I run the Ultra ATA/100 HDD in it? Yes, the HDD will not run in UDMA/100 mode but instead is a slower compatible mode such as Ultra ATA/33, DMA Mode 2 (16.6 MB/s) or PIO Mode 4 (16.6MB/s)

- Paulb

[oz_paulb]

QUOTE (dmsdude90 @ Aug 28 2003, 08:19 PM)

when will this probably be done

I'm testing it right now.  I've written a test app that fills the F: partition with a bunch of unique files, and will go back and compare them after the disk is full to verify that there was no cross-writing/'wrapping' at 137GB.

The test app is very slow (I just hacked it together using OpenXDK).  But, it's been running long enough now that I don't want to stop it.

So far, it's written a total of 0x11b80000 (29 bits LBA, btw) unique sectors (152,202,903,552 bytes) without error.  I won't know until it's finished writing/goes back to read whether/not the test is successful.

My F: partition had 195,876,110,336 bytes free when I started the test, so it's still got a ways to go.  I'll keep updating this thread with results.

There's also the issue with Slayer's installer 'hanging' when used with my new LBA48 KERNEL.  I'd like to get that resolved before making a release.

I think I'll be releasing something in the next couple of days, assuming everything continues to go well.

- Paulb

[oz_paulb]

I just found another Ultra ATA/100 page that hints at the same issue Franz spoke of:

  http://www.seagate.com/support/kb/disc/ultra_ata100.html

QUOTE

Are the Ultra ATA/33, Ultra ATA/66 and Ultra ATA/100 interfaces backward compatible? All Seagate Ultra ATA/100 drives are backward compatible with Ultra ATA/33, Ultra ATA/66, and legacy ATA interfaces. However, due to the inability of some ATA host controllers and motherboards to properly interface with Ultra ATA drives, Seagate suggests using the "toggle" utility to set the Ultra ATA/100 drives to Ultra ATA/33 or Ultra ATA/66 mode for better compatibility with a non-ATA/100 host controller or motherboard.

So, some host systems may have problems with some Ultra ATA/100 drives.  But, in the case of Seagate, it looks like an Ultra ATA/100 drive can be 'downshifted' to be Ultra ATA/33 via a PC-based utility (then used in the Xbox).

- Paulb

[crumb]

QUOTE (oz_paulb @ Aug 28 2003, 08:45 PM)

http://www.wdc.com/e...y/ata/index.asp QUOTE Ultra ATA/100 hard drives are 100 percent backwards compatible with Ultra ATA/66, Ultra ATA/33 and DMA, and with existing EIDE/IDE hard drives, CD-ROM drives and host systems.   http://www.redneck-p.../help/ata.shtml QUOTE 4. I don't have a system that supports Ultra ATA/100, can I run the Ultra ATA/100 HDD in it? Yes, the HDD will not run in UDMA/100 mode but instead is a slower compatible mode such as Ultra ATA/33, DMA Mode 2 (16.6 MB/s) or PIO Mode 4 (16.6MB/s)

But are they backwards compatible with 48-bit LBA or the standard 28-bit LBA on ATA/66, ATA/33, and DMA?

A way to determine this would be to get a bunch of large hard drives from many manufacturers.  Connect all the hard drives with 40-conductor cables.  Attempt to partition the drives.  If they will partition to sizes greater than "137 GB" then 48-bit LBA  will pretty much work for at least UDMA2 speeds.  You could also try setting the UDMA/PIO settings manually in the BIOS and see what low speeds 48-bit LBA will operate under.

(P.S. I am still guessing that 48-bit LBA can be accessed at speeds lower than UDMA5.)

[oz_paulb]

QUOTE (crumb @ Aug 28 2003, 09:33 PM)

(P.S. I am still guessing that 48-bit LBA can be accessed at speeds lower than UDMA5.)

Yes, I think the ATA-command set is complete different from the physical interface.  There would be no reason for a drive that physically works in LBA28-addressing mode to stop working when you use (slightly) different LBA48 commands.

- Paulb

[desertboy]

This is going to be interesting to see what happens next.
If you add a g: with the extra space >137 gig on you drive then reverted to a previous bios then I would assume it would simply diaspeer much like f: disapeers when you turn off your modchips or load a retail bios with the phoenix loader which would add another level of compatibility if it turns out this has unresolvable issues with retail software.

To answer a previous question Exploit users can load a bios with the phoenix loader.

[dmsdude90]

paulb when do u think it will be realesed to us modders to use because i just fried my 120hd and got and 80 and i am about to open it till i read this post so   do our best so can got get that beautiful 200 maxtor  or 250



this kicks ass

[Quest]

"behind every big success is someone with a great idea
and behind every great idea is someone saying it won't work"

[krawhitham]

QUOTE (Xeero @ Aug 28 2003, 02:16 PM)

QUOTE (krawhitham @ Aug 28 2003, 08:55 AM) you're not a dick or anything are you not everyone will to use a "normal kernel".  I installed a homebrew mod and have never had a problem or a desire to load the "normal kernel" since if you are talking about the soft mod users, he said he did not know if it would work. Get a clue most users have a modchip or have flashed the tsop.  just the new kids on the block that are afraid to open the xbox are using the soft mods FYI, Live requires the retail kernel...

Buy another xbox.

this does not bother me, I hate online games

[Flagg3]

Whew, man this is a LONG thread for something that only really started a few days ago!

First off, a big thanks to you oz_paulb.  I have been very interested in this and was wondering why interest died down in the original thread when it seemed that it was possible to break the 137gb barrier.

After just now reading this whole thread, here is my input:

You asked about the source for Slayers Auto install.  He is no longer actively updating it but that's not what you'd need either way.  If you look at it, all it is is a very cleverly written evox.ini.  The auto installer doesn't actually add any code to evox, it just takes advantage of the ability to heavily customize Evox.  If you look at the included evox.ini, you'll see that the auto-installer simply calls the format functions from evox to prepare a new drive.  So basically, if your having a problem with formatting all of the partitions in Slayer's Auto-install, you'd need the source for the evox dashboard to determine where the problem is.  

I am curious to hear your results of the testing that your doing right now, because there is the possiblilty that even though you could format the drive to higher than 137gb, the area above 137gb may not be accessible.  (I have in the past been able to seem to overcome a size limitation on a drive only to have the extra space be unusable.  So hopefully your test results are positive.)

As for these new limitations in newer games like Enter the Matrix I have yet to see any evidence of this.  Enter the Matrix works fine from an extended partition and IGR works as well, leading me to believe that the hacked kernel is never removed from memory.

And finally, I have installed quite a few 160gb drives in xboxes and never used the compatibility jumper settings at all, so it obviously is working fine at UDMA2 as is.  I see no reason why there would be a hardware limitation to implementing LBA48 addressing.  

Thanks again for all of your hard work!  

Flagg

[oz_paulb]

The first pass of my LBA48 test is complete (finished writing files).  It wrote over 0x16cd0000 unique sectors (195,857,219,584 bytes) spread out across 182 files.

Initial result: all of the files are there on drive F:, and so are the other drives (C/E).  This means that (at least) it didn't "wrap" at 137GB and start back at the beginning of the disk.

I'm now going to run the 'verify/compare' portion of the test.  I'll post results here when I have them.

Update: I didn't want to wait for my entire 'compare' test to run before getting a feeling for whether/not it was working.  So, I threw together a version that reads/compares the first 128KB of each of the 182 files.  I ran it, and it passed.  It's not a complete test, but it at least tells me that things are looking good.  Now I'll run the full (slow) compare test.

Update 2: At the rate the 'full compare' test is running (about 57 secs per GiB), it looks like I'll have full results by about 11:10pm US Eastern time tonight.  That'll be a test over the entire 195GB that I wrote.  I'll pass the 137GB barrier sooner, and once I notice that it's occurred, I'll update.


- Paulb

- Paulb