KaosEngineer

Not that it matters now, but when cloning, did you use the Selective Cloning option in Chimp? Was the original hard drive a stock 8GB drive or an already larger updated drive? How is your Xbox modded: soft or hard mod?

The stock dashboard files, IIRC, must all go on the C drive. Not on another drive letter or even in a Apps subfolder on C. Install the content in the root directory of the C drive. There will be subfolders of the stock dashboard on the C drive.

To create a properfly formatted version for a game's XISO disc image, run the XISO to HDD Installer script in XBMC4Gamers. Upload the XISO files to the Games folder on your Xbox, run the script. It will prompt you for the source folder of the disc images. It then moves each to a game named subfolder and places the attach app named default.xbe file in each subfolder.

Try a known working OEM / Microsoft controller.

Ignore the error about unsupported modchip. All of the XBlast OS's features are only supported on an XBlast Lite or Pro modchip. That's the reason it prints that message, you are not running it on a modchip that supports all of its features.

The HDDKey is not saved on the hard drive. It is stored in an 8-pin serial EEPROM on the motherboard. There are several methods available to read the data from this chip. Arduino and one of several sketches available on github.com Raspberry Pi and PiPROM software PC with a 9-pin serial port, DIY Xbox EEPROM reader/write cable and PonyProg software just to name a few methods. Each unmodded Xbox console's HDDKey value is unique to it. And, the password used to lock the hard drive is computed using it along with the hard drives model and serial number which makes the password unique for each different hard drive too. Edit: If you have the eeprom.bin backup from the Xbox, you can use FATXplorer 3.0 beta or XBOXHDM23USB Beta 3 to unlock the hard drive.

No problem downloading it here.

IIRC, they also have a different MCPX chip v2 instead of the retail unit's v3 version.

Is it default_720p.xbe or something similar? If so, rename it to default.xbe for the game to appear in the Games menu list.

yes you need both Xboxs' eeprom.bin files. Unlock the current softmodded HDD with the 1.6 Xbox's eeprom.bin then use the unmodded Japanese Xbox's eeprom.bin to relock it for that Xbox. It's not the password that you are obtaining within the eeprom.bin file but an encryption key that along with the hard drive's model and serial number computes the correct password to lock the hard drive.

To do the HDD Flash, you need to create the BIOS folder on the real C drive of a softmodded console. If you softmodding using Rocky5's Xbox Softmodding Tool, run NKPatcher Settings then FTP to the console to have access to the real C drive to create the BIOS subfolder and upload the bios's .bin file to.

All stock Xbox BIOSes and most modified Xbox BIOSes are only 256 KBs in size. Microsoft (MS) installed a 1MB flash chip on v1.0 and v1.1 motherboards and Evox dumps the entire flash memory chip - 4 copies of the same BIOS. And, with v1.2 and later motherboards MS changed the flash memory chip to 256KBs; however, the replacement dashboard's backup routine did not change and the same chip is accessed 4 times to dump a 1MB file too. This occurs because the memory address decoding is incomplete throughout the entire 16MBs of memory space MS allocated for the TSOP. For a v1.0 or v1.1s 1MB flash, it can be accessed at 16 different evenly divisible 1MB addresses throughout this space to dump the 1MB flash memory chip. And for v1.2-1.4s, the 256KB flash can be accessed at 64 different 256KB starting addresses to dump the same data. If the BIOS's base size is 256KBs, you can split the file into 4 256KB sections one after the other to obtain 4 copies of the same BIOS.

From the ScummVM-1.4.1.rar archive's README-XBOX.txt file, available from emuxtras.net's Download section [XBOX] - Emulators: ScummVM 1.4.1 ported by A600 This is a ScummVM port for the Xbox1, possible thanks to the hard work of the ScummVM team and the SDLx libs by Lantus. It features all the 1.4.1 supported engines, MP3, Vorbis, Flac, AAC and FluidSynth (the MT-32 emu isn't included because the Xbox lacks the power to handle it). All HQ scalers should work. The file xbox.patch is the diff patch against the 1.4.1 branch https://github.com/scummvm/scummvm.git

Didn't the first level boot loader and decoding key and algorithm change between a v1.2 and 1.4 motherboards? Or was that just v1.0 to later revs then again with v1.6 motherboards. 512 bytes of code are stored in a permanent masked ROM that is part of the MCPX3 chip. It contains the first-stage boot loader (1BL) , decryption algorithm of the second-stage boot loader (2BL) decryption key(s), and X-code interpreter. For more about the boot process of the Xbox read Matt Borgerson's archived write-up available on archive.org's Wayback Machine: https://web.archive.org/web/20220518102811/https://mborgerson.com/deconstructing-the-xbox-boot-rom/ Edit: Excerpt from Microsoft's Copilot's reply when queried aboiut deconstructing the xbox boot rom: Certainly! Let’s delve into the fascinating world of the Xbox boot ROM. Xbox Boot ROM (MCPX): The Xbox has a 256 kiB ROM that contains the startup animation, sound, and crucial components like the kernel. The kernel is a stripped-down version of the Windows 2000 (NT 5.0) microkernel. When you power on the Xbox, the software in the ROM is decompressed into RAM, and the kernel initializes the hardware1. (Reference: Boot Process - xboxdevwiki) MCPX Versions: There are two known versions of the MCPX ROM: 1.0 and 1.1. The 1.0 version, found in the original Xbox, used an RC4 algorithm to decrypt the 2BL (second bootloader). For the 1.1 version, Microsoft switched to a TEA algorithm2. (Reference: MCPX ROM - xboxdevwiki) From the information provided above, one would think that a v1.1 or later motherboard rev's MCPX3 would work on any v1.1 or later motherboard.

I agree with @Bowlsnapper. If it does this at startup, the chip needs to be replaced. The System Management Controller (SMC) - the PIC processor on v1.0-1.4 motherboards or Xyclops chip on v1.6s - handles the overheating condition at a hardware level. It flashes the eject ring LED orange and spins the fan(s) up to max speed to cool the system. If the temperature reading does not go down the SMC shuts off the console. The front panel buttons do not respond after the overheating condition has been sensed by the SMC. Edit: A damaged trace from the CPU's temp diode to the ADM1032 temp sensor or from the sensor to the SMC could cause a false overheating condition to be sensed. As well, leaked clock cap electrolyte under the chip that cannot easily be cleaned without removing the chip could cause the error to occur.