SaturnX

Just installed the OpenXenium in my 1.4 and my UDMA5 bios appears to work great using a StarTech adapter and WD Black 2TB drive. Will need to test further, but it boots and played a few games off the HDD. Everything seemed a little snappier in loading/transitions.

I'm totally cool with that! Your installers have been super helpful, and I really wanted to find a way to contribute The only thing is I would love to have some more testing done (especially on the non 1.6 bios) as I really don't want anyone to mess up their console if they TSOP flash. And/or please include a warning.... once my next Xenium arrives I'll be able to fiddle around more with my 1.4. I pieced this together fairly quickly after tracing back through the Titan code so in theory it should work as it's only a one byte change in the bios kernel - but you never know!

@oysterjetski @coldasijs - FYI. First off, I'm going to caution - USE THESE FILES AT YOUR OWN RISK! - ensure you have a way to recover your BIOS should the flash/UDMA setting impact the ability to boot off the HDD. I've modified the stock EvoxM8+ bios for 1.0-1.4 (EvoX.m8) and 1.6 (EvoX.m8.16) bios files to set the UDMA4 and UDMA5 flags in the bios Kernel - this is for HDDs 2TB and less. The intent here was to offer the ability to maintain my current HDD structure on my 2TB drive, while enabling UDMA4/5 speeds, keeping everything else constant. So in effect, this is simply the usual EvoxM8+ with F/G partitions with UDMA flags set - nothing more, nothing less. I also have the following boot order set for all of them, and all include the flubber animation, no Evox Logo, and no DVD drive check. DVD:\ default.xbe C:\evoxdash.xbe E:\evoxdash.xbe C:\xboxdash.xbe I have only tested the 1.6 bioses as I'm awaiting on an another OpenXenium to install in my TSOP'd 1.4 so I can test the others. I also have yet to do any benchmarking or detailed testing - I simply flashed and then attempted to boot into Halo, Halo 2, MechWarrior - all of which worked for me on my setup - using an IDE ATA133 (UDMA6) HDD. I have yet to test with my StarTech adapter, that''s on my to do list. Once again - use these at your own risk I take no responsibility if this bricks your Xbox. 1.0-1.4 Only: UDMA4: EvoX.m8.cec.67.noDVD.noLogo.UDMA4.256.bin UDMA5: EvoX.m8.cec.67.noDVD.noLogo.UDMA5.256.bin 1.6/1.6b Only: UDMA4: EvoX.m8.16.CEC.fg.67.noDVD.noLogo.UDMA4.256.bin UDMA5: EvoX.m8.16.CEC.fg.67.noDVD.noLogo.UDMA5.256.bin Hope this helps and if anyone can support in testing, that would be awesome!

Good to know! I've just built/packed two new M8Plus 1.6 BIOSes with the bytes changed for UDMA4/UDMA5. I'll give it a go on my 1.6/OpenXenium later to see what happens. One other question, but I guess I'll get the answer when I test - I also have an old Maxtor DiamondMax Plus 9 IDE HDD that is rated for ATA133 (UDMA6) that I've setup as quick test HDD for OG Xbox mods. I would assume by taking the SATA/IDE controller out of the equation, given the HDD is capable of ATA133, and using an 80-wire/40-pin cable, I should in theory be able to use UDMA5 without issue.

Hmm... just looking through the code, unfortunately my Python skills are not as honed as I'd like... but reading through the following section and working through the additional routines, and my understanding is that I need to unpack the Kernel .IMG via EvTool, and make the following changes and repack. Hex Address (unpacked kernel.img) 0x000453FF: UDMA2: 0x42 (Stock - which follows the convention/code below so instills confidence in deciphering the code). UDMA3: 0x43 UDMA4: 0x44 UDMA5: 0x45 if self._udma > 2: patch_address = 0x800553FE print(f"[*] - 0x{patch_address:08X}: Patching UDMA to version {self._udma}") patch_bytes = self._assemble(f"push 0x{0x40+self._udma:02X}", patch_address) self._write_bytes(patch_bytes, patch_address) Source: titan/tpatch.py at main · gaasedelen/titan · GitHub @KaosEngineer if you have any thoughts/insight that would be greatly appreciated. Thanks again!

I’ll take a look - I’ve got a StarTech adapter and OpenXenium - figure I can give it a go and see how it performs.

Oh that’s amazing!! Are you aware of where that byte is / and is it detailed anywhere? Thanks!

@KaosEngineer So apologies for what seems to be a stupid question... but I've got a 2TB drive formatted with F/G (927GB each) - that means I cannot use the Titan patches to enable higher UDMA speeds? If so, doesn't that mean that essentially anyone who had previously set up a 2TB drive wouldn't be able to utilize the Titan patches without re-formatting? I had originally formatted the drive w/ XBPartitioner 1.3 (with proper cluster sizes, and no ER) when initially setting up the drive a while back.

Just a quick update and in case anyone is in the same boat as I am - everything went smoothly with updating to 2.3.5 with the following steps. 1. Flashed a “Raw 2MB Flash Dump” of XOS2.3.1 provided by @KaosEngineer in the thread linked above (not from the TruHexen Installer) using the latest release of Xenium Tools Note: After flashing, my system LEDs pulsed amber several times then stopped on red. I was a little concerned at first, let it sit then powered it down. Upon powering back up, I was greeted with the fresh XOS2.3.1 message, so all went well! 2. Grabbed the latest MakeMHz XeniumOS (2.3.5 at the time of posting) - followed the instructions provided (copy over recovery.bin to E:\ and run the updater xbe) The updater detected the correct XOS version and proceeded to update the OS and Bootloader. Reboot when done! 3. Enjoy the v1.6 without any component video issues when in XeniumOS

Excellent - finally had a moment to sit down and do a more detailed compare, running the MD5 checksums on the block range 100000-1FBFFF is exactly the same between your dump and the TruHexen dump. Further the CRC32 of your dump/TruHexen match the expected CRCs checked against the MakeMHz updater for the XeniumOS block (0x100000-0x17FFFF) and the expected Bootloader block (0x180000-0x1BFFFF). I won't bother digging any further, I'll go ahead and flash over your dump and then proceed with the upgrade to the Unofficial 2.3.5 from MakeMhz. Thanks for the help!

@KaosEngineer so I did a super quick hex compare between the TruHexen flash.bin and the dump you provided. Seems like the following is the case: 00000000-000FFFFF - different (first 1MB is stored bioses, so to be expected) 001FC000-001FFFFF - different (non-volatile settings, so to be expected) The remaining content appears to be same across both dumps, so I guess that leads me to believe I’m good to flash either.

I had a feeling that was the case - just a question regarding the use of Xenium-Tools - so I select the “Write a 2.3.1 OS Update” or “Write a raw flash .bin”? Also would the link you posted be different from the Xbins version of XeniumOS 2.3.1 (which is the recovery.bin) Thanks again! I feel like I’m being overly cautious… really just don’t want to mess this up.

Hey everyone! Not new to the OG Xbox scene, but am new to using OpenXenium chips. I’ve just done an install on my Crystal 1.6 - rebuilt LPC with a Chimeric Systems QSB - and everything is working fine. However, I’m trying to update to the “unofficial” MakeMHz XeniumOS to address the “lines” issue when using component out on a 1.6. When I attempt to use the MakeMHz updater tool, it throws back the error: ”Unknown XeniumOS Detected” The supplier that I got my chip from seems to have loaded the XeniumGold OS 2.3.1 - as when I boot into XeniumOS I have a “Xenium 24k Gold” skin. How would I go about reinstalling XeniumOS 2.3.1 (as per the recommendation on the MakeMHz GitHub) so that I can update to 2.3.5? I’m sure this is a stupid/noob question - but just wanted to be sure so I don’t brick/soft brick the chip. Thanks for the help!

Thank you @sweetdarkdestiny downloading now.

Yeah it’s really strange, it’s almost as if when it tried to unzip the necessary packages (stock dash) it wasn’t able to extract all the files. Some were there (root of C), but I was missing all of the sub folders and most of the Audio folders/files. I know the HDD is good - did a full sector scan before using it, and using the 80-pin cable from Chimeric Systems with a StarTech IDE/SATA adapter (jumper set to Cable Select) It’s really strange. Yep! I’ve already extracted it using extract-xiso and grabbing the other files I need