MrBriteSide

I see what you're saying. The one thing im just questioning is does anyone know what the actual difference between the two is? I've seen on XboxDevWiki there are numerous versions listed, but nothing saying on effectively what the difference between each version even is other then dev/debugs have this retail have that. No one seems to have hooked a bus sniffer to the I2C lines and even see whats going on during boot-up between the consoles. Even so, with the retail PIC on the board, would you not be able to take a Gen 1.0 bios like the 3944 version, patch it by filling in the last 512 bytes of code with the actual extracted data and then run it on the MCPX X2 and have it work? Thats what I was thinking would work but didnt seem to.

This is an interesting find. I guess its definitely possible, the only reason why im hesitant is that I cant think of much of a reason why someone would do this/ go to this effort. Im not to doubting you by any means, but this seems like a lot of work for someone to effectively transfer the MCPX from one board to another (Assuming it was properly done and nothing went wrong) and then to have a small problem like that creep up. I guess then my next question is, what's different between a development PIC and a retail PIC? From what I remember, i dont think the Flash of the PIC has been dumped yet. I would think the PIC wouldn't make sense to have a Dev version and a retail unless thats where the flash write enable is all handled as the PIC was used for basic system management as far as I know. Getting my hands on something like that may be difficult as I received the board and only the board from an Ebay auction. Someone else then must've done the chip transplants and would then have the corresponding PIC from the dev/debug board that the MCPX was salvaged from.

This is a general shot. The only thing I've done to the board is add the LPC header and remove the flash chip and solder it to a breakout.

Hey N64, Sorry for the long waited reply. The photos are gonna be below for the areas in question. I took them with a macro and my phone light to help with visuals. If you think a better angle might help I'll try and get back faster.

Sounds good. One thing I guess to note on that, when I got the board the TSOP flashing solder points (R7D3 and R7R3) had been made which leads me to believe one of the previous owners tried to flash the chip with another BIOS. I'll work on that and hope that they were dumb and only did a 256k that didnt mirror over the entire 1mb. In regards to the ZIF, are you just wondering if the FLASH is getting the same address requests as the LPC is? I guess I've never seen an in place ZIF socket before so that could be interesting trying to find one.

Hey Guys, Im currently working on trying to fix a FRAG'd motherboard that I bought sometime last year. While normally I would just ditch the motherboard in a normal FRAG circumstance, this motherboard is special. Its a board that has the MCPX X2 chip instead of the retail X3 and has only 64mb of RAM. Im not entirely sure on what its history is, the person who I bought it from on Ebay didnt seem to know either so whether he is 2nd owner or even further down the line, im not sure. Either way im trying to do all I can to diagnose and fix the board so that I can turn it into a proper debug board that could maybe run stock un-modified Debug ROMs. Just a nice small little thing. Anyways, I had recently posted about this around a year ago asking if anyone had any X2 bioses and whether there was any main difference between a BIOS for a X2 and X3 other then the secret boot portion. After all that I built a Couple OpenXenium modchips and went to town on trying BIOS's. Ill note, the original 1mb ROM chip was FRAG'ing and at the moment i've pulled it and put it on a breakout but havent gotten around to reading it out. Anyways right now i've made a dumb variant of the Xenium firmware so that instead of doing all the smart stuff, it just boots and mirrors the first 1mb 16x across the memory space. I've also attached a stackable header to one of the chips so I could attach a logic analyzer I bought to read things out. So onto the results. While I haven't decoded the LPC address requests yet, based upon my initial inspection, it seems the system is requesting a set of data, and then just stopping. The clock still runs untill the PIC comes in and restarts the system since it didnt receive the special code. I've attached a photo to show what I mean. Im trying to work up a decoder for the analyzer so I can see what address its requesting and what data gets sent back. From what I see and speculate, it almost seems like a memory failure or something along the lines of that maybe? Im just thinking if the MCPX is requesting the first reset vector worth of data for the CPU but then nothing is getting transferred into ram, then it might not execute? Then again I didnt think things got transferred into RAM until the 1bl is loaded, and from what I figure from the capture, only about 16 bytes is getting transferred ( 16 LFRAME signals). If anyone has some suggestions, im all ears right now. I'd like to try and get this board up and running, but a FRAG state is hard to figure out and diagnose. If I cant get the decoder up and running in a bit here, i may just hand calculate the LPC transactions. And for those wondering, the bios im running is a patched 3944 bios. Patched as in I tossed the security 256 bytes into it. The dumb firmware works as I've tried it on a retail machine and it boots fine. If anyone is curious or wants a specific picture of the LPC capture, just ask and I'll see what I can do. Thanks in advance.

Okay so its been a while since I've last posted so I'll give a quick update. At the moment I was able to create a new CPLD image for the OpenXenium I'm dubbing the dumbXenium. This effectively transforms the xenium into a generic 1mb modchip with no special features. After testing it with a couple bioses (stock 3944 and X2 5035) I was able to get it working on a retail board. After flashing it with the bioses packed in with the XDK 5849 (or whatever the number is) I tried it out with the DV6 and Xblade labeled bioses. Nothing. Ill try it with a bios that KaosEngineer suggested earlier but at this time its not looking to good for the dev board. I might try and just give it a good cleaning with some iso and distilled water and just inspect the hell out of the board. As well Im planning on soldering some wires to one of the xenium modchips I made, specifically to the LPC data pins so I can try and monitor if any data is even transferring through to the MCPX. The logic analyzer I have isnt technically rated for that bandwidth, but it should be able to at least show some activity on the LAD lines. Im getting tired.

Maybe this is another hardware difference between the X2 and X3. To my knowledge there hasnt been much documented difference between the two other then one has a secret ROM and the other doesnt and one comes on retail hardware and the other comes on debug/development and Chihiro hardware. Would be nice if there was more thorough documentation on what the differences are since I thought the only hardware level difference was the ROM section. I dont know if people ever looked into whether there is a special register you write to through the PCI bus that will re-enable the FLASH access and instead just accepted the FLASH recovery method developed by the Chameleon people.

Once I can get at least something booting, debug or hacked retail, this is what I plan on doing so I can properly setup a hard drive. I find it interesting since Ive heard this is how the Xbox ROM was flashed from the factory from what I assume where Pogo pin style connectors to the LPC header. Surprised no one has really gone into depth with how the factory recovery actually happens since all the homebrew TSOP ROM recovery methods with modchips seem a little sketchy and only seem to work on the 1mb ROM xbox's.

This is exactly what I did with the BIOS marked DVT6. I think the specific version was 5844 or something like that that was packed within the 5849 SDK. Its hard to tell without the XenoimOS source code, but I think SamSpin is right in terms of how the Xenium works. It hooks in and hijacks the 2BL process with custom X-codes and such which is why its able to offer services such as recovery, quick boot and multi bios boot without having toggle switches. The system regardless of what happens boots to XeniumOS but immediately XeniumOS checks status bits like quickboot and such which is why its able to have custom LED colors display depending on the bios you have setup. It would make sense then why it still FRAG's even with those setting on since that "hidden" X3 section wont be filled in on the Xenium hijack section and the X2 xbox will directly be requesting the reset vector data from the Xenium which it doesnt have as appose to an X3 which starts in the hidden section and then gets hijacked. At least thats my take on things.

Out of curiosity, which debug bios are you talking about? When I go into the 5849 SDK, I see 3 bios's. A DVT 4 one, DVT 6 one and an XBlade one. I tried the DVT 6 and XBlade one and neither of them seemed to work. They both just instantly FRAG'd making me wonder if its a side effect more of the Xenium and not the bios image.

Well interesting to see how this has developed. I guess that is one thing I didnt know about the Xenium and how it goes about booting. Makes me think now I should use me FPGA dev board and get craft something up such that the system will be able to view the exact flash image and nothing special. In regards to the X2 motherboard, I am certain it is a test kit board and not a Chihiro. From what I understand of what you are saying, all Chihiros are 128mb and up for RAM. This board is only 64mb. I also think the previous owner did try and do a FLASH overwrite with something like hexen since, unless someone wants to show pictures of the bridge points from there dev-kit, the bridge points look very hand-soldered. At the moment I have removed the memory chip with a hot air system and am trying to find out where the hell I put my TSSOP breakout board that I had ordered a little while back. I made a little program that fit on a TI dev kit that read out the memory contents of a retail 256kB flash chip correctly and so I plan on doing that once I find the damn breakout. Then I can make it official once and for all if one of the previous owners tried to flash the chip with a retail BIOS, or if maybe the board is just toast in general.

By chance do you know which version of the Xecuter BIOS you are running? The X2 4981 should be able to run without any disc drive attached and will boot to whatever its set to in the hard drive. Sometimes I know if you install a softmod on top of a hardmod it can result in a blank screen after flubber animation and the front lights going orange. It shouldnt show an error code since the HDD is attached but it wont show anything.

Hey guys, So I have a project where I was able to come in possession of what im assuming to be a original Xbox test kit motherboard. The reason I say this is because it is an xbox motherboard with an MCPX X2 as appose to the X3 and yet it only has 64mb of ram soldered to it. It also looks like one of the previous owners tried to run Hexen and flash a retail bios on it since the solder points have been connected. Since (I'm assuming) it has a retail bios loaded on it it wont boot due to the lack of hidden boot sector in the X2. Ive finally fixed some OpenXeniums ive been working on so I have access to a couple modchips that can fit 1mb bioses in them. I am wondering, with the lack of 128mb of ram on the board, does anyone know if the development bioses will still boot to a screen showing something at least like the startup animation? I would like to see if the board is at least still functional with a proper bios and not completely nuked since it is currently in a state of FRAG that I hope is due to a retail BIOS being flashed on there. Thanks

I never ran into this screen. Since the ISE software spat out an SVF file, i assumed the pin assignments where baked into it. The programming application I use is purely CMD prompt based but may look into that, but since at least one of the six chips is being picked up by the xbox, im not sure if that is the problem.

So I had some time to work on this again and removed, cleaned and re-soldered the chips to the boards again. After which I tested with a multimeter the LAD lines. From one to the other I got no continuity and when I tested resistance I was getting around 24-25 MegOhms which tells me there really should even be any bridging whatsoever. I forgot to test the LCLK and LRESET lines but Id imagine they would be the same. It just baffles me at this point that they arent working event though I can control the LED from the xbox and everything looks good regarding continuity and resistance checks. Im thinking I might order a couple new chips and maybe even female LPC connectors. Thinking some gunk/flux got in them which is causing maybe some high speed transfer data mess-ups with it not fully contacting the LPC header on the board. I dont know at this point.

So I finally had some time to work on the chips. I did what you had suggested and I managed to fix the one chip that was only partially flashing and now I have 1 fully working OpenXenium chip. The rest though didnt seem to follow. Since I had a hot air station, I spent a good amount of time removing the chips, re-tinning the pads and cleaning the old flux up and trying to re-solder them . I then followed with two passes of solder braid, one thick and one thinner to try and get the little stuff. Unfortunately only the CPLD was still being programmed and the xbox just wouldn't recognize the chips. Im just at a loss since the LED can change color and will match the color listed in the Xenium tools meaning at least the LPC writes to the chip are working. Im thinking of using a 3.3v Micro controller board to bit-bang the lines and see what the output is and maybe that will help. Oh well.

Okay so small update. Of the one chip that was detected by Xenium-tools, I was able to use the tools and create a dump of whats on the flash chip. After looking at the code for the tool, it is writing the Cromwell loader section into the XeniumOS Part 1 section. This is making me wonder if I have some address pins bridged potentially. I think what I might try here is get a little messy and create a pseudo 2mb flash by stitching together the binary sections on my computer first and then have the tools simply flash over the stitched 2mb file. Guess ill have to try it and see.

Hey guys, So I was attempting to make my own OpenXenium modchips. I managed to get all the components and build 6 of them. Of the 6, 4 of them were successfully programmed with a BusPirate XSVF programmer (i figure I just need to reflow and check for bridges on the other 2). When I go to do the final programming using Ryzee's Xenium tools only 1 of the 4 that were programmed actually get detected with the software. Even then when I go to program that one chip with the the tools it only gets to 50% complete and then the xbox just freezes on the flashing process leaving the chip in a partially flashed state. Im using the recovery.bin file from xbins for flashing. I was wondering if you guys have any ideas as to what might be wrong in this situation. Im in the process of setting up an NXDK environment to see if I can build the tools .xbe from there. Thanks

As far as I could tell it wasnt the wrong way around, the installation orientation being with the red light pointing towards the controller headers. Im surprised that the chip wouldnt almost be reverse protected, at least I would think all pins would be 5V tolerant unless for some reason it shorted it to ground within the chip itself. Oh well, ill be sending it in for a return and hopefully this time itll be better. Thanks

Hi guys, I recently attempted an Aladdin XT plus modchip install on my xbox V1.0. Other then trying to suck out the solder from the LPC ports, the process was relatively smooth. When I first went to boot the box, the Aladdin instantly smoked hard so I it off. At the moment I'm trying to figure out whether it was my install error or a faulty chip. When I remove the chip and boot the xbox, it boots fine and normal. As soon as I add the chip back on, which doesn't smoke anymore, the xbox FRAGS. I tested the LPC pins and didnt get any continuity between ones I shouldnt have. I then tested to make sure the 5 and 3,3 voltages were still good and they were. I was gonna test each individual pin and see if maybe Im seeing 5V/3.3V where I shouldnt, but other then that I'm not sure if it was the install, but instead just a faulty chip. I bought it from Modchipcentral and I've gotten good stuff from them before. Any input would be appreciated. Thanks

Ahh okay. I totally forgot about the whole boot from media thing. Thanks I'll give it a try.