Ideas For Yet Another Boot Disc Options

[FrostyTheSnowman]

Also, if you guys want to 'officially' release your disc on XBINS and see your release on the front page of Xbox-Scene, contact Iriez, he provided me with an admin login to the XBINS FTP site and also to XBINS.org about 3 years ago for my releases, i'm sure he can do the same for you guys (Heimdall/ldotsfan/bc54) for your release.

NOTE: If he does provide you with an admin login, then any release you put on the XBINS FTP and the XBINS.org site automatically gets you a front page spot here on Xbox-Scene. (XBINS.org is scripted to automatically post front page news of new releases on Xbox-Scene, AFAIK)

yeah, i have a question about the custom BIOS you used, is it capable of working on a 1.6? and is it .06 or .67? when i was putting together xmu, i wanted an option to install to hdd, and i figured that i would need a bfm bios version for .06 setups and one for .67 setups. then it hit someone might need a 1.6 specific bios. so then i wondered if your bios would work on a 1.6, and if it doesn't, then i might have to release a 1.6 only version.

Yes, the BIOS is a heavily-modified version of Evox M8plus (converted to BFM with many hex edits to point to the DVD drive for booting the dashboard (root.xbe), and also for In-Game Reset to return to the dashboard on the DVD (which is also coded to return to root.xbe) and has DVD-booting disabled to prevent the BIOS from looping when returning to the dash) which is also compatible with v1.6 XBOXes.

It is currently set up for .06 partitioning, however, it also recognizes XBPartitioner partition tables natively.

Which means that ANY partition style created using XBPartitioner is recognized correctly by my modified Evox M8plus BIOS, regardless of whether the partitions are .06 style, .67 style, or any custom partitioning style.

So basically, the BIOS file included in my rescue disc is a 'frankenstein' Evox M8plus .06 BIOS.

This post has been edited by FrostyTheSnowman: Jun 17 2009, 10:39 PM

[Heimdall]

Mine's all working, but ...... I've hit a bit of a brick wall with Kingroach, all down to file sizes, and I'm stumped!

The C partition has 524,189,696 bytes free.

Stock C is 180,218,830 bytes

You then remove:
settings_adoc.xip 4,208,200 bytes
xboxdash.xbe 1,961,984 bytes
\xodash\xonlinedash.xbe 2,617,344 bytes

That leaves 352,758,394 bytes free.

From Kingroach you then add:
xboxdash.xbe 1,929,216 bytes
xb0xdash.xbe 1,961,984 bytes
\bios\ 21,976 bytes
\media\ 1,214,284 bytes
\xodash\ 7,197,176 bytes
\shadowc\resc\ 773,105 bytes
\shadowc\filler1.img 16,567,500 bytes
\shadowc\shadowc.img 352,321,536 bytes

That's a total of 381,986,777 bytes, and it's 29,228,383 bytes MORE than the free space.

Now, I've installed Kingroach loads of times before and it's worked fine, so I'm obviously doing something stupid! I've fixed it temporarily by reducing the size of shadowc.img to 320,000,010, but the problem is that if you subsequently use ndts to repair the installation it tries to reinstall the original shadowc, and fails.

I've checked my process against the Kingroach manual, and the xboxhdm ndure script, and it seems fine. I'd be grateful if someone could check my method and my numbers, because it must be something obvious, but after three days of frustration I just can't see it!

Once I get this sorted I've got one-click updates nailed ....... so close.......

Thanks

[bc54]

yeah, i just tried to install kingroach, and the same thing happened to me. while copying shadowc.img, the xbox's c drive filled up. shadowc.img was about 30mb less than what it should be, or something like that.
i didn't look into it much, because this is gonna be a tsop, but just wanted to confirm that this happens. well, it was gonna be a tsop, until the dumb little traces decided they wanted to lift.
whatever, ish happens. hope you figure out how to fix the kingroach ndure prob.

This post has been edited by bc54: Jun 18 2009, 02:32 AM

[ldotsfan]

Which means that ANY partition style created using XBPartitioner is recognized correctly by my modified Evox M8plus BIOS, regardless of whether the partitions are .06 style, .67 style, or any custom partitioning style.

So basically, the BIOS file included in my rescue disc is a 'frankenstein' Evox M8plus .06 BIOS.

Was the xbpartitioner support hex-edited in as well or you used some tool for that?

That's a total of 381,986,777 bytes, and it's 29,228,383 bytes MORE than the free space.

Is the total size of stock C the same across copies of CASH , AID and Slayer 2.7?

When I was testing lxhdm, I also had issues with the overlapping of Kingroach files with msdash but I dismissed it then as my copy of stock C was dirty. I also adjusted the size of shadowC manually. So with bc54 confirming this as well, we all faced the same problem at different points of time

Will have to do some searching in the Ndure development thread to shed some light on this or ask if kingroach knows about this.. filler1.img size is smaller than the difference you found: 29,228,383 bytes

Is this the culprit?

This post has been edited by ldotsfan: Jun 18 2009, 01:55 PM

[Heimdall]

Is the total size of stock C the same across copies of CASH , AID and Slayer 2.7?

Almost. One has \xodash\update.xbe at around 2MB (at work at the moment, can't check exactly), the others don't. It's not enough to account for the difference....

ask if kingroach knows about this..

Already sent him a PM on this, and on some minor ndts config.xml changes

As we've all seen the same problem with the size of shadowc it's clearly not finger trouble on my part, so that makes me feel less stupid!

I've decided to make a smaller shadowc and embed it in a modified ndts and ship it with my disc configs, so that it's completely self-consistent.

A quick question - all I did to make shadowc smaller was truncate the file, and the softmod picked up the smaller size. Should I do anything else? I had a look at the header in hexedit, and couldn't see anything that looked like an explicit declaration of the size of the virtual disk, but I'd appreciate some confirmation that it isn't going to fall over as the virtual disk fills up.

[ldotsfan]

A quick question - all I did to make shadowc smaller was truncate the file, and the softmod picked up the smaller size. Should I do anything else? I had a look at the header in hexedit, and couldn't see anything that looked like an explicit declaration of the size of the virtual disk, but I'd appreciate some confirmation that it isn't going to fall over as the virtual disk fills up.

I usually use this method. AFAIK, once nkpatcher kicks in, the shadowC.img will be formatted to FATX. Then you will be able to find the FATX header when you hex-edit the file. I'll check nkpatcher source code to confirm this later.

EDIT: Krayzie's formats shadowC from the dash. Maybe you need to search the shadowC.img from Kingroach for the FATX string

This post has been edited by ldotsfan: Jun 18 2009, 02:30 PM

[Heimdall]

Thanks for that - it's load easier than truncating the file manually. I'll use that to create a new clean copy tonight.

Interestingly, the one that's shipped with Kingroach already has a FATX header, but nkpatcher still detects the change in virtual disk size if you just truncate it. Clever!

[ldotsfan]

Interestingly, the one that's shipped with Kingroach already has a FATX header

Ah, he probably did it with loop file mounting in Linux and mkfs.fatx - when I was developing xboxhdm2 and studying how xboxhdm worked, I did a lot of that stuff - but now the exact syntax is a bit hazy

This post has been edited by ldotsfan: Jun 18 2009, 02:43 PM

[FrostyTheSnowman]

Was the xbpartitioner support hex-edited in as well or you used some tool for that?

That one was actually natively supported by the Evox M8plus BIOS before my hex edits.

I'm not sure if the EvolutionX team ever documented this feature or not, but the Evox M8plus fully recognizes all custom XBPartitioner partition tables natively, according to many tests by myself.

I did not add this support, only tested it's functionality to confirm my suspicions.

My exact changes to the Evox M8plus are as follows:

1. Converted to BFM
2. Hex edited the dashboard launch code to boot d:\root.xbe
3. Hex edited the IGR code to return to d:\root.xbe
4. NOP'd out the Game Disc boot code (NOP'd out the default.xbe references, to prevent the BFM Evox BIOS from continuously reloading itself into an endless loop)

IMPORTANT NOTE: I am using the v1.0-v1.5 Evox M8plus version that is normally NOT compatible with v1.6 models, however, when this version is loaded through BFM instead of a modchip it loads and works fine on a v1.6 XBOX, thereby making this BFM Evox M8plus BIOS compatible with all versions by being loaded through BFM.

Thanks for that - it's load easier than truncating the file manually. I'll use that to create a new clean copy tonight.

Interestingly, the one that's shipped with Kingroach already has a FATX header, but nkpatcher still detects the change in virtual disk size if you just truncate it. Clever!

On a side note, I have done the same with the shadowc.img file in my custom softmods. I use a shadowc.img file in my custom softmods that has 5MB truncated from the end of the file, and I have never had any issues.

I haven't tried removing more than 5MB, but mine has worked fine for years this way.

[Heimdall]

Found it!!!!!

The missing 30 MB is the two fonts from the root of the stock C - XBox Book.xtf at 17,068,868 bytes and Xbox.xtf at 15,613,736 bytes, and you are supposed to delete them.

I knew it was obvious! It took me three days to work that out.....

[ldotsfan]

Is this the culprit?

The missing 30 MB is the two fonts from the root of the stock C - XBox Book.xtf at 17,068,868 bytes and Xbox.xtf at 15,613,736 bytes, and you are supposed to delete them.

I'm not sure if the EvolutionX team ever documented this feature or not, but the Evox M8plus fully recognizes all custom XBPartitioner partition tables natively, according to many tests by myself.

Don't see this mentioned in other threads so this is a important piece of information on M8plus bios.

My exact changes to the Evox M8plus are as follows:

1. Converted to BFM
2. Hex edited the dashboard launch code to boot d:\root.xbe
3. Hex edited the IGR code to return to d:\root.xbe
4. NOP'd out the Game Disc boot code (NOP'd out the default.xbe references, to prevent the BFM Evox BIOS from continuously reloading itself into an endless loop)

IMPORTANT NOTE: I am using the v1.0-v1.5 Evox M8plus version that is normally NOT compatible with v1.6 models, however, when this version is loaded through BFM instead of a modchip it loads and works fine on a v1.6 XBOX, thereby making this BFM Evox M8plus BIOS compatible with all versions by being loaded through BFM.

Brilliant!

So a BFM bios works across all versions - is this true for other bios or specific to M8Plus?

This post has been edited by ldotsfan: Jun 19 2009, 12:46 PM

[FrostyTheSnowman]

Brilliant!

So a BFM bios works across all versions - is this true for other bios or specific to M8Plus?

The Evox M8plus (v1.0-v1.5 version) does load and work just fine on a v1.6 XBOX, i'm not sure about other BIOSes working on all versions through BFM, but I know the Evox M8plus does.

It might be related to the bootstrap, i'm not sure though. I've only seen a few BIOSes that load on different (incompatible) models through BFM, like the 5101 stock BIOS (from a v1.1 XBOX) loads correctly on v1.0 systems through BFM, but FRAGS if you flash it to a v1.0 XBOX.

So yeah, I think it is only a few specific BIOSes that can do this. My theory on why the Evox M8plus (v1.0-v1.5 version) works on a v1.6 console is that the kernel (5838) contains all the necessary information for controlling the XBOX regardless of the version, it's just the bootstrap that is different. (which isn't used when loaded by BFM, AFAIK)