Is there anyway to update to get the debug units to recognize drives bigger than 137 gigs? I installed a 160gig to get every bit of that 137 gigs out of it! But I want more!
Need a new BIOS. But I'm not sure if there are debug ones out with the LBA48 hack and nothing else changed. Reason for the 137 gig limit is because the default BIOS is only LBA28 and that tops out at 137 gigs. Need LBA48 to get up to the 2.2 TB limit.
I am guessing you have to flash the TSOP then on the debug motherboard with a hacked bios? Can you flash the TSOP on a debug?
how did you get it use the entire 137 gb of the disc , when i put a 20gb disc in and used a recovery it just formated 8gb of it and left the rest
Honestly youre better off with a modded console if you want bigger HDD support. Easier to work with, with more bios that support the hardware properly. And why would the recovery format the extra space? Doesnt make sense. Use the standard formatting tools.
I just format the drive in my test XBOX that has a X3 chip installed. Then I put it in the debug and let the recover disk format all the drives but F: But that was formatted by my Test XBOX. It will use up 137GB. If you use a 120 you will not get to use the whole 137 gigs. I use 160 gig drives and it only wastes the extra 20 something gigs. Make sure you add the file to let you see the F: drive though
Upgrade a standard XBOX motherboard with 128MB with a custom bios. Don't go doing weird things with debugs. Also davidthomas, use the damn edit button. I've had to merge so many of your posts, post reasonable things and don't try and boost over to 50 posts to sell stuff. Don't think it will go unnoticed.
I would love to make a debug firmware for Xbox that supported large drives, but I don't know how. Are there any hacked firmwares for retail systems that support >137 GB drives that are based on patches to an existing kernel, rather than compiling a custom kernel? I could use those to make patches to a debug kernel.
Not sure if this helps or not but I think I came across a tool a long time ago that would add in the LBA48 patch to any BIOS thus enabling drives over 137GB to show full capacity. Don't remember where or what it was though... If someone finds it perhaps it would work on debug BIOS?
lmao, I like my debugs with little modification. It would be neat to have a debug with tons of storage but the bios support just isn't there.
Exactly. Why mod the rare debug kits when the common man's console can be modded to have all the same features of debug? All the debug has that replacement dashboards don't is the support of Neighborhood and the various tools with it. If this an attempt to get a 128MB console then just get a damned 128MB modded retail board. Not that hard. If the Neighborhood tools are needed then the XDK dash can be installed and launched on a retail system. I forget the exact method and I have a document describing what's needed to do so. I'll read through it later.
It is not about the RAM upgrade at all. I have 128 RAM xboxs already. I wanted a board with the MPCX 2 with the ability to load a couple of different bioses. I will have 3 different chihiro bioses to try. Loading the bios through a launcher is not gonna work for what I want to do. N64 freak is dumping the bios off the 2 chihiro boards I just sent him and I want to try to get some more of these chihiro games to run on a xbox and we wanted to see if the MPCX makes a difference or not. The debug and chihiro are the same motherboards with different TSOP flashes. I have a few of the debug kits and the one that I was planning on trying was previously damaged and not in a debug shell. So to me this board is perfect for these experiments. I am not destroying a good debug.
In my case, my Debug Kit was effectively already modded, so it's not really a problem for me. One day, I saw someone selling an empty Debug Kit case on eBay. I emailed the seller and asked what happened to the board. He said that he actually had three broken Debug Kits, and was selling the cases since the systems themselves were useless. I asked whether he'd be willing to sell the three boards, and I got them for $150. One of the boards clearly only had a corrupted flash. I fixed it by attaching a switch between flash D0 and ground, and doing the swap trick with the Bioxx LPC mod chip. I understand now how flashing the on-board flash ROM from an LPC mod chip works now, and clearly I knew back then, too. Basically, you use a custom ROM and flasher program to rig the Xbox hardware such that the MCPX ROM will fail the security checks. When this happens, the MCPX code will run off the end of memory, attempting to crash the CPU, but in fact this just causes the CPU to execute the code at address 0 - also known as RAM. Since in this warm reboot case RAM is already initialized, you can put x86 code at address 0 and it will survive the hard reset, but now the MCPX will map FFxxxxxx to the on-board flash instead of the LPC bus. As for the other two boards, those weren't corrupted flashes, so I couldn't fix them. I'm not really an electronics person. I sent them to a European hacker friend - I don't remember whether I sold them to him or gave them for free. In any case, Ed was able to fix one of the two boards; it had a blown $gizmo123 and worked when the part was replaced. Two working DVT-4 motherboards for $150 and repair time isn't bad at all. We have them in retail Xbox 1.0 cases.
If it boils down to reviving the unit, I'm cool with. Not a function Debug Kit that people want to use for retail games and so on. It's like "why bother?" when a $10 unit can do exactly the same. :/
