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

Yeah I’m not sure why it didn’t work - I’m wondering if my burn wasn’t good or if my drive is on its way out. I've just copied over everything from your new download to the C and E drives. Will give it a go soon. Thanks so much for all the help and support on this!

Thanks @SS_Dave! That’s exactly what I’m doing right now with FatXplorer to copy things over.

@phrunt So checked out my HDD with FatXplorer and as expected, most of the stock dash files (and others) were missing. Guess only a handful of files copied over from the HDD during the AiO setup. Once again pointing my to drive or the burned disc. I’m just copying over the files from @sweetdarkdestiny’s latest download for FatXplorer/HDM users, and I’m hoping all should be good! Another follow up - what would be the best way to flash any new bios versions on my v1.4 TSOP knowing my drive is temperamental with reading?

Yeah I was just dissecting the scripts within the OGXbox Installer to see what happens when you set a default dash, etc.. I may just toss the HDD into my SATA/USB adapter and copy over with FATXplorer. I'm wondering if the reason I'm having issues with the disc is that my drive doesn't like continued access (i.e. it gets tired haha) - given that everything *seemed* to go well with the initial copy during the AiO HDD setup, I had figured it was all good. I'll let the console rest for a bit and come back later.

@sweetdarkdestiny So it seems this did the trick! I formatted with FatXplorer then was able to boot the new drive with the Installer! I did the AIO Setup for the new large hdd After copying everything over, it brought me to XBPartitioner I reduced both F/G partitions by 2GB, formatted them (~925MB) After I quit XBPartitioner it appears to have been caught in a bit of boot loop for the Installer? Not sure if this was my dvd drive acting up or not and was unable to read the disc, it just kept showing the "Loading" screen then went black, then "Loading". I power cycled, and without the installer disc it booted into xmbc4xbox (I'm assuming since my current bios first tries evoXdash.xbe) Ran XBPartioner1.3 from E:\Apps and increased the size of the two partitions (F/G) to 927MB and formatted. Just for fun I tried to launch the stock dashboard from the File Manager in xbmc4xbox: C:\xboxdash.xbe When I tried to do that, i was given Error 21? So it seems I'm marking progress... got two things to figure out now: Need to set my default dash to XMBC4Gamers Find out why it errored out trying to boot the stock dash?

So I'm starting to think it may be my dvd drive (Thomson) and the burned media (Verbatim DVD-R). It's almost as if times out during the boot sequence with the new bios as it can't boot/read the default.xbe fast enough. I didn't seem to have any issues with reading burned media while softmodded since I was booting it from the UnleashX dash, but it almost appears as it can't read it fast enough during the boot sequence. Just to go through a process of elimination, I kept my stock HDD (softmod) and swapped in the 80-pin cable and after two tries, I was able to boot the Installer so now I know the cable is good. I'm going to try swapping in the blank HDD again to see if I can get it boot again. @sweetdarkdestiny My first step is get the new HDD and dash setup, but I was wondering if there was any way to get the "flubber" animation back during boot? I've currently got "EvoX.m8.cee.67.noDVD.X4G.256.bin" flashed which just shows the blue "X" on boot, but would love to get the class flubber back. I like the blue "x" to show it's modded, but adding the flubber would be nice.

@sweetdarkdestiny Thanks! I’ll try this first - my HDD is also completely brand new and no file system has been initialized on it, not sure if that is contributing to the issues @phrunt Yep - using an 80pin cable from Chimeric Systems along with a StarTech IDE > SATA adapter. Thanks for all the support! I’ll report back with how things go. Im truly thankful this community is still so active

I had thought about that - however prior to the TSOP flash, I didn’t have any issues reading burned discs. Whether it was a fluke coincidence, I’m not sure.

Thanks so much @SS_Dave I’ll give that a go and report back. This might be a silly question, but after using FATXplorer, will that take care of formatting the F/G partitions? Or would I need to run XBPartioner? Thanks for the help!!

Ok - just a quick update. I was finally able to boot the installer again with my stock HDD attached. I just stepped away and decided to give it a go a few hours later and it managed to boot off the installer disc which was promising. This is where I need some support - as of right now my stock HDD still has the softmod files on it. I haven't tried booting into the dash again yet as I don't believe it'll work since I flashed the X4G bios. The only thing I did prior to this was softmod with Rocky's v1.1.8 (which installed UnleashX). This is where I need some help... TSOP BIOS: Evox m8+ CEE 67 noDVD (X4G) 256kb According to the Installer I have the following space free: C : 0.73MB E: 4,783MB I want to set up my new (blank HDD) however when I last tried to replace it I was met with Error 16. Could anyone let me know what steps I should take to make this happen? I was really disheartened when the system would lock up at the Blue "X" logo, but I'm happy I was able to boot up the installer again with my stock HDD. Thanks for the help!!