ryzee119/openxenium

OpenXenium - Open Source Xenium Modchip CPLD replacement project for the Original Xbox

OpenXenium

About this Repository

This is an open source recreation of an Original Xbox LPC memory/IO device. Generally known as a modchip. The VHDL is 100% compatible with XeniumOS, which is a legal non-Microsoft based bootloader made by TeamXodus for the Original Xbox. This allows loading user BIOS binaries and some basic Xbox tools (EEPROM Backup/modification, Hard drive Rebuilding, Locking, Unlocking, FTP access).

The VHDL written by Team Xodus was never released and the CPLD is read protected so it is not trivial to extract the bitstream. My own VHDL is probably quite similar to what Team Xodus produced for the Xenium Modchip but I have independently reverse engineered the behavioral design on the CPLD. (There was no bypassing of the protection features of a genuine Xenium.) Therefore I have named this project OpenXenium. An open source recreation of the Xenium CPLD released under GPL which documents the internal workings by means of open source VHDL of the Xenium Modchip.

I do a quick run through of the build process here: https://youtu.be/P6YYViKby74

To manage your OpenXenium device's flash memory, the Xenium-Tools homebrew program has been moved here.

Supported Features

The VHDL implements the following LPC transactions:

• Memory Read/Writes (Translated to a parallel flash memory interface)
• IO Read/Writes

From an Original Xbox perspective, this covers all requirements to make a custom LPC memory/IO peripheral for the console. Colloquially known as a modchip which can load custom BIOS files like Cromwell and its derivatives without modifying the onboard TSOP flash memory or softmodding. This supports IO control for accessories like LCD screens, LED controllers, external switches etc.

When used with XeniumOS the VHDL in this repo supports the following features:

• Software controlled BIOS bank switching (any BIOS combinations that fit into 1mbyte of flash memory (4x256k, 1x512+2x256k, 2x512k, 1x1mbyte).
• Instant boot to a chosen BIOS using the power button.
• Boot the XeniumOS with eject button.
• Ability to boot from the onboard BIOS (colloquially known as TSOP booting). This will completely disable OpenXenium and release D0/LFRAME(1.6) to boot the Xbox as if stock.
• All the standard features in XeniumOS. (EEPROM tools, Hard drive tools, FTP/SMB Server etc.).
• Three general purpose outputs. These are normally bitbanged as a SPI master (MOSI,CLK,CS) with the most common use an LCD, however could support any SPI peripheral in theory.
• Two general purpose inputs. On a Xenium, these are I believe intended to be MISO lines to complement the SPI interface but could be used for any 3.3V digital logic.
• Three outputs are connected to an RGB led (Or an external user added RGB led).
• Reserved memory on the flash chip for non-volatile storage of an EEPROM backup and XeniumOS settings.
• If you bridge the two recovery pins on power up, it will attempt to boot the XeniumOS recovery BIOS if available. This functions the same as a genuine Xenium modchip.
• I also simulate the LFRAME abort mechanism (Ref Intel LPC Interface Spec Rev 1.1 Section 4.2.1.13) so that this will work on a v1.6 Original Xbox. This aborts the LPC transaction to prevent the Xyclops responding to the MCPX LPC Memory Read requests during boot (and conflicting with an external LPC memory peripheral). This is generally accepted to be better than shorting LFRAME the ground constantly which some traditional Modchips do.

XeniumOS BIOS

The recommended way to get a copy of XeniumOS is to take a backup of your own Xenium modchip using Xenium-Tools. It is also possible to parse the v2.3.1 XeniumOS update files released by Team Xodus to extract the neccessary data; however this will not contain the factory programmed recovery sector, but otherwise works in the same way.

This has been tested with XeniumOS 2.3.1 (Last release) and XeniumOS 2.3.1(Gold variant). The only way to obtain Gold OS is to dump the flash contents of your XeniumGold as the binary files were never distributed individually.

Installation and Initial Setup

See Installation.MD

Licensing

OpenXenium is free and open source. Please respect the licenses available in their respective folders.

• Hardware is shared under the CERN OHL version 1.2..
• Firmware is shared under GPLv3.
• xenium-tools was made with NXDK and is shared under GPLv2.

References that helped me in this project

• Intel LPC Spec
• NXDK
• AladdinLCD Github Repo (CPLD LCD Driver)
• LPC Analyser Plugin
• Deconstructing the Xbox Boot ROM

If you like my work please consider a small donation

By Ryzee119

openxenium's Issues

XeniumOS graphical issue on v1.6 Xboxes

EDIT: This can be fixed by an unofficial patch: https://github.com/MakeMHz/xenium-fw-update

On some 1.6 consoles when booting into XeniumOS, there is a graphical issue which results in vertical lines across the screen.

It is suspected this is a bug in Cromwell's Xcalibur or GPU initialization code. This issue is present on my Genuine Xenium and my OpenXenium boards running XeniumOS v2.3.1.

There have been instances of a reflow of the LPC resolving this issue but it is unclear what the root cause is.

No functionality is impacted and once booted into a 1.6 compatible bios the issue is no longer present.

You can work around this by using XeniumOS 2.0.0 and 2.2.1. For the most part these have all the same features.

S29AL016J70TFI02 Not working

Hello Ryzee119.

Got a lot of S29AL016J70TFI02 chips, but it does not seem to work with the openxenium.
I use a programmer on my pc to program the chips, this always works with the S29AL016J70TFI01 chips.

But now on the S29AL016J70TFI02, it boots (sometimes), will take a while too load the menu, but when booting a bios.
it will hang, and it looks like the chip is empty.(after desoldering the chip again and dumping it)

Is there a way to make openxenium work with the S29AL016J70TFI02 ?

Regards,

Nextria

1.6 with 128MB RAM unable to boot.

I've noticed since using the 1.4 release, the 1.6 boards that I've been upgrading to 128MB RAM are unable to boot. When powering on the console, the LED on the OpenXenium will start it's cycle and stop on solid blue. The front LEDs on the console will be flashing green until powered off.

Long story short, I ended up testing various different chips (Aladdin, Authentic Xenium, X3, X2, & CheapMod). They all seemed to work okay booting the console. I had another OpenXenium on the 1.3 release and decided to test to find out that it loaded XeniumOS just fine.

To verify that it was indeed the 1.4 release causing the issue. I decided to do something sketchy (Don't recommend) of connecting the CS lines while xBlast 0.60 was booting. This showed the RAM install works after getting past the OpenXenium boot process. Then I took the same chip that had 1.4, reflashed to 1.3, and now the console boots reliably.

I'm not sure if this is the case for all 1.6s with RAM upgrades, as I don't remember running into this issues until this week. Maybe I finally ran through my stash of 1.3s, possibly only select 1.6s, or some tolerance thing with the RAM upgrade?

Potential replacement for Spansion S29AL016J

Hiya,

I think it's not a secret there's a global chip shortage. I had foolishly assumed one could just get any TSOP48 parallel chip, like Macronix MX29LV160DBTI, and build away based on that. Realization came very late - there are constants in xenium tools and elsewhere (e.g. xenium-programmer) that look for 0x01 0xc4 explicitly and thus the hardware is not classed as a xenium device.

Do we have something remotely similar to S29AL016J readily (albeit at a higher cost) available these days? Farnell has Spansion chips on preorder due late March 2022, Digikey barely has any, looking more likey they actually don't.

Xenium-Tools font changed with latest NXDK

NXDK was updated (XboxDev/nxdk@e25923b) to change the default debug font to something more readable and consequently larger.

This will impact how Xenium-Tools currently renders and likely causes text to overlap or go off screen.

Until I fix this, you can use the pre-compiled versions from Releases or build with an older NXDK tree

How to retrieve eeprom backup without hd

I'm having HDD problems, so I'm wondering how to get the EEPRom off the chip?

Program XeniumOS without need for modchipped Xbox

Hi there,

Is it possible to have a way of programming XeniumOS to the OpenXenium without needing a modchipped Xbox? I want to build one myself from scratch, given that I don't have a modchip and modchip prices are greater than I would like. Building one from scratch would be cheaper, however, impossible if I cannot program XeniumOS onto it without having a modchipped Xbox.

Would it be possible to program the software onto it using something such as an Arduino or Pi Pico?

Kind regards,

VoxelTek

XeniumOS: v1.0 Xboxes 'frag' when booting Cromwell/Xblast from XeniumOS

There appears to be an incompatibility with XeniumOS and Cromwell that is specific to version 1.0 Xboxes. Im yet to see a report with another version Xbox.

When attempting to boot Cromwell or its derivatives (Such as XblastOS) on a 1.0 Xbox via OpenXenium the xbox will frag (Flashing Red And Green eject button).

This is a known issue as far back as 2004 (From https://tinymicros.com/wiki/Gentoo_Linux_On_An_Xbox)
VERY IMPORTANT: As of 2004/10/27, v1.0 Xboxen with Xenium ICEs can only use Cromwell BIOS 2.30 and BELOW. This limits you to using 2.4 verison(sic) kernels. Cromwell 2.31 and higher changed the memory map so that 2.6(sic) BIOSs can be be used. The problem with the Xenium on v1.0 boxes is believed to be a CPLD issue. The problem shows up when trying to start the 2.31+ BIOS. The box will power cycle twice, and then FRAG (Flashing Red And Green eject button). This may or may not be fixable. If you have a v1.1 or higher XBox, you won't have to concern yourself with this issue.

It claims it could be a CPLD issue, but I believe its an issue with Cromwell initialization being incompatible with XeniumOS previous initialization which causes some a conflict.

Workaround is to use Cromwell 2.30 or below.

Issue with superio when lframe is shorted to d0 point like in a 1.6 install

When I tried to use a superio serial board in a 1.6 console with the 1.6 jumper shorted, the superio board refused to work. This went away when the jumper was cut. I'd take a guess that the lframe cancellation for the xyclops rom is also cancelling the calls to the superio board.

Schematics not readable for everyone

Hi! 🙋‍♀️
Hope your are alright, haven't read you a long time!

I wonder if you could provide the schematics in a more accessible format? Currently it is only provided in a non-free, highly specialised file format. I would love to see some *.svg or *.pdf.

Typed with love,
Teufelchen

Xenium Blue

Hi.
It is a very interesting Project. I have a issue with my Xenium chip it is a Xenium blue chip
My xbox is V1.4 with winbond Bios chip and Focus Video Decoder chip. My xbox is tsoped with xecuter 2 vga bios. I have a Xenium blue chip my xbox didn't detect it. I tried hot swap and direct install method but it didn't detect it. BTW Xenium tools 1.1 and 1.0 works on my Xbox without any modchip. I didn't have jtag programmer. Is there any way to program CPLD without JTAG? I have tried everything else. Can you help me?

Thanks in Advance.

XeniumOS hangs without DVD drive

XeniumOS 2.3.1 can hang when attempting to flash a bios when you dont have a DVD drive connected.
This can also impact FTP browsing (will fail to retrieve directory listing)

As the source code for XeniumOS is not available, this type of thing is tricky to fix, but the issue is documented here for information.

The current work around is to ensure you have a DVD drive connected to setup XeniumOS. No DVD drive is needed to just boot into pre-flash bioses.

XeniumOS, password protection

There's an option is XeniumOS v2.3.1 to enable a password but never asks you to set a password or tell you what the default is.

The password is not in the manual but has been dug up through some old links:

• XWAY - (X White A Y)
• or UUDDLRLRBAS (Konami Code)

Thanks for finding that info kaos.

it'll be in a boot loop.

If you have a default BIOS, it'll reboot into that dash which gives you a chance fix with Xenium-Tools, otherwise you must be the recovery jumper with recovery.bin at the root of E, or burnt to a DVD.

FRAG with Hitachi-LG drive connected

Xenium OS boots without a DVD drive, it boots with a Thomson drive, but FRAGs when Hitachi-LG drive connected. FRAG occurs when pressing either eject or power. Hitachi-LG DVD drive thoroughly tested after refurb, on non-modded system, works without issue. This is a 1.6 system.

not really an issue

Hi !
JLCPCB made a mistake and send me 100 of your PCB for your openxenium project...
Do you need them (i'm in france)

Just send me a message arnoz @ arnoz . com

More than 64mb of RAM but less than 128mb

I don't know if this is an issue, a potential feature request or just something I need to deal with, but I installed the Open Xenium chip today and I setup Xblast OS so that I could test RAM chips as I installed them. However, I came to the realization that I didn't set Xblast OS as the default kernel before installing the first chip. My Xbox no longer boots to Open Xenium.

My question is, should it boot regardless of RAM or is that not something it handles?

If it is handled by Open Xenium, I guess I have an issue with my RAM chip installation.

I doubt there is any bypass to boot Xblast OS, but if there is, let me know.

iMPACT project file missing.

When you implement the Top Module and clicking on Tools >> iMPACT, it complains that there is no iMPACT project file.

I guess you would need to create a new iMPACT project by using a JTAG boundary scan?

Pcbway issue

Pcbway says they can not proceed due to an issue with soldermask *(see pic)

Subject: PCBWay- EQ of order W539954AS2D1_OpenXenium-ddff195-gerbers

Hi,
There is a engineering question of order W539954AS2D1.
As shown, the spacing between IC pad is only 0.12mm, we can not do the solder mask bridge.
Please check is it ok to do whole opening for this area?

Any suggestions

Thank you

Support for Bottom Boot Flash devices

Hi, i wanted to ask if it is possible for you to add support for bottom boot flash chips?

I have a bunch of them here, that works normally when reading from it, but writing from the console is the big problem, because of the flipped sectors and the shifted address space.

Like a translation layer between the consoles normal top boot flash sectors and the bottom boot flash sectors. E.g. sector SA34(bottom) == SA0(top), sector SA33(bottom) == SA1(top), etc. And redirecting the addresses for read and write to the specific sectors. So that the CPLD behaves like with a Top Boot Device?

Page 14 and 15 from the Datasheet.

greez.

iND-BiOS.5004.67 Refuses to boot until re-Flashed

I have had this issue a few times now with my Open Xenium chip where I'll reboot my Xbox, which defaults to the XeniumOS boot, and then I'll select iND-BiOS.5004.67 which was previously working and nothing will ever show up on screen and the Xbox will not boot. If I reboot and reflash it, it works fine.

This has happened three times now in a short period of time (one night). I changed to iND-BiOS.5003.67 to see if that made a difference but I haven't used it enough to know if it's something failing with the bios or the chip. I also have XblastOS loaded as an option and it works every time and has never failed.

README.md slight typo

Hey there,
The README.md has a slight issue, in that it says section 4.3.1.13 is the section in the LPC spec document is where the LFRAME ABORT mechanism is documented. However, this is actually found in 4.2.1.13. Figured I might as well mention this.

Kind regards,
VoxelTek