xboxdevwiki - User contributions [en]

Xyclops

2025-12-28T21:11:25Z

Prehistoricman: /* Internal registers */ Add reg 0xAA

The [[SMC]] on v1.6 Xboxes is a custom chip called Xyclops. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

== Processor core ==
The embedded microcontroller that supports SMC functions is an 8051 core.

== Debug serial protocol ==

9600 baud UART, enabled by setting the DEBUG pin (pin 29) high. Baud can be changed by writing to a register. The very first byte sent will cause Xyclops to enter debug mode where normal SMC operations are paused.

The protocol is based on 4-byte or 67-byte commands.
# Byte 0 is the opcode. Bit 0 is often controlling a destination.
# Bytes 1 - 2 are the address. The most significant byte is sent first. Commands that don't address memory will ignore this.
# Byte 3 is the payload byte, or the first byte of the 64-byte payload for some commands.

Each command will produce a response of at least 2 bytes.
# Byte 0 is the echo of the command byte, or 0x4B if the command is not accepted.
# Byte 1 is the response payload
# Bytes 2 - 64 are the rest of the payload for commands that respond with 64 bytes of data.

=== Opcodes ===

SFR = Special Function Register

{|class="wikitable"
|-
!Opcode (hex)!!Length!!Response length!!Purpose
|-
|00 and 01||4||2||Read 1 byte of RAM
|-
|02 and 03||4||2||Write 1 byte to RAM
|-
|04 and 05||4||65||Read 1 byte of RAM 64 times (yes, really)
|-
|06 and 07||67||2||64-byte to something, possibly RAM.
|-
|08 and 09||4||2||Duplicate of 00
|-
|0A and 0B||4||2||Duplicate of 02
|-
|0C and 0D||4||65||Duplicate of 04
|-
|0E and 0F||67||2||Duplicate of 06
|-
|10||4||2||Read 1 byte from the BIOS flash
|-
|11||4||2||Read 1 byte from the SMC flash
|-
|12||4||2||Program 1 byte of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|13||4||2||Program 1 byte of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|14||4||65||Read 64 bytes of BIOS flash
|-
|15||4||65||Read 64 bytes of SMC flash
|-
|16||67||2||Program 64 bytes of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|17||67||2||Program 64 bytes of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|18 and 19||4||2||Read 1 byte from spare sector 0 or 1
|-
|1A and 1B||4||2||Program 1 byte of spare sector 0 or 1. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 2KiB or 0.5KiB memory space.
|-
|1C and 1D||4||65||Read 64 bytes from spare sector 0 or 1
|-
|1E and 1F||67||2||Program 64 bytes of spare sector 0 or 1
|-
|20 and 21||4||2||Read 1 byte of RAM/SFRs
|-
|22 and 23||4||2||Write 1 byte to RAM/SFRs
|-
|24 and 25||4||65||Read 1 byte of RAM/SFRs 64 times
|-
|26 and 27||?||?||Possibly broken write of 64 bytes to RAM/SFRs
|-
|28 and 29||4||2||Duplicate of 20 and 21
|-
|2A and 2B||4||2||Duplicate of 22 and 23
|-
|2C and 2D||4||65||Duplicate of 24 and 25
|-
|2E and 2F||?||?||Assumed to be duplicate of 26
|-
| --- || --- || --- || ---
|-
|30 to 3F|| - || - ||Similar to 10 - 1F, but the data read is always 00. Write attempts with opcode 0x32 are always rejected.
|-
| --- || --- || --- || ---
|-
|40||4||4 or 6||Exits and re-enters debug mode
|-
|41||4||2||Exits debug mode and locks programming
|-
|42||4||2||Exits debug mode and locks programming
|-
|43||4||2||Unlocks programming and erasing flash
|-
|48 - 4A||4||2||Not sure, appears to do nothing.
|-
| --- || --- || --- || ---
|-
|80||4||2||Sector erase BIOS flash. Sectors are 0x800 bytes.
|-
|81||4||2||Sector erase SMC flash. Sectors are 0x200 bytes.
|-
|84||4||2||Mass erase BIOS flash. Takes about 350ms.
|-
|85||4||2||Mass erase SMC flash. Takes about 350ms.
|-
|88||4||2||Erase spare sector 0 (0x200 bytes)
|-
|89||4||2||Erase spare sector 1 (0x80 bytes)
|-
|8C||4||2||Erase spare sector 0
|-
|8D||4||2||Erase spare sector 1
|}

== Xyclops memory spaces ==

* 128-byte RAM (could be 256)
** Upper 128 bytes read out as semi-random values. The 8051 core would need a bank select to naturally access them.
* 16KiB SMC flash
* 1KiB SMC debug ROM (at address 0xFC00 in the SMC flash space)
* 256KiB BIOS flash (4 banks)
** Bank selected by register 0x91
* 512-byte spare sector 0
* 128-byte spare sector 1
* 256-byte mixed RAM+SFR space (first 128 is RAM, second 128 is SFRs)

== Internal registers ==

{| class="wikitable"
|-
!Address (hex)!!Purpose
|-
|80||Port 0 output value (write) and input value (read)
|-
|90||Port 1 output value (write) and input value (read)
|-
|91||BIOS flash bank select. 0 - 3 for 256KiB.
|-
|9D||Port 0 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9E||Port 1 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9F||Port 2 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|A0||Port 2 output value (write) and input value (read)
|-
|AA||Audio (AC97 and I2S) enable. 1 = enabled. 0 = disabled.
|-
|B0||Port 0 tristate. 0 = output on. 1 = floating.
|-
|C0||Port 1 tristate. 0 = output on. 1 = floating.
|-
|D1||Fan PWM duty cycle or fan DAC level. 0xFF = fan off. 0 = fan full speed.
|-
|D2 - D5||Scratch spaced used by the serial debug ROM
|-
|D6 - D7||SMBus related
|-
|D6 - D7||SMBus related
|-
|D8||Port 2 tristate. 0 = output on. 1 = floating.
|-
|D9 - DE||SMBus related
|-
|E9||Debug serial baud control. Higher value = faster serial. 0xB0 = 9600. 0xEC = 38400 baud
|-
|EC||Flash program/erase control. Bits 3:0 determine the flash region to target. Bits 7:5 control the kind of operation. Bit 4 starts the operation.
|-
|EF||Scratch spaced used by the serial debug ROM
|-
|F1 - F4||Scratch spaced used by the serial debug ROM
|}

== GPIO mapping ==

{| class="wikitable"
|-
!GPIO port.pin!!Pin number!!GPIO pin name!!Notes
|-
|P0.0 || 59 || AUD_CLAMP ||
|-
|P0.1 || 7 || EJTSW ||
|-
|P0.2 || 6 || POWSW ||
|-
|P0.3 || 28 || PSUON ||
|-
|P0.4 || 13 || VREGON ||
|-
|P0.5 || 26 || VPLLON ||
|-
|P0.6 || 32 || GPIO/FANOUT || FANOUT does not operate unless P0.6 is set high (regardless of open-drain/tri-state mode).
|-
|P0.7 || 33 || RTCACTIVE ||
|-
|P1.0 || 5 || DVDEJECT ||
|-
|P1.1 || 40 || XCALRESET* ||
|-
|P1.2 || 35 || SCL ||
|-
|P1.3 || 34 || SDA ||
|-
|P1.4 || 65 || SMI* ||
|-
|P1.5 || 41 || SYSRESET* ||
|-
|P1.6 || 11 || LEDGRN* ||
|-
|P1.7 || 12 || LEDRED* ||
|-
|P2.0 || 14 || PSUGD ||
|-
|P2.1 || 27 || VREGGD ||
|-
|P2.2 || 42 || VMODE<0> ||
|-
|P2.3 || 43 || VMODE<1> ||
|-
|P2.4 || 44 || VMODE<2> ||
|-
|P2.5 || 62 || TRAYSTATE<0> ||
|-
|P2.6 || 61 || TRAYSTATE<1> ||
|-
|P2.7 || 60 || TRAYSTATE<2> ||
|}

== Revisions ==

Known revisions are:
* Unlabelled - prototypes
* A-A02 - flashable
* A-B01 - not flashable

The die and bonding of A-B01 looks identical to A-A02, so it is not currently understood what prevents it from being flashed. The program and erase commands still execute successfully but don't produce any change in memory contents.

Xyclops

2025-12-28T18:18:52Z

Prehistoricman:

The [[SMC]] on v1.6 Xboxes is a custom chip called Xyclops. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

== Processor core ==
The embedded microcontroller that supports SMC functions is an 8051 core.

== Debug serial protocol ==

9600 baud UART, enabled by setting the DEBUG pin (pin 29) high. Baud can be changed by writing to a register. The very first byte sent will cause Xyclops to enter debug mode where normal SMC operations are paused.

The protocol is based on 4-byte or 67-byte commands.
# Byte 0 is the opcode. Bit 0 is often controlling a destination.
# Bytes 1 - 2 are the address. The most significant byte is sent first. Commands that don't address memory will ignore this.
# Byte 3 is the payload byte, or the first byte of the 64-byte payload for some commands.

Each command will produce a response of at least 2 bytes.
# Byte 0 is the echo of the command byte, or 0x4B if the command is not accepted.
# Byte 1 is the response payload
# Bytes 2 - 64 are the rest of the payload for commands that respond with 64 bytes of data.

=== Opcodes ===

SFR = Special Function Register

{|class="wikitable"
|-
!Opcode (hex)!!Length!!Response length!!Purpose
|-
|00 and 01||4||2||Read 1 byte of RAM
|-
|02 and 03||4||2||Write 1 byte to RAM
|-
|04 and 05||4||65||Read 1 byte of RAM 64 times (yes, really)
|-
|06 and 07||67||2||64-byte to something, possibly RAM.
|-
|08 and 09||4||2||Duplicate of 00
|-
|0A and 0B||4||2||Duplicate of 02
|-
|0C and 0D||4||65||Duplicate of 04
|-
|0E and 0F||67||2||Duplicate of 06
|-
|10||4||2||Read 1 byte from the BIOS flash
|-
|11||4||2||Read 1 byte from the SMC flash
|-
|12||4||2||Program 1 byte of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|13||4||2||Program 1 byte of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|14||4||65||Read 64 bytes of BIOS flash
|-
|15||4||65||Read 64 bytes of SMC flash
|-
|16||67||2||Program 64 bytes of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|17||67||2||Program 64 bytes of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|18 and 19||4||2||Read 1 byte from spare sector 0 or 1
|-
|1A and 1B||4||2||Program 1 byte of spare sector 0 or 1. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 2KiB or 0.5KiB memory space.
|-
|1C and 1D||4||65||Read 64 bytes from spare sector 0 or 1
|-
|1E and 1F||67||2||Program 64 bytes of spare sector 0 or 1
|-
|20 and 21||4||2||Read 1 byte of RAM/SFRs
|-
|22 and 23||4||2||Write 1 byte to RAM/SFRs
|-
|24 and 25||4||65||Read 1 byte of RAM/SFRs 64 times
|-
|26 and 27||?||?||Possibly broken write of 64 bytes to RAM/SFRs
|-
|28 and 29||4||2||Duplicate of 20 and 21
|-
|2A and 2B||4||2||Duplicate of 22 and 23
|-
|2C and 2D||4||65||Duplicate of 24 and 25
|-
|2E and 2F||?||?||Assumed to be duplicate of 26
|-
| --- || --- || --- || ---
|-
|30 to 3F|| - || - ||Similar to 10 - 1F, but the data read is always 00. Write attempts with opcode 0x32 are always rejected.
|-
| --- || --- || --- || ---
|-
|40||4||4 or 6||Exits and re-enters debug mode
|-
|41||4||2||Exits debug mode and locks programming
|-
|42||4||2||Exits debug mode and locks programming
|-
|43||4||2||Unlocks programming and erasing flash
|-
|48 - 4A||4||2||Not sure, appears to do nothing.
|-
| --- || --- || --- || ---
|-
|80||4||2||Sector erase BIOS flash. Sectors are 0x800 bytes.
|-
|81||4||2||Sector erase SMC flash. Sectors are 0x200 bytes.
|-
|84||4||2||Mass erase BIOS flash. Takes about 350ms.
|-
|85||4||2||Mass erase SMC flash. Takes about 350ms.
|-
|88||4||2||Erase spare sector 0 (0x200 bytes)
|-
|89||4||2||Erase spare sector 1 (0x80 bytes)
|-
|8C||4||2||Erase spare sector 0
|-
|8D||4||2||Erase spare sector 1
|}

== Xyclops memory spaces ==

* 128-byte RAM (could be 256)
** Upper 128 bytes read out as semi-random values. The 8051 core would need a bank select to naturally access them.
* 16KiB SMC flash
* 1KiB SMC debug ROM (at address 0xFC00 in the SMC flash space)
* 256KiB BIOS flash (4 banks)
** Bank selected by register 0x91
* 512-byte spare sector 0
* 128-byte spare sector 1
* 256-byte mixed RAM+SFR space (first 128 is RAM, second 128 is SFRs)

== Internal registers ==

{| class="wikitable"
|-
!Address (hex)!!Purpose
|-
|80||Port 0 output value (write) and input value (read)
|-
|90||Port 1 output value (write) and input value (read)
|-
|91||BIOS flash bank select. 0 - 3 for 256KiB.
|-
|9D||Port 0 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9E||Port 1 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9F||Port 2 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|A0||Port 2 output value (write) and input value (read)
|-
|B0||Port 0 tristate. 0 = output on. 1 = floating.
|-
|C0||Port 1 tristate. 0 = output on. 1 = floating.
|-
|D1||Fan PWM duty cycle or fan DAC level. 0xFF = fan off. 0 = fan full speed.
|-
|D2 - D5||Scratch spaced used by the serial debug ROM
|-
|D6 - D7||SMBus related
|-
|D6 - D7||SMBus related
|-
|D8||Port 2 tristate. 0 = output on. 1 = floating.
|-
|D9 - DE||SMBus related
|-
|E9||Debug serial baud control. Higher value = faster serial. 0xB0 = 9600. 0xEC = 38400 baud
|-
|EC||Flash program/erase control. Bits 3:0 determine the flash region to target. Bits 7:5 control the kind of operation. Bit 4 starts the operation.
|-
|EF||Scratch spaced used by the serial debug ROM
|-
|F1 - F4||Scratch spaced used by the serial debug ROM
|}

== GPIO mapping ==

{| class="wikitable"
|-
!GPIO port.pin!!Pin number!!GPIO pin name!!Notes
|-
|P0.0 || 59 || AUD_CLAMP ||
|-
|P0.1 || 7 || EJTSW ||
|-
|P0.2 || 6 || POWSW ||
|-
|P0.3 || 28 || PSUON ||
|-
|P0.4 || 13 || VREGON ||
|-
|P0.5 || 26 || VPLLON ||
|-
|P0.6 || 32 || GPIO/FANOUT || FANOUT does not operate unless P0.6 is set high (regardless of open-drain/tri-state mode).
|-
|P0.7 || 33 || RTCACTIVE ||
|-
|P1.0 || 5 || DVDEJECT ||
|-
|P1.1 || 40 || XCALRESET* ||
|-
|P1.2 || 35 || SCL ||
|-
|P1.3 || 34 || SDA ||
|-
|P1.4 || 65 || SMI* ||
|-
|P1.5 || 41 || SYSRESET* ||
|-
|P1.6 || 11 || LEDGRN* ||
|-
|P1.7 || 12 || LEDRED* ||
|-
|P2.0 || 14 || PSUGD ||
|-
|P2.1 || 27 || VREGGD ||
|-
|P2.2 || 42 || VMODE<0> ||
|-
|P2.3 || 43 || VMODE<1> ||
|-
|P2.4 || 44 || VMODE<2> ||
|-
|P2.5 || 62 || TRAYSTATE<0> ||
|-
|P2.6 || 61 || TRAYSTATE<1> ||
|-
|P2.7 || 60 || TRAYSTATE<2> ||
|}

== Revisions ==

Known revisions are:
* Unlabelled - prototypes
* A-A02 - flashable
* A-B01 - not flashable

The die and bonding of A-B01 looks identical to A-A02, so it is not currently understood what prevents it from being flashed. The program and erase commands still execute successfully but don't produce any change in memory contents.

Memory

2025-08-12T15:43:34Z

Prehistoricman: /* I/O port map */ Add modchip IO port information

The Xbox has 64MB Memory. This could be expanded to 128MB of memory on boards of revision 1.0-1.4 (Boards of revision 1.0-1.4 have empty spots for the extra memory, but they were later removed on 1.6 boards) but no games took advantage of it. The debug Xbox and the Chihiro both contained 128MB Memory.

The memory was shared between the CPU and GPU. On the retail Xbox, the [[Flash ROM]] and [[MCPX ROM]] are also mapped to memory at the top 16 MiB and the top 512 Bytes respectively. However on Debug Xboxes and Chihiro, only the Flash is mapped as they don't contain an MCPX ROM.

= Memory map =
{| class="wikitable" style="text-align: center;"
! Memory Type
! Retail Xbox Range
! Debug/Chihiro Range
|-
|Main Memory
|0x00000000 - 0x03FFFFFF
|0x00000000 - 0x07FFFFFF
|-
|Shadow RAM
|0xF0000000 - 0xF3FFFFFF
|0xF0000000 - 0xF7FFFFFF
|-
|[[GPU|GPU (NV2A) Registers]]
|colspan="2"|0xFD000000 - 0xFDFFFFFF
|-
|[[APU|APU Registers]]
|colspan="2"|0xFE800000 - 0xFE87FFFF
|-
|[[ACI|ACI (AC97) Registers]]
|colspan="2"|0xFEC00000 - 0xFEC00FFF
|-
|USB 0 Registers
|colspan="2"|0xFED00000 - 0xFED00FFF
|-
|USB 1 Registers
|colspan="2"|0xFED08000 - 0xFED08FFF
|-
|NIC (NVNet) Registers
|colspan="2"|0xFEF00000 - 0xFEF003FF
|-
|[[Flash ROM]]
|colspan="2"|0xFF000000 - 0xFFFFFFFF
|-
|[[MCPX ROM]]
|0xFFFFFE00 - 0xFFFFFFFF
|N/A
|}

= I/O port map =
{{FIXME|reason=Taken from the KVMBOX memorymap.txt, not confirmed}}

Modchips often place control registers for LCD, bank selection, and other features in the range of 0xF000 - 0xF800 such as [https://bitbucket.org/prehistoricman/lpcmod_os/src/c6c5ceb04ad6c583b01522e58308f83254dbedb5/include/lpcmod_v1.h#lines-81:96 Xblast] and [https://github.com/Kekule-OXC/R3DUX/blob/main/Research/io%20registers.png Xecuter X3].

{| class="wikitable" style="text-align: center;"
! Device
! Retail Xbox Range
! Debug/Chihiro Range
|-
|DMA Channels 0-3
|colspan="2"|0x0000 - 0x000F
|-
|Master PIC
|colspan="2"|0x0020 - 0x0021
|-
|[[Super I/O|Super I/O Configuration]]
|N/A
|0x002E - 0x002F
|-
|[[Porting an Operating System to the Xbox HOWTO #Timer Frequency|PIT]]
|colspan="2"|0x0040 - 0x0043
|-
|[[17 Mistakes Microsoft Made in the Xbox Security System #The Xbox Hardware|A20 Gate]] / [[MCPX #Pin L21: PC Speaker|Speaker]]
|colspan="2"|0x0060 - 0x006F
|-
|CMOS / RTC
|colspan="2"|0x0070 - 0x0073
|-
|DMA Page Address
|colspan="2"|0x0080 - 0x008F
|-
|Slave PIC
|colspan="2"|0x00A0 - 0x00A1
|-
|DMA Channels 4-7
|colspan="2"|0x00C0 - 0x00DF
|-
|FPU Error Control
|colspan="2"|0x00F0 - 0x00F1
|-
|IDE
|colspan="2"|0x01F0 - 0x01F7
|-
|vesafb {{FIXME|reason=Does XGPU expose I/O ports?}}
|colspan="2"|0x03C0 - 0x03DF
|-
|IDE {{FIXME|reason=Really? This is rather one of FDC ports}}
|colspan="2"|0x03F6 - 0x03F6
|-
|[[Super I/O|Super I/O Serial]]
|N/A
|0x03F8 - 0x03FF
|-
|[[PCI|PCI Configuration]]
|colspan="2"|0x0CF8 - 0x0CFF
|-
|[[SMBus|SMBus (I2C)]]
|colspan="2"|0x1000 - 0x100F
|-
|rowspan="2"|Modem (MC97)
|colspan="2"|0x1080 - 0x10FF
|-
|colspan="2"|0x1400 - 0x14FF
|-
|[[PCI #00.01:0 - ISA Bridge|LPC PM]]
|colspan="2"|0x8000 - 0x80FF
|-
|rowspan="2"|[[SMBus|SMBus (I2C)]]
|colspan="2"|0xC000 - 0xC00F
|-
|colspan="2"|0xC200 - 0xC21F
|-
|rowspan="2"|[[ACI|ACI (AC97)]]
|colspan="2"|0xD000 - 0xD0FF
|-
|colspan="2"|0xD200 - 0xD27F
|-
|NIC (NVNet)
|colspan="2"|0xE000 - 0xE007
|-
|IDE
|colspan="2"|0xFF60 - 0xFF6F
|}

= Emulation =
Code for emulating the memory might consist of:

<pre>
#ifdef DEBUG || CHIHIRO
#define MEMORY_SIZE 128 * 1024 * 1024
int mcpx_active = 0;
#else
#define MEMORY_SIZE 64 * 1024 * 1024
int mcpx_active = 1;
#endif

#define FLASH_SIZE 256 * 1024
#define FLASH_MAP_SIZE 16 * 1024 * 1024
#define FLASH_MAP_ADDRESS (0xFFFFFFFF - FLASH_MAP_SIZE + 1)

#define MCPX_SIZE 0x200
#define MCPX_MAP_ADDRESS (0xFFFFFFFF - MCPX_MAP_SIZE + 1)

uint8_t memory[MEMORY_SIZE] = {0};
uint8_t flash[FLASH_SIZE] = {0};
uint8_t mcpx[MCPX_SIZE] = {0};

uint8_t get_memory_byte(uint32_t location) {
if (location < MEMORY_SIZE) {
return memory[location];
}

if (mcpx_active && location >= MCPX_MAP_ADDRESS) {
return mcpx[location - MCPX_MAP_ADDRESS];
}

if (location >= FLASH_MAP_ADDRESS) {
return flash[(location - FLASH_MAP_ADDRESS) % FLASH_SIZE];
}

printf("Memory in unspecified range: %08X\n", location);
return 0;
}

uint16_t get_memory_word(uint32_t location) {
return get_memory_byte(location + 1) << 8 | get_memory_byte(location);
}

uint32_t get_memory_dword(uint32_t location) {
return get_memory_word(location + 2) << 16 | get_memory_word(location);
}

void deactivate_mcpx() {
mcpx_active = 0;
}
</pre>

Xyclops

2025-07-10T00:27:36Z

Prehistoricman: /* GPIO mapping */ Add GPIO pin numbers

The [[SMC]] on v1.6 Xboxes is a custom chip called Xyclops. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

== Processor core ==
The embedded microcontroller that supports SMC functions is an 8051 core.

== Debug serial protocol ==

9600 baud UART, enabled by setting the DEBUG pin (pin 29) high. Baud can be changed by writing to a register. The very first byte sent will cause Xyclops to enter debug mode where normal SMC operations are paused.

The protocol is based on 4-byte or 67-byte commands.
# Byte 0 is the opcode. Bit 0 is often controlling a destination.
# Bytes 1 - 2 are the address. The most significant byte is sent first. Commands that don't address memory will ignore this.
# Byte 3 is the payload byte, or the first byte of the 64-byte payload for some commands.

Each command will produce a response of at least 2 bytes.
# Byte 0 is the echo of the command byte, or 0x4B if the command is not accepted.
# Byte 1 is the response payload
# Bytes 2 - 64 are the rest of the payload for commands that respond with 64 bytes of data.

=== Opcodes ===

SFR = Special Function Register

{|class="wikitable"
|-
!Opcode (hex)!!Length!!Response length!!Purpose
|-
|00 and 01||4||2||Read 1 byte of RAM
|-
|02 and 03||4||2||Write 1 byte to RAM
|-
|04 and 05||4||65||Read 1 byte of RAM 64 times (yes, really)
|-
|06 and 07||67||2||64-byte to something, possibly RAM.
|-
|08 and 09||4||2||Duplicate of 00
|-
|0A and 0B||4||2||Duplicate of 02
|-
|0C and 0D||4||65||Duplicate of 04
|-
|0E and 0F||67||2||Duplicate of 06
|-
|10||4||2||Read 1 byte from the BIOS flash
|-
|11||4||2||Read 1 byte from the SMC flash
|-
|12||4||2||Program 1 byte of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|13||4||2||Program 1 byte of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|14||4||65||Read 64 bytes of BIOS flash
|-
|15||4||65||Read 64 bytes of SMC flash
|-
|16||67||2||Program 64 bytes of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|17||67||2||Program 64 bytes of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|18 and 19||4||2||Read 1 byte from spare sector 0 or 1
|-
|1A and 1B||4||2||Program 1 byte of spare sector 0 or 1. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 2KiB or 0.5KiB memory space.
|-
|1C and 1D||4||65||Read 64 bytes from spare sector 0 or 1
|-
|1E and 1F||67||2||Program 64 bytes of spare sector 0 or 1
|-
|20 and 21||4||2||Read 1 byte of RAM/SFRs
|-
|22 and 23||4||2||Write 1 byte to RAM/SFRs
|-
|24 and 25||4||65||Read 1 byte of RAM/SFRs 64 times
|-
|26 and 27||?||?||Possibly broken write of 64 bytes to RAM/SFRs
|-
|28 and 29||4||2||Duplicate of 20 and 21
|-
|2A and 2B||4||2||Duplicate of 22 and 23
|-
|2C and 2D||4||65||Duplicate of 24 and 25
|-
|2E and 2F||?||?||Assumed to be duplicate of 26
|-
| --- || --- || --- || ---
|-
|30 to 3F|| - || - ||Similar to 10 - 1F, but the data read is always 00. Write attempts with opcode 0x32 are always rejected.
|-
| --- || --- || --- || ---
|-
|40||4||4 or 6||Exits and re-enters debug mode
|-
|41||4||2||Exits debug mode and locks programming
|-
|42||4||2||Exits debug mode and locks programming
|-
|43||4||2||Unlocks programming and erasing flash
|-
|48 - 4A||4||2||Not sure, appears to do nothing.
|-
| --- || --- || --- || ---
|-
|80||4||2||Sector erase BIOS flash. Sectors are 0x800 bytes.
|-
|81||4||2||Sector erase SMC flash. Sectors are 0x200 bytes.
|-
|84||4||2||Mass erase BIOS flash. Takes about 350ms.
|-
|85||4||2||Mass erase SMC flash. Takes about 350ms.
|-
|88||4||2||Erase spare sector 0 (0x200 bytes)
|-
|89||4||2||Erase spare sector 1 (0x80 bytes)
|-
|8C||4||2||Erase spare sector 0
|-
|8D||4||2||Erase spare sector 1
|}

== Xyclops memory spaces ==

* 128-byte RAM (could be 256)
** Upper 128 bytes read out as semi-random values. The 8051 core would need a bank select to naturally access them.
* 16KiB SMC flash
* 1KiB SMC debug ROM (at address 0xFC00 in the SMC flash space)
* 256KiB BIOS flash (4 banks)
** Bank selected by register 0x91
* 512-byte spare sector 0
* 128-byte spare sector 1
* 256-byte mixed RAM+SFR space (first 128 is RAM, second 128 is SFRs)

== Internal registers ==

{| class="wikitable"
|-
!Address (hex)!!Purpose
|-
|80||Port 0 output value (write) and input value (read)
|-
|90||Port 1 output value (write) and input value (read)
|-
|91||BIOS flash bank select. 0 - 3 for 256KiB.
|-
|9D||Port 0 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9E||Port 1 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9F||Port 2 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|A0||Port 2 output value (write) and input value (read)
|-
|B0||Port 0 tristate. 0 = output on. 1 = floating.
|-
|C0||Port 1 tristate. 0 = output on. 1 = floating.
|-
|D7||SMBus related
|-
|D8||Port 2 tristate. 0 = output on. 1 = floating.
|-
|D9 - DE||SMBus related
|-
|E9||Debug serial baud control. Higher value = faster serial. 0xB0 = 9600. 0xEC = 38400 baud
|-
|EC||Flash program/erase control. Bits 3:0 determine the flash region to target. Bits 7:5 control the kind of operation. Bit 4 starts the operation.
|}

== GPIO mapping ==

{| class="wikitable"
|-
!GPIO port.pin!!Pin number!!GPIO pin name!!Notes
|-
|P0.0 || 59 || AUD_CLAMP ||
|-
|P0.1 || 7 || EJTSW ||
|-
|P0.2 || 6 || POWSW ||
|-
|P0.3 || 28 || PSUON ||
|-
|P0.4 || 13 || VREGON ||
|-
|P0.5 || 26 || VPLLON ||
|-
|P0.6 || 32 || GPIO/FANOUT || FANOUT does not operate unless P0.6 is set high (regardless of open-drain/tri-state mode).
|-
|P0.7 || 33 || RTCACTIVE ||
|-
|P1.0 || 5 || DVDEJECT ||
|-
|P1.1 || 40 || XCALRESET* ||
|-
|P1.2 || 35 || SCL ||
|-
|P1.3 || 34 || SDA ||
|-
|P1.4 || 65 || SMI* ||
|-
|P1.5 || 41 || SYSRESET* ||
|-
|P1.6 || 11 || LEDGRN* ||
|-
|P1.7 || 12 || LEDRED* ||
|-
|P2.0 || 14 || PSUGD ||
|-
|P2.1 || 27 || VREGGD ||
|-
|P2.2 || 42 || VMODE<0> ||
|-
|P2.3 || 43 || VMODE<1> ||
|-
|P2.4 || 44 || VMODE<2> ||
|-
|P2.5 || 62 || TRAYSTATE<0> ||
|-
|P2.6 || 61 || TRAYSTATE<1> ||
|-
|P2.7 || 60 || TRAYSTATE<2> ||
|}

== Revisions ==

Known revisions are:
* Unlabelled - prototypes
* A-A02 - flashable
* A-B01 - not flashable

The die and bonding of A-B01 looks identical to A-A02, so it is not currently understood what prevents it from being flashed. The program and erase commands still execute successfully but don't produce any change in memory contents.

Xyclops

2025-06-20T13:20:14Z

Prehistoricman: Add GPIO mapping table

The [[SMC]] on v1.6 Xboxes is a custom chip called Xyclops. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

== Processor core ==
The embedded microcontroller that supports SMC functions is an 8051 core.

== Debug serial protocol ==

9600 baud UART, enabled by setting the DEBUG pin (pin 29) high. Baud can be changed by writing to a register. The very first byte sent will cause Xyclops to enter debug mode where normal SMC operations are paused.

The protocol is based on 4-byte or 67-byte commands.
# Byte 0 is the opcode. Bit 0 is often controlling a destination.
# Bytes 1 - 2 are the address. The most significant byte is sent first. Commands that don't address memory will ignore this.
# Byte 3 is the payload byte, or the first byte of the 64-byte payload for some commands.

Each command will produce a response of at least 2 bytes.
# Byte 0 is the echo of the command byte, or 0x4B if the command is not accepted.
# Byte 1 is the response payload
# Bytes 2 - 64 are the rest of the payload for commands that respond with 64 bytes of data.

=== Opcodes ===

SFR = Special Function Register

{|class="wikitable"
|-
!Opcode (hex)!!Length!!Response length!!Purpose
|-
|00 and 01||4||2||Read 1 byte of RAM
|-
|02 and 03||4||2||Write 1 byte to RAM
|-
|04 and 05||4||65||Read 1 byte of RAM 64 times (yes, really)
|-
|06 and 07||67||2||64-byte to something, possibly RAM.
|-
|08 and 09||4||2||Duplicate of 00
|-
|0A and 0B||4||2||Duplicate of 02
|-
|0C and 0D||4||65||Duplicate of 04
|-
|0E and 0F||67||2||Duplicate of 06
|-
|10||4||2||Read 1 byte from the BIOS flash
|-
|11||4||2||Read 1 byte from the SMC flash
|-
|12||4||2||Program 1 byte of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|13||4||2||Program 1 byte of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|14||4||65||Read 64 bytes of BIOS flash
|-
|15||4||65||Read 64 bytes of SMC flash
|-
|16||67||2||Program 64 bytes of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|17||67||2||Program 64 bytes of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|18 and 19||4||2||Read 1 byte from spare sector 0 or 1
|-
|1A and 1B||4||2||Program 1 byte of spare sector 0 or 1. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 2KiB or 0.5KiB memory space.
|-
|1C and 1D||4||65||Read 64 bytes from spare sector 0 or 1
|-
|1E and 1F||67||2||Program 64 bytes of spare sector 0 or 1
|-
|20 and 21||4||2||Read 1 byte of RAM/SFRs
|-
|22 and 23||4||2||Write 1 byte to RAM/SFRs
|-
|24 and 25||4||65||Read 1 byte of RAM/SFRs 64 times
|-
|26 and 27||?||?||Possibly broken write of 64 bytes to RAM/SFRs
|-
|28 and 29||4||2||Duplicate of 20 and 21
|-
|2A and 2B||4||2||Duplicate of 22 and 23
|-
|2C and 2D||4||65||Duplicate of 24 and 25
|-
|2E and 2F||?||?||Assumed to be duplicate of 26
|-
| --- || --- || --- || ---
|-
|30 to 3F|| - || - ||Similar to 10 - 1F, but the data read is always 00. Write attempts with opcode 0x32 are always rejected.
|-
| --- || --- || --- || ---
|-
|40||4||4 or 6||Exits and re-enters debug mode
|-
|41||4||2||Exits debug mode and locks programming
|-
|42||4||2||Exits debug mode and locks programming
|-
|43||4||2||Unlocks programming and erasing flash
|-
|48 - 4A||4||2||Not sure, appears to do nothing.
|-
| --- || --- || --- || ---
|-
|80||4||2||Sector erase BIOS flash. Sectors are 0x800 bytes.
|-
|81||4||2||Sector erase SMC flash. Sectors are 0x200 bytes.
|-
|84||4||2||Mass erase BIOS flash. Takes about 350ms.
|-
|85||4||2||Mass erase SMC flash. Takes about 350ms.
|-
|88||4||2||Erase spare sector 0 (0x200 bytes)
|-
|89||4||2||Erase spare sector 1 (0x80 bytes)
|-
|8C||4||2||Erase spare sector 0
|-
|8D||4||2||Erase spare sector 1
|}

== Xyclops memory spaces ==

* 128-byte RAM (could be 256)
** Upper 128 bytes read out as semi-random values. The 8051 core would need a bank select to naturally access them.
* 16KiB SMC flash
* 1KiB SMC debug ROM (at address 0xFC00 in the SMC flash space)
* 256KiB BIOS flash (4 banks)
** Bank selected by register 0x91
* 512-byte spare sector 0
* 128-byte spare sector 1
* 256-byte mixed RAM+SFR space (first 128 is RAM, second 128 is SFRs)

== Internal registers ==

{| class="wikitable"
|-
!Address (hex)!!Purpose
|-
|80||Port 0 output value (write) and input value (read)
|-
|90||Port 1 output value (write) and input value (read)
|-
|91||BIOS flash bank select. 0 - 3 for 256KiB.
|-
|9D||Port 0 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9E||Port 1 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9F||Port 2 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|A0||Port 2 output value (write) and input value (read)
|-
|B0||Port 0 tristate. 0 = output on. 1 = floating.
|-
|C0||Port 1 tristate. 0 = output on. 1 = floating.
|-
|D7||SMBus related
|-
|D8||Port 2 tristate. 0 = output on. 1 = floating.
|-
|D9 - DE||SMBus related
|-
|E9||Debug serial baud control. Higher value = faster serial. 0xB0 = 9600. 0xEC = 38400 baud
|-
|EC||Flash program/erase control. Bits 3:0 determine the flash region to target. Bits 7:5 control the kind of operation. Bit 4 starts the operation.
|}

== GPIO mapping ==

{| class="wikitable"
|-
!GPIO port.pin!!GPIO pin name!!Notes
|-
|P0.0 || AUD_CLAMP ||
|-
|P0.1 || EJTSW ||
|-
|P0.2 || POWSW ||
|-
|P0.3 || PSUON ||
|-
|P0.4 || VREGON ||
|-
|P0.5 || VPLLON ||
|-
|P0.6 || GPIO/FANOUT || FANOUT does not operate unless P0.6 is set high (regardless of open-drain/tri-state mode).
|-
|P0.7 || RTCACTIVE ||
|-
|P1.0 || DVDEJECT ||
|-
|P1.1 || XCALRESET* ||
|-
|P1.2 || SCL ||
|-
|P1.3 || SDA ||
|-
|P1.4 || SMI* ||
|-
|P1.5 || SYSRESET* ||
|-
|P1.6 || LEDGRN* ||
|-
|P1.7 || LEDRED* ||
|-
|P2.0 || PSUGD ||
|-
|P2.1 || VREGGD ||
|-
|P2.2 || VMODE<0> ||
|-
|P2.3 || VMODE<1> ||
|-
|P2.4 || VMODE<2> ||
|-
|P2.5 || TRAYSTATE<0> ||
|-
|P2.6 || TRAYSTATE<1> ||
|-
|P2.7 || TRAYSTATE<2> ||
|}

== Revisions ==

Known revisions are:
* Unlabelled - prototypes
* A-A02 - flashable
* A-B01 - not flashable

The die and bonding of A-B01 looks identical to A-A02, so it is not currently understood what prevents it from being flashed. The program and erase commands still execute successfully but don't produce any change in memory contents.

Xyclops

2025-06-20T12:46:09Z

Prehistoricman: Amending last edit

The [[SMC]] on v1.6 Xboxes is a custom chip called Xyclops. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

== Processor core ==
The embedded microcontroller that supports SMC functions is an 8051 core.

== Debug serial protocol ==

9600 baud UART, enabled by setting the DEBUG pin (pin 29) high. Baud can be changed by writing to a register. The very first byte sent will cause Xyclops to enter debug mode where normal SMC operations are paused.

The protocol is based on 4-byte or 67-byte commands.
# Byte 0 is the opcode. Bit 0 is often controlling a destination.
# Bytes 1 - 2 are the address. The most significant byte is sent first. Commands that don't address memory will ignore this.
# Byte 3 is the payload byte, or the first byte of the 64-byte payload for some commands.

Each command will produce a response of at least 2 bytes.
# Byte 0 is the echo of the command byte, or 0x4B if the command is not accepted.
# Byte 1 is the response payload
# Bytes 2 - 64 are the rest of the payload for commands that respond with 64 bytes of data.

=== Opcodes ===

SFR = Special Function Register

{|class="wikitable"
|-
!Opcode (hex)!!Length!!Response length!!Purpose
|-
|00 and 01||4||2||Read 1 byte of RAM
|-
|02 and 03||4||2||Write 1 byte to RAM
|-
|04 and 05||4||65||Read 1 byte of RAM 64 times (yes, really)
|-
|06 and 07||67||2||64-byte to something, possibly RAM.
|-
|08 and 09||4||2||Duplicate of 00
|-
|0A and 0B||4||2||Duplicate of 02
|-
|0C and 0D||4||65||Duplicate of 04
|-
|0E and 0F||67||2||Duplicate of 06
|-
|10||4||2||Read 1 byte from the BIOS flash
|-
|11||4||2||Read 1 byte from the SMC flash
|-
|12||4||2||Program 1 byte of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|13||4||2||Program 1 byte of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|14||4||65||Read 64 bytes of BIOS flash
|-
|15||4||65||Read 64 bytes of SMC flash
|-
|16||67||2||Program 64 bytes of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|17||67||2||Program 64 bytes of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|18 and 19||4||2||Read 1 byte from spare sector 0 or 1
|-
|1A and 1B||4||2||Program 1 byte of spare sector 0 or 1. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 2KiB or 0.5KiB memory space.
|-
|1C and 1D||4||65||Read 64 bytes from spare sector 0 or 1
|-
|1E and 1F||67||2||Program 64 bytes of spare sector 0 or 1
|-
|20 and 21||4||2||Read 1 byte of RAM/SFRs
|-
|22 and 23||4||2||Write 1 byte to RAM/SFRs
|-
|24 and 25||4||65||Read 1 byte of RAM/SFRs 64 times
|-
|26 and 27||?||?||Possibly broken write of 64 bytes to RAM/SFRs
|-
|28 and 29||4||2||Duplicate of 20 and 21
|-
|2A and 2B||4||2||Duplicate of 22 and 23
|-
|2C and 2D||4||65||Duplicate of 24 and 25
|-
|2E and 2F||?||?||Assumed to be duplicate of 26
|-
| --- || --- || --- || ---
|-
|30 to 3F|| - || - ||Similar to 10 - 1F, but the data read is always 00. Write attempts with opcode 0x32 are always rejected.
|-
| --- || --- || --- || ---
|-
|40||4||4 or 6||Exits and re-enters debug mode
|-
|41||4||2||Exits debug mode and locks programming
|-
|42||4||2||Exits debug mode and locks programming
|-
|43||4||2||Unlocks programming and erasing flash
|-
|48 - 4A||4||2||Not sure, appears to do nothing.
|-
| --- || --- || --- || ---
|-
|80||4||2||Sector erase BIOS flash. Sectors are 0x800 bytes.
|-
|81||4||2||Sector erase SMC flash. Sectors are 0x200 bytes.
|-
|84||4||2||Mass erase BIOS flash. Takes about 350ms.
|-
|85||4||2||Mass erase SMC flash. Takes about 350ms.
|-
|88||4||2||Erase spare sector 0 (0x200 bytes)
|-
|89||4||2||Erase spare sector 1 (0x80 bytes)
|-
|8C||4||2||Erase spare sector 0
|-
|8D||4||2||Erase spare sector 1
|}

== Xyclops memory spaces ==

* 128-byte RAM (could be 256)
** Upper 128 bytes read out as semi-random values. The 8051 core would need a bank select to naturally access them.
* 16KiB SMC flash
* 1KiB SMC debug ROM (at address 0xFC00 in the SMC flash space)
* 256KiB BIOS flash (4 banks)
** Bank selected by register 0x91
* 512-byte spare sector 0
* 128-byte spare sector 1
* 256-byte mixed RAM+SFR space (first 128 is RAM, second 128 is SFRs)

== Internal registers ==

{| class="wikitable"
|-
!Address (hex)!!Purpose
|-
|80||Port 0 output value (write) and input value (read)
|-
|90||Port 1 output value (write) and input value (read)
|-
|91||BIOS flash bank select. 0 - 3 for 256KiB.
|-
|9D||Port 0 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9E||Port 1 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9F||Port 2 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|A0||Port 2 output value (write) and input value (read)
|-
|B0||Port 0 tristate. 0 = output on. 1 = floating.
|-
|C0||Port 1 tristate. 0 = output on. 1 = floating.
|-
|D7||SMBus related
|-
|D8||Port 2 tristate. 0 = output on. 1 = floating.
|-
|D9 - DE||SMBus related
|-
|E9||Debug serial baud control. Higher value = faster serial. 0xB0 = 9600. 0xEC = 38400 baud
|-
|EC||Flash program/erase control. Bits 3:0 determine the flash region to target. Bits 7:5 control the kind of operation. Bit 4 starts the operation.
|}

== Revisions ==

Known revisions are:
* Unlabelled - prototypes
* A-A02 - flashable
* A-B01 - not flashable

The die and bonding of A-B01 looks identical to A-A02, so it is not currently understood what prevents it from being flashed. The program and erase commands still execute successfully but don't produce any change in memory contents.

Xyclops

2025-06-20T01:03:11Z

Prehistoricman: Add port registers

The [[SMC]] on v1.6 Xboxes is a custom chip called Xyclops. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

== Processor core ==
The embedded microcontroller that supports SMC functions is an 8051 core.

== Debug serial protocol ==

9600 baud UART, enabled by setting the DEBUG pin (pin 29) high. Baud can be changed by writing to a register. The very first byte sent will cause Xyclops to enter debug mode where normal SMC operations are paused.

The protocol is based on 4-byte or 67-byte commands.
# Byte 0 is the opcode. Bit 0 is often controlling a destination.
# Bytes 1 - 2 are the address. The most significant byte is sent first. Commands that don't address memory will ignore this.
# Byte 3 is the payload byte, or the first byte of the 64-byte payload for some commands.

Each command will produce a response of at least 2 bytes.
# Byte 0 is the echo of the command byte, or 0x4B if the command is not accepted.
# Byte 1 is the response payload
# Bytes 2 - 64 are the rest of the payload for commands that respond with 64 bytes of data.

=== Opcodes ===

SFR = Special Function Register

{|class="wikitable"
|-
!Opcode (hex)!!Length!!Response length!!Purpose
|-
|00 and 01||4||2||Read 1 byte of RAM
|-
|02 and 03||4||2||Write 1 byte to RAM
|-
|04 and 05||4||65||Read 1 byte of RAM 64 times (yes, really)
|-
|06 and 07||67||2||64-byte to something, possibly RAM.
|-
|08 and 09||4||2||Duplicate of 00
|-
|0A and 0B||4||2||Duplicate of 02
|-
|0C and 0D||4||65||Duplicate of 04
|-
|0E and 0F||67||2||Duplicate of 06
|-
|10||4||2||Read 1 byte from the BIOS flash
|-
|11||4||2||Read 1 byte from the SMC flash
|-
|12||4||2||Program 1 byte of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|13||4||2||Program 1 byte of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|14||4||65||Read 64 bytes of BIOS flash
|-
|15||4||65||Read 64 bytes of SMC flash
|-
|16||67||2||Program 64 bytes of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|17||67||2||Program 64 bytes of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|18 and 19||4||2||Read 1 byte from spare sector 0 or 1
|-
|1A and 1B||4||2||Program 1 byte of spare sector 0 or 1. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 2KiB or 0.5KiB memory space.
|-
|1C and 1D||4||65||Read 64 bytes from spare sector 0 or 1
|-
|1E and 1F||67||2||Program 64 bytes of spare sector 0 or 1
|-
|20 and 21||4||2||Read 1 byte of RAM/SFRs
|-
|22 and 23||4||2||Write 1 byte to RAM/SFRs
|-
|24 and 25||4||65||Read 1 byte of RAM/SFRs 64 times
|-
|26 and 27||?||?||Possibly broken write of 64 bytes to RAM/SFRs
|-
|28 and 29||4||2||Duplicate of 20 and 21
|-
|2A and 2B||4||2||Duplicate of 22 and 23
|-
|2C and 2D||4||65||Duplicate of 24 and 25
|-
|2E and 2F||?||?||Assumed to be duplicate of 26
|-
| --- || --- || --- || ---
|-
|30 to 3F|| - || - ||Similar to 10 - 1F, but the data read is always 00. Write attempts with opcode 0x32 are always rejected.
|-
| --- || --- || --- || ---
|-
|40||4||4 or 6||Exits and re-enters debug mode
|-
|41||4||2||Exits debug mode and locks programming
|-
|42||4||2||Exits debug mode and locks programming
|-
|43||4||2||Unlocks programming and erasing flash
|-
|48 - 4A||4||2||Not sure, appears to do nothing.
|-
| --- || --- || --- || ---
|-
|80||4||2||Sector erase BIOS flash. Sectors are 0x800 bytes.
|-
|81||4||2||Sector erase SMC flash. Sectors are 0x200 bytes.
|-
|84||4||2||Mass erase BIOS flash. Takes about 350ms.
|-
|85||4||2||Mass erase SMC flash. Takes about 350ms.
|-
|88||4||2||Erase spare sector 0 (0x200 bytes)
|-
|89||4||2||Erase spare sector 1 (0x80 bytes)
|-
|8C||4||2||Erase spare sector 0
|-
|8D||4||2||Erase spare sector 1
|}

== Xyclops memory spaces ==

* 128-byte RAM (could be 256)
** Upper 128 bytes read out as semi-random values. The 8051 core would need a bank select to naturally access them.
* 16KiB SMC flash
* 1KiB SMC debug ROM (at address 0xFC00 in the SMC flash space)
* 256KiB BIOS flash (4 banks)
** Bank selected by register 0x91
* 512-byte spare sector 0
* 128-byte spare sector 1
* 256-byte mixed RAM+SFR space (first 128 is RAM, second 128 is SFRs)

== Internal registers ==

{| class="wikitable"
|-
!Address (hex)!!Purpose
|-
|80||Port 0 output value (write) and input value (read)
|-
|90||Port 1 output value (write) and input value (read)
|-
|91||BIOS flash bank select. 0 - 3 for 256KiB.
|-
|9D||Port 0 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9E||Port 1 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|9F||Port 2 open drain mode. 0 = normal GPIO. 1 = open drain mode (pin is floating when output value == 1).
|-
|A0||Port 2 output value (write) and input value (read)
|-
|B0||Port 0 tristate. 0 = output on. 1 = floating.
|-
|C0||Port 1 tristate. 0 = output on. 1 = floating.
|-
|D7||SMBus related
|-
|D8||Port 2 tristate. 0 = output on. 1 = floating.
|-
|D8||GPIO port 2 related (seemingly related to reading pin states)
|-
|D9 - DE||SMBus related
|-
|E9||Debug serial baud control. Higher value = faster serial. 0xB0 = 9600. 0xEC = 38400 baud
|-
|EC||Flash program/erase control. Bits 3:0 determine the flash region to target. Bits 7:5 control the kind of operation. Bit 4 starts the operation.
|}

== Revisions ==

Known revisions are:
* Unlabelled - prototypes
* A-A02 - flashable
* A-B01 - not flashable

The die and bonding of A-B01 looks identical to A-A02, so it is not currently understood what prevents it from being flashed. The program and erase commands still execute successfully but don't produce any change in memory contents.

Xyclops

2025-05-28T18:22:40Z

Prehistoricman: Add some registers

The [[SMC]] on v1.6 Xboxes is a custom chip called Xyclops. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

== Processor core ==
The embedded microcontroller that supports SMC functions is an 8051 core.

== Debug serial protocol ==

9600 baud UART, enabled by setting the DEBUG pin (pin 29) high. Baud can be changed by writing to a register. The very first byte sent will cause Xyclops to enter debug mode where normal SMC operations are paused.

The protocol is based on 4-byte or 67-byte commands.
# Byte 0 is the opcode. Bit 0 is often controlling a destination.
# Bytes 1 - 2 are the address. The most significant byte is sent first. Commands that don't address memory will ignore this.
# Byte 3 is the payload byte, or the first byte of the 64-byte payload for some commands.

Each command will produce a response of at least 2 bytes.
# Byte 0 is the echo of the command byte, or 0x4B if the command is not accepted.
# Byte 1 is the response payload
# Bytes 2 - 64 are the rest of the payload for commands that respond with 64 bytes of data.

=== Opcodes ===

SFR = Special Function Register

{|class="wikitable"
|-
!Opcode (hex)!!Length!!Response length!!Purpose
|-
|00 and 01||4||2||Read 1 byte of RAM
|-
|02 and 03||4||2||Write 1 byte to RAM
|-
|04 and 05||4||65||Read 1 byte of RAM 64 times (yes, really)
|-
|06 and 07||67||2||64-byte to something, possibly RAM.
|-
|08 and 09||4||2||Duplicate of 00
|-
|0A and 0B||4||2||Duplicate of 02
|-
|0C and 0D||4||65||Duplicate of 04
|-
|0E and 0F||67||2||Duplicate of 06
|-
|10||4||2||Read 1 byte from the BIOS flash
|-
|11||4||2||Read 1 byte from the SMC flash
|-
|12||4||2||Program 1 byte of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|13||4||2||Program 1 byte of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|14||4||65||Read 64 bytes of BIOS flash
|-
|15||4||65||Read 64 bytes of SMC flash
|-
|16||67||2||Program 64 bytes of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|17||67||2||Program 64 bytes of SMC flash. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 16KiB flash space.
|-
|18 and 19||4||2||Read 1 byte from spare sector 0 or 1
|-
|1A and 1B||4||2||Program 1 byte of spare sector 0 or 1. Needs to be unlocked by opcode 0x43. Addresses are aliased within the 2KiB or 0.5KiB memory space.
|-
|1C and 1D||4||65||Read 64 bytes from spare sector 0 or 1
|-
|1E and 1F||67||2||Program 64 bytes of spare sector 0 or 1
|-
|20 and 21||4||2||Read 1 byte of RAM/SFRs
|-
|22 and 23||4||2||Write 1 byte to RAM/SFRs
|-
|24 and 25||4||65||Read 1 byte of RAM/SFRs 64 times
|-
|26 and 27||?||?||Possibly broken write of 64 bytes to RAM/SFRs
|-
|28 and 29||4||2||Duplicate of 20 and 21
|-
|2A and 2B||4||2||Duplicate of 22 and 23
|-
|2C and 2D||4||65||Duplicate of 24 and 25
|-
|2E and 2F||?||?||Assumed to be duplicate of 26
|-
| --- || --- || --- || ---
|-
|30 to 3F|| - || - ||Similar to 10 - 1F, but the data read is always 00. Write attempts with opcode 0x32 are always rejected.
|-
| --- || --- || --- || ---
|-
|40||4||4 or 6||Exits and re-enters debug mode
|-
|41||4||2||Exits debug mode and locks programming
|-
|42||4||2||Exits debug mode and locks programming
|-
|43||4||2||Unlocks programming and erasing flash
|-
|48 - 4A||4||2||Not sure, appears to do nothing.
|-
| --- || --- || --- || ---
|-
|80||4||2||Sector erase BIOS flash. Sectors are 0x800 bytes.
|-
|81||4||2||Sector erase SMC flash. Sectors are 0x200 bytes.
|-
|84||4||2||Mass erase BIOS flash. Takes about 350ms.
|-
|85||4||2||Mass erase SMC flash. Takes about 350ms.
|-
|88||4||2||Erase spare sector 0 (0x200 bytes)
|-
|89||4||2||Erase spare sector 1 (0x80 bytes)
|-
|8C||4||2||Erase spare sector 0
|-
|8D||4||2||Erase spare sector 1
|}

== Xyclops memory spaces ==

* 128-byte RAM (could be 256)
** Upper 128 bytes read out as semi-random values. The 8051 core would need a bank select to naturally access them.
* 16KiB SMC flash
* 1KiB SMC debug ROM (at address 0xFC00 in the SMC flash space)
* 256KiB BIOS flash (4 banks)
** Bank selected by register 0x91
* 512-byte spare sector 0
* 128-byte spare sector 1
* 256-byte mixed RAM+SFR space (first 128 is RAM, second 128 is SFRs)

== Internal registers ==

{| class="wikitable"
|-
!Address (hex)!!Purpose
|-
|91||BIOS flash bank select. 0 - 3 for 256KiB.
|-
|D7||SMBus related
|-
|D8||GPIO port 2 related (seemingly related to reading pin states)
|-
|D9 - DE||SMBus related
|-
|E9||Debug serial baud control. Higher value = faster serial. 0xB0 = 9600. 0xEC = 38400 baud
|-
|EC||Flash program/erase control. Bits 3:0 determine the flash region to target. Bits 7:5 control the kind of operation. Bit 4 starts the operation.
|}

== Revisions ==

Known revisions are:
* Unlabelled - prototypes
* A-A02 - flashable
* A-B01 - not flashable

The die and bonding of A-B01 looks identical to A-A02, so it is not currently understood what prevents it from being flashed. The program and erase commands still execute successfully but don't produce any change in memory contents.

Xyclops

2025-05-28T14:57:06Z

Prehistoricman: Update spare sector sizes

Xyclops

2025-05-28T14:01:40Z

Prehistoricman: Opcode 1E and 1F

Xyclops

2025-05-27T13:01:05Z

Prehistoricman:

Xyclops

2025-05-27T13:00:14Z

Prehistoricman: Add info about spare sectors

Xyclops

2025-05-27T11:53:54Z

Prehistoricman: Add SMC sector erase command

Xyclops

2025-05-27T02:55:08Z

Prehistoricman: Commands table updates and corrections

Xyclops

2025-05-21T13:52:39Z

Prehistoricman: Add Revisions and Processor core sections

System Management Controller

2025-05-21T13:41:34Z

Prehistoricman:

The System Management Controller (SMC) is a PIC16LC63A-04/SO microcontroller which handles a variety of tasks on the Xbox.
This includes rebooting the system, returning the connected kind of video cable, the DVD tray state, controlling the fan, LED control and sensing temperature.
It is also the hardware which is connected to the Power and Eject buttons.
The PIC is running at 10 MHz and has an internal ROM and RAM.

The PIC is always running, even if the Xbox is turned off. When the power cable is unplugged, it gets its energy from a capacitor for some hours.

It is connected via I²C and located on address 0x10.

== Xyclops ==

The SMC on v1.6 Xboxes is a custom chip called [[Xyclops]]. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

Go to [[Xyclops]] for more details.

== Revisions ==

The chip is also marked with a revision.
Known revisions include:

* P01 (v1.0)
* P05 (v1.1)
* P11 (v1.2 - 1.4)
* P2L (v1.6)
* D01 (Seen in a debug kit)
* D05 (seen in a earlier model chihiro)

System Management Controller

2025-05-21T13:39:23Z

Prehistoricman:

The System Management Controller (SMC) is a PIC16LC63A-04/SO microcontroller which handles a variety of tasks on the Xbox.
This includes rebooting the system, returning the connected kind of video cable, the DVD tray state, controlling the fan, LED control and sensing temperature.
It is also the hardware which is connected to the Power and Eject buttons.
The PIC is running at 10 MHz and has an internal ROM and RAM.

The PIC is always running, even if the Xbox is turned off. When the power cable is unplugged, it gets its energy from a capacitor for some hours.

It is connected via I²C and located on address 0x10.

== Xyclops ==

The SMC on v1.6 Xboxes is a custom chip called [[Xyclops]]. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

Go to [[Xyclops]] for details on the debug UART interface.

== Revisions ==

The chip is also marked with a revision.
Known revisions include:

* P01 (v1.0)
* P05 (v1.1)
* P11 (v1.2 - 1.4)
* P2L (v1.6)
* D01 (Seen in a debug kit)
* D05 (seen in a earlier model chihiro)

Xyclops

2025-05-21T13:36:27Z

Prehistoricman: Created page with "The SMC on v1.6 Xboxes is a custom chip called Xyclops. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the..."

The [[SMC]] on v1.6 Xboxes is a custom chip called Xyclops. It has a debug UART interface on pins 63 (RXD) and 64 (TXD) which can be used to read/write the BIOS flash, and the SMC's RAM, registers and flash.

== Xyclops serial protocol ==

9600 baud UART, enabled by setting the DEBUG pin (pin 29) high. Baud can be changed by writing to a register. The very first byte sent will cause Xyclops to enter debug mode where normal SMC operations are paused.

The protocol is based on 4-byte or 67-byte commands.
# Byte 0 is the opcode. Bit 0 is often controlling a destination.
# Bytes 1 - 2 are the address. The most significant byte is sent first. Commands that don't address memory will ignore this.
# Byte 3 is the payload byte, or the first byte of the 64-byte payload for some commands.

Each command will produce a response of at least 2 bytes.
# Byte 0 is the echo of the command byte, or 0x4B if the command is not accepted.
# Byte 1 is the response payload
# Bytes 2 - 64 are the rest of the payload for commands that respond with 64 bytes of data.

=== Opcodes ===

SFR = Special Function Register

{|class="wikitable"
|-
!Opcode (hex)!!Length!!Response length!!Purpose
|-
|00 and 01||4||2||Read 1 byte of RAM
|-
|02 and 03||4||2||Write 1 byte to RAM
|-
|04 and 05||4||65||Read 1 byte of RAM 64 times (yes, really)
|-
|06 and 07||67||2||64-byte to something, possibly RAM.
|-
|08 and 09||4||2||Duplicate of 00
|-
|0A and 0B||4||2||Duplicate of 02
|-
|0C and 0D||4||65||Duplicate of 04
|-
|0E and 0F||67||2||Duplicate of 06
|-
|10||4||2||Dump 1 byte from the BIOS flash
|-
|11||4||2||Dump 1 byte from the SMC flash
|-
|12||4||2||Program 1 byte of BIOS flash (untested). Needs to be unlocked by opcode 0x43.
|-
|13||4||2||Program 1 byte of SMC flash (untested). Needs to be unlocked by opcode 0x43.
|-
|14||4||65||Read 64 bytes of BIOS flash
|-
|15||4||65||Read 64 bytes of SMC flash
|-
|16||67||2||Program 64 bytes of BIOS flash. Needs to be unlocked by opcode 0x43.
|-
|17||67||2||Program 64 bytes of SMC flash. Needs to be unlocked by opcode 0x43.
|-
|18 and 19||4||2||Read 1 byte of some unknown areas
|-
|1A and 1B||?||?||Untested
|-
|1C and 1D||4||65||Read 64 bytes of some unknown areas
|-
|1E and 1F||?||?||Possible write to unknown areas. Untested.
|-
|20 and 21||?||?||Assumed to read 1 byte of RAM/SFRs
|-
|24 and 25||4||65||Read 64 bytes of RAM/SFRs
|-
|26 and 27||?||?||Assumed to write 1 byte to RAM/SFRs
|-
|28 and 29||4||2||Read 1 byte of RAM/SFRs
|-
|2A and 2B||4||2||Write 1 byte to RAM/SFRs. TODO: verify that 2A works in the same way
|-
|2C and 2D||4||65||Duplicate of 24
|-
|2E and 2F||?||?||Assumed to be duplicate of 26
|-
| --- || --- || --- || ---
|-
|30 to 3F||?||?||Similar to 10 - 1F, but the data read is always 00. TODO: test if 32 is unlocked by opcode 0x43. TODO: dump whole area
|-
| --- || --- || --- || ---
|-
|40||4||4 or 6||Exits and re-enters debug mode
|-
|41||4||2||Exits debug mode and locks programming
|-
|42||4||2||Exits debug mode and locks programming
|-
|43||4||2||Unlocks programming and erasing flash
|-
|48 - 4A||4||2||Not sure, appear to do nothing.
|-
| --- || --- || --- || ---
|-
|80 and 81||?||?||Could be another kind of erase, such as block or sector erase
|-
|84||4||2||Mass erase BIOS flash
|-
|85||4||2||Assumed to mass erase SMC flash. Danger: might also erase the command handler code!
|}

== Xyclops memory spaces ==

* 128-byte RAM (could be 256)
** Upper 128 bytes read out as semi-random values. The 8051 core would need a bank select to naturally access them.
* 64KiB SMC flash
* 256KiB BIOS flash (4 banks)
** Bank selected by register 0x91
* Unknown 512 and 1024 byte spaces
* 256-byte mixed RAM+SFR space (first 128 is RAM, second 128 is SFRs)

== Xyclops internal registers ==

{| class="wikitable"
|-
!Address (hex)!!Purpose
|-
|91||BIOS flash bank select. 0 - 3 for 256KiB.
|-
|E9||Debug serial baud control. Higher value = faster serial. 0xB0 = 9600. 0xEC = 38400 baud
|}

System Management Controller

2025-04-23T13:05:20Z

Prehistoricman: Associate Xbox version with SMC version

The System Management Controller (SMC) is a PIC16LC63A-04/SO microcontroller which handles a variety of tasks on the Xbox.
This includes rebooting the system, returning the connected kind of video cable, the DVD tray state, controlling the fan, LED control and sensing temperature.
It is also the hardware which is connected to the Power and Eject buttons.
The PIC is running at 10 MHz and has an internal ROM and RAM.

The PIC is always running, even if the Xbox is turned off. When the power cable is unplugged, it gets its energy from a capacitor for some hours.

It is connected via I²C and located on address 0x10.

== Revisions ==

The chip is also marked with a revision.
Known revisions include:

* P01 (v1.0)
* P05 (v1.1)
* P11 (v1.2 - 1.4)
* P2L (v1.6)
* D01 (Seen in a debug kit)
* D05 (seen in a earlier model chihiro)

System Management Controller

2025-03-25T03:47:28Z

Prehistoricman: Fix PIC clock speed

The System Management Controller (SMC) is a PIC16LC63A-04/SO microcontroller which handles a variety of tasks on the Xbox.
This includes rebooting the system, returning the connected kind of video cable, the DVD tray state, controlling the fan, LED control and sensing temperature.
It is also the hardware which is connected to the Power and Eject buttons.
The PIC is running at 10 MHz and has an internal ROM and RAM.

The PIC is always running, even if the Xbox is turned off. When the power cable is unplugged, it gets its energy from a capacitor for some hours.

It is connected via I²C and located on address 0x10.

== Revisions ==

The chip is also marked with a revision.
Known revisions include:

* P01
* P05
* P11
* P2L{{citation needed}}
* D01 (Seen in a debug kit)
* D05 (seen in a earlier model chihiro)

Flash ROM

2024-02-21T04:43:26Z

Prehistoricman: Add details about the addressing

The Flash is a 256 kiB or 1 MiB [[Wikipedia:Flash_memory|non-volatile <abbr title="Thin Small Outline Package">TSOP</abbr> ROM chip]] and connected to the [[MCPX]] via a parallel bus on [[hardware revisions]] 1.0 to 1.4. The 256 kiB ROM on revision 1.6 is stored in the Xcalibur chip, not a flash chip, and is connected to the [[MCPX]] via the [[Wikipedia:Low Pin Count|<abbr title="Low Pin Count">LPC</abbr>]] bus (Xbox revision 1.6).

The Flash ROM is mapped at physical addresses 0xFF000000 to 0xFFFFFFFF (revision 1.0) or 0xFFFFFDFF (revisions 1.1 - 1.6). The 256 kiB or 1 MiB ROM is [[Wikipedia:Aliasing (computing)#Hardware aliasing|aliased]] throughout this 16 MiB address range.
The ROM is commonly based in software at either 0xFFF00000 or 0xFFFC0000 as these are the addresses of the last alias for 1 MiB and 256 kiB respectively.
Due to [[Exploits#MIST hack|the MIST hack]], Microsoft blocked the use of flash ROM in the range of the [[MCPX ROM]] (0xFFFFFE00 - 0xFFFFFFFF) for revisions 1.1 to 1.6. Once the MCPX ROM is hidden, accessing this memory range will freeze the system.

For the content of the Microsoft flash images see [[BIOS]].

Flash ROM

2024-02-21T04:15:35Z

Prehistoricman: Fix information about MCPX connection

Memory

2024-02-20T23:59:31Z

Prehistoricman: Add shadow RAM to memory map

The Xbox has 64MB Memory. This could be expanded to 128MB of memory on boards of revision 1.0-1.4 (Boards of revision 1.0-1.4 have empty spots for the extra memory, but they were later removed on 1.6 boards) but no games took advantage of it. The debug Xbox and the Chihiro both contained 128MB Memory.

The memory was shared between the CPU and GPU. On the retail Xbox, the [[Flash ROM]] and [[MCPX ROM]] are also mapped to memory at the top 16 MiB and the top 512 Bytes respectively. However on Debug Xboxes and Chihiro, only the Flash is mapped as they don't contain an MCPX ROM.

= Memory map =
{| class="wikitable" style="text-align: center;"
! Memory Type
! Retail Xbox Range
! Debug/Chihiro Range
|-
|Main Memory
|0x00000000 - 0x03FFFFFF
|0x00000000 - 0x07FFFFFF
|-
|Shadow RAM
|0xF0000000 - 0xF3FFFFFF
|0xF0000000 - 0xF7FFFFFF
|-
|[[GPU|GPU (NV2A) Registers]]
|colspan="2"|0xFD000000 - 0xFDFFFFFF
|-
|[[APU|APU Registers]]
|colspan="2"|0xFE800000 - 0xFE87FFFF
|-
|[[ACI|ACI (AC97) Registers]]
|colspan="2"|0xFEC00000 - 0xFEC00FFF
|-
|USB 0 Registers
|colspan="2"|0xFED00000 - 0xFED00FFF
|-
|USB 1 Registers
|colspan="2"|0xFED08000 - 0xFED08FFF
|-
|NIC (NVNet) Registers
|colspan="2"|0xFEF00000 - 0xFEF003FF
|-
|[[Flash ROM]]
|colspan="2"|0xFF000000 - 0xFFFFFFFF
|-
|[[MCPX ROM]]
|0xFFFFFE00 - 0xFFFFFFFF
|N/A
|}

= I/O port map =
{{FIXME|reason=Taken from the KVMBOX memorymap.txt, not confirmed}}

{| class="wikitable" style="text-align: center;"
! Device
! Retail Xbox Range
! Debug/Chihiro Range
|-
|DMA Channels 0-3
|colspan="2"|0x0000 - 0x000F
|-
|Master PIC
|colspan="2"|0x0020 - 0x0021
|-
|[[Super I/O|Super I/O Configuration]]
|N/A
|0x002E - 0x002F
|-
|[[Porting an Operating System to the Xbox HOWTO #Timer Frequency|PIT]]
|colspan="2"|0x0040 - 0x0043
|-
|[[17 Mistakes Microsoft Made in the Xbox Security System #The Xbox Hardware|A20 Gate]] / [[MCPX #Pin L21: PC Speaker|Speaker]]
|colspan="2"|0x0060 - 0x006F
|-
|CMOS / RTC
|colspan="2"|0x0070 - 0x0073
|-
|DMA Page Address
|colspan="2"|0x0080 - 0x008F
|-
|Slave PIC
|colspan="2"|0x00A0 - 0x00A1
|-
|DMA Channels 4-7
|colspan="2"|0x00C0 - 0x00DF
|-
|FPU Error Control
|colspan="2"|0x00F0 - 0x00F1
|-
|IDE
|colspan="2"|0x01F0 - 0x01F7
|-
|vesafb {{FIXME|reason=Does XGPU expose I/O ports?}}
|colspan="2"|0x03C0 - 0x03DF
|-
|IDE {{FIXME|reason=Really? This is rather one of FDC ports}}
|colspan="2"|0x03F6 - 0x03F6
|-
|[[Super I/O|Super I/O Serial]]
|N/A
|0x03F8 - 0x03FF
|-
|[[PCI|PCI Configuration]]
|colspan="2"|0x0CF8 - 0x0CFF
|-
|[[SMBus|SMBus (I2C)]]
|colspan="2"|0x1000 - 0x100F
|-
|rowspan="2"|Modem (MC97)
|colspan="2"|0x1080 - 0x10FF
|-
|colspan="2"|0x1400 - 0x14FF
|-
|[[PCI #00.01:0 - ISA Bridge|LPC PM]]
|colspan="2"|0x8000 - 0x80FF
|-
|rowspan="2"|[[SMBus|SMBus (I2C)]]
|colspan="2"|0xC000 - 0xC00F
|-
|colspan="2"|0xC200 - 0xC21F
|-
|rowspan="2"|[[ACI|ACI (AC97)]]
|colspan="2"|0xD000 - 0xD0FF
|-
|colspan="2"|0xD200 - 0xD27F
|-
|NIC (NVNet)
|colspan="2"|0xE000 - 0xE007
|-
|IDE
|colspan="2"|0xFF60 - 0xFF6F
|}

= Emulation =
Code for emulating the memory might consist of:

<pre>
#ifdef DEBUG || CHIHIRO
#define MEMORY_SIZE 128 * 1024 * 1024
int mcpx_active = 0;
#else
#define MEMORY_SIZE 64 * 1024 * 1024
int mcpx_active = 1;
#endif

#define FLASH_SIZE 256 * 1024
#define FLASH_MAP_SIZE 16 * 1024 * 1024
#define FLASH_MAP_ADDRESS (0xFFFFFFFF - FLASH_MAP_SIZE + 1)

#define MCPX_SIZE 0x200
#define MCPX_MAP_ADDRESS (0xFFFFFFFF - MCPX_MAP_SIZE + 1)

uint8_t memory[MEMORY_SIZE] = {0};
uint8_t flash[FLASH_SIZE] = {0};
uint8_t mcpx[MCPX_SIZE] = {0};

uint8_t get_memory_byte(uint32_t location) {
if (location < MEMORY_SIZE) {
return memory[location];
}

if (mcpx_active && location >= MCPX_MAP_ADDRESS) {
return mcpx[location - MCPX_MAP_ADDRESS];
}

if (location >= FLASH_MAP_ADDRESS) {
return flash[(location - FLASH_MAP_ADDRESS) % FLASH_SIZE];
}

printf("Memory in unspecified range: %08X\n", location);
return 0;
}

uint16_t get_memory_word(uint32_t location) {
return get_memory_byte(location + 1) << 8 | get_memory_byte(location);
}

uint32_t get_memory_dword(uint32_t location) {
return get_memory_word(location + 2) << 16 | get_memory_word(location);
}

void deactivate_mcpx() {
mcpx_active = 0;
}
</pre>

The Hidden Boot Code of the Xbox

2024-02-20T23:05:20Z

Prehistoricman: MIST hack is fixed on 1.1

{{retrieved|https://web.archive.org/web/20100617012156/http://www.xbox-linux.org/wiki/The_Hidden_Boot_Code_of_the_Xbox|ours=MCPX ROM}}

or '''"How to fit three bugs in 512 bytes of security code"'''

by [https://web.archive.org/web/20100617012156/http://www.xbox-linux.org/wiki/User:Michael_Steil Michael Steil]

Note: This article is partially incomplete. It is superseded by the more detailed article [https://web.archive.org/web/20100617012156/http://www.xbox-linux.org/wiki/The_Hidden_Boot_Code_of_the_Xbox 17 Mistakes Microsoft Made in the Xbox Security System]

In order to lock out both copied games as well as homebrew software, including the GNU/Linux operating system, Microsoft built a chain of trust on the Xbox reaching from the hardware to the execution of game code, in order to avoid the infiltration of code that has not been authorized by Microsoft. The link between hardware and software in this chain of trust is the hidden "MCPX" boot ROM. The principles, the implementations and the security vulnerabilities of this 512 bytes ROM will be discussed in this article.

<div class="center">'''Missing image'''<br />''Chain_Of_Trust.png'' <br />Image:Chain Of Trust.png<br /><br /> </div>

In short: The memory limitations in the hidden ROM made the system vulnerable in principle. A terribly wrong design and three bugs in the implementation opened three independent backdoors.

== Why a Hidden ROM is Needed ==

The Xbox is an IBM PC, i.e. it has an x86 CPU. When the machine is turned on, it starts execution 16 bytes from the top of its address space, at the address FFFF_FFF0 (F000:FFF0 in 8086 segment:offset notation). On an IBM PC, the upper 64 KB (or more) of the address space are occupied by the BIOS ROM, so the CPU starts execution in this ROM.

The Xbox, having an external (reprogrammable) 1 MB Flash ROM chip (models since 2003 have only 256 KB), would normally start running code there as well, since this megabyte is also mapped into the uppermost area of the address space. But this would make it too easy for someone who wants to either replace the ROM image with a self-written one or patch it to break the chain of trust ("modchips"). If the ROM image could be fully accessed, it would be easy to reverse-engineer the code; encryption and obfuscation would only slow down the hacking process a bit.

A common idea to make the code inaccessible is not to put it into an external chip, but integrate it into one of the other chips. Then there is no standard way to extract the data, and none to replace the chip with one with different contents. But this way, it is a lot more expensive, both the design of a chip that includes both ROM and additional logic, and updating the ROM in a new version of the Xbox if there is a flaw in the ROM.

A good compromise is to store only a small amount of code in one of the other chips, and store the bulk of it in the external Flash chip. This small ROM can not be extracted easily, and it cannot be changed or replaced. The code in there just has to make sure that an attacker can neither understand nor successfully patch the bulk of the code he has access to, which is stored in Flash ROM.

Microsoft decided to go this way, and they stored 512 bytes of code in the Xbox' Southbridge, the MCPX (Media and Communications Processor for Xbox), which is manufactured by nVidia. This code is supposed to be mapped into the uppermost 512 bytes of the address space, overriding the Flash ROM at this position, so that the CPU starts execution there. It includes x86 code for a decryption function with a secret key that makes the CPU decipher (parts of the) "unsafe" code in the Flash ROM into RAM and run it. Without knowing the key, it is practically impossible to understand or even patch the encrypted code in Flash ROM.

== The Code in the Hidden ROM ==

ROM in a multifunction IC is expensive, therefore it has to be small. Microsoft decided it to be only 512 bytes. Microsoft's implementation of the RC4 decryption algorithm fits well in about 150 bytes, so, at first inspection, this should be no problem.

=== The 512 Bytes problem ===

But it is. When the CPU starts up, we cannot simply start decrypting data from flash ROM into RAM. We have to

* initialize the CPU (32 bit mode, caching, segmenting)
* initialize the chipset and RAM so that the machine is in a stable state

While the CPU initialization can be done in less than 150 bytes, the initialization of the chipset and RAM, if done completely, will require more than 1000 bytes of assembly code. Even at a minimum, Microsoft probably did not see a way to fit all this into these 512 bytes.

Therefore it was decided to store some initialization tables in Flash ROM. The Southbridge was modified to read these tables even before the CPU starts running, and to pass these values to the Northbridge and Southbridge components. These tables are fetched from the very beginning of Flash ROM (FFF0_0000) and are 52 bytes long.

But these tables are not enough for full hardware initialization. Tables are just not powerful enough - for memory initialization, memory stability tests have to be made. Putting some x86 code to do this into Flash ROM would pervert the security system, because a hacker could then easily put his own code there.

=== The Xcodes ===

Microsoft decided to create a simple virtual machine that was well-suited for running hardware initialization code, but not much else. They created a tiny interpreter that understands 12 statements, but is not supposed to be powerful enough to take over the machine. As it is secure, this bytecode, called Xcode by the hackers that discovered it, can then be stored in Flash ROM. So the hidden ROM initializes the CPU, interprets the Xcodes stored in Flash ROM to set up the machine and then decrypts and runs x86 code from Flash ROM.

The Xcodes start at FFF0_0080 (at 128 bytes) in Flash ROM. As the Flash can be easily updated in newer revisions of the Xbox, their size needn't be constant; they are typically about 3000 bytes in size, which is about 330 statements.

An Xcode consists of an 8 bit statement, always followed by two 32 bit operands. The virtual machine has a 32 bit accumulator. The following table summarizes possible instructions; all other codes are treated as NOP:

{| class="wikitable"
|-
| 0x02
| PEEK
| ACC := MEM[OP1]
|-
| 0x03
| POKE
| MEM[OP1] := OP2
|-
| 0x04
| POKEPCI
| PCICONF[OP1] := OP2
|-
| 0x05
| PEEKPCI
| ACC := PCICONF[OP1]
|-
| 0x06
| AND/OR
| ACC := (ACC & OP1) OP2
|-
| 0x07
| (prefix)
| execute the instruction code in OP1 with OP1 := OP2, OP2 := ACC
|-
| 0x08
| BNE
| IF ACC = OP1 THEN PC := PC + OP2
|-
| 0x09
| BRA
| PC := PC + OP2
|-
| 0x10
| AND/OR ACC2
| ''(unused/defunct)'' ACC2 := (ACC2 & OP1) OP2
|-
| 0x11
| OUTB
| PORT[OP1] := OP2
|-
| 0x12
| INB
| ACC := PORT(OP1)
|-
| 0xEE
| END
|}

So the interpreter, rewritten in C, looks roughly like this:

<pre>struct {
char opcode;
int op1;
int op2;
} *p;
int acc;

p = 0xFFF00080;

while(1) {
switch(p->opcode) {
case 2:
acc = *((int*)p->op1);
break;
case 3:
*((int*)p->op1) = p->op2;
break;
case 4:
outl(p->op1, 0x0CF8);
outl(p->op2, 0x0CFC);
break;
case 5:
...
case 0xEE:
goto end;
}
p++;
}
end:
</pre>

PEEK and POKE read from and write constants to main memory. OUTB and INB do the same with 8 bit I/O ports. (I/O ports are another address space, 16 bit wide, next to the 32 bit memory address space. While most other CPU architectures control hardware by accessing their registers as if they were memory, the Intel architecture can access some older components through specialized in/out assembly instructions.) POKEPCI and PEEKPCI access the PCI configuration area, by sending the PCI config address to 32 bit I/O port 0xCF8 and accessing the value at 32 bit I/O port 0xCFC. (On PCI-equipped computers, every PCI device has at least 64 bytes of PCI config registers. On a PC, the BIOS or a Plug-and-Play operating system communicates through these registers to find out what resources (memory, I/O ports, interrupts) a device needs and then maps these resources. The I/O ports 0xCF8/0xCFC are the communication mechanism for the PCI config space on PCs.)

The AND/OR instruction can do a 32 bit AND or OR or both at the same time with the accumulator. BNE branches if the accumulator is equal to a constant, BRA branches always. The prefix 0x07 can be used to execute any of the other statements with the accumulator as the second operand. This way, "POKE addr, ACC", "POKEPCI addr, ACC", "BNE PC+ACC", "BRA PC+ACC" and "OUT addr, ACC" are possible. The code 0x07 is handled by the interpreter, and uses a second accumulator, but this code is never used by the Xcodes. The code 0xEE ends the interpreter and makes the hidden ROM go on with the RC4 decryption.

=== RC4 decryption, validity check and panic code ===

After the Xcodes have completed the hardware setup, the machine is in a stable state, so that it is possible to decrypt parts of the Flash ROM directly into RAM and run it there. As mentioned earlier, the RC4 code including the key is about 150 bytes in size. The Xcode interpreter is about 175 bytes, and CPU init about 145 bytes. This leaves only about 40 bytes for a check whether decryption was successful and halt the machine otherwise.

This seems not to have been enough space for Microsoft's engineers to implement a small checksum routine, so they only checked for one 32 bit constant (0x7854794A) at the end of the decrypted data in RAM (0x0009_5FE4). If this is successful, the CPU jumps to 0x9_0000 in RAM, where the new code has been written. This code, the "second bootloader" ("2bl") is about 25 KB in size. It continues initializing the hardware and decompresses the kernel from Flash ROM.

If the decrypted value is not correct, the CPU is supposed to halt. Simply using the "hlt" opcode would mean that the machine would remain turned on and idle with the hidden ROM visible in the address space. A hacker could then use some hardware attached to the chipset that extracts the data from ROM from a running machine. The designers therefore decided to always turn off the hidden ROM as soon as possible in both branches, when decryption was successful (then it is turned off as one of the first instructions in the "2bl" code), and if it wasn't.

But making the CPU crash and turning off the ROM it is running in is a challenge. If we halt the CPU, we cannot turn off the ROM afterwards. If we turn off the ROM, we turn off the code that gets run and we cannot halt the CPU - even worse, the CPU would continue fetching its opcodes from the underlying Flash ROM as soon as the hidden ROM is deactivated.

Microsoft's developers came up with a very interesting trick: They led execution to the absolute top of the address space, and as the very last instruction, they turn off the hidden ROM. Then the instruction pointer is supposed to overflow from FFFF_FFFF to 0000_0000 and an exception is supposed to be generated which in turn is supposed to halt the CPU because no exception handler is registered.

<div class="center"><img src="https://web.archive.org/web/20100617012156im_/http://www.xbox-linux.org/pic/memorymap.png" alt="memorymap.png" /></div>

== Security Issues ==

This system looks pretty secure. If we don't know what's going on, it is a lot of work to find out that there is a hidden boot ROM (but it's easy to prove because the Xbox still boots if you overwrite the upper 512 bytes of Flash ROM since they never get used). If we don't have access to the boot ROM, we cannot decrypt and thus cannot understand the code in Flash ROM. Because we don't know how to reencrypt, we cannot patch the code in Flash.

=== The Importance of the Secret Key ===

But what happens if someone finds out the hidden 512 bytes? [https://web.archive.org/web/20100617012156/http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html Bunnie] did, Christmas 2001. He tapped the bus between the Southbridge (where the secret MCPX code is stored) and the Northbridge (the CPU's memory interface) where all secret data gets transmitted. The compromise to store the secret ROM in the MCPX instead of the CPU, so that data would travel over a bus, finally broke the system. Knowing the algorithm and the secret key, he could easily disassemble the whole code in Flash ROM, and he could have even patched and reencrypted the code - the decryption code won't notice the difference, as the Flash ROM is not hashed: Only a single 32 bit value is checked. Modchip makers, who used similar tricks to get hold of the hidden ROM, used this knowledge to create patched versions of the Flash ROM image and distributed them on boards that, soldered to the Xbox motherboard, overrode the onboard Flash ROM.

=== Security Measures in the Hidden ROM ===

So as soon as the encryption algorithm and the key are known, everything is possible? Not quite. In order to create a working Flash ROM image, you have to use Microsoft's secret key, which is considered illegal under certain jurisdictions. So for a completely legal replacement Flash ROM image that takes over the machine to be free to run any homebrew software or alternative operating systems, a complete security analysis had to be made.

Since the hidden code depends in some way on external data, stored in Flash ROM, which can be quite easily changed by the user, it may be attackable through certain data stored there. Microsoft understood this danger and added some precautions so that the Xcodes could not be abused - supposedly - in case the secret ROM was known.

==== PEEK ====

The Xcode language is powerful enough to easily read and write memory, the PCI configuration space as well as I/O ports. The user could easily add Xcodes that read the hidden MCPX ROM and send the data to some I/O ports, e.g. the I2C bus. Therefore all memory reads are limited to the lower 256 MB:

<pre> and ebx, 0FFFFFFFh  ; clear upper 4 bits
mov edi, [ebx]  ; read from memory location op1 into di
jmp next_instruction
</pre>

==== POKEPCI ====

Turning off the hidden ROM is done by the following statements:

<pre> mov eax, 80000880h
mov dx, 0CF8h
out dx, eax
add dl, 4
mov al, 2
out dx, al
</pre>

This code sets bit #1 in the PCI config space, device 0:1:0, register offset 0x80 (coded in 0x80000880).

Using the POKEPCI instruction, it would be possible to disable the hidden ROM prematurely, so that the underlying Flash ROM, which is normally overlapped by the secret ROM, would be visible, and CPU would continue running there, where the hacker could simly store his code:

<pre> POKEPCI 0x80000880, 2
</pre>

Therefore the interpreter always clears bit 1 if the Xcode wants to write to 0x80000880:

<pre> cmp ebx, 80000880h  ; ISA Bridge, MCPX disable?
jnz short not_mcpx_disable ; no
and ecx, not 2  ; clear bit 1
not_mcpx_disable:
mov eax, ebx
mov dx, 0CF8h
out dx, eax  ; PCI configuration address
add dl, 4
mov eax, ecx
out dx, eax  ; PCI configuration data
jmp short next_instruction
</pre>

==== Halt ====

As described earlier, if the hidden ROM detects that decryption was unsuccessful, it halts the CPU and turns off the hidden ROM by turning it off as the very last statement in the CPU's address space, causing an address overflow exception and thus a CPU halt in the very next cycle. This is supposed to make it impossible for a hacker to extract the hidden ROM contents, because the hidden ROM is always turned off very quickly, even if the machine does not boot correctly.

<pre> mov eax, ds:95FE4h
cmp eax, 7854794Ah
jnz short bad_checkcode
mov eax, ds:90000h
jmp eax  ; jump to decrypted second bootloader in RAM
bad_checkcode:
mov eax, 80000880h  ; prepare MCPX ROM disable
mov dx, 0CF8h
out dx, eax
jmp far ptr 8:0FFFFFFFAh ; jump to end of ROM, wraparound
[...]
FFFA: ; this is address FFFFFFFA
add dl, 4
mov al, 2
out dx, al
; ------ this is address 00000000 ------
</pre>

=== Security Flaws in the Hidden ROM ===

While these three security precautions that have just been described are indeed vital, two of them are faulty. The POKEPCI check is incorrectly implemented, and the somewhat clever "Halt" trick, which was supposed to lock out hardware sniffers, opened a software backdoor.

==== The Visor Trick ====

The roll over of the instruction pointer from FFFF_FFFF to 0000_0000 is supposed to generate an exception. Since no exception handlers are installed, this is supposed to halt the machine. But in reality, no exception is generated. Execution just happily continues at 0000_0000 - in RAM! Apparently the i386 CPU family throws no exception in this case, Microsoft's engineers only assumed it or misread the documentation and never tested it.

By adding Xcodes to write a jump to some Flash ROM address, like FFF0_0000, into memory at location 0, and causing the decryption check to fail by just not including the 32 bit check value into the Flash ROM, one's own code will be run right after the RC4 decryption:

<pre> POKE 0x00000000, 0x001000B8 ; store "mov eax, 0xFF001000; jmp eax"
POKE 0x00000004, 0x90E0FFFF ; at 0x00000000 in memory
END
 ; now we can place our code at 0x1000 in Flash
</pre>

==== The MIST Trick ====

POKEPCI's check for 0x80000880, the address of the configuration register to turn off the hidden ROM, is incorrect. The Southbridge, which decodes the 32 bit value into "bus", "device", "function" and "register" and sends the funcion and register numbers to the specific device on the specific bus, simply ignores the unused bits of that 32 bit value, so 0x88000880 or 0xF0000880 behave exactly the same as 0x80000880 - but POKEPCI's check does not detect them. So this check even gives the attacker a hint how to circumvent it.

By adding the statement POKEPCI 0x88000880, 2 to the Xcodes, the interpreter will turn off the hidden ROM - where it is running itself! As soon as the CPU cache has run empty, execution will continue somewhere between FFFF_FE00 and FFFF_FFFF in Flash ROM. You can simply fill everything with NOPs and add a JMP to your own code at the very top.

==== More Attacks? ====

Since two methods to circumvent the Xbox hidden ROM security without touching any crypto both work equally well, there has been little need for further research, but there might very well be more than two security issues in these 512 bytes. There are two more approaches for attacks that we do not want to disclose yet, as Microsoft may still offer updated Xboxes in the future.

== Microsoft's Fixes ==

In August 2002, Microsoft started manufacturing V1.1 Xboxes, which had been improved in many ways. In concerns of security, the hidden ROM and the MCPX' PCI config behavior had been updated (the MCPX revision is "C3" instead of "B2"): They now squeezed a TEA hash into the 512 bytes, replacing the old 32 bit test. The "2bl" code now couldn't be altered easily. And they changed the RC4 secret key.

But although they had the possibility to patch their design, Microsoft again failed to make the Xbox secure this time:

* They left the Visor backdoor wide open.
* The TEA hash has been a bad choice. If they had even read Schneier's "Applied Cryptography" (''the'' book on crypto), they would have known that TEA is insecure if used as a hash. This can be easily exploited so that 2bl changes remain undetected, leading to the third bug in the second implementation.

It is pretty obvious that the changes had been made in reaction to Bunnie's hack, who retrieved the secret key for the RC4 decryption, and before the Visor or MIST bugs had been found.

In May 2004, Microsoft started shipping Xboxes that had the ROM image, the video encoder and the security chip (SMC) integrated into a single package, so that it was no longer possible to overwrite the firmware. The secret ROM in the MCPX was still the same though. But as of November 2005, it is still possible to attach a replacement ROM to the LPC bus ("modchip") of new Xboxes, as the verification weakness is still there.

== Microsoft's Strategy ==

Microsoft's engineers first seem to have thought that the secret key would never be revealed: security by obscurity. This explains why the decrypted code did not get hashed. Once the secret key was known, anyone could decrypt, patch and reencrypt the flash contents.

So when the secret key had been extracted, Microsoft understood that it could be done again with another key very easily, so they added a hash function over the decrypted code. If the new secret key was to be found out again, attackers should at least not have had the possibility to change the code. Changing the key introduced no security, but was easy to do and at least required attackers to repeat the ROM extraction process.

== Conclusion ==

The design of the first MCPX was very wrong, and the implementation was catastrophic. The design of the second version was a lot better, but the implementation was not.

Without the various security holes (Visor and MIST bugs as well as possibly more) and with a working hash function, the system would have been pretty secure. Encrypting the ROM contents with a secret key, i.e. security by obscurity, simply does not work if the key travels over a bus that can be sniffed.

So with the first version of the MCPX, Microsoft was too naive and apparently did not understand basic security concepts. After they had learnt their lesson, they designed a pretty good system with the second version of the MCPX - but the implementation still contained at least three security holes (Visor, MIST, TEA). They were too fast releasing a new version of the MCPX, spending a lot of money in trashing tons of already manufactured MCPX chips and manufacturing updated ones, apparently without any further code audit which should have revealed the security holes.

512 bytes is a very small amount of code (it fits on a single sheet of paper!), compared to the megabytes of code contained in software like Windows, Internet Explorer or Internet Information Server. Three bugs within these 512 bytes compromised the security completely - a bunch of hackers found them within days after first looking at the code. Why hasn't Microsoft Corp. been able to do the same? Why?

==Links==

* [https://web.archive.org/web/20100617012156/http://www.xbox-linux.org/ The Xbox Linux Project]
* [https://web.archive.org/web/20100617012156/http://hackingthexbox.com/ Hacking the Xbox]
* [https://web.archive.org/web/20100617012156/http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html bunnie's adventures hacking the Xbox]
* [https://web.archive.org/web/20100617012156/http://web.archive.org/web/20021208233956/http://65.108.63.67/visor/ visor's aXventure]