Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About MrBriteSide

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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
  14. 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
  15. 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

Board Life Status

Board startup date: April 23, 2017 12:45:48
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.