Mu.

Locking/unlocking the drive has absolutely nothing to do with the BIOS you're using, but Cerbios (like any other respectable custom BIOS) will ignore whether the HDD is locked or not.

Supporting Insignia simply involves not blocking Xbox Live access. It was necessary for custom BIOS users back before it was shut down but not anymore, so I'm certain it'll work. And besides, supporting Insignia requires absolutely zero work on Cerbios' part.

Nope, adding the fanSpeed line doesn't seem to have done anything. I'm guessing it hasn't been included yet in any fashion.

Is there a way I can brute force the fan speed via hex editing or something until a new version arrives? I'd be using this if it wasn't for a lack of fan speed adjustment.

I feel as though I'm missing something when trying this myself. I'll go through the whole process but my console will just relaunch the dashboard (XBMC4G) and not boot the game at all. I'm using a supposed XISO supported version of ind-bios 5003.

XBlastOS can flash it from either your HDD (c:\BIOS), or over your network via a webserver.

The metal shielding is there to comply with regulations such as those laid out by the FCC in the US for transmission of RF signals coming from the console, rather than taking in anything of the sort. Removing it won't make a difference unless if you're running some extremely sensitive and unshielded equipment close by.

Hypothetically you could perform such a mod and have the hard drive continue to work afterwards for an indeterminate amount of time, ideally you would have prepared another top piece with the window already installed and ready to go so you don't have the internals exposed any longer than necessary. Based on a tiny amount of second-hand anecdotal evidence (namely the video 'Can a hard drive breathe regular air like us' by Cathode Ray Dude), I'm sure you could do it and have a working drive afterwards... Just don't leave any super important and irreplaceable files on the drive.

Eaton mentioned on Reddit that support was coming in the new week or so, check r/originalxbox.

Just flashed my 1.2 with it, it's definitely a BIOS alright!

Guess I'll just have to build up one of the Jafar PCBs I bought if it ends up being >256kb lol

I think the search terms you're looking for are "AWM 20624 Ribbon Flex", there should be plenty of sellers on eBay and AliExpress that have 20 pin variants in many different lengths. No sense in scavenging something like this from another drive when it's a standardized part.

Sounds good, I can see it easily being a 512kb BIOS which will make TSOP users like myself a little upset.

I had good luck in the past using an Aladdin XT2+ with the m7 tsop recovery BIOS flashed to it, of course you'd need to boot the Xbox with the chip in order to program said m7 BIOS onto it or do it externally via a device like the TL866.

Great design, I had one printed several months back for extra security with using my StarTech adapter. I'll be sure to grab another at some point.

Using a softmod with 128MB of memory sounds a little unusual to me. I was under the impression that a custom bios was required. Perhaps their softmod solution loads some kind of compatible BFM bios as part of its startup routine.

If you have a modchip (and thus a custom bios) installed, you can simply install the hard disk, format it using a disc like OGXbox Installer 2021 and install whatever software you need.

The initial problem that caused this whole thing has been sorted out. I desoldered the EEPROM chip from the console, read its content using a CH341a programmer and then locked the hard disk using XboxHDM2.3. As for the modchip I'm really not sure what went wrong, the only thing I've yet to try it putting it in my main 1.2.

I'd used an OpenXenium in the past so I knew to give that a try, but it didn't seem to change anything. At this point I'm really not sure what it could be.

I flowed each and every pin on both the header and the chip with plenty of flux and extra solder where necessary but nope, I'm still getting the ol' 3-boot FRAG.

It's fitted to the pins closest to the front of the console (leaving two at the back), I'll be sure to scrub it and take another photo for you. And yeah, the LED lights up red.

Unfortunately disconnecting D0 or the modchip from its header just causes it to properly boot into the TSOP's own BIOS like normal. Plus this is happening with the original IDE cable completely removed as well as with it installed so I'm not sure if that's making a difference at this point. As asked before I have some closeup photos of my soldering both on the chip and the point under the board (hopefully the orientation is clear).

I made the boneheaded mistake of flashing my backup 1.2's TSOP chip with a retail BIOS while the hard disk was unlocked. I ended up purchasing an OpenXenium that was pulled from another console (evidently a 1.6 based on the use of the 1.6 jumper). After installing the pin header and connecting D0 to the chip on the underside of the board (I found continuity between the pad on the chip and the topside via for D0) I found that the console wouldn't boot. It was the typical 3 boot attempts before a 50:50 FRAG. I'm unsure as to why this is happening, it was previously used which leads me to believe it was working just fine in the console it came from. The only thing I've yet to try is to install it into my main 1.2 and see if it has the same problem there, and if so, I can figure out if the CPLD needs reprogramming and the flash chip needs XeniumOS reflashed. Has anyone else had an issue like this with their OpenXenium?

I found myself using double sided tape, though it didn't end up lasting very long. I eventually replaced them with a set of 3D printed feet (https://www.thingiverse.com/thing:4725922)

I'd suggest using a different dash than Avalaunch, either XBMC or UnleashX.