Post by: TeamTEOR on October 10, 2004, 05:43:00 PM
Post by: hipko on October 10, 2004, 07:59:00 PM
Post by: thecowsays on October 10, 2004, 08:18:00 PM
this is over a year old
brought back from the dead
Post by: TeamTEOR on October 11, 2004, 01:20:00 AM
Post by: JoeBrady on November 13, 2004, 02:32:00 AM
Post by: hoshantm on February 07, 2006, 10:52:00 AM
Post by: oxjeremy334 on February 07, 2006, 02:26:00 PM
Post by: ventline on February 07, 2006, 05:34:00 PM
QUOTE(oxjeremy334 @ Feb 7 2006, 02:57 PM) 
What the hell? This is like 2 years+ since the last post and you reffed something that doesn't have to do with xboxes?
what the hell ill bump it also. and for thoughs who dont know by now yes you can go over 137 with a bios that has lba48. and yes you can go over 250 just need to use XBpartitioner and format with 32 byte clusters
lol lol lol
Post by: HardEight on May 06, 2006, 07:52:00 PM
Will the new 750gb Seagate Drive Work fine in the Xbox even with the 32 byte cluster partitioning?
What is the max size the Xbox can handle?
I really don't want to bye the new 750gb, fill it up and then have all my data start getting all messed up like it did when I didn't 36 byte partition my 400gb drive... Man did that suck lamma's.
Hard8
Post by: mrdan on May 06, 2006, 08:36:00 PM
Post by: HardEight on May 06, 2006, 09:17:00 PM
This Topic is completly relevent to my question.
Instead of somone having to search for the history of what is the largest hard drive and what relevent obstacles were overcome, they can start at the begining of this thread and see the histroy of the LBA48 hack, the 32k Cluster partitioning and the differences between F: and G: support.
NO Reason to close whatsoever... please feel free to contribute though, if you can!
Post by: oz_paulb on August 24, 2003, 10:42:00 AM
I've searched through the forums, and it appears that the largest hard drive supported is still 137GB (any larger drive will be limited to 137GB). Is that the case?
Xbox-Linux seems to support LBA-48 (where Xbox kernel only supports LBA-28, limiting it to 137GB), so it seems that it's not a 'chipset' issue (as was previously thought).
I think it would be simple to make the Xbox kernel support LBA-48 (I'm willing to do this), but I don't want to make the effort if it's already been done.
Thanks,
- Paulb
This post has been edited by oz_paulb: Aug 24 2003, 05:42 PM
Post by: Champ189WS on August 24, 2003, 10:42:00 AM
Post by: oz_paulb on August 24, 2003, 10:44:00 AM
- Paulb
Post by: a9h3x on August 24, 2003, 10:50:00 AM
| QUOTE (oz_paulb @ Aug 24 2003, 02:37 PM) |
| Can I assume that people would be interested in support for larger drives? - Paulb |
absoloutly
Post by: Mad_Gouki on August 24, 2003, 10:56:00 AM
Post by: a9h3x on August 24, 2003, 11:16:00 AM
Post by: xVanWildeRx on August 24, 2003, 10:51:00 PM
Post by: heinrich on August 25, 2003, 08:38:00 AM
| QUOTE (Champ189WS @ Aug 24 2003, 02:35 PM) |
| 137 is the limit |
| QUOTE |
| 137gb is the most that xbox supports |
If this was the case, then why does the cromwell bios support larger drives?
oz_paulb: if you are serious, i would recommend trying to contact Team Xecuter (maybe PM Ubergeek here on the forums)
Post by: bitbyte on August 25, 2003, 09:57:00 AM
Post by: oz_paulb on August 25, 2003, 07:16:00 PM
| QUOTE (bitbyte @ Aug 25 2003, 06:50 PM) |
| Linux does not bother with the bios, so If you have a 180GB disk, The xbox only uses 137, but you can format a linuxpartiton on the rest of 43GB and use it happily in linux. |
Right, that's proof that there is nothing in the chipset that prevents LBA-48 (>137GB) drive support - it's 100% a software problem.
(others have also confirmed that Linux uses >137GB drives on Xbox just fine)
- Paulb
Post by: oz_paulb on August 26, 2003, 09:53:00 PM
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: mikejf on August 27, 2003, 03:30:00 AM
Post by: -Gadget- on August 27, 2003, 11:15:00 AM
its people like u that keeps this scene always moving and i LOVE the ride
and i think u have every ones support !
Mick ...
Post by: boxorox on August 27, 2003, 11:29:00 AM
Post by: oz_paulb on August 27, 2003, 11:54:00 AM
| QUOTE (boxorox @ Aug 27 2003, 08:29 PM) |
| Nice job paulb. I knew it would only be amatter of time. Keep us posted |
Thanks.
It's amazing how a little bit of 'mis-information', when said with authority, can cause everyone to just give up on LBA48. (A long time ago, someone said that it was a problem with the chipset/LBA48 was impossible, and everyone (including myself) must have believed that person).
Thanks to bob_mckenzie for pointing out that it is in fact possible.
- Paulb
Post by: heinrich on August 27, 2003, 05:05:00 PM
Post by: AzraBlackmoor on August 27, 2003, 05:48:00 PM
Post by: shortstuff22090 on August 27, 2003, 05:16:00 PM
Post by: Large Dopant white on August 27, 2003, 05:53:00 PM
Post by: Glycerine on August 27, 2003, 06:00:00 PM
Post by: oz_paulb on August 27, 2003, 06:29:00 PM
| QUOTE (heinrich @ Aug 28 2003, 02:05 AM) |
| I am not sure if you have talked to either xecuter or evox about this incredible hack (or maybe you were with one of them, and doing this on your own) but this is certainly HUGE news, and I would think that they would love to hear about it. You say you have a 'MS Xbox KERNEL' doing this, but can run your own apps and recognizing 8 more partitions? Excuse me for sounding sceptacle, but it is hard to believe that was done in just a few days time, when other teams have been doing bios hacks for quite some time and havent managed this. Hopefully you will share your findings with one of the established bios teams, and we can get this in our xbox's |
So far, I'm doing this independently. I'd like for the various 'mod bios' developers to take my changes/incorporate them into their BIOS's, but I figured I'd get it all worked out ahead of time.
Since I'm not sure if/when mod bios developers will incorporate my changes (and whether/not they'll incorporate ALL of my changes - I'm really concerned that the 'partition table' stuff may get ignored since it really only helps other OS's like Linux), I'm also in contact with the developer of Xbtool, and it's possible this will be a selectable option that can be applied as a 'patch' to any bios - just like the various other color/etc patches he's already got.
As far as being sceptical, I understand - there's always someone making great claims that ends up being bogus. But, you can check my history - even though my account on 'xbox-scene.com' is new, I've been hacking the Xbox since about December, 2001. I wrote the 'xbflash' utility, which eventually became the (excellent) 'Xbtool' utility. I know the Xbox KERNEL/security system inside-out (although I'm willing to admit that I don't know it 100%). For an example of my knowledge on the Xbox KERNEL, see the following article that I wrote:
http://xbox-linux.so.....sh structures
(I'm not trying to 'brag' about my abilities - just trying to make the point that I'm not feeding everyone BS - I know how to hack the KERNEL)
As for whether/not my own app can recognize 8 partitions - I haven't tried it (yet), but there's no reason it wouldn't work. There's a single place in the KERNEL where partition #'s are converted to a 'starting LBA sector/# of bytes in partition'. It was hacked in other bios's to allow for the extra 'F:' partition (didn't exist in original Xbox KERNEL). I've just replaced/extended this function to use a table. The size of this table is arbitrary - I suppose I could make '32' partitions if I wanted. There may be other limits in the Xbox KERNEL for 'max # partitions' on a physical media, but I'm not aware if it at the moment.
I've got my copy of the KERNEL working with LBA48 now (in all disk I/O functions (read/write/verify)). As I said in an earlier post, I'm going to write a test app that'll fill the F: drive with a bunch of unique files, then go back and compare them/verify that it's all actually working. I think I'll get that finished tonight - unless I run into problems.
Well, I should get out of here now (back to hacking). I'll update this thread when I've got more news.
- Paulb
Post by: Scan-C on August 27, 2003, 06:32:00 PM
| QUOTE (heinrich @ Aug 28 2003, 02:05 AM) |
| I am not sure if you have talked to either xecuter or evox about this incredible hack (or maybe you were with one of them, and doing this on your own) but this is certainly HUGE news, and I would think that they would love to hear about it. You say you have a 'MS Xbox KERNEL' doing this, but can run your own apps and recognizing 8 more partitions? Excuse me for sounding sceptacle, but it is hard to believe that was done in just a few days time, when other teams have been doing bios hacks for quite some time and havent managed this. Hopefully you will share your findings with one of the established bios teams, and we can get this in our xbox's |
maybe the teams didn't manage it because they never tried.
i never thought you could get a xbox bios to use lba48 without increasing it's size a few mb which would be to much to cache it into the ram at bootup.games would slow down and so on.because of that i thought no one would ever try it.
great work!keep it up and keep us informed if the drive is 100% accessable or if it overwrites itself after 137 gb.
Post by: myst1x on August 27, 2003, 06:37:00 PM
excellent work Paul B....EXCELLENT WORK!!!
Post by: heinrich on August 27, 2003, 06:43:00 PM
Keep us updated, and I cant wait to get more out of this 160gig drive
Post by: nolga on August 27, 2003, 06:47:00 PM
Keep us posted this is great news
Post by: SigTom on August 27, 2003, 07:35:00 PM
All i could say when i read it was Holy Shit. This is some great news. I am very impressed that youve got it to do this man. This is a great leap for anyone whose modded thier XBox. Please keep up the good work. May I give you a "Big Up, Much Respect" (shades ala Ali G) and say keep on hacking boy keep on hacking!!!!
Post by: Illumina on August 27, 2003, 07:03:00 PM
Post by: oz_paulb on August 27, 2003, 07:39:00 PM
| QUOTE |
| "Big Up, Much Respect" (shades ala Ali G) |
I wish I got Ali G on DirecTV
His show has been on HBO a couple of times (and I thought he was great), but I think it's on "HBO Zone" more often (which isn't on DirecTV).
Oh well...
- Paulb
Post by: lowry383 on August 27, 2003, 07:03:00 PM
Post by: trevlenOO6 on August 27, 2003, 07:26:00 PM
Post by: VCD_Junky! on August 27, 2003, 08:13:00 PM
199 games totaling 256gb; 137gb just isn't enough. This is also perfect for users with an Xbox in their car. Finally they can carry all their games, a chunk of movies, roms, and a hoard of mp3s without HD switching/swapping!
...if this proves to work, the last Xbox storage hurdles would be USB storage and games/apps executed from network drives (I can only dream
)
Post by: Heet on August 27, 2003, 08:23:00 PM
Post by: EvilWays on August 27, 2003, 08:16:00 PM
| QUOTE (VCD_Junky! @ Aug 28 2003, 04:37 AM) |
| the last Xbox storage hurdles would be USB storage and games/apps executed from network drives (I can only dream ) |
It'll most likely stay that way since the Xbox only uses USB 1.1.
Post by: Large Dopant white on August 27, 2003, 08:54:00 PM
Even without that, you've discovered an awesome hack. Makes me happy I haven't upgraded from my 40GB HDD yet.
Post by: oz_paulb on August 27, 2003, 08:59:00 PM
| QUOTE (Large Dopant white @ Aug 28 2003, 05:18 AM) |
| One question just came to mind: you mentioned you made your own partition table, right? I'm under the assumption that you only did it for the space beyond 137GB, but correct me if I'm wrong. Regardless, you think you have a way to change ALL the partition tables (i.e. say I wanted 10GB on E:, 40GB on F:, and 80GB on G:)? Even without that, you've discovered an awesome hack. Makes me happy I haven't upgraded from my 40GB HDD yet. |
Yes, I believe all the partitions can be changed (assuming that apps like dashboard don't make assumptions about sizes of each of the drives).
Of course, I'm just talking about the low-level (empty) partitions on disk. Some sort of utility would need to be written/modified to re-format these partitions, and load all of the default stuff back into them.
Slayer's EvoX installer deals with formatting "F:" based on how big the partition is. I don't know if it will format other partitions based on what the KERNEL tells it about sizes, or if it's got built-in hard-coded sizes.
- Paulb
Post by: ikkuranus on August 27, 2003, 09:25:00 PM
soon maybe we all can get that monster drive for our xboxes
Post by: oz_paulb on August 27, 2003, 09:43:00 PM
With my bios installed, when I tell it to load a new big hard drive from scratch, it pops-up "Writing config sector" (or something like that) and 'hangs'.
If I go back to my old bios and do the same thing, it works.
If, after having my drive prepared, I go to my new bios and tell it (Slayer's EvoX installer) to format F: only, it works fine.
I'm going to ignore this problem for now, since it could be some hard-coded KERNEL memory accesses in Slayer's code, but it's a reminder that my code may not be perfect the first time around.
I don't suppose anyone knows where to get the source code to the Slayer EvoX installer app/apps? I know most people don't seem to publish source. Is "Slayer" still active? Anyone know how to contact him?
- Paulb
Post by: SigTom on August 27, 2003, 09:09:00 PM
| QUOTE |
| I wish I got Ali G on DirecTV |
PM Me, I can hook you up with the rips of the Shows that have been on HBO. Ive got HBO On Demand, so i can set ya up with some epis. Once again man, awesome work.
And yeah yo contact Slayer, just PM 1wolf1, aka Slayer, and he can talk with ya. Or head to his post here Slayers 2.1 Thread and head over to his IRC Channel.
Post by: msn25 on August 27, 2003, 09:49:00 PM
Post by: mav on August 27, 2003, 10:14:00 PM
i do belive that the partitions are all hardcoded for e,c,x,y,z (yes e drive is first on the xbox hdd) then evox added suport for f, afterwards
trying preping the hdd and doing the other partions manually (im thinking using evox + ftp commands) rather than a predefied utility, possible even format the partions from within linux (cd boot) with fatx.
hope that gives you some ideas at least. cant wait to add a 300GB HDD
Post by: elduderino1234 on August 27, 2003, 10:25:00 PM
| QUOTE (oz_paulb @ Aug 27 2003, 10:07 PM) |
| I've run into a problem with the Slayer EvoX installer (2.1) With my bios installed, when I tell it to load a new big hard drive from scratch, it pops-up "Writing config sector" (or something like that) and 'hangs'. If I go back to my old bios and do the same thing, it works. If, after having my drive prepared, I go to my new bios and tell it (Slayer's EvoX installer) to format F: only, it works fine. I'm going to ignore this problem for now, since it could be some hard-coded KERNEL memory accesses in Slayer's code, but it's a reminder that my code may not be perfect the first time around. I don't suppose anyone knows where to get the source code to the Slayer EvoX installer app/apps? I know most people don't seem to publish source. Is "Slayer" still active? Anyone know how to contact him? - Paulb |
he goes by the name 1wolf1 on these forums. you can try PMing or emaling him here http://forums.xbox-s...ODE=03&MID=2154
Post by: purist on August 28, 2003, 12:22:00 AM
Post by: oz_paulb on August 27, 2003, 11:55:00 PM
| QUOTE (purist @ Aug 28 2003, 08:46 AM) |
| So what about the rest of us lackeys that use the font audio exploits for the soft mod...do we get to have fun too? |
I haven't messed with any of these new 'soft mods', so I really can't say how things would work.
I'm not sure. When you load a 'soft mod', are you loading a completely new bios/kernel into memory? If so, then it may be possible.
But, the Xbox would boot in LBA-28 mode (limited to 137GB), then you'd load your new bios, and it would be in LBA-48 mode. Partitions would need to be set up so they'll work in both modes, or so everything is 'below' the 137GB line, and an extra partition above the 137GB line that's only visible after loading the new bios/kernel.
- Paulb
Post by: hamtitampti on August 28, 2003, 12:38:00 AM
but i hear this discussion now since weeks.
and it is false.
First, you should tell all people that if you enable lba48 (which is simple)
you can not access the data with an normal kernel anymore
From a Windows Support Site
>If you enable 48-bit LBA support on a system that does NOT have a 48-bit LBA-
>compatible BIOS, and a hard disk larger than 137 GB, you will experience data
>corruption.
but as people sure are "more intelligent" as i, please consult ATA/ATAPI 6.0 specification.
It is written very clear there, why the "using in both worlds" is not possible.
Good luck for your non-working & incompatible system .
franz
Post by: Biznaz on August 28, 2003, 12:19:00 AM
here's to hoping
Post by: Troed on August 28, 2003, 12:58:00 AM
franz - who cares about XboxLive? That's still the only reason for anyone to dual-boot an Xbox with mod on/off.
Post by: xboxSlayer on August 28, 2003, 01:03:00 AM
Post by: SigTom on August 28, 2003, 01:43:00 AM
(the following is meant to be read in an Arnold Schwarzenegger (austrian) accent)
Franz:
This is Hans. Where have you been? We need to work out those weak arms of yours. You little girly man. Why do you come on here and say youve heard about this for weeks when this discussion just started (well at least Pauls Thread) on Aug 24th. I am thinking you need to go and pump yourself up, mind and body. Let the man work and see if he is correct. I am always wanting to look at you puny small minded nay sayers and slap you like the little girly men you are. Because I am here to PUMP (clap) YOU UP!!
(OK im Done the above was a complete joke, so take it in that light)
For real tho, let the man work, dont dog him, let him work and work and work, then he can say if it is accesible 100% of the time. When it comes to modding your XBox your ALWAYS taking the chance youll have a non-working & incompatible system, thats nothing new and quite frankly, doesnt scare most of the people that read these forums. Dont be a divider, be a combiner just like good ol G.W. Bush. Now, Paul, hows it going man? Hope all is well, work hard, and if you need some other people to test this out, I have a couple virgin XBoxs and 137 GB + drives. Let me know, ill be a guinea pig, wont be the first time Ive destroyed an XBox, how else am I supposed to get replacement parts?
Post by: xVanWildeRx on August 28, 2003, 01:46:00 AM
i guess ill wait on deciding on which hard drive to buy for my baby.
Post by: janson on August 28, 2003, 01:47:00 AM
What is it that i haven't understood correct?
Post by: loveisweakness on August 28, 2003, 02:06:00 AM
| QUOTE (janson @ Aug 28 2003, 10:11 AM) |
| I just don't get it. afaik the limit is set because xbox uses ATA33 which can only support 137gb because of the limit of the LBA mode. However, ATA/ ATAPI-6, the prevailing version of the ATA standard so far includes UltraDMA mode 5 and the expansion of the LBA mode from 28 bits (with a maximum of 137 GB per drive) to 48 bits, but xbox doesn't use ATAPI-6 afaik. What is it that i haven't understood correct? |
from what i remember reading not long ago when i was looking up some info when putting linux on an old computer the lba48 addressing scheme isnt dependant on the controller
i never put that to the test tho as i was just running it off a 4 gig hard drive
Post by: fixxxer on August 28, 2003, 02:28:00 AM
Post by: chinmi on August 28, 2003, 02:35:00 AM
keep up the good work
Post by: hamtitampti on August 28, 2003, 03:51:00 AM
Look.
We had this discussion in cromwell and was a long discussion inside the xbox-linux team
and i know cromwell very good, as i am the main programmer now there.
i see not a problem starting the dashbaord
not even linux.
but i see a problem in most of the new games.
most new games, like HALO, matrix ....
compleate exit the kernel in RAM
and have a new kernel inside
so this games are not playable anymore, as they get corrupted data
there are hdd's > 137 Gybte, who have a lba compability mode, where this could work.
but note, not every hdd.
and even then, the hdd is limited to 137 GB again, which makes your fatx partition corrutped again.
again, i not only came on 24. august when paul published it.
i told this now long time ago.
But it seems, it is still hard for some people (..) to belive that this is the truth.
so i wish you all luck in your attempt to create a non-working bios for most of the games.
Post by: janson on August 28, 2003, 03:17:00 AM
| QUOTE (loveisweakness @ Aug 28 2003, 10:30 AM) | ||
from what i remember reading not long ago when i was looking up some info when putting linux on an old computer the lba48 addressing scheme isnt dependant on the controller i never put that to the test tho as i was just running it off a 4 gig hard drive |
I doubt that it's that way. Anyone can confirm this?
Post by: Troed on August 28, 2003, 04:45:00 AM
| QUOTE (hamtitampti @ Aug 28 2003, 11:15 AM) |
| but i see a problem in most of the new games. most new games, like HALO, matrix .... compleate exit the kernel in RAM and have a new kernel inside |
... so, following your argument, those games would be immune to kernel hacks ... like ... IGR?
Can't say I've tried - maybe you have? (I see no point in using an Xbox for games)
Or, do you mean to say that those games would use their own methods for accessing the HD?
Post by: oz_paulb on August 28, 2003, 05:15:00 AM
| QUOTE |
| but as people sure are "more intelligent" as i, please consult ATA/ATAPI 6.0 specification. It is written very clear there, why the "using in both worlds" is not possible. |
Can you point me to a specific chapter/section # of the ATA-6 spec where it's written so clearly? I haven't read the entire spec, but it doesn't appear to have any big warnings about incompatibility.
In the meantime, I'm continuing with my testing. My test app has been running, filling the F: drive with unique files (has written about 60GB in LBA-48 mode so far without errors - when it's filled the disk, I'll go back and verify everything).
As with any Xbox hack, people should be careful. I'm not going to make any guarantees that every > 137GB drive will work - maybe Franz is right and only certain "> 137GB" drives will work on the Xbox. In that case, a list of 'known good' drives can be published - as more people experiment with the new KERNEL.
As someone else pointed out, Xbox-Linux seems to work with LBA-48 just fine - again, maybe they've been lucky with the specific brand/model of drive they purchased.
- Paulb
Post by: oz_paulb on August 28, 2003, 05:22:00 AM
| QUOTE |
| Drives larger than 137GB require Windows 2000 SP3 or higher, XP SP1 or higher, or ATA/133 PCI card |
This certainly sounds to me like it'll work on any PC (including Xbox) as long as your software drivers are up to date (have support for LBA-48). There doesn't seem to be any hardware incompatibilities with 'old' PC's (like Xbox).
Maybe the Maxtor drive is unique - if so it looks like I was lucky in my first purchase of a "> 137GB" drive.
- Paulb
Post by: krawhitham on August 28, 2003, 05:31:00 AM
| QUOTE (hamtitampti @ Aug 28 2003, 09:02 AM) |
| Sorry to write here, paul but i hear this discussion now since weeks. and it is false. First, you should tell all people that if you enable lba48 (which is simple) you can not access the data with an normal kernel anymore From a Windows Support Site >If you enable 48-bit LBA support on a system that does NOT have a 48-bit LBA- >compatible BIOS, and a hard disk larger than 137 GB, you will experience data >corruption. but as people sure are "more intelligent" as i, please consult ATA/ATAPI 6.0 specification. It is written very clear there, why the "using in both worlds" is not possible. Good luck for your non-working & incompatible system . franz |
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
Post by: juan23 on August 28, 2003, 05:36:00 AM
with a sigh of releif, I can invision my 200 gigger getting full to the max
keep us all posted
Post by: krawhitham on August 28, 2003, 05:45:00 AM
| QUOTE (hamtitampti @ Aug 28 2003, 12:15 PM) |
| but i see a problem in most of the new games. most new games, like HALO, matrix .... compleate exit the kernel in RAM and have a new kernel inside so this games are not playable anymore, as they get corrupted data |
if that was true, Why does Halo and Matrix both work off the HD, if they load a new kernel why would the new Kernal allow access to the F: partition?
just a question
also I put the halo game (retail) in the xbox loaded it and the IGR still worked. why would the new kernel also have the IGR function
Post by: Xeero on August 28, 2003, 05:16:00 AM
| 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...
Post by: Troed on August 28, 2003, 06:01:00 AM
| QUOTE (oz_paulb @ Aug 28 2003, 12:46 PM) |
| Maybe the Maxtor drive is unique - if so it looks like I was lucky in my first purchase of a "> 137GB" drive. |
I have a Maxtor Diamondmax 9 Plus or something, 160Gb. To get it to work in Windows 2000 I hade to install a "big drive patch". That was it - could well have been superseeded with a service pack now.
Post by: Blind_Samurai on August 28, 2003, 06:28:00 AM
Post by: Quest on August 28, 2003, 06:54:00 AM
i'm pretty shure not even a .wmv movie can exchange the kernel :-)
Quest
Post by: lookformeb on August 28, 2003, 06:57:00 AM
Post by: janson on August 28, 2003, 07:13:00 AM
| QUOTE (oz_paulb @ Aug 28 2003, 01:46 PM) | ||
I just looked at the side of the box for my Maxtor 200GB drive ("System requirements"). It says:
This certainly sounds to me like it'll work on any PC (including Xbox) as long as your software drivers are up to date (have support for LBA-48). There doesn't seem to be any hardware incompatibilities with 'old' PC's (like Xbox). Maybe the Maxtor drive is unique - if so it looks like I was lucky in my first purchase of a "> 137GB" drive. - Paulb |
It's just to add the functionality to use 48bit, however you must have the same support at the hardware. That's what i think.
Post by: dmsdude90 on August 28, 2003, 08:05:00 AM
make a tutorial on this it will change THE WORLD or just x-s but that is still great
Post by: janson on August 28, 2003, 09:28:00 AM
This interested me so i started to read some documentation, the following is my own personal conclusion.
(<ATA 133 = ata33,66 etc.. ATA133> = ata133 and newer..)
<ATA133 uses a 28bit LBA adressing. When windows was developed they allocated 28bit for the LBA adressing, why adress more when it wasn't needed?
ATA133> uses a 48bit LBA adressing. As i wrote before, windows only allocates 28 bit for the LBA adressing as default, that's why you have to use Windows 2000 SP3 or higher, XP SP1 ... It makes windows allocate 48 bits for the LBA adressing.
So, why can't i just update windows and use >137GB on my <ATA133 ? Because the systems with <ATA133, BIOS is set to only allocate 28bit! In newer BIOS for the ATA133> the bios adresses 48bits.
Conclusion: If we could rewrite the bios to allocate 48bit then we should be able to use 137GB> even on 'old systems' running <ATA133. I claim that the limitation is NOT in the hardware, it's in the software.
This is only a theory and i don't know if it works practically or if there's something importatant i've missed,
thank you oz_paulb for working on this, we'll soon have an answear to this.
Post by: archon79 on August 28, 2003, 09:29:00 AM
http://www.storagereview.com/guide2000/ref.../bios/over.html
BIOS translation (which looks like what paul is doing) seems to be a possible solution to the >137GB drive problem...
BTW, good work regardless of the outcome paul! :)
This post has been edited by archon79: Aug 28 2003, 04:29 PM
Post by: nyarrgh on August 28, 2003, 09:29:00 AM
Is it possible to access a drive using both LBA24 and LBA48? It might be okay to add another partition. Then make all the regular partitions + Drive F available when using LBA24, and all partitions when booting off a bios that supports LBA48. Sort of like Drive F not being available when booting off the retail bios.
Post by: warbeast on August 28, 2003, 09:43:00 AM
will it work on v1.2 v1.3 ?
Post by: oz_paulb on August 28, 2003, 09:44:00 AM
| QUOTE |
| Conclusion: If we could rewrite the bios to allocate 48bit then we should be able to use 137GB> even on 'old systems' running <ATA133. I claim that the limitation is NOT in the hardware, it's in the software. |
This has been my understanding, too.
Shortly before I saw Franz's initial post to this thread stating that it's not possible, I saw the following message on the xbox-linux mailing list:
| 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. (I would hope that the packaging would warn about this, though).
Now, I don't know enough about differences between UDMA5 and PIO/UDMA2, but my feeling is that if a drive doesn't support PIO/UDMA2, and the Xbox doesn't support UDMA5, then it just plain won't work - even in LBA28 mode (because I think that this is a lower-level hardware/chipset method of data transfer between the two devices).
If a drive supports PIO/UDMA2 transfers in LBA28 mode, then I don't see why they'd disable that method just because the BIOS software is using the LBA48 commands instead of LBA24 commands - the drive is either hardware-compatible with the PC or it isn't (again, this is my feeling, but I can't say for sure).
So, if a >137GB drive 'works' in a standard Xbox KERNEL (in LBA28 mode - limited to 137GB), then I don't see any reason why it won't work in LBA48 mode with a modified KERNEL.
As I said before, this will be a learning experience for many of us here, and we may find that certain drives are incompatible. In that case, we'll just need to make a list of 'known good' and 'known bad' drives. Anyone experimenting with LBA48 in the early stages will risk data corruption - but that's to be expected (I think).
- Paulb
Post by: oz_paulb on August 28, 2003, 09:09:00 AM
| QUOTE (warbeast @ Aug 28 2003, 06:07 PM) |
| great work paul will it work on v1.2 v1.3 ? |
It should be possible to patch any KERNEL version to use LBA48, so I don't see why it wouldn't work on 1.2/1.3/1.xx Xbox's.
- Paulb
Post by: oz_paulb on August 28, 2003, 09:47:00 AM
| QUOTE (nyarrgh @ Aug 28 2003, 05:53 PM) |
| It would be enough for me to add support for an extra partition. Drive G for example? so that the other partitions remain the same. Is it possible to access a drive using both LBA24 and LBA48? It might be okay to add another partition. Then make all the regular partitions + Drive F available when using LBA24, and all partitions when booting off a bios that supports LBA48. Sort of like Drive F not being available when booting off the retail bios. |
It seems like this should work, but some experimentation would be necessary to prove that it's possible. (Linux is working by having an extra partition above the 137GB line)
- Paulb
Post by: MemphisReins on August 28, 2003, 09:58:00 AM
I wish I could offer come support but I don't have anywhere near the knowledge this takes to do, so all i can do is offer my congrats and hope that you don't get pissed off by those who doubt you. At the end of the day, things may or may not work, but until you try to find a way around problems, no-one will get anywhere.
Nice one on your work so far and keep it up!
Post by: KamelRed on August 28, 2003, 10:36:00 AM
Secondly, I would like to thank oz_paulb for all his work and giving us hope that the 137gb barrier will be broken.
Post by: oz_paulb on August 28, 2003, 10:48:00 AM
| QUOTE (KamelRed @ Aug 28 2003, 07:00 PM) |
| Secondly, I would like to thank oz_paulb for all his work and giving us hope that the 137gb barrier will be broken. |
Let's remember that it was 'bobmckenzie' who first broke the myth that LBA48 wouldn't work - I'm just taking the info he provided and actually trying it out.
- Paulb
Post by: Xeero on August 28, 2003, 10:15:00 AM
| QUOTE (MemphisReins @ Aug 28 2003, 01:58 PM) |
| Well, no idea what the dude above me is on about but anyways... |
Deleted it.
Post by: dmsdude90 on August 28, 2003, 11:55:00 AM
Post by: Spency234 on August 28, 2003, 12:02:00 PM
Thank You
Post by: crumb on August 28, 2003, 12:11:00 PM
| QUOTE (oz_paulb @ Aug 28 2003, 06:08 PM) | ||
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.
Post by: dmsdude90 on August 28, 2003, 12:15:00 PM
Post by: oz_paulb on August 28, 2003, 12:21:00 PM
| QUOTE (crumb @ Aug 28 2003, 08:35 PM) | ||||
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
Post by: oz_paulb on August 28, 2003, 12:29:00 PM
| 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
Post by: oz_paulb on August 28, 2003, 12:35:00 PM
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
Post by: crumb on August 28, 2003, 12:33:00 PM
| QUOTE (oz_paulb @ Aug 28 2003, 08:45 PM) | ||||
http://www.wdc.com/e...y/ata/index.asp
http://www.redneck-p.../help/ata.shtml
|
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.)
Post by: oz_paulb on August 28, 2003, 01:23:00 PM
| 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
Post by: desertboy on August 28, 2003, 01:32:00 PM
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.
Post by: dmsdude90 on August 28, 2003, 02:03:00 PM
this kicks ass
Post by: Quest on August 28, 2003, 02:51:00 PM
and behind every great idea is someone saying it won't work"
Post by: krawhitham on August 28, 2003, 02:22:00 PM
| QUOTE (Xeero @ Aug 28 2003, 02:16 PM) | ||
FYI, Live requires the retail kernel... |
Buy another xbox.
this does not bother me, I hate online games
Post by: Flagg3 on August 28, 2003, 03:35:00 PM
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
Post by: oz_paulb on August 28, 2003, 04:14:00 PM
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
Post by: silentkiller on August 28, 2003, 04:19:00 PM
Post by: mhernie on August 28, 2003, 05:35:00 PM
Been on the forums constantly since I modded by xbox last month. This is the most exciting news by far. Thanks PaulB for keeping me on the edge of my seat on this one...
Post by: Xeero on August 28, 2003, 05:09:00 PM
| QUOTE (krawhitham @ Aug 28 2003, 06:22 PM) | ||||
Buy another xbox. this does not bother me, I hate online games |
Good thing we're not out to please you. If it's possible to make this procedure compatible with LBA24 (i.e., compatible with the MS BIOS, and thereby Live), why in the world would Paul stop on the presumption that most people don't ever use the MS BIOS. Seems like reckless imprudence to me.
Post by: crumb on August 28, 2003, 06:39:00 PM
| QUOTE (oz_paulb @ Aug 29 2003, 12:38 AM) |
| 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. |
Did you use a random file generator and keep 200GB of random files on your PC or did you use a random number generator where you kept the seed?
Post by: oz_paulb on August 28, 2003, 06:49:00 PM
| QUOTE (crumb @ Aug 29 2003, 03:03 AM) | ||
Did you use a random file generator and keep 200GB of random files on your PC or did you use a random number generator where you kept the seed? |
The files don't contain 'random' data, but they are unique.
I keep a running 32-bit count of the total # of 512-byte sectors I've written to files. The data that I write to a given 512-byte disk sector is just a 512-byte block filled with the 32-bit 'total sector count' value (the same 32-bit value repeated 128 times in a 512-byte sector).
As I create a new file, I don't reset the 'total sector count' value (the value keeps incrementing across all sectors in all files). So, when the test is completed, every 512-byte sector of the partition (excluding OS overhead/directory entries/etc) will be unique from one another. Going back and re-reading/verifying that "file N, subsector M" contains what it was created with will confirm that there was no overwriting.
- Paulb
Post by: oz_paulb on August 28, 2003, 07:04:00 PM
As I said, I think the test will be complete about 1 hour from now. I'll give a final update on test status then.
- Paulb
Post by: oz_paulb on August 28, 2003, 08:10:00 PM
Success!!!
My full read/compare of the ~195GB partition has finished, without any errors!!
As a final sanity check, I changed my test program to self-corrupt one of the sectors, just to be sure it's reporting errors OK - and it is.
So, things look GREAT for > 137GB!
I'm now going to try and figure out why the Slayer/EvoX installer doesn't seem to like the new partition stuff...
- Paulb
Post by: IonBlade on August 28, 2003, 08:12:00 PM
Thanks again for what I consider the largest Xbox breakthrough this year!
Post by: Illumina on August 28, 2003, 07:40:00 PM
and bob M.
Post by: heinrich on August 28, 2003, 08:21:00 PM
While not trying to jump the gun here, but here is where most (if not all) people with >137 gig drives have right now:
C E X Y Z = standard size
F = all the rest
So do you think it wil be possible to create a G partition, and format just that 1, without having to format the entire drive?
Post by: boxorox on August 28, 2003, 08:02:00 PM
| QUOTE (heinrich @ Aug 29 2003, 04:45 AM) |
| oz_paulb: While not trying to jump the gun here, but here is where most (if not all) people with >137 gig drives have right now: C E X Y Z = standard size F = all the rest So do you think it wil be possible to create a G partition, and format just that 1, without having to format the entire drive? |
Wholly shit! if I could get my 23GB back without messing with my existing partitions, I would have a hard time explaining to my family my utter elation.
Post by: heinrich on August 28, 2003, 08:40:00 PM
why?
Lets say you have a a 7th partion (ie: G) which would be DeviceHarddisk0Partition7
In the code i have seen for neXgen dash (i will look at the MXM and XBMP code tonight as well hopefully), values are hard coded in for each partition....
| CODE |
| struct pathconv_s { char * DriveLetter; char * FullPath; } pathconv_table[] = { { "DVD:", "\Device\Cdrom0" }, { "SYSTEM:", "\Device\Harddisk0\Partition2" }, { "STORAGE:", "\Device\Harddisk0\Partition1" }, { "EXTENDED:", "\Device\Harddisk0\Partition6" }, { "TEMPX:", "\Device\Harddisk0\Partition3" }, { "TEMPY:", "\Device\Harddisk0\Partition4" }, { "TEMPZ:", "\Device\Harddisk0\Partition5" }, { "BSYSTEM:", "\Device\Harddisk1\Partition2" }, { "BSTORAGE:", "\Device\Harddisk1\Partition1" }, { "BEXTENDED:", "\Device\Harddisk1\Partition6" }, { "BTEMPX:", "\Device\Harddisk1\Partition3" }, { "BTEMPY:", "\Device\Harddisk1\Partition4" }, { "BTEMPZ:", "\Device\Harddisk1\Partition5" }, { NULL, NULL } }; |
Which would seem to me, that any dash wanting to launch xbe's off this 7th partition, as well as any filemanagers, would need to be updated.
In the case of actually formatting the drive via EVOX, there is a RAW ftp command:
| CODE |
| Formatpath DeviceHarddisk0Partitionx |
where x is the partition 1 - 6. I dont know if you could try this with '7' and have it work. But even if it did, the 7th partition will still be inaccessible via FTP, and most likely any filemanager.
So an expected release a 'few days' is great, but only if the dashboard and filemanager devs are given proper info upfront to support this.
Now, about XBMP, as I am sure most people have noticed in the config.xml...
| CODE |
Not sure the ftpd looks at this file, but if so, then we would be set for ftp access to any new partitions.
Post by: oz_paulb on August 28, 2003, 08:41:00 PM
| QUOTE (heinrich @ Aug 29 2003, 04:45 AM) |
| oz_paulb: While not trying to jump the gun here, but here is where most (if not all) people with >137 gig drives have right now: C E X Y Z = standard size F = all the rest So do you think it wil be possible to create a G partition, and format just that 1, without having to format the entire drive? |
I think it should be possible, but there could be some 'gotchas'.
By default, my 'partition table' assigns the remainder of the drive (regardless of whether/not it's > 137GB) to drive F: - to be compatible with EvoX. I could make my default partition table leave F: maxed-out to the 137GB size, and auto-create a G:.
Or, if I left it alone, a boot CD could be made that writes a partition table to the drive. This new parition table would have to exist on the drive before you booted with my modified BIOS/tried accessing a pre-existing (smaller) drive F: - otherwise, you may corrupt F:.
I think it'll be 'do-able', just some thought needs to be put into a procedure.
- Paulb
Post by: heinrich on August 28, 2003, 09:00:00 PM
Post by: Ub3rn3wb on August 28, 2003, 09:10:00 PM
Looks like my 120gig HD in my Xbox is now going to be replaced with a 300gig HD!
Thanks a lot by doing this. I think you should be voted right up there with Xport and his emulators.
Post by: mav on August 28, 2003, 09:11:00 PM
so if your going to use another letter there might be issues there
xyz are cache of course so maybe O->W. i might be wrong just thought i would through that in.
Post by: heinrich on August 28, 2003, 09:23:00 PM
| QUOTE (heinrich @ Aug 29 2003, 12:24 AM) |
| Makes sense, and in some cases, it is needed to use an older bios in order to get around certain errors (like no system time), so i would think that the best way to do it would be to have that 1 extra partition for everything above the 137gig mark. Since I will admit right now that i have NO clue if this is do-able (to have C E F Y Z, then F from the 8 gig mark to 137, and a G from 137 and on), I will leave it to you, but if sing an older bios later on would currupt data, i can see this as being the only feasible way to do it. |
Another time when you would need to extra F drive, but couldnt use past the 137gig mark is any debug bios. While i suppose that >137 support could be put into lets say... the TATX bios, or just 5558. Its great that it *works* but implementation i think will take a bit of work, and you will need the help and support of other homebrew devs.
Post by: fixxxer on August 28, 2003, 08:53:00 PM
Post by: oz_paulb on August 28, 2003, 09:29:00 PM
| QUOTE (mav @ Aug 29 2003, 05:35 AM) |
| Just a note, iirc GH,IJ,KL,MN are reserved for memory cards (controler 1 slot1=G controler 1 slot2=H etc...) so if your going to use another letter there might be issues there xyz are cache of course so maybe O->W. i might be wrong just thought i would through that in. |
The partition table in the bios will only assign a partition number (7, for example) - not a drive letter. It's up to applications (like EvoX dash) to decide what partition should be mapped to what driie letter.
C/D/E have 'standard' assignments in Xbox, F: was added to map to the hard drive's "partition6", and has become a new 'standard' drive letter. If more partitions are created in the future, new 'standard' drive letters will probably emerge.
- Paulb
Post by: oz_paulb on August 28, 2003, 09:50:00 PM
| QUOTE (Flagg3 @ Aug 28 2003, 11:59 PM) |
| 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've figured out where the problem is with the Slayer EvoX installer (compatibility with my BIOS).
It's nothing to do with partition tables (I thought it was this before). It's the fact that I've got LBA48 support in the BIOS (if I disable my LBA48 'hooks', everything works OK).
The EvoX.ini entry "ConfigSector" is the culprit. If I remove that line, the rest of the format of all other partitions works fine (with LBA48 support turned ON).
Does anyone know what happens on the ConfigSector command? Is that code built-into EvoX, or is it executing an external app (like ConfigMagic) to do the work?
I noticed that the source to much of ConfigMagic is available online at team-assembly.com - maybe some of that has been put into EvoX. The source code does direct access to IDE command/status registers. I can't think why this would be a problem (if they're doing all of their IO separate from the KERNEL, and not trying to mix the two, for example).
I know that when you issue an LBA48 command, the subsequent 'status' that you get back is in a different format than for LBA28 commands (because the status registers need to show you what LBA address failed, and have to be modified for LBA48 in a way like the commands). But, if you issue LBA28 commands, you get LBA28 status results.
I'd like to understand what's going on here before I release the BIOS mod to the world - I don't want to find that there are lots of programs doing direct IDE access that will start crashing (I think it's probably only utilities - not games/etc). I don't think there's anything I can do in the KERNEL to fix this - I think some of these utilities may need to be re-written with the knowledge that LBA48 may be in effect. I'm not sure, though - as I said, I don't really understand why it fails.
Can anyone confirm that the "ConfigSector" command is based on the code @ team-assembly.com? I'm guessing that it is, just because it looks like it makes use of a "disk.bin" file that was the result of a ConfigMagic "backup". But, they could be unrelated. (come to think of it, I've never used "ConfigMagic", and I'm not sure it's the tool that creates the "backup" stuff that I've seen reference to before - so I could be totally confused here (it is getting late)).
Well, I'm about to head to bed, and have to get up early for work in the morning. Since I'll be @ work all day tomorrow, I may not have time to check in to the forums too often.
- Paulb
Post by: fixxxer on August 28, 2003, 10:02:00 PM
Post by: starwarznut on August 28, 2003, 09:52:00 PM
Post by: focusracer1 on August 28, 2003, 10:23:00 PM
| QUOTE |
| Sorry to write here, paul but i hear this discussion now since weeks. and it is false. First, you should tell all people that if you enable lba48 (which is simple) you can not access the data with an normal kernel anymore From a Windows Support Site >If you enable 48-bit LBA support on a system that does NOT have a 48-bit LBA- >compatible BIOS, and a hard disk larger than 137 GB, you will experience data >corruption. but as people sure are "more intelligent" as i, please consult ATA/ATAPI 6.0 specification. It is written very clear there, why the "using in both worlds" is not possible. Good luck for your non-working & incompatible system . franz |
Well, at least we know Franz has his PHD (Playa Hater Degree)
BooyaKasha!!!!!
Post by: feliperal on August 28, 2003, 11:16:00 PM
I'm very interested in studying the work you have been doing. Would it be possible if you could document or explain in more depth how you were able to do it? I would also be interested in viewing the kernel modifications and some of the source code.
If it is so troublesome, can you perhaps give us a quick overview of what you did? I would like to reproduce these steps and document it, giving credit where it belongs. Perhaps, this can spur new ways to circumvent this limitation for soft mods, also.
Thank Again for all your work.
Post by: greengiant on August 28, 2003, 11:21:00 PM
I wrote the NewHDEvox installer, witch was used for quite a while. The foundation where Slayers came from.
The backup you talk about has NOTHING to do with ConfigMagic.
Backup is done by EvolutionX for quite a few builds now, it creates a few files in
Cbackup
EEPROM .bin file and HD partition/other .bin file
as well as the HD key and a cpl other files.
In my installer I used the drive.bin file because at the time evox did not have any INI commands for formating the drive. The ConfigSector command was the preliminary way of doing it, using raw data from the bin file.
Later on the builds evox came with built in INI commands that would format the proper partitions.
Since your now using LBA48 the paritition table and a few other things will be much different that when the drive is accessed in LBA28.
The disk.bin was created using standard LBA28 commands and thus the data will be in a format that will probably not be compatible with LBA48.
I donot know much about the ATA standard so please bear with me.
I beleive, not for sure, the format drive commands use a much less 'raw' way of formatting and setting up the partitions than if you where you use a disk.bin file and do it the raw way.
Let me know if this helps you.
And many apps, like evox and utilities do access the hd drive and many other xbox functions directly via memory calls and not via the kernel, because of certain needs.
Some functions within those apps do make direct calls, and others do kernel calls.
So it may be nessary to provide a module for developers to incorporate into their programs to make them compatible with your new work.
Post by: neomaytricks on August 29, 2003, 12:07:00 AM
Post by: xVanWildeRx on August 29, 2003, 12:28:00 AM
Post by: SigTom on August 29, 2003, 01:26:00 AM
Post by: oz_paulb on August 29, 2003, 04:37:00 AM
| QUOTE (greengiant @ Aug 29 2003, 07:45 AM) |
| The backup you talk about has NOTHING to do with ConfigMagic. Backup is done by EvolutionX for quite a few builds now, it creates a few files in Cbackup EEPROM .bin file and HD partition/other .bin file as well as the HD key and a cpl other files. In my installer I used the drive.bin file because at the time evox did not have any INI commands for formating the drive. The ConfigSector command was the preliminary way of doing it, using raw data from the bin file. Later on the builds evox came with built in INI commands that would format the proper partitions. Since your now using LBA48 the paritition table and a few other things will be much different that when the drive is accessed in LBA28. The disk.bin was created using standard LBA28 commands and thus the data will be in a format that will probably not be compatible with LBA48. I donot know much about the ATA standard so please bear with me. I beleive, not for sure, the format drive commands use a much less 'raw' way of formatting and setting up the partitions than if you where you use a disk.bin file and do it the raw way. |
I don't think the 'hang' problem I'm seeing has anything to do with the fact that the "disk.bin" file is being written, or anything to do with the contents of "disk.bin". I think it has to do with the method of writing the file to the hard drive's sectors.
If the "ConfigSector" command were to use KERNEL methods to read/write sectors, then I think it would work. But, I'm guessing it's doing direct ATA/IDE commands, and that there is some sort of interaction between those (LBA28) commands and the KERNEL's LBA48.
Where is the underlying code for the "ConfigSector" evox.ini command? Is it part of the EvoX executable (built-in to EvoX), or does it launch another standalone app that does the work?
Does the "ConfigSector" stuff do direct ATA/IDE access (direct to the I/O ports), or does it make use of KERNEL functions for reading/writing to 'raw' hard drive sectors?
When I saw 'KERNEL functions', I mean using functions like NtOpenFile/NtReadFile/NtWriteFile on the 'file' called "\Device\Harddisk0\partition0" (partition "0" is for raw access to the entire drive).
I'd really like to get to the bottom of this, to make sure I haven't missed some part of the KERNEL code that I need to update for LBA48.
Thanks,
- Paulb
Post by: oz_paulb on August 29, 2003, 04:42:00 AM
| QUOTE (feliperal @ Aug 29 2003, 07:40 AM) |
| pualdb, first I would like to commend you for all the hard work you are putting on this project. I'm very interested in studying the work you have been doing. Would it be possible if you could document or explain in more depth how you were able to do it? I would also be interested in viewing the kernel modifications and some of the source code. If it is so troublesome, can you perhaps give us a quick overview of what you did? I would like to reproduce these steps and document it, giving credit where it belongs. Perhaps, this can spur new ways to circumvent this limitation for soft mods, also. Thank Again for all your work. |
I plan on publishing everything that I did, including source code to the new code I've added. I won't be publishing a complete BIOS 'binary' (for legal concerns), but will release a method of patching an existing BIOS (hopefully via Xbtool).
The actual code I've added is very small - the hardest part was coming up with a method to 'expand' the KERNEL to make room for my patches, then tracking down all of the locations in the KERNEL that I needed to patch (finding all I/O instructions to ATA/IDE ports, deciding which ones needed to be converted to LBA48).
- Paulb
Post by: erexx on August 29, 2003, 06:18:00 AM
and have it work with your new bios?
Post by: oz_paulb on August 29, 2003, 06:51:00 AM
| QUOTE (erexx @ Aug 29 2003, 02:42 PM) |
| At this point would it be possible to set up (prep) a new 200 gb hd using winhex and have it work with your new bios? |
Yes, that should work. I've still got a bit of 'cleanup' to do on my bios patches - I expect to release them this weekend.
I've been thinking about the Slayer installer incompatibility problem (really looks like EvoX compatibility issue), and may have a 'workaround': I'll try to use LBA28 commands whenever I'm accessing the first 137GB of the drive. I'll only use LBA48 commands when accessing past that point.
This way, most likely, the most recent accesses to the IDE controller will have been LBA28 commands whenever EvoX is doing its "ConfigSector" stuff, and any LBA28 vs LBA48 issues should go away. This is just a theory - I'll have to test it out.
It doesn't make the underlying problem go away, and there could be other programs with similar compatibility issues with LBA48, but it'll make it much less likely to occur (until these programs are modified to deal with LBA48 - assuming it's an issue in the programs (and not in my KERNEL mods)).
- Paulb
Post by: precisionmods on August 29, 2003, 06:57:00 AM
Post by: VerticalE on August 29, 2003, 07:12:00 AM
Post by: juan23 on August 29, 2003, 07:19:00 AM
great job, I been folowing since Bobmckensie has started this.
Props to oz_paul for making a dream reality.
Post by: Flagg3 on August 29, 2003, 07:20:00 AM
| QUOTE (oz_paulb @ Aug 29 2003, 12:01 PM) |
| Where is the underlying code for the "ConfigSector" evox.ini command? Is it part of the EvoX executable (built-in to EvoX), or does it launch another standalone app that does the work? |
This command is built into the Evox executable. Slayers does not use any external utilities AFAIK.
Update:
Looks like I may be wrong about this. I just received a message back from someone at Evox that this option IS added by Slayer. Looks like there may be some added functionality in Slayers after all.
Flagg
Post by: jaskjok on August 29, 2003, 07:41:00 AM
Is LBA48 patched bios still 256kb? And have you tried to run game or some software from partition on >137gb space?
I also got suggestion, I think you said that your bios loads partition tables from hd, it would be nice if it uses default partition sizes if there is no partitiontable on hd.
I think also HD manufactures will be happy, there is probably going to be quite a hike on 200+ GB HD sales
Post by: oz_paulb on August 29, 2003, 07:12:00 AM
| QUOTE (jaskjok @ Aug 29 2003, 04:05 PM) |
| Thanks Paulb, great job! Is LBA48 patched bios still 256kb? And have you tried to run game or some software from partition on >137gb space? I also got suggestion, I think you said that your bios loads partition tables from hd, it would be nice if it uses default partition sizes if there is no partitiontable on hd. I think also HD manufactures will be happy, there is probably going to be quite a hike on 200+ GB HD sales |
The LBA48 patches are pretty small. If you're starting with a 256k BIOS (as I am in my testing), then it'll probably fit in 256k. You'll only see a problem if you're starting with a 256k BIOS that's right on the 'edge' of going over 256k.
I haven't tried running programs from above 137GB, but there's no reason it wouldn't work (of course, I'll try it out before finalizing this stuff).
There is a built-in 'default' partition table. It only uses a partition table from disk if it finds one.
- Paulb
Post by: Troed on August 29, 2003, 08:18:00 AM
| QUOTE (oz_paulb @ Aug 29 2003, 02:15 PM) |
| compatibility issue), and may have a 'workaround': I'll try to use LBA28 commands whenever I'm accessing the first 137GB of the drive. I'll only use LBA48 commands when accessing past that point. |
Paulb, While understanding why you want to do that - don't. I'd say that when you release your patches, the homebrew-scene till simply have to use kernel commands instead of IDE/ATA commands in their programs. You shouldn't have to use workarounds - I fear your patches might become less stable if you do.
However, that solution might also minimise some of the risks franz talked about. I guess it's a "test and see" issue.
Excellent work. This thread is one of the more interesting I'm following, anywhere, atm.
Post by: oz_paulb on August 29, 2003, 08:45:00 AM
| QUOTE (Troed @ Aug 29 2003, 04:42 PM) | ||
Paulb, While understanding why you want to do that - don't. I'd say that when you release your patches, the homebrew-scene till simply have to use kernel commands instead of IDE/ATA commands in their programs. You shouldn't have to use workarounds - I fear your patches might become less stable if you do. However, that solution might also minimise some of the risks franz talked about. I guess it's a "test and see" issue. Excellent work. This thread is one of the more interesting I'm following, anywhere, atm. |
What I'm suggesting is exactly what bobmckenzie's code does in cromwell - only using LBA48 commands when necessary.
I don't see any real down-side to this, but I'll give it a try and see if there's any issues.
I agree that homebrew apps should probably avoid direct access to IDE registers - except when necessary (locking/unlocking hard drive). If the task can be done via standard KERNEL functions, then apps should make use of that (I've designed BIOS's pretty much my entire career - that's the point of a BIOS: to isolate the app from the low-level details of the hardware).
- Paulb
Post by: dmsdude90 on August 29, 2003, 11:52:00 AM
i think we should also make a list of hard drives that we know are lockable that are over 137 gigs
it would suck if some one got one and it wouldn't lock and they wanted xbox live down $$$
YOU ARE THE BEST PAULB I WISH ALL OF US WERE AS SMART AS YOU ARE
Post by: oz_paulb on August 29, 2003, 12:21:00 PM
| QUOTE (dmsdude90 @ Aug 29 2003, 08:16 PM) |
| this is so great so when will we probably get the patches out to us modders i think we should also make a list of hard drives that we know are lockable that are over 137 gigs it would suck if some one got one and it wouldn't lock and they wanted xbox live down $$$ YOU ARE THE BEST PAULB I WISH ALL OF US WERE AS SMART AS YOU ARE |
I think that I'll have the code cleaned-up enough to release by this weekend. As I said, I'm working with the "Xbtool" author and trying to incorporate the patch into Xbtool (will make it easier for most people to start using it ASAP).
I'll also be publishing the details of the patch (with source code), so that (hopefully) all of the 'mod bios' developers will eventually merge it into their standard bios' (so it won't require 'patching' by the end user in the future).
- Paulb
Post by: crumb on August 29, 2003, 11:50:00 AM
| QUOTE (oz_paulb @ Aug 29 2003, 03:15 PM) |
| I've been thinking about the Slayer installer incompatibility problem (really looks like EvoX compatibility issue), and may have a 'workaround': I'll try to use LBA28 commands whenever I'm accessing the first 137GB of the drive. I'll only use LBA48 commands when accessing past that point. |
Would that also be slightly more efficient? Would there be less traffic over the UDMA2 channel?
Every cycle savings count (and at the price of more code it may be worth it).
Post by: oz_paulb on August 29, 2003, 11:57:00 AM
| QUOTE (crumb @ Aug 29 2003, 08:50 PM) | ||
Would that also be slightly more efficient? Would there be less traffic over the UDMA2 channel? Every cycle savings count (and at the price of more code it may be worth it). |
I don't think there'll be a huge efficiency savings, and with the additional code to check whether/not it's above/below the 137GB, it'll probably be a 'wash'.
As I said, I think it can't hurt to try to stick to LBA28 unless LBA48 is necessary - it can only help with compatibility issues.
- Paulb
Post by: Xeero on August 29, 2003, 12:08:00 PM
| QUOTE (oz_paulb @ Aug 29 2003, 03:57 PM) | ||||
I don't think there'll be a huge efficiency savings, and with the additional code to check whether/not it's above/below the 137GB, it'll probably be a 'wash'. |
I wouldn't think that LBA48 commands are any more taxing on the bandwidth of the IDE channel than LBA28 commands. Of course, my knowledge in this area could be described as "vaccuous", so....
Post by: oz_paulb on August 29, 2003, 12:58:00 PM
| QUOTE (Xeero @ Aug 29 2003, 09:08 PM) | ||||||
I wouldn't think that LBA48 commands are any more taxing on the bandwidth of the IDE channel than LBA28 commands. Of course, my knowledge in this area could be described as "vaccuous", so.... |
The setup time for any given LBA48 command is probably double that of an LBA28 command (since two 'banks' of IDE registers are being written), but the amount of time to write a command vs. the amount of time to transfer the resulting data to/from the drive is negligable (we're talking 5 or 10 I/O instructions vs. transferring (at least) 512 bytes of data (and usually more data (since commands include a 'sector count', and it's usually more than '1')).
- Paulb
Post by: klik on August 29, 2003, 01:55:00 PM
Suppose I install a new >137G hard drive with your new bios with LBA 48bit command support. Later I boot xbox with an old bios or original bios which only support LBA 28bit command, can the old bios recognize the new hard drive? Will the partition table or data on the new hard drive be corrupted?
Post by: oz_paulb on August 29, 2003, 02:41:00 PM
| QUOTE (klik @ Aug 29 2003, 10:19 PM) |
| Paulb, great work! I have a question here. Suppose I install a new >137G hard drive with your new bios with LBA 48bit command support. Later I boot xbox with an old bios or original bios which only support LBA 28bit command, can the old bios recognize the new hard drive? Will the partition table or data on the new hard drive be corrupted? |
I think this will probably be covered in an F.A.Q. in the future, but if you want your hard drive to remain compatible with an 'old' LBA-28 BIOS, then all of your partitions that you'd want to access with that 'old' BIOS should be 100% below the 137GB point.
Probably the best setup would be to create "F:" to fill up the drive to 137GB (as current LBA-28 BIOS's do), then create an additional partition/drive letter for the remainder of the drive. That partition wouldn't be available if you booted an LBA-28 BIOS, but the rest of the partitions would be available.
- Paulb
Post by: heinrich on August 29, 2003, 02:59:00 PM
| QUOTE (oz_paulb @ Aug 29 2003, 03:45 PM) | ||
I think that I'll have the code cleaned-up enough to release by this weekend. As I said, I'm working with the "Xbtool" author and trying to incorporate the patch into Xbtool (will make it easier for most people to start using it ASAP). I'll also be publishing the details of the patch (with source code), so that (hopefully) all of the 'mod bios' developers will eventually merge it into their standard bios' (so it won't require 'patching' by the end user in the future). - Paulb |
I really dont see how the end user is going to be able to use this in the near future. Right now, as far as I know, no apps will allow you to format either an extra partition, or one of larger size. Assuming this is taken care of, the ability to USE an extra partition from any dash or filemanager is not present. Even if this is easy to implement in each app, there is the pure and simple fact that filemanagers (boxplorer, xcommander) do not allow for a 7th partition and no longer in development. Assuming the 3 active dashboard projects (Avalaunch, MXM, neXgen) can implement support fairly easily, its still not done....
Post by: greengiant on August 29, 2003, 03:07:00 PM
| QUOTE (oz_paulb @ Aug 29 2003, 01:01 PM) |
| -snip- I don't think the 'hang' problem I'm seeing has anything to do with the fact that the "disk.bin" file is being written, or anything to do with the contents of "disk.bin". I think it has to do with the method of writing the file to the hard drive's sectors. If the "ConfigSector" command were to use KERNEL methods to read/write sectors, then I think it would work. But, I'm guessing it's doing direct ATA/IDE commands, and that there is some sort of interaction between those (LBA28) commands and the KERNEL's LBA48. Where is the underlying code for the "ConfigSector" evox.ini command? Is it part of the EvoX executable (built-in to EvoX), or does it launch another standalone app that does the work? Does the "ConfigSector" stuff do direct ATA/IDE access (direct to the I/O ports), or does it make use of KERNEL functions for reading/writing to 'raw' hard drive sectors? When I saw 'KERNEL functions', I mean using functions like NtOpenFile/NtReadFile/NtWriteFile on the 'file' called "DeviceHarddisk0partition0" (partition "0" is for raw access to the entire drive). I'd really like to get to the bottom of this, to make sure I haven't missed some part of the KERNEL code that I need to update for LBA48. Thanks, - Paulb |
Thats the second possibility I pointed out.
It may not be the actual disk.bin contents that are the problem, but how they are written to the HD.
Evox does everything itself, it does not rely on any external applications.
Contrary to what someone later posted, Slayers uses all of Evox's functions, it doesnt actually add anything to evox. It may be done thru external apps, set as menu items.
I donot actually have or have seen the code for the ConfigSector command.
From experience to prep a New Drive, it is no longer needed in the newer drives, you can just use the FormatDrive command.
I would suspect with the changes you have made, the command no longer working it may be possible that direct i/o may be at play.
I donot think you can access that part of the drive for that type of access via NTOpen/etc.
If you really want to get to the bottom of the ConfigSector matter, just email me off list or pm me, and I will see what I can find out for you. I'm also on IRC in several channels
Post by: dmsdude90 on August 29, 2003, 03:11:00 PM
if the issue is that it the bios is full i u gust need code to say look on the f: partion and then have a file their stating to update the files i thingk that would make the apps load but it wouldn't make the app recongize the next partition but that would help a little
what do u think? i am not the best at any code writing????
Post by: onthereal on August 29, 2003, 04:07:00 PM
| QUOTE (oz_paulb @ Aug 29 2003, 03:05 PM) |
| Probably the best setup would be to create "F:" to fill up the drive to 137GB (as current LBA-28 BIOS's do), then create an additional partition/drive letter for the remainder of the drive. That partition wouldn't be available if you booted an LBA-28 BIOS, but the rest of the partitions would be available. - Paulb |
Why not use LBA-28 for the first 8gig (ie. C: & E:) as to not disrupt the retail BIOS and MS Live? Then use the LBA-48 mode for the remainder of the disk as "F:" This way the partition table would not have too change and we can have one huge F: as we do now.
Post by: dmsdude90 on August 29, 2003, 04:10:00 PM
i am an organized freak
Post by: the joker on August 29, 2003, 04:39:00 PM
I'm one of those who's been working very very much with the filesystem at least, due to scandisk and defrag. And I can only tell you that it's not fatx32 that stops this from working at least, and the kernel seems to sopport up to 20 partitions if you want so... :-)
-The Joker
Post by: heinrich on August 29, 2003, 05:26:00 PM
| QUOTE (onthereal @ Aug 29 2003, 07:31 PM) | ||
Why not use LBA-28 for the first 8gig (ie. C: & E:) as to not disrupt the retail BIOS and MS Live? Then use the LBA-48 mode for the remainder of the disk as "F:" This way the partition table would not have too change and we can have one huge F: as we do now. |
So that if at some point, we need to load a bios that does not support LBA-48, the F drive would not become corrupt.
Post by: Ub3rn3wb on August 29, 2003, 05:36:00 PM
| QUOTE (heinrich @ Aug 29 2003, 05:50 PM) | ||||
So that if at some point, we need to load a bios that does not support LBA-48, the F drive would not become corrupt. |
I think the best way Paulb has it is the best way to do things and thats probably the best way things should be handled.
Why change something that already works? Are you not able to store all your files on the F drive without it messing the original functionality of the system up? No! Just allow the full 137gigs in the F Drive then, if you choose to activate the LBA48 allow it to make its own drive.
Post by: heinrich on August 29, 2003, 05:40:00 PM
Post by: naughtsmart on August 29, 2003, 07:18:00 PM
| QUOTE (onthereal @ Aug 29 2003, 11:31 PM) | ||
Why not use LBA-28 for the first 8gig (ie. C: & E:) as to not disrupt the retail BIOS and MS Live? Then use the LBA-48 mode for the remainder of the disk as "F:" This way the partition table would not have too change and we can have one huge F: as we do now. |
don't forget about the swap drives (X,Y,Z) those will need to be accessed by lba-28 in order to run quite a few games.
nevermind, partitions X,Y,and Z are probably partitions 2-4 or 3-5 and are below 137gb anyways
This post has been edited by naughtsmart: Aug 30 2003, 02:21 AM
Post by: incinerator on August 29, 2003, 08:31:00 PM
Post by: oz_paulb on August 29, 2003, 08:52:00 PM
Of course, this would just be the 'default/built-in' partition table - if you were to write a different parition table to the hard drive's boot sector, then you can override everything.
I have no control over whether/not apps can (at this moment in time) access drives other than "C/D/E/F", and don't think I should take that into consideration/limit my options at this point. I'll try to make things 'generic' enough, and hope that apps will catch-up with whatever becomes the 'standard' drive layout.
Remember, drive "F:" didn't always exist... it's assumed that apps support it now, but it wasn't always the case. That'll be true for any 'extra' drives that end up being added via the partition-table mechanism.
As a matter of fact, instead of hard-coded "drive letter-to-partition #" tables into each and every app (as seems to be the case now), maybe apps will migrate more toward the way Windows apps work - where they ask the operating system for a list of available drives (or partitions), and display a list to the user. This will (in the long run) be much more flexible: more partitions can be added in the future, and apps will continue to work (instead of apps needing to be re-compiled to deal with filesystem changes all of the time).
- Paulb
Post by: oz_paulb on August 29, 2003, 09:31:00 PM
| QUOTE (the joker @ Aug 30 2003, 01:03 AM) |
| hupp I'm one of those who's been working very very much with the filesystem at least, due to scandisk and defrag. And I can only tell you that it's not fatx32 that stops this from working at least, and the kernel seems to sopport up to 20 partitions if you want so... :-) -The Joker |
Yep - there's a hard-coded limit of 20 partitions in the KERNEL.
This could be patched to be larger, if we ever decide it should be (20 partitions is quite a few).
- Paulb
Post by: dmsdude90 on August 29, 2003, 08:58:00 PM
Post by: oz_paulb on August 29, 2003, 09:39:00 PM
| QUOTE (dmsdude90 @ Aug 30 2003, 05:58 AM) |
| so what else needs to happen before we can get these patches out to everything |
I think the patches will be out by the end of the weekend.
- Paulb
Post by: xVanWildeRx on August 29, 2003, 09:52:00 PM
well, reading the updates on the thread totally make my day worthwhile everyday. ive got my mod installed, and it seems to be working ok, but im waiting on the update before i buy a hard drive. paulb, you rock! im just sitting here dreaming of a 300 gb monster hdd in my xbox.. wow.. *drool*
Post by: crumb on August 29, 2003, 10:57:00 PM
| QUOTE (xVanWildeRx @ Aug 30 2003, 06:52 AM) |
| im just sitting here dreaming of a 300 gb monster hdd in my xbox.. wow.. *drool* |
I've read somewhere the hard drive industry's next generation of drives are 120GB per platter. If you crammed 4 of those in to a 3.5" enclosure the drives would be about 500GB or 0.5 TB.
Some companies have said those platter sizes will roll out in Q3 this year.
But wait... 160GB per platter is around the corner after that in Q4/2004 and we could see drives that are about 650GB.
Post by: fixxxer on August 29, 2003, 10:23:00 PM
-Jim
Post by: crumb on August 30, 2003, 01:26:00 AM
| QUOTE (fixxxer @ Aug 30 2003, 07:23 AM) |
| here is a little info that might/might not help..... i have a WD 200gb special edition and to access over 137 i need to use the controller card that came with it. ok but if i unplug it from the controller card and pulg it right into my ide on my mobo i can boot up windows and acces up to the 137gb mark without errors... so its not corrupting the data when it reads the drive and if im correct it shouldnt. i dont think it rights the data any different it just uses older commands that dont support over the 137 gig mark so what im tryin to say is if you load an older unpatched bios (ie live bios) it should read the pre 137 gig without a problem. -Jim |
Accessing the first 137GB using LBA28 will not per se corrupt your drive. The problem(s) would lie where the system registers garbage data because it can't access data above the 137GB mark or it possibly wraps around to data below the 137GB that is also garbage.
That is why Paul's suggestion of creating an extended partition (i.e. 6) up to 137GB and another above 137GB would solve the problem of possible corruption by isolating the LBA48 system from the LBA28 system.
Anyway, you are right.
This post has been edited by crumb: Aug 30 2003, 08:27 AM
Post by: dmsdude90 on August 30, 2003, 08:15:00 AM
Post by: EvilWays on August 30, 2003, 02:39:00 PM
Post by: oz_paulb on August 30, 2003, 04:33:00 PM
It was a bug in my code, and I'm surprised it didn't hang/crash in other places.
So, I can use the Slayer EvoX 2.1 installer 'as is' (don't need to remove "ConfigSector") with my LBA48-enabled BIOS with no problems.
Here's my "System Settings" screen showing free space just after the install (200GB drive):
- Paulb
Post by: oz_paulb on August 30, 2003, 04:36:00 PM
| QUOTE (EvilWays @ Aug 30 2003, 11:39 PM) |
| Should go with using Partition7 then. Consider it modder friendly. Definately a beautiful thing. |
I'm hoping for the 'default partition method' to be a configurable option in Xbtool (can always be overridden by hard drive's partition table in boot sector).
The various options I've coded support for are:
- Don't allocate any extra partitions (work just like retail Xbox)
- Allocate entire remainder of disk to "partition6" (F:)
- Allocate remainder of disk *up to 137GB* to "partition6" (F:), and the rest to "partition7"
- Allocate remainder of disk *up to 137GB* to "partition6" (F:), and don't create "partition7" (works just like existing EvoX BIOS's do when they see a >137GB drive in LBA28 mode - everything up to 137GB is F:, the rest is wasted)
- Paulb
Post by: dmsdude90 on August 30, 2003, 05:40:00 PM
-
-
i didn't understand its like you said the opposite wording it dif
could ylu explain taht to us idots
Post by: oz_paulb on August 30, 2003, 05:54:00 PM
| QUOTE (dmsdude90 @ Aug 31 2003, 02:04 AM) |
| oz paulb i hjsut got a little confusing the last two - - i didn't understand its like you said the opposite wording it dif could ylu explain taht to us idots |
| QUOTE |
| - Allocate remainder of disk *up to 137GB* to "partition6" (F:), and the rest to "partition7" |
This is exactly like how EvoX/other BIOS's currently deal with a >137GB hard drive (all free space up to 137GB are for drive "F" , with the addition of an extra partition ("partition7"), which could be assigned to another drive letter (P:, for example).
The reason for this is to allow booting with an older LBA28 bios - you'll still have access to drive F: (but not to drive P:). It also allows someone who already has a drive "F:" (with lots of apps/music/etc already loaded onto it) to leave it alone, and just create a new partition/drive letter for all of the space above 137GB (no need to reformat F:/re-load everything).
| QUOTE |
| - Allocate remainder of disk *up to 137GB* to "partition6" (F:), and don't create "partition7" (works just like existing EvoX BIOS's do when they see a >137GB drive in LBA28 mode - everything up to 137GB is F:, the rest is wasted) |
This is just how current BIOS's work. You may think that it doesn't make sense for this option. But, some people already have Linux installed "above" the 137GB mark. This option would be most compatible with their existing setup.
I hope that clarifies things.
- Paulb
Post by: splash911 on August 30, 2003, 06:09:00 PM
Can't wait to try your code
!Congratulations!
Post by: Heet on August 30, 2003, 07:09:00 PM
What about data corruption though? Is that gonna be an issue possibley? I mean, i know anything is possible, but what are your thoughts. Thanks.
Post by: irajames1176 on August 30, 2003, 07:30:00 PM
Post by: oz_paulb on August 30, 2003, 07:43:00 PM
| QUOTE (irajames1176 @ Aug 31 2003, 03:54 AM) |
| Ok what about people that are formatting a new drive or would rather not have more partitions after the 137gb mark, maybe have it setup the way you have yours with all of the space on the F: partition no splitting at all? |
Read my previous post (at the end of the last page). The post above (top of this page) was just clarifying 2 of 4 partitioning options.
And, again, these are 'default partition table' options - what's built-into the BIOS. Any partition data written in the 'boot sector' of the harddrive will override - so you have as many partitioning options as you like (up to 14 total partitions).
- Paulb
Post by: oz_paulb on August 30, 2003, 07:10:00 PM
| QUOTE (Heet @ Aug 31 2003, 03:33 AM) |
| This is the one thing i thought would never happen. What about data corruption though? Is that gonna be an issue possibley? I mean, i know anything is possible, but what are your thoughts. Thanks. |
I've done a good amount of testing, but nothing is 100% (ever). I think that once I release this, there will be more testing by 'early adopters' who are willing to take (what I think to be a small) risk of corruption.
People who can't take the risk should hold-off until more people have used/validated the code.
- Paulb
Post by: irajames1176 on August 30, 2003, 08:02:00 PM
Post by: xVanWildeRx on August 30, 2003, 08:53:00 PM
Post by: RiceCake on August 30, 2003, 08:59:00 PM
Cool.
Post by: KiLaHuRtZ on August 30, 2003, 10:56:00 PM
either way i'm upgrading to a 300GB HDD
Post by: assmonkey on August 30, 2003, 10:28:00 PM
| QUOTE |
| will i have to reformat the entire drive? or with this patch will it just let me "see" and utilize the extra 23GB or so without a re-format. |
why can't you read the whole thread
Post by: KiLaHuRtZ on August 31, 2003, 12:07:00 AM
Post by: mvm on August 31, 2003, 12:40:00 AM
Shoulden't you be the one to first come congratulate Paul whith his "useless and non-working discovery" as I remember you calling it ?
Anyway, great work Paul !
Post by: SigTom on August 31, 2003, 12:57:00 AM
| QUOTE |
| KiLaHuRtZ Posted on Aug 31 2003, 03:31 AM umm lets see, maybe because it is 12 pages long assgoblin!!! |
Actually, its only 8 pages so far, and the answer to your question is only one page back. So take the time, and do as the rest of us have, and read the frigging complete thread!!!! Ive been following this since 8/24/03 (day the thread was started) and I read EVERY page each time I come back. You never know when someone will edit a post and add some info. So just READ my man READ. Its the path to enlightenment young Padawan.
oz_paulb: Ive already mentioned it, think I was the 1st at least on this thread, thatd Id like to help test this out. Lemme know man, [email protected] or PM me.
Post by: nino on August 31, 2003, 01:32:00 AM
at Outpost ,do search for 3699695
Post by: xVanWildeRx on August 31, 2003, 01:05:00 AM
Post by: oblox on August 31, 2003, 01:09:00 AM
Just thought it was time to pop out of the woodwork only been haunting these forums for a month or so.
Okay okay on with the points
1)Maxtor hard drives have a unique feature of future proofed UDMA modes (aka the drives can set themselves)
2)Is there any chance someone could add into xbtool or something, a way to remap partition6 to a new partition at the end of the drive?
Wouldn't this give apps (assuming they map F to Partition6) the ability to use the new space where as other bioses like say M$ original would not see it.
Hell there's a though how about remapping all the Partitions in the bios!!!! A dual boot system ahoy?
Post by: sykotik on August 31, 2003, 03:19:00 AM
Post by: Heet on August 31, 2003, 04:39:00 AM
Post by: juan23 on August 31, 2003, 04:19:00 AM
HEET::: if you go on ebay maxtor makes 300 gig hdd's
Post by: Sc0rpion on August 31, 2003, 05:03:00 AM
Did you actually do a search on outpost mate? i did and look what i found first attempt:-
http://shop1.outpost.com/product/3699695
300gb for $289 just like nino said
Post by: oz_paulb on August 31, 2003, 06:55:00 AM
| QUOTE (oblox @ Aug 31 2003, 10:09 AM) |
| Hell there's a though how about remapping all the Partitions in the bios!!!! A dual boot system ahoy? |
That's really a great idea - you could have multiple sets of Xbox system partitions (drive C:), and use a partition editor to choose which one should be 'active' for the next boot.
I haven't tried it, but there's no reason why the standard Xbox partitions can't be moved around/put > 137GB. The offsets/sizes were all hard-coded into the BIOS before - now they are just entries in the partition table. The only thing that is 'hard-coded' is the partition numbers - (example: the 2nd entry in the partition table ("partition2") is always the Xbox system drive (C:)). That 2nd entry can be changed to point to any place on the drive. As I said, I haven't tried this, but it should work.
- Paulb
Post by: gggie on August 31, 2003, 06:35:00 AM
-- which of these two is better for xbox purposes:western digital 250gb, 8mb cache, 7200rpm
maxtor 300gb, 2mb cache, 5400rpm
will the greater amount of cache and faster rpm result in a noticable improvement in performance? or would there be no real difference because of the way the xbox works?
Post by: JohnA on August 31, 2003, 07:29:00 AM
Post by: Schweino on August 31, 2003, 07:32:00 AM
| QUOTE (gggie @ Aug 31 2003, 03:35 PM) |
| this is a frickin' awesome discovery! but now need to figure out which hard drive to get -- which of these two is better for xbox purposes: western digital 250gb, 8mb cache, 7200rpm maxtor 300gb, 2mb cache, 5400rpm will the greater amount of cache and faster rpm result in a noticable improvement in performance? or would there be no real difference because of the way the xbox works? |
Get the 5400 rpm since it stays cooler. The xbox doesnt make any use of the 8 mb cache and the 7200 rpm at all, so it makes no sense getting the WD
Post by: Heet on August 31, 2003, 07:42:00 AM
Post by: oz_paulb on August 31, 2003, 07:58:00 AM
| QUOTE (Heet @ Aug 31 2003, 04:06 PM) |
| sorry for the dumb inquiry. Just woke up and posted without lookin. Does this mean the theoretical capacity is 2.2 terabytes? Thats what ive read but i dont know if thats fact. Thanks for the heads up on 300 gigs. Im gonna get one as soon as a bios is released with this goodie. |
Yes, 2.2TB is the theoretical max drive capacity (since we're only using 32bits of the possible 48bits of LBA48 addressing).
There will likely be issues with max partitions sizes for FATX, though, so you'll probably never see a 2.2TB F: drive (but it should be possible to make multiple partitions of whatever the max FATX partition size is).
Of course, by the time drives in the TB capacity come out, Xbox 2 (or 3) will probably be shipping.
- Paulb
Post by: crumb on August 31, 2003, 09:33:00 AM
| QUOTE (oz_paulb @ Aug 31 2003, 04:22 PM) |
| Yes, 2.2TB is the theoretical max drive capacity (since we're only using 32bits of the possible 48bits of LBA48 addressing). |
Q: Is that a result of the BIOS accepting a long as a parameter in it's disk functions?
Could it possibly accept a structure that is 48-bits in total? That would allow drives up to 144,115 TB or 144 PB.
Post by: AsTnBoMb on August 31, 2003, 09:37:00 AM
Post by: MetaliFreak on August 31, 2003, 09:46:00 AM
I kid I kid...
Post by: MaXa on August 31, 2003, 09:49:00 AM
| QUOTE (AsTnBoMb @ Aug 31 2003, 06:01 PM) |
| I dunno oz_paulb, I wouldnt underestimate the hard drive companies, they sure have come a long way very very fast. |
But my money always takes longer
Post by: Flagg3 on August 31, 2003, 10:04:00 AM
| QUOTE (Schweino @ Aug 31 2003, 02:56 PM) |
| Get the 5400 rpm since it stays cooler. The xbox doesnt make any use of the 8 mb cache and the 7200 rpm at all, so it makes no sense getting the WD |
Why do people still believe this? The xbox will ABSOLUTELY benefit from a faster hard drive with more cache!
Both of these features help increase access times. While it's true that you will still be limited by the ATA-33 transfer rate, that only affects maximum sustained throughput.
I believe this myth has perpetuated because of the fact that faster hard drives don't really offer much benefit for people who are upgrading PVRs.
So you will definitely see a very noticeable improvement in performance with a faster hard drive. As for the heat issue that really depends. In general, the xbox doesn't have any problems with overheating so this isn't that big of a concern. However I have seen some boxes which tend to run hotter than others. My boxes always average around 120 degrees farenheight cpu temp even with a 7200rpm drive. If your box runs around 140 degrees before upgrading the drive then you might want to opt for a cooler drive. Although I have seen boxes that run perfectly stable with a cpu temp of 160 degrees, the hotter your box runs the shorter it's lifespan will most likely be.
Flagg
Post by: NightL1fe on August 31, 2003, 10:09:00 AM
| QUOTE (Flagg3 @ Aug 31 2003, 01:28 PM) | ||
Why do people still believe this? The xbox will ABSOLUTELY benefit from a faster hard drive with more cache! Both of these features help increase access times. While it's true that you will still be limited by the ATA-33 transfer rate, that only affects maximum sustained throughput. I believe this myth has perpetuated because of the fact that faster hard drives don't really offer much benefit for people who are upgrading PVRs. So you will definitely see a very noticeable improvement in performance with a faster hard drive. As for the heat issue that really depends. In general, the xbox doesn't have any problems with overheating so this isn't that big of a concern. However I have seen some boxes which tend to run hotter than others. My boxes always average around 120 degrees farenheight cpu temp even with a 7200rpm drive. If your box runs around 140 degrees before upgrading the drive then you might want to opt for a cooler drive. Although I have seen boxes that run perfectly stable with a cpu temp of 160 degrees, the hotter your box runs the shorter it's lifespan will most likely be. Flagg |
very true indeed.. i have noticed the 8mb caches access files and games a tad bit fast..correct me if i'm wrong but i thought the xbox will shut itself down after 140f-145f?
how could you see a 160f xbox running stable ?
Post by: heinrich on August 31, 2003, 10:26:00 AM
I concur that a 7200rpm, 8mb chache drive means better seek times, and overall better performance. Especially on large, fragmented drives.
Post by: crumb on August 31, 2003, 10:30:00 AM
| QUOTE (AsTnBoMb @ Aug 31 2003, 06:01 PM) |
| I dunno oz_paulb, I wouldnt underestimate the hard drive companies, they sure have come a long way very very fast. |
The hard drive manufacturers won't have 2.2TB in 3.5" enclosures by 2005.
Post by: NightL1fe on August 31, 2003, 10:46:00 AM
| QUOTE (heinrich @ Aug 31 2003, 01:50 PM) |
| From my understanding the xbox shut down at 71C, or 159.8F. I concur that a 7200rpm, 8mb chache drive means better seek times, and overall better performance. Especially on large, fragmented drives. |
RIGHT! so how the hell is Flagg seeing xboxs running stable at 160F?
Post by: GuySmily on August 31, 2003, 01:55:00 PM
I have some "Quantum Fireball" drive.. It gets as hot as a fireball (the case of the xbox actually gets very hot.. and the vent in the back is like a heater), but as long as the fan ran the system was fine.
Great work on all this development. I'm putting off purchasing my second hard drive until this is released.
Post by: alphaman on August 31, 2003, 02:37:00 PM
I'd love to do Beta! I'm just kinda wondering how hard it would be to apply this fix when it's available?
Post by: GuySmily on August 31, 2003, 02:44:00 PM
Post by: oz_paulb on August 31, 2003, 02:54:00 PM
| QUOTE (crumb @ Aug 31 2003, 05:57 PM) | ||
Q: Is that a result of the BIOS accepting a long as a parameter in it's disk functions? Could it possibly accept a structure that is 48-bits in total? That would allow drives up to 144,115 TB or 144 PB. |
Throughout the kernel, a 32bit sector number is used for low-level access.
To change it to use something larger would make it incompatible with existing apps.
If we start filling up 2.2TB drives, and it becomes a problem, I'll take another look at expanding it past 32bits.
- Paulb
Post by: XanTium on August 31, 2003, 03:32:00 PM
| QUOTE (oz_paulb @ Aug 31 2003, 04:19 PM) | ||
That's really a great idea - you could have multiple sets of Xbox system partitions (drive C:), and use a partition editor to choose which one should be 'active' for the next boot. I haven't tried it, but there's no reason why the standard Xbox partitions can't be moved around/put > 137GB. The offsets/sizes were all hard-coded into the BIOS before - now they are just entries in the partition table. The only thing that is 'hard-coded' is the partition numbers - (example: the 2nd entry in the partition table ("partition2") is always the Xbox system drive (C:)). That 2nd entry can be changed to point to any place on the drive. As I said, I haven't tried this, but it should work. - Paulb |
I like that idea ...
Would make it possible to have a fully retail C/E drive to play on xbox live (so even if MS scans HD they won't detect anything (unless they go raw axx the drive ofcourse)).
And if you boot your xbox with the hacked bios you get other C/E/F drives with edited stuff.
Post by: dmsdude90 on August 31, 2003, 03:59:00 PM
Post by: oz_paulb on August 31, 2003, 04:37:00 PM
| QUOTE (XanTium @ Aug 31 2003, 11:56 PM) | ||||
I like that idea ... Would make it possible to have a fully retail C/E drive to play on xbox live (so even if MS scans HD they won't detect anything (unless they go raw axx the drive ofcourse)). And if you boot your xbox with the hacked bios you get other C/E/F drives with edited stuff. |
It seems like this would be possible, but it depends on what live looks for.
If they do raw access to the drive ("\Device\Harddisk0\partition0"), then they can scan the entire drive, and all bets are off.
- Paulb
Post by: EvilWays on August 31, 2003, 05:00:00 PM
Post by: alphaman on August 31, 2003, 05:16:00 PM
Post by: Flagg3 on August 31, 2003, 05:19:00 PM
| QUOTE |
I like that idea ... Would make it possible to have a fully retail C/E drive to play on xbox live (so even if MS scans HD they won't detect anything (unless they go raw axx the drive ofcourse)). And if you boot your xbox with the hacked bios you get other C/E/F drives with edited stuff. It seems like this would be possible, but it depends on what live looks for. If they do raw access to the drive ("DeviceHarddisk0partition0"), then they can scan the entire drive, and all bets are off. |
You can do this already.
XBTool allows you modify the bios to boot from any partition that you wish. As long as you set it to boot from F, there is no reason to modify anything on C and E.
Still won't help if they check the partition table, but due to the privacy issues involved, I would guess that MS wouldn't scan the hard drive at all for fear of the backlash about privacy issues.
Flagg
Post by: Buttza on August 31, 2003, 08:25:00 PM
Sorry for this post being slightly off-topic. But would it be possible to add support for a second hard drive? For example, DeviceHarddisk1partition0?
Thanks and well done with your work thus far.
Post by: mattg39 on August 31, 2003, 08:38:00 PM
Thanks
Post by: oz_paulb on August 31, 2003, 09:55:00 PM
| QUOTE (mattg39 @ Sep 1 2003, 05:02 AM) |
| Buttza, that is exactly what I was about to post. Add a second hard drive where the dvd rom is right now. Would it be possible Paulb? This would be great. Two small cheap 120gig drives or two 300gig hdd's. Thanks |
The only way to do it would be to remove the DVD (since you can only have 2 physical IDE devices on the cable).
I've never really thought about that, so I haven't looked-into the code enough to know how difficult it would be. After the LBA48 stuff is settled down, I'll take a look.
- Paulb
Post by: GuySmily on August 31, 2003, 10:55:00 PM
The reason two hard drives would be nice is that you can get a 2:1 gig:dollar ratio at around 120gigs (wait for sales, they do come this low), and I would much rather do that (240 gigs for $120) than pay around $300 for a single 250gig drive.
Post by: Large Dopant white on August 31, 2003, 10:30:00 PM
| QUOTE (GuySmily @ Sep 1 2003, 07:19 AM) |
| and I would much rather do that (240 gigs for $120) than pay around $300 for a single 250gig drive. |
Check here. $223 for a 250GB HDD... that's with ground shipping, I believe.... and less than $1 per Gig, to boot. Pricewatch.com is awesome.
Post by: GuySmily on August 31, 2003, 11:17:00 PM
Wherever the best gig:dollar ratio is, I'll be watching =p
Post by: StealthRT on September 01, 2003, 12:17:00 AM
I just wanted to add my thoughts on the "adding a second hard drive" question. I am in the process of building a new box for my xbox and in the design i have taken out the DVD drive. Now i have yet to test 2 hard drives with it but i know it does boot fine with just one hard drive without the DVD drive attached. MxM is a little chopping as is the XBOX Logo animation at the beginning, but i guess its looking for the dvd at that time...
I have a few retail xbox hard drives laying around here that i can use to boot up the xbox of mine to test out the 2 hard drive question. But i would have to use a switch /(4 pole, 2 throw) to switch to each hard drive since oz_paulb hasent released the BHDB Bio yet (Bigger Hard Drive Bio).
So i will try hooking up the hard drives 1) Seprate power with the switch.. and 2) On the same ide cable both together at startup. See what i come up with in the days to come
Talk to u all later!
David
Post by: GuySmily on September 01, 2003, 12:35:00 AM
Post by: oblox on September 01, 2003, 12:39:00 AM
Original Bios <137
New Bios >137
Place new partitions on drive and in bios >137
I know you loose space but if your scared about them scanning while your online then wouldn't this be a solution? Mod off looks like an original Xbox besides an overly large Harddrive
NOTE: If they are scanning then this would force them to produce an update so they could see >137 which would then tell us that they are scanning and then we can gather the pitchforks etc.
Post by: JohnA on September 01, 2003, 01:54:00 AM
Post by: sshanafe on September 01, 2003, 04:33:00 AM
| QUOTE (JohnA @ Sep 1 2003, 10:18 AM) |
| Just a thought, if adding a second hdd in place of dvd is possible. Dare I say as another user said, would software raid be possible? I could just about live with 2 * 300GB drives |
Don't drink the well dry fellas.... Thanks Paul!
Post by: Xmo on September 01, 2003, 07:13:00 AM
first off all great work paul, my 120 gb hd was nearly full :-)
But a few things I didn't understand 100%:
Is it possible to add all the space above 137 to the f: drive?
Naturally only with the hacked Bios but I am using not the original
MS Bios anyway. I only use it to play XB Live, and so I don't need
the f: Drive.
(I have read the whole threat but I couldn't find an answer, because my
english is not that good)
Thx
Xmo
Post by: X-ace on September 01, 2003, 07:00:00 AM
| QUOTE (Large Dopant white @ Sep 1 2003, 06:30 AM) | ||
Check here. $223 for a 250GB HDD... that's with ground shipping, I believe.... and less than $1 per Gig, to boot. Pricewatch.com is awesome. |
Circuit city has WD 160 GB for $99 after rebate.
Fry's has it without rebates at all.
200GBs will probably fall to the $100 mark within a few months.
Post by: boxorox on September 01, 2003, 07:41:00 AM
| QUOTE (Xmo @ Sep 1 2003, 03:37 PM) |
| Hi, first off all great work paul, my 120 gb hd was nearly full :-) But a few things I didn't understand 100%: Is it possible to add all the space above 137 to the f: drive? Naturally only with the hacked Bios but I am using not the original MS Bios anyway. I only use it to play XB Live, and so I don't need the f: Drive. (I have read the whole threat but I couldn't find an answer, because my english is not that good) Thx Xmo |
You did not read the whole thread
Post by: Xmo on September 01, 2003, 07:20:00 AM
| QUOTE |
| You did not read the whole thread |
Thank You a lot, and thousand times sorry that I underrated Your
capability to know more about other people then they know about theirsels.
Post by: Large Dopant white on September 01, 2003, 07:35:00 AM
| QUOTE (X-ace @ Sep 1 2003, 04:00 PM) | ||||
Circuit city has WD 160 GB for $99 after rebate. Fry's has it without rebates at all. 200GBs will probably fall to the $100 mark within a few months. |
Yeah, the prices of EIDE HDDs are falling by the day. My guess is because of the new, cheap, and fast SATA drives, but I could be wrong.
Post by: paperchas on September 01, 2003, 10:44:00 AM
Post by: WiT on September 01, 2003, 11:13:00 AM
| QUOTE (mattg39 @ Sep 1 2003, 05:02 AM) |
why the hell do you have that avatar, this is not the place for gay shit like that
Post by: GuySmily on September 01, 2003, 12:03:00 PM
| QUOTE (paperchas @ Sep 1 2003, 11:08 AM) |
| I just bought a 200gig hard drive for 99.99 after mail in rebate at Fry's |
Really? Which Fry's was this? I see a couple at outpost.com for $130 after rebate.. One even comes with a free lego bionicle!
Post by: gggie on September 01, 2003, 12:57:00 PM
| QUOTE (alphaman @ Sep 1 2003, 12:40 AM) |
| Is there really a noticeable difference between the 5400rpm and 7200rpm drives? I would think you may see a difference in maybe the load time of the game, but not actual game play? Anyone have specific info on this and buffer size? |
I'm wondering about this too -- anyone who said 8mb cache/7200 would definitely be faster want to comment?
After all, these are games meant to be run from a DVD - which is going to be slower than any hard drive (even a 5400rpm one with 2mb cache) -- what is the real world difference going to be between a 7200/8mb drive and a 5400/2mb drive on the xbox?
(if it just means games loading slightly faster, i wouldn't really feel a need to get the faster drive)
Post by: GuySmily on September 01, 2003, 01:23:00 PM
Post by: bullsonparade on September 01, 2003, 01:25:00 PM
can offer is speedier load times. The games themselves
won't run any faster because they are paced and frame limited
to run on the xbox hardware. Unlike pc games which are made
to scale and degrade "gracefully", console games are given strict
fps and timing limits. This is all AFAIK, of course i could be wrong.
~bulls
Post by: Jsmith on September 01, 2003, 02:31:00 PM
| QUOTE (GuySmily @ Sep 1 2003, 03:47 PM) |
| The difference between drives will be unnoticable. However, I would still go with the highest quality possible, since you are still paying money for it. |
And because one day your may upgrade your xbox hard drive with an even larger one, and you'll put the current one into your computer. Now, would you really want a 5400 rpm 2mb hard drive in your PC? I wouldn't.
Post by: GuySmily on September 01, 2003, 02:35:00 PM
Post by: seneros on September 01, 2003, 06:49:00 PM
http://home.alltel.net/nghtshd/Data/XBtool_1.0.8b6.zip
on
http://home.alltel.net/nghtshd/xbtool.html
Post by: oz_paulb on September 01, 2003, 06:15:00 PM
| QUOTE (seneros @ Sep 2 2003, 03:13 AM) |
| ive been trying my best to keep up on this post, but is this it? (beta, but it nonetheless?) http://home.alltel.n...ool_1.0.8b6.zip on http://home.alltel.n...shd/xbtool.html |
Yes, that's it. I've done some amount of testing, but I'm not guaranteeing that it's bug-free. People should use at their own risk. After more people are actively using it, we'll get a better feel for how 'solid' it is.
- Paulb
Post by: oz_paulb on September 01, 2003, 06:16:00 PM
http://forums.xbox-s...ST&f=41&t=97997
- Paulb
Post by: Heet on September 01, 2003, 06:53:00 PM
Post by: Flagg3 on September 01, 2003, 06:58:00 PM
| QUOTE (gggie @ Sep 1 2003, 08:21 PM) | ||
I'm wondering about this too -- anyone who said 8mb cache/7200 would definitely be faster want to comment? After all, these are games meant to be run from a DVD - which is going to be slower than any hard drive (even a 5400rpm one with 2mb cache) -- what is the real world difference going to be between a 7200/8mb drive and a 5400/2mb drive on the xbox? (if it just means games loading slightly faster, i wouldn't really feel a need to get the faster drive) |
Well, obviously gameplay will not improve per se, but load times are SIGNIFICANTLY faster on the 7200rpm/8mb drives.
Load times affect you in almost every aspect of the box. Every time you load a game, whenever you see a "LOADING" screen in a game, whenever you load a new piece of software, etc.
It's basically the same advantages you'll see with the faster drives on a PC. It's definitely a noticeable improvement.
Flagg
Post by: boxorox on September 01, 2003, 06:39:00 PM
| QUOTE (Flagg3 @ Sep 2 2003, 03:22 AM) | ||||
Well, obviously gameplay will not improve per se, but load times are SIGNIFICANTLY faster on the 7200rpm/8mb drives. Load times affect you in almost every aspect of the box. Every time you load a game, whenever you see a "LOADING" screen in a game, whenever you load a new piece of software, etc. It's basically the same advantages you'll see with the faster drives on a PC. It's definitely a noticeable improvement. Flagg |
This thread is not about HDD speed and cache, but I agree. There was an immediate noticeable improvement when I switched from the orginal HDD. I had Halo backed up on both and i don't think it is my imagination, the maxtor160GB 7200 8mb cache boots the game alot faster.
It would be excellent if someone could try it with two Xboxes side by side.
Post by: AsTnBoMb on September 01, 2003, 10:14:00 PM
Post by: EvilWays on September 02, 2003, 12:09:00 AM
Post by: Striker2k2 on September 02, 2003, 05:11:00 AM
anyone tested the xbtool or Dominion-X Bios 0901 yet with a big harddrive and
care to inform us of the results?
Post by: drewZen on September 02, 2003, 05:40:00 AM
Post by: Kontra on September 02, 2003, 07:19:00 AM
First let me say Thanks Paul, and nice work on a job well done. You did a very nice job on the work, and the information as you were working on it. Glad to see good teamwork brang us such a usefull tooll.
For what I did for those inquiring. I used a WD 160GB 7200rpm 8 meg cache drive. I took the 4978.03 bios, used the new xbtool to add all exhisting data > 137gb to partition6 (F:) then reformated the whole drive. I was allocated about 155gbs to drive F:, and the usualls to E: C: and the cache drives.
Everything seems to be working smoothly, I have started to refill the drive, and all first run tests of applications and games seem to work smoothly.
Thanks again
-Kontra
[email protected]
Post by: uberx on September 02, 2003, 09:41:00 AM
Post by: wailer6084 on September 02, 2003, 06:11:00 PM
Post by: Alpha-Omega on September 03, 2003, 01:47:00 PM
Post by: NghtShd on September 04, 2003, 01:11:00 AM
| QUOTE (wailer6084 @ Sep 3 2003, 02:35 AM) |
| I would think it would work with the phoenix bios loader as long as all files needed to boot (phoenix bios loader, bios file, etc..) are _not_ on the f drive. |
I don't have a > 137GB drive, so I can't test that, but most of my BIOS testing is done with BFM versions. I've had no problems, so far.
The only problem I see would be if you use the option in which the F drive takes the rest of the drive. In that case, you couldn't use the F drive until after the BFM BIOS loaded and you'd run the risk of data loss if something wrote to the F drive while the firmware loaded BIOS was running--assuming it wasn't setup the same as the BFM one.
If you are using any other partitioning option, I would think that you could even run the Phoenix Loader from the F drive, since it will be there and fully functional.
I've tested making BFM versions of all XBtool supported BIOSes using XBtool 1.0.8b8 and it works fine. All BIOSes patched for LBA48 support and converted to BFM by XBtool and were functional. See the BFM packer section of the documentation if you plan on using the BFM packing function.
Post by: Corvo on September 04, 2003, 02:05:00 AM
I format my 200gb HDD with the option to allocate the F: partition up to 137gb and the rest to the g: partition.
So, with my modchip disabled... everything would work (even though it is LBA24).
With my modchip enabled... everything works with whatever BIOS I use, and if I use a LBA48 patched BIOS: The G: partition is available.
Right?
Or is it the best to just patch all BIOS'es one has, and allocate all space to the F: partition?
Anyways: Keep up the great work Paul!
Post by: oz_paulb on September 04, 2003, 04:50:00 AM
| QUOTE (Corvo @ Sep 4 2003, 10:29 AM) |
| Let me get this correctly... I format my 200gb HDD with the option to allocate the F: partition up to 137gb and the rest to the g: partition. So, with my modchip disabled... everything would work (even though it is LBA24). With my modchip enabled... everything works with whatever BIOS I use, and if I use a LBA48 patched BIOS: The G: partition is available. Right? Or is it the best to just patch all BIOS'es one has, and allocate all space to the F: partition? Anyways: Keep up the great work Paul! |
Your summary is correct - selecting the option with F: using all space up to 137GB is the most compatible, and if you tend to switch bios's a lot, then it's probably best to use this option. Your G: drive will only be visible when you have an LBA48-enabled bios installed.
- Paulb
Post by: faf on September 04, 2003, 06:22:00 AM
This development seems exciting for everyone... even for people who dont have drives larger than 137GB...
now the way i figured... Paul didnt want to give a letter/name to the "extra drive" because he was leaning towards allowing people to choose thier own drive letters and hoping apps in the future will "request" which drives are available and be presented with a list...
but... did he just endorse the extra drive as G? i think he did. So G it is then.
Also... i'm kindda surprised that "that guy who seemed to know it all about the bios not working" .... hasnt been back to apologize.
Maybe he's too busy to have noticed?
Post by: explicitlyrics100 on September 04, 2003, 08:22:00 AM
Post by: AsTnBoMb on September 07, 2003, 07:23:00 PM
Post by: elduderino1234 on September 07, 2003, 07:57:00 PM
| QUOTE (AsTnBoMb @ Sep 7 2003, 07:47 PM) |
| I was thinking the same thing, but then again, F-Drive wasn't a partition that games were programmed for and that still works, so im sure G-drive will work just fine. |
a kernel hack allows games to be launched off the hdd and allows the use of the extra partition F
Post by: Dreamcazman on September 07, 2003, 10:48:00 PM
Anyways I was wondering what the maximum size now is for LBA48? I've just noticed WD have a new 250Gb drive (which costs a bomb) and sometime down the track I will no doubt get a drive bigger than my 120 gigger.
I mean, would G: drive work up to 300Gb, 400Gb and up or what is the limit? (once drives that big are released, that is
)
Post by: oz_paulb on September 07, 2003, 11:37:00 PM
| QUOTE (Dreamcazman @ Sep 8 2003, 07:48 AM) |
| Firstly, I have just been reading through this thread, cheers to you Paulb, you're a champ Anyways I was wondering what the maximum size now is for LBA48? I've just noticed WD have a new 250Gb drive (which costs a bomb) and sometime down the track I will no doubt get a drive bigger than my 120 gigger. I mean, would G: drive work up to 300Gb, 400Gb and up or what is the limit? (once drives that big are released, that is ) |
The only real limit will be a limit in the FATX filesystem (I'm unaware of any real limits there, but I'm sure there is something). The 32bits we use of LBA48 gives us a max physical drive size of 2.2Terabytes. But, I think a FATX limit will probably be hit before then.
People are successfully using 300GB drives with the LBA48 code.
- Paulb
Post by: Dreamcazman on September 08, 2003, 12:13:00 AM
Post by: Cannibalistic on September 08, 2003, 01:01:00 AM
n00b question:
If I want to upgrade and swap my current WD 120GB (2MB Cache) HDD with a larger drive, can I use your patch to do so?
Also, since I got my HDD prepared for me, I want to "ghost" all the data from the current drive to the future larger one. Can I still use the patch?
Thanks!
Post by: =ByTcHS|AppA= on September 08, 2003, 02:56:00 AM
http://www.areca.com.tw/products/5010.htm
Sitting on my desk at work ATM - so me can see 5x250gig drives going in there....thats 1 TB of RAID 5 storage
I'm sure that an xbox would make a cheap file server
Post by: stormace on September 08, 2003, 03:19:00 AM
Can people post their lockable 200GB or 300GB HD Model #?
Looking to upgrade now.
Post by: alphaman on September 08, 2003, 04:27:00 PM
Post by: ryan-neil on September 08, 2003, 04:42:00 PM
Can i get the extra 26gb from my 160 drive to the G partition without formatting it or do i have to format the entire drive to get the extra space
If so how, please put me out of my misery,
Post by: stormace on September 08, 2003, 05:02:00 PM
downside to G: is the apps don't see it...like boxexplorer or xtoolbox. but autoitem within the xbox does, so loading games on there is no problem. Just manually ftp files...no big deal.
Post by: ryan-neil on September 08, 2003, 06:44:00 PM
This is the shit,
Ive gone from 2 Gigs left on my 160 to 27
I feel an upgrade comming on,
Good work to anyone involved on this
Does anyone know if this is compataable with the msdash hack
Post by: Cannibalistic on September 08, 2003, 09:49:00 PM
1 - Ghost (or clone) the contents of my current to the new HDD that I would buy?
2 - When I apply this patch, does it "automatically" creates a Partition G?
3 - Normally games would go in F partition, what is the purpose of this G partition the? Does it allow games to be read off of it?
Thansk in advance.
Post by: faf on September 09, 2003, 02:34:00 AM
| QUOTE (Cannibalistic @ Sep 9 2003, 06:13 AM) |
| If I upgrade my current WD HDD 120GB (2MB Cache) to a bigger one, how can I first: 1 - Ghost (or clone) the contents of my current to the new HDD that I would buy? 2 - When I apply this patch, does it "automatically" creates a Partition G? 3 - Normally games would go in F partition, what is the purpose of this G partition the? Does it allow games to be read off of it? Thansk in advance. |
reading a bit of the thread will help y'know?
Post by: chinmi on September 09, 2003, 03:02:00 AM
| QUOTE (Cannibalistic @ Sep 9 2003, 12:13 PM) |
| If I upgrade my current WD HDD 120GB (2MB Cache) to a bigger one, how can I first: 1 - Ghost (or clone) the contents of my current to the new HDD that I would buy? 2 - When I apply this patch, does it "automatically" creates a Partition G? 3 - Normally games would go in F partition, what is the purpose of this G partition the? Does it allow games to be read off of it? Thansk in advance. |
1 - Yes, just read the tutorial on xbox-scene
2 - Yes
3 - Enabling the usage of extra space above 137 Gb limit; Yes
Post by: Elixo on September 09, 2003, 08:27:00 PM
| QUOTE (Dreamcazman @ Sep 8 2003, 03:37 AM) |
| Thanks Paul, I look forward to installing a huge drive once they come down in price. |
You can get OEM HD for about $1-$1.05/gig, at that price their a steal
And yes their 7500RPM some even 8mb cache
*EDIT*
Newegg.com has MAXTOR 250GB 7200RPM ATA133 HD 8MB cache 9ms seek OEM $262
mwave.com has Western Digital 250GB 7200RPM ATA100 HD 8MB cache 8.9ms seek OEM $249
Of course if you find cheaper websites then SPIT IT OUT!
websites that you bought from please none of this pricewatch crap, i've purchased more then $3k from newegg within the past 2yrs, also dealt with mwave.
Post by: Xmo on September 10, 2003, 02:30:00 AM
| QUOTE | ||
1 - Yes, just read the tutorial on xbox-scene 2 - Yes 3 - Enabling the usage of extra space above 137 Gb limit; Yes |
Hi,
one question relating to cloning a hdd:
The x-box tutorial says that it there could be problems with cloning
a smaller to a bigger hdd, can someone confirm or negate that?
Thx
Xmo
Post by: Cannibalistic on September 10, 2003, 02:33:00 AM
Post by: chinmi on September 10, 2003, 06:00:00 AM
if you have an original un-modified xbox hdd, the clone process will only clone the 1st 8 Gb of data.... the rest of drive F is un-cloned, so you have to format the drive f to make a full use of it's capacity
Post by: Deezle on September 10, 2003, 06:40:00 AM
Greetz,
Deezle
Post by: Cannibalistic on September 12, 2003, 01:23:00 PM
Post by: SigTom on September 12, 2003, 02:29:00 PM
Post by: Deezle on September 12, 2003, 02:49:00 PM
That's not what I would call 'cunning'. It would be a pain in the ass to do it that way.
But anyway, thnx for the reply!I am sure Cannibalistic is searching for a more elegant way to transfer the data from one hd to another. The same goes for me. Has anyone a good idea?
Greetz,
Deezle
Post by: stormace on September 12, 2003, 04:43:00 PM
Post by: RadiatedAnt on September 12, 2003, 05:27:00 PM
now thats a major steal, Im going tommarow because they ran out of stock
Post by: boredombud on September 18, 2003, 07:24:00 PM
im totally going on pricewatch and getting a fucking 250 fuckin gig drive to slap in this piece..
aww man xboxes blow sliced bread away like whoa.
go paul.. id love to read all about your steps in creating this "fix" . it sounds mad cool.
you should set up a paypal and charge like a dollar n shit to download it! id buy it for a dollar
anyways theres my 5 cents.. rock on .me
Post by: markduncan on September 19, 2003, 09:22:00 AM
| QUOTE |
| boredombud Posted on Sep 19 2003, 03:48 AM -------------------------------------------------------------------------------- YEAHH hi dudes.. id just like to say personally, I CANT FUCKING WAIT. im totally going on pricewatch and getting a fucking 250 fuckin gig drive to slap in this piece.. aww man xboxes blow sliced bread away like whoa. go paul.. id love to read all about your steps in creating this "fix" . it sounds mad cool. you should set up a paypal and charge like a dollar n shit to download it! id buy it for a dollar anyways theres my 5 cents.. rock on . me |
Well if you "Had Actually Read" the full thread you would understand that this is now a working realitiy, through the use of the tools listed by "oz-paulb" to patch a bios and to patch evox. These patches and tools are freely available from the
"usual sources" and are self explanitary to use.
I have now been running a 300gig past the previous limit of 137Gig on the xbox with "NO" problems what so ever.
Scotsman
Post by: KAC on September 19, 2003, 10:20:00 AM
Post by: markduncan on September 19, 2003, 10:59:00 AM
| QUOTE |
| is that the Maxtor Maxline II 300Gb, 5400RPM, 2MB drive? |
Yes I got it on a special from DABS "a computer store here in the UK"
Post by: juan23 on September 19, 2003, 11:41:00 AM
| QUOTE (RadiatedAnt @ Sep 13 2003, 02:27 AM) |
| well for all you Microcenter fans who are lucky enough to have one in your state, they have a 250GB Western Digital sale 99 Dollars after REBATE !!! now thats a major steal, Im going tommarow because they ran out of stock |
Raidiatedant??
I am on microcenters website looking at there add that went out in the newspaper. I cant find anything that says about the 250 gig hdd for only 99.00 after rebate. can you show me your link or give any more info on this.
thanks in advance
Post by: KAC on September 19, 2003, 12:47:00 PM
| QUOTE |
| Yes I got it on a special from DABS "a computer store here in the UK" |
Thanks markduncan, I just wanted to make sure cuz I have the same drive on order and was worried about being able to lock it but now I'm not so worried thanks to your reply.