XBOX MODCHIP DESIGN DISCUSSIONS

The project has the potential to be very complex, but the good part is that I can borrow a lot from my other embedded projects. In fact, the only new piece of code I developed for the demo above was an LPC HOST ip to allow me to program the SST49LF160C. I already have the SST49LF160C working with the Aladdin XT's from eurasia. I just have to finish up on incorporating the drivers for the SST49LF160C into XBLAST OS. That will take sometime as I have to understand how XBLAST OS is structured so I can make the required modifications.

 

Along the lines of looking at alternative memories for xbox modchips, I was curios if the xbox lpc host actually reads its 1MB ROM sequentially from base address 0xFF000000. If it did, then it is possible to utilize NAND flash in modchips instead of LPC flash that is quickly becoming obsolete.

It turns out that the xbox does not read its ROM sequentially from 0xFF000000. I found this out by incorporating a feature in my lpc_device sources above that allowed my to log the lpc addresses requested by the xbox lpc host. Below are the first 256 addresses ranges requested by my v1.4 xbox:

1. 0xFF000070 - 0xFF000077
2. 0xFF000000 - 0xFF000003
3. 0xFF000008 - 0xFF000033
4. 0xFF000080 - 0xFF000146

My observations are in agreement with https://web.archive.org/web/20050309231722/http://warmcat.com:80/milksop/x.html. I don't know if this is the same for all xbox versions, but it will be interesting to find out.

This is exciting as it makes it possible to use very cheap NAND flash in xbox modchips. You will need to re-order the bios files according to the full range of addresses requested by the xbox, but this is a minor step.

 

I'd say that all Xbox's with MCPX 1.0 would have one load order and MCPX 1.1 another.

As MS changed the boot-up code, these 512 bytes are different between the two versions of MCPX's. Not sure how much the order of BIOS data loads changed.

 

Thanks, I will investigate further.

Another interesting find is that the MCPX does not request 1MB of ROM: it is much less. This is evident since some memory addresses are missing. For example, 4 bytes from 0xFF000004 - 0xFF000007 are not included.

 

Adding support for read/write in XBlast OS for the 160C might be very easy, if it's not in there already! Looking at the datasheet of the 160C, it seems it uses an alternate command set more related to Sharp flash devices (identified as 28xxx protocol in XBlast OS). The 49LF160C is already in the list of supported flash devices (flashtypes.h). In FlashLowLevel.c, the necessary code is there to handle Sharp's 28xxx protocol. You'd have to double check if the 49LF160C is fully compliant with the same command set. You could try to add block erase command (64KB erase) as I think I did not implement it for 28xxx targets, only 4KB erase (which is in fact the 64KB erase in real Sharp TSOP) is in place.

Possibly, there would be any work involved in it. You'll notice that this device in XBlast OS is reported as a 1MB flash device and it is normal. The MCPX can only access 1MB of memory mapped ROM space. From memory, trying to read the second 1MB part of the mapped area just mirrors the first 1MB of data.

Makes sense, 0x70 - 0x77 contains MCPX config registers, first DWORD of the image is to determine wether there is valid data on the selected BUS line and switch BUS (from TSOP to LPC for example) if need be.

I don't know what's in 0x08 - 0x33, probably more MCPX init once it has established a image is present.

Finally, everything read from 0x80 and above are X-Codes interpreted by the boot rom inside the MCPX. The length of this area is variable depending on the BIOS. M8+ is very long, XBlast OS is medium (goes from 0x80 to 0xECF) and most other BIOSes are shorter and more straightforward. I don't think reading of this section is necessarily sequential. Stock BIOSes and most early hack BIOSes are pretty straighforward and will execute these sequentially but more complex X-Codes (like on XBlast OS and M8+) have GOTO (ie. jump) instructions that makes the code hop over certain sections depending on the video encoder detected. This makes the read of this section non sequential as I don't think the MCPX copies the entire X-Code area into memory as it is variably sized. The boot rom most likely blindly execute
the codes has it is going through them and exits when it reaches the "xcode_END()" instruction. If you want to reorder the BIOS file to make it sequential, you'll need to make sure to include the entire X-Code range then.

If you're up to it, you could try loading a stock BIOS, M8+ and XBlast Lite on different Xbox revisions. I know for sure that XBlast OS on a Xbox with a Connexant encoders will have jumps in their X-Codes sequences but then again, I think they all do. Check "2bBootStartup.S" source file for X-codes execution sequence. I've added comments on what I assume it does.

I don't think there's much changed in the way the boot rom works in the MCPX. Sure the 2bl encryption algo changed from RC4 to TEA hash but that's about it. Anyway, execution of the boot rom is really short lived. I'd be more concerned about how the 2bl handles reading the compressed kernel. Not all BIOSes use the same 2bl. Again, stock and most early hack BIOSes have the same 2bl but cromwell-based and M8-based have their own custom implementation of 2bl. M8-based BIOSes also include X2 5xxx and X3 BIOSes (1.6/1.6b image at least, not sure about 1.0-1.5).

 

Thanks for the info. Indeed, the 49LF160C is already on the list of supported devices. Just need to make sure the drivers are complaint as advised. I need to spend more time with the XBLAST OS sources to be familiar with its capabilities.

A ton of info to digest. Great stuff!!

 

From my learnings so far on Xbox Modchip design, I have been able to put together 2 different designs to share with the community.

These designs are still in the early stages of development but they can help guide anyone interested in xbox modchip development. The first design is based on the LC4064 CPLD, which is the same CPLD used in the popular modchips. I was able to break out all the IO so there is enough IO to be creative with features. In addition, it supports all the microchip LPC flash devices and you do not need modify the vhdl sources. Below is a video of the modchip in action:


For the second design, I chose the Intel (Altera) Max V CPLD with TSOP flash instead of the usual LPC flash. The TSOP flash is 2MB and is readable/writeable from the LPC interface of the modchip. The Max V CPLD is the 5M160Z with 128 Macrocells. I also was able to break out all the IO. A video of the modchip is shown below:


I will be releasing the design files and the vhdl sources shortly.

 

I would like to add that cost wise, both designs are less than $10; including the price of the PCB.

 

I assume you mean tsop flash, the cpld is the qfp device.

But good work and extra thanks for the up coming source/design files!

 

Thanks for the correction, I must have been sleeping on the page. In addition, I want to stress that both designs are not final and are still prototypes. I am releasing the design so that they can be used as a starting point for a final design. Whenever I have some time, I will add features such as D0 support, LPC IO for the LCD, OS support e.t.c, and perhaps finalize the design.

 

Good work monk u've come quite a ways with this

 

If you need more info on those, don't hesitate to ask. I've done my share of research on the best way to interface d0 and LFRAME (On 1.6/1.6b).

For LCD IO mappings, I suggest you use the same layout as SmartXX did for their V1 and V2 devices. To my knowledge it's the most widely used "standard". It's the same mapping used by the Aladdin XTs 4064 with LCD port, LCD-MOD and lastly XBlast Lite. I know IND-BIOS Feb Beta (dubbed version 5004) do output data on the LCD using SmartXX mappings, I don't think it does it for Xecuter3 or Xenium mappings.

 

Yes indeed. Just a few months ago I had no idea how xbox modchips work, let alone to design one. My only advantage was my background in electronics/computer engineering/embedded systems and the various tools at my disposal. Now my biggest challenge is finding/making time to work on this and on other consoles .

 

Thanks, I have come across several discussion where you talk about the best way to control the LFRAME signal on v1.6/1.6b consoles. I certainly agree that, and it make sense to drive LFRAME high only during the start of the LPC cycle. I believe the same goes for d0: drive it low until first access to the LPC memory.

Unfortunately, I do not have a v1.6/1.6b to test with. By releasing my design to the public, I hope to get others to contribute especially with testing on different versions of the XBOX. In addition, I think it is a great idea to align with any standards/formats that are available; both for LCD IO support and OS support. I just have to find the time to work on this some more.

 

As promised, I am uploading all the design files (Schematic and layout + FPGA project files with sources) for both XBOX modchip designs from above. The Schematic and Layout of both designs was done using DIPTRACE (http://diptrace.com). The freeware version is good enough for most modchip design projects. In addition, DIPTRACE is also very intuitive with a very minimal learning curve compared to EAGLE.

For the design implementation of the LC4064 CPLD, I used Lattice ispLEVER Classic software. The complete ispLEVER project is attached. This will make it convenient for anyone to learn and customize as they get familiar with the tool. Also, I use the Lattice Diamond Software programmer with a FTDI C232HM (https://www.digikey.com/product-det...tional-ltd/C232HM-DDHSL-0/768-1106-ND/2714139) cable for programming. This is because I run ispLEVER on a Linux platform using wine and do not have usb access to the default programmer for ispLEVER. If you run on Windows, then you do not have any problems using just ispLEVER and its supporting programmer.

The NOR Flash based design uses the MAX V CPLD from Intel. I used the free Quartus Prime Design Software and associated tools. In this case, there is support for Linux and Windows.

I hope someone will find these very useful and improve upon these designs.

 

Awesome, thanks for sharing.

 

For soldering, I would recommend the use of tacky flux. It is very convenient for the QFP CPLDs and SOP Flash. I was able to solder the LC4064V CPLD is under 2 mins. The best thing about using tacky flux is that you don't need a wick: the solder will flow very easily around and under the pins. You can find lots of videos on YouTube that will guide you.

 

If that was directed at me, I have soldering covered.

 

No, it was meant as a general comment for folks that are beginners in soldering. Another important comment is that the MAX V CPLD has an exposed pad that is the grounding pad (GND). I got about soldering it by flooding the via underneath the MAX V CPLD with solder paste and heating the paste with a soldering iron. This was done right after I finished soldering the other pins in the QFP package.

 

Nice work.

Just a suggestion. As there is no LFRAME signal coming from the Xbox to reset the LPC FSM, you should passively follow along any LPC transaction the Xbox supports instead of resetting the LPC FSM when getting a CYC nibble you don't support. To my knowledge, the MCPX will only generate Memory Read/Write and I/O Read/Write transactions.

There's a small risk that your LPC FSM might de-synchronize if you ever receive a LPC IO transaction with a X"0" followed by a "01xx" somewhere in it. On bootup, it is highly unlikely (even impossible unless severe electrical interference I guess) but it might be more frequent once the system is running and something periodically sends LPC IO transactions, like when you enable LCD in XBMC4Xbox. Granted the FSM would ultimately reset and the problem would correct itself but there is the possibility of having a moment when the MCPX and the modchip both tries to write on the LPC bus at the same time, which is not good.

Concerning handling LFRAME on 1.6(b), you just need to output the LFRAME signal you regenerated to a high speed, high current driver (I used a SN74LVC125 which has a T_enable of 4.6ns at its worst, I toggle the /OE line, A input is connected to 3.3V). Just make sure to include timing constraint rules that ensure the entire function block that handles LFRAME gets prioritized for speed during placement.

For D0, things are a bit easier. Just tie up d0 output from the modchip to a high current driver and enable the driver's output when LPC_RST = 0 (or rising edge) until the end of the first Memory Read transaction. Reset state on LPC_RST. You could just disable it on first CYC reception but doing it after a full memory read cycle, you're kinda sure the d0 grounding only is disabled once a BIOS as started to be read from the modchip. In practice, on bootup, the Xbox will only generates Memory Read transaction so it's really up to you; you don't really need to wait that long to release d0. In my modchip design, I did it on CYC reception and I never had any issue; but in retrospect, I should have done it the way I describe it. It's cleaner.
You could also just leave it grounded as we can assume the MCPX just release the ISA bus connecting the TSOP once it switches over to LPC. But hey, have a little fun!

I suggest you put your work on GitHub or Bitbucket. That way people could contribute to the effort.