Got the idea from one of Heimdall's post when Frosty's file manager was used to load CASH.

The design goals I have in mind:

1. Small download like Frosty's xbox rescue disc.
2. UnleashX based. As opposed to EvoX. Gets lxhdm's PrepareHD and built-in file manager.
3. Loads PBL Metoo like Frosty's to bypass virtual eeprom protection/shadowC.
4. CASH 1.1 like capabilities : Krayzie's Ndure 1.1.1 , allows a chipped xbox to be softmodded and upgrade for older/other softmods to Krayzie's Ndure.
5. Xbpartitioner 1.1 for hdd upgrade over 256Gb.

Boot disc = Frosty's PBL rescue capabilities + lxhdm's softmod hdd upgrade capability + CASH's Krayzie's Ndure package. A all-in-one solution.

I've already got something similar hacked together (that's how I knew the Frosty's + Cash to upgrade SID 4.5 would work!) - based on Frosty's PBL, UnleashX front end, currently launches native CASH, AID and Slayers (no lxhdm at the moment), and I'm working my way through a more integrated menu, but it's stalled completely due to pressures of work. Trouble is, it's 4.2GB (most of that is AID)...... There's a pile of duplication that could be removed to bring that down (e.g. three copies of stock C), but that would require hacking about with the native CASH, AID and Slayers menus - possible, but time consuming. Problem is, I still need to get a Raincoat flasher on there, and Kingroach.

My design goals were broadly the same, but with some added things:
- choice of installing Krayzie or Kingroach as the upgraded softmod, and adding back in the two options missing from the Kingroach menu (bs06 and rt06, as I recall)
- menu options for installing all the NKP11 .bin variants (fan.bin, LED.bin, video.bin), maybe also using NKPatcher Runtime Config. Really only interested in the video.bin options, but I thought I may as well include the others.
- TSOP flashing utilities for all chips including Winbond, with only the newer BIOSes (also putting working config files for X2.5035 and iND-BIOS.5003 in the right places). Scripted to install the dash in the right place before the TSOP flash.
- Install different dashboards on the two flavours of softmod (to automate the response to the endless "how do I make XBMC my dashboard" questions!). I'd thought about doing this by installing all dashboards, then using the XBMC shortcut to point to the selected dash, so switching dashboards could be included as an option on the final user menu.
- move/rename all copies of eeprom.bin from places where it would interfere with proper operation of virtual eeprom

I'd thought of doing it in the same way you did lxhdm - a recipe for self-build, plus a custom config.xml.

Edit: I'd also planned on changing a bit of the CASH functionality, so it didn't automatically erase the E partition, but simply copied the dash files across, so that gamesaves etc. were retained.

Have deliberately left out the dash change feature in AID/CASH to reduce the size as a small download is one of the design goals. In fact, intend to leave out stock msdash since Krayzie's Ndure has a minimum install option - but have to test that out to see if that will work without any msdash files in place at all. Raincoat/EvoX as a tsop flasher and a limited choice of bios files (X2.5035, IND-BIOS.5003) is a desirable feature to include in and it won't violate the size goal. So I might adapt your idea

As for Krayzie's Ndure vs Kingroach's Ndure, the existing UnleashX based installation script in Krayzie's make it easier to work with than Kingroach's Ndure, though I briefly looked at Ndure Toolset...

Of course you already have a working prototype while mine is still an idea in my mind

Could you share your trade secret: How did you get the 3 discs' contents to work together? One config.xml, full paths to the individual default.xbe of each disc in separate folders in the unleashX menu?

I'm trying to avoid rewriting the evox.ini of CASH into unleashX equivalent...

Yes, that's sort of how I did it. From memory (I'm at work at the moment).....

- Unpack Frosty's into a directory, unpack CASH into another one.
- Move the CASH folders (not the root files) into the root of the Frosty's directory.
- Create a directory \CashRoot\ in the Frosty's directory, move the CASH root files there.
- Create a directory \FrostysRoot\, and copy the Frosty's root files there.
- Delete evox.ini and root.xbe from Frosty's root (NB not \FrostysRoot\), then put a clean Unleashx.xbe into Frosty's root, and rename it root.xbe.
- Create a config.xml in Frosty's root to launch D:\CashRoot\default.xbe and D:\FrostysRoot\default.xbe, plus whatever else you want - mine currently has a link to d:\Applications\XBPArtitioner\ and a standard UnleashX menu as well, while I work on the full version.
- I also copied disk.bin, default.suo and default.tbn into Frosty's root from \CashRoot\.
- **do the path substitution changes in \FrostysRoot\evox.ini and \CASHRoot\evox.ini** (See next paragraph)
- Make the whole thing into an iso with Qwix (obviously!)

I thought that the advantages of this method rather than putting all of CASH in a \CASH\ directory were that it retains avoids any path length issues (not sure there would have been any, but it avoided that potential complexity), and it retains the absolute locations of all files. However, from memory (haven't looked at it for a couple of months) I had to replace the relative paths in CASH and Frosty's evox.ini to make them absolute paths - global search and replace "\ for "d:\ because it isn't running from the root of D any more - but I can't remember if that was just an interim paranoid step....

I then did the same for Slayers and AID, but didn't have time to do any serious testing other than confirming that the menu would launch. The only directory conflict was \Skin - AID and CASH both use it, but with different contents, so no issue.

My plan was to get all three working with minimal changes (like the relative - absolute path changes), then gradually extract the functionality I wanted directly into the UnleashX front end, but leave native CASH, Slayers and AID there. Essentially I wanted an UnleashX version of CASH that had far fewer choices, so there was less explaining to do - the same sort of logic that Krayzie applied to his softmod installer, to make it almost completely idiot-proof.

Brilliant! If I understand you: the evox default.xbe and evox.ini for CASH and Frosty's stay in the their respective Root folders while the rest of the folders from CASH and Frosty's are on the root of the xiso? The replacement of root.xbe is to let unleashX piggyback on PBL of Frosty's - like what lxhdm did?

I'll need to add in PrepareHD , the Format C,E,X,Y,Z and ConfigMagic in the UnleashX menu to get the lxhdm functionalities


Is this for aesthetics or there's functionality behind?


Relative paths...right.

Correct.

. Both Slayers and CASH Evox use disk.bin when it formats drives, and I wasn't sure whether it looked for it in the directory evox was running from, or the root of the boot drive (another relative/absolute path issue - ConfigSector "\disk.bin" is the line) - so I decided to put it in both! I have no idea what the two default files do, but applied the same logic - belt and braces. I'd planned on polishing out this sort of duplication later - this first incarnation was just a quick and dirty hack.

I really can't remember if I needed the relative - absolute path changes, or if evox reads \directory\file to implictly mean from the root (like DOS) or from the current working directory (like linux?). I won't be anywhere near my Xboxes or home PC for a few days to check, but I think my logic was that it can't hurt to make the paths absolute, and it avoided me having to exhaustively check every option in the transplanted CASH / Slayers / AID.

Edit: And of course, you spotted my deliberate mistake earlier. To run native Frosty's you launch d:\FrostysRoot\root.xbe, not default.xbe. If you launch d:\FrostysRoot\default.xbe it reloads PBL, which then reloads your initial menu from d:\default.xbe, because that's how the PBL BIOS is configured.......

Sorry, missed the edit, and I'm not being very structured about this! My initial plan was to simply "port" CASH options 1, 5B or 5C (depending on where you are in the world), then option 5D, directly into UnleashX as a single item, but only reformatting C, not E - a really simple, one-click "fix my softmod" button" regardless of the user's initial softmod. I was then going to do the same for Kingroach, then add all of the other stuff from my previous post - starting with deleting / renaming all copies of eeprom.bin, to avoid the boot / runtime eeprom mismatch that leaves people with a black screen.

....but all the while leaving the links into the original boot disc menus for any functionality I hadn't bothered to port forwards!

I keep remembering bits of my original thought processes! The other reason I was fiddling with absolute paths wasn't just for legacy rescue disc operation, but also because I'm fairly certain that to do some of the things I had planned I'd need to copy UnleashX and a set of config files into a temporary location on E, run it from E, then use config switching to provide state retention, with "Press A to continue" to continue batch execution on return from e.g. Evox, or xman954's eeprom dumper - exactly the same way that Krayzie's installer does it between reboots. Trouble is the rescue files would still be on D:\, hence the need for absolute paths in the new config.

Now, I can't remember exactly why I thought I'd need to do that, but I think it was to replicate the eeprom backup and the copying of stock C files into shadow C for the Kingroach installation option. If it comes back to me I'll let you know!

Thanks. I won't be needing Kingroach's in my disc and will be using ConfigMagic for manual eeprom backup if needed. I'll leave it to EvoX eeprom backup in Krayzie's installer in the CASH portion to do it as part of the softmod install.

hi, i just noticed your thread about creating a unleashx based installer/recovery disc. about a couple of weeks ago, i made myself a similar kind of disc. it is an unleashx dash that can install/update/remove a softmod, install/remove dashboards, install/remove apps, install/remove emulators, and install/remove XDSL.

it can also do backups of eeprom and hard drive parttitions, flash the bios, and help with hard drive upgrades.
i can post the contents of the config.xml if you are interested.

thanks.

Yes, please, at pastebins? Thanks.

okay, i recently saw your idea about using pbl/frosty's so a shadowc could be disabled, and incorporated that into it as an "EMERGENCY MODE". as of now my plan is like this: boot to an evolutionx dash, with three options (normal=D:\root.xbe; EMERGENCY=D:\pbl.xbe; Evox Settings).
the idea is that in normal mode, you can't mess up your shadowc, because you never load a different bios.
now on to the real deal, i call it XMU - Xbox Management Utility:
EDIT: okay, it won't fit so here is a link to it.
http://www.mediafire.com/?sharekey=7e82d9e...04e75f6e8ebb871

i have tested this mostly, but i couldn't test anything with the F and G drive, but all the E stuff worked.
also, i have to give credit where it is due, i "borrowed" the zip archives from aid, and plugged them into my disc.
and, about the apps, as you can see i split them up into three categories - important (chimp, configmagic, xboxpartitioner, evox), useful, and extra (homebrew games, other fun stuff). other than that, it is just like a mashup of aid and cash, and now frosty's kind of, i guess.

Good work Based on the menu contents, your boot disc does what I wanted and most of what Heimdall wanted as well.

I see that you have incorporated lxhdm's error 5 hotswapping/PrepareHD into the config.xml as well with a mini-howto in the menu.

Looking forward to the completed product.

i am mostly done with this, i just want to test f and G drive stuff, and softmod on a chipped box. but, once i am finished, i don't know how to get it out there, aka put it at the usual places.
any way, your free to change the config.xml as you wish. glad i could help.

Excellent work Seems like we've all been doing similar things, but this doesn't quite do what I was aiming for....

- It doesn't provide one-click softmod fixing (the user still has to know which softmod they have, and make appropriate choices.)
- The Softmod Menu assumes that the user already has a clean 5960 dash with no previous softmods, and relies on the Krayzie installer to sort that out.
- The lxhdm implementation doesn't seem to leave the user with a softmodded xbox
- it doesn't ruthlessly remove / rename floating copies of eeprom.bin
- like CASH, it erases the E drive.

I have an old (but I think working) UnleashX fragment to automate lxhdm that leaves the user with a softmodded Xbox that I wrote some time ago, and another similar fragment to do the one click softmod fixing, plus a recipe to build the disc to support both (an extended version of my post about 5 back). I'm on my way to a party at the moment (Yes ), I'll post the recipe and the fragments after I've had time to check them (and recover from the hangover )

I suspect that the recipe plus config files approach is the easiest method for making this happen - it's easier than setting up and hosting another torrent for a complete disc image download, and Xbins (for obvious reasons) doesn't seem to host large files.

hmm. i don't really know how to implement a one-click softmod fix or the eeprom.bin rename/remove issue, but i can elaborate on the other points you made.

i don't know how to fix the reliance on the 5960, but the user should know if the xbox is softmodded, then they could pick "Upgrade from any other softmod" so then the C & E drives would be formatted and NDURE would be installed.

at the end of my lxhdm an evox dash call hddlock.xbe is launched. in that menu:

this gives the user a chance to ftp any backups over, or the option to return to xmu and install a fresh NDURE.

actually, it will only format C and E when upgrading from a non-NDURE xbox. installing the gamesaves will just copy over files, and upgrading just copies over upgrade files.

Krayzie's Minimum (Or is it called Basic) Install should work regardless of the dash version on C - likewise Kingroach's Ndure C can be used for verbatim replacement of C contents. Just no dual boot or the other fanciful features of Ndure.


The changelog for UnleashX V0.39.0222a Build 572 states that hdd locking/unlocking is available but I've not seen any references on how to use it on config.xml though.

Answered my own question
The Settings Action in config.xml will allow the Storage->Hard Drive Locked Status to be toggled between locked and unlocked from that version of UnleashX onwards. But I have not tried it yet.

yeah, about the 5960 dash reliance, i figured if one did choose upgrade, the C drive would be formatted, and a 5960 dash would be installed. i could add an option to install 5960 dash in the softmod menu, thereby saving the E drive from being formatted. also, is the minimum install accessible from the gamesave? if it then i would let the gamesave handle that option.

i would rather not have the disc install a premade C drive softmod (minmum install or retail install), because that could lead to people wanting to be lazy, and skipping the gamesave install. then if their softmod goes bad, and they can't run any homebrew, having a exploitable game won't help them at all. then they will be back at step 1. this way they can always recover with one of the exploitable games.

secondly, i just tried the system -> settings -> storage -> hard drive locked status, and it works perfectly. however, i don't know how to incorporate this into a singular Action="something" command. so, i plan on leaving it as is, because i can guarantee it will work and the user won't have to search through setting menus to lock the drive.

saying all this, i figure that all that is left to achieve all of the goals, is a one-click softmod repair and remove extra copies of eeprom.bin. i guess a one-click repair could be achieved thru a format of C, then copying a retail NDURE onto C. if i recall correctly, any E drive problems on a softmod (ex. missing dash) can be fixed thru recovery dashes on the C drive. as for the eeprom.bin issue, i tried to copy NDURE's approach, by using the same location used by the ShadowC setup (E:\Backups\eeprom). i didn't want to copy CASH's location (C:\Backup) because many options would end up formatting C, and somebody might not care to ftp the backup immediately. also, eeprom backups don't take up much space, so it shouldn't really bother, and if it did really bother you, all you have to do is delete the extra copies.

also, i have started working on to this some more today, and i have it fully capable of installing to the hard drive, with fully working config files and xboxrom.bin's (1 for .06 bios and 1 for .67 bios). now i think it can fully replace AID (i should double check, but its late).

Just a quick update:

So, I've now got:
- one-click* Kingroach and Krayzie** softmods working, with only the C partition reformatted regardless of the original softmod, and with 5960 restored before the softmod starts (similar to lxhdm)
(*apart from the "Are you sure" warnings and the extra keypresses for eeprom backup for Kingroach)
(**that's one-click up to the point that the Krayzie installer is launched )

- three step lxhdm (untested, but taken from a previously working version). Similar to bc54's version, but with the softmod install automated as part of the rebuild - exactly as per the original lxhdm process, but with the stock C files taken from CASH

- a troubleshooting section to help fix video / eeprom / shadowc problems

- Evox TSOP/chip flash, recent BIOSes only, with copying of config files and dash before flashing

- Winbond flash, recent BIOSes only, with copying of config files and dash before flashing (untested, but taken from a previous working fragment)

- a recipe for building the disc image (like LXHDM), so only the configs need to be downloaded

- a backdoor to all existing AID, CASH, Frosty's and Slayers functionality (which was where all this started - using Frosty to run CASH with shadow C bypassed!)


Still to do:
- unwanted eeprom rename to prevent eeprom mismatches. The process is sorted and working, but I'm struggling to find a definitive list of locations that Kingroach and Krayzie check when looking for an eeprom.bin to use as the virtual copy.

- a bit more testing on more Xboxes, especially on older softmods, and specifically on SID 2.0 (PBL) and SID 4.0-5.1, and on partially broken softmods.

- add in lots more error checking, in case files are missing or in case copying doesn't work, etc.

- add more in-line comments to the config

- try to find a Winbond flash process that requires fewer steps (this looks promising).

- polish the embedded instructions, and check them on a 4:3 screen.


Still thinking about:
- using xman954's eeprom dumper for the eeprom backup - requires one less click than using Evox, and gives total control over the name and location of the eeprom backup

- changing the disc logic so that the Kingroach install also populates the shadow C automatically in the same way that Krayzie does. Trouble is, to do that compromises one of the original design goals, of making a recovery disc that provides simple CASH-like repair functionality on all existing softmods (because you can't automate the Kingroach process AND boot PBL initially, which means that things like existing softmod video and eeprom problems can't be bypassed at initial boot). It also creates a potential problem with incomplete updates that's too long to describe here at the moment (I have to go to work in 5 minutes ), but I'll have a think about that while I'm driving.

Nkpatcher 8.1 comes with a driveimageutils and inside, there is a shadow C maker which remakes real C into a shadow C - sort of the reversal of the usual way shadow C is created nowadays in the softmod package.

Does this serve your purpose?

I am very impressed with the work you guys are doing. Keep up the good work! If I can help you all any way don't hesitate to ask.

@Heimdall and bc54, any updates on your progress? I'm looking forward to both of your finished products very eagerly.

Hit a couple of small snags (bugs) with UnleashX file handling within scripts. I think I now have them nailed - fingers crossed. I think I'm also having some problems with my DVD burner, which isn't helping - I can't easily tell the difference between a bug in the script and a bug in the DVD burn!

I'm also working through more robust error handling, and optimising the order things are done in to make it more failsafe.

With a bit of luck I'll be making the beta recipe and config files available later today, if not then it will be the weekend.

I'll post the UnleashX bugs and workrounds in the UnleashX section once I've finished and I'm sure it all works.

thats impressive heimdall. i cant wait to see how you put it all together

@ ldotsfan - hmm, i didnt know that people might be interested in my little home project. i never really intended for this to be a release type of thing, it was just meant as a more useful version of aid, but if you want me to realease it, i could do that. it really does everything i want right now, so i really don't have any intentions of maintaining it (unless i come up with some new ideas later), but if anyone out there wants it, i can set something up. just a warning, if i do release it, i haven't gotten around to testing everything (mainly stuff with g drive & softmod upgrades), so you know...

Yes, please release it. The little gem XMU you have come up with deserves that

@Heimdall: What are you going to call your disc?

ok, its on the net, just google XMU1.0 .
i have to say, i could probably fix some bugs for now, but i can't do any major maintaining for very long. i hope you all can understand.

Wow, looks you guys are having a lot of fun with this idea, I support it.

Just think of it, an all-in-one 'master disc' for the original XBOX... it gets the nerd in me all excited.

If you guys have any questions about the custom PBL and BIOS contained on my Rescue Disc, let me know, i'm happy to help.

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.

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)



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.

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

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.

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



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?

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....

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.

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

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!

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

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.



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.

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.....

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


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)