OGXbox Admin

I know people get really tired of hearing this debate, but I'd like to make my position as clear as possible once and for all. First and foremost: The reason the LPC exists on the Xbox motherboard is because the TSOP is soldered to the board blank, and programmed via the lpc port later in the manufacturing process. When the TSOP is blank, the xbox then looks to the LPC for a bios image to boot. This is because a pre-programmed rom is more expensive than a blank eeprom (TSOP in this case). It also allowed Microsoft to more easily update the bios image in new Xboxes for whatever reason. So we know that they would have to retool the LPC programming device if they disconnected some LPC points. This new tool would need to be incredibly fine because the point it needs to make contact with is no longer a nice big pad. Since nobody can find a 1.5, this retooling would have been for just a handful of motherboards. So they would have gone through this expense of retooling for such a tiny amount of boards it wouldn't have made any sense. Next, what exactly did the alleged 1.5 board prevent? It ONLY would slow down mod chip installation. I say slow down because any knucklehead with a DMM could figure out how to get it working again. It does absolutely nothing to stop soft modding or TSOP flashing. Why would Microsoft go to such an expense to stop only one method of modding the Xbox? I don't doubt that people have found LPC points that show no continuity. This could be because of the very programmer I mentioned at the beginning of this post. It could be due to trace rot. It could be due to operator error in measuring the components. Whatever the reason for a person measuring this situation, I don't believe it was a particular version of motherboards that Microsoft intended to put out. We saw with the 1.6, where it DID come with a pre-programmed rom (so no TSOP) on the board that they could finally disconnect the LPC. That's why we have to rebuild it there. It is perfectly consistent. It stops TSOP mods. It stops modchips for noobs. It required a new bios that supported the new video encoder. I think they believed they could use updates on game disks and Xbox Live to patch the softmods. So they thought they had all the bases covered with 1.6. I got my information from the Xbox-Linux Project. They published an article on Xbox Security which I preserved on this site. "Now other people found out that, if the flash chip is completely missing, the Xbox wants to read from a (non-existant) ROM chip connected to the (serial) LPC bus. This is of course because of the manufac- turing process: As it has been explained before, the flash chip gets programmed in-system, the first time they are turned on, using an external LPC ROM chip. Modchip makers soon developed chips that only needed 9 wires and connected to the LPC bus. It was enough to ground the data line D0 to make the Xbox think that flash memory is empty. Lots of these “cheapermods” appeared, as they only consisted of a single serial flash memory chip. They could be installed within minutes, especially after some companies started shipping chips that used pogo pins, so that no soldering was required. Some groups wrote applications like boot menus that made it possible to copy games to hard disk and run them from there. Patched Xbox kernels ap- peared that supported bigger hard disks. Making the Xbox run copies from DVD-R or hard disk as well as homebrew applications written with the official Xbox SDK was now easy." https://www.ogxbox.com/archive/xboxsecurity.html It's under the "Modchips" heading.

If anyone cares, measuring the input to the m-atx psu, I supply it with 12.6vdc. On boot when the xbox is checking the dvd drive it draws 7.1 amps. That puts us at almost 90w. It drops to 5.1 amps at unleashx dash. It doesn't change much when running a game. That is with the DVD drive in and full 3.5" hdd. Obviously power consumption can be reduced by removing the dvd drive motors from the equation and using a 2.5" hdd, ssd, or some form of flash... which don't reduce the draw much at idle. That ~5 amps is kind of what we're stuck with. I've built a few that run on battery power and it's difficult to get 6+ hours once you include an lcd screen. You REALLY have to invest in the battery bank.... unless someone else can come up with some efficiency improvements or things that can simply be removed.

This is a great post and I'm interested in taking it a bit further. It's ironic that SS Dave and I were sort of doing this at the same time. I just took a m-atx power supply and got it to work like the stock power supply on my 1.4 motherboard. I used an NPN transistor to more or less act like a relay. So when the POW ON signal goes high from the Xbox, the transistor holds the ATX POW ON line to ground. KSP 2222a. Pin 1 is emitter. Pin 2 is Base. Pin 3 is Collector. Pin 1 to gnd. pin 2 to xbox POW ON. Pin 3 to ATX POW ON. I also used some 5v to 3.3v step downs to change the ATX 5v power ok and standby to 3.3v that Xbox expects. https://www.amazon.com/gp/product/B07FCMF6SV/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1

Glad you're here!

What are the voltages when plugged into your working board?

Does the fan spin like 1/4 turn when you press the power button and that's the only sign of life? or does it do absolutely nothing?

This is usually because the evox.ini file doesn't contain the correct flash information for the flash rom on the chip.

The confusion is that on a retail... this absolutely does not work like this. I didn't expect it to work like this on my debug... but it did. The debug had a bad flash and wouldn't boot. I booted from a Chameleon modchip with debug bios installed to my lpc and booted to the xdk dash. I backed up all data on the hdd and popped in the recovery disc. As soon as I saw it was loading the recovery executable I flipped my toggle to turn the chameleon off. (ungrounded D0). I assumed it would just fail to flash anything at that point since on retail that's what would have happened. It proceeded and shut off the console. I pulled the chip off the header and booted up and it worked. Edit: I always put the yoshihiro bfm bios on there that lets the debug run retail xbe's. I doubt that had anything to do with it... but thought I would mention it.

It's not special to me... if that's what you are implying. I don't want to distribute the xdk recovery disks on this site as that could make us a target. They are pretty widely available out there. Are you insinuating that I am not being truthful in some way?

Yeah I didn't just say it or make it up. I've done it.

Yeah you can boot a debug bios on a lpc modchip just fine. You can also unground d0 and run the recovery disk and it will reflash your tsop. I know because I recovered one this way.

that one actually kind of makes sense because the "uplink" ports are specifically to connect one switch to another. They behave differently than normal switch ports. In some cases you can get away with it because some modern switches don't treat them that differently.... but some older switches would not and it would really mess up the network traffic. Also, if you are plugged into a "console" port on the switch that isn't ethernet. I think it would be good to see your network setup / switch. This is a mystery I really want to solve.

None of that matters even a little bit. Please follow the steps I just gave you and report back. Edit: The main purpose of this site is to assist future users that may come across the thread and information. So if we just wipe out your hdd and rebuild it... it will probably work but we won't know SPECIFICALLY what it was and what it would take to fix it.

That looks like a version mismatch to me. You might want to copy off the game's save folders from E: drive. Tdata and Udata hold that information. You'll have to find which one is correct from google. Then when you've cleared it from there, you will be loading the exact same version from disk and you won't get denied anymore. Edit: I'd also clear the e:\cache directory plus anything contained on x, y, and z to be sure.

Basically every xbox once in system link mode changes its IP to 0.0.0.1 and begins listening for broadcasts. Once an Xbox is hosting a game, it begins sending those broadcasts. The other consoles see this broadcast from the host and do not change their ip. So this means that every Xbox on the lan has an ip conflict. Is that a problem? Not for system link. Why? Only a device that is looking at the IP addresses and trying to associate them with the proper mac address will be confused. Layer 2 switches (unmanaged) don't know or care about IP addresses. (Layer 3 are aware of ip addresses but an ip conflict is not a deal-breaker to them at all. They really just need to be managed via ip so therefore they are aware of ip's. They are still switches and still really only care about layer 2.) Your router would obviously but since system link traffic isn't supposed to go across the internet, your router won't see it. System link would need to have a default gateway set and of course it does not. The Xbox's expect traffic sent this way so they aren't confused. So it works just fine. Inside of that broadcast packet was the game server name and mac address. The other Xbox's begin communicating with that Xbox via its mac address. (It does send traffic from 0.0.0.1 to 0.0.0.1 and that traffic does not come to itself. I believe this is because they wanted to use some encryption of the system link traffic and that needed to take place at layer 3... but they needed to make this work without configuration from the end user who won't know how to set ip addresses. So even though it uses the same ip address, the mac address allows the traffic to flow from 1 xbox to another on UDP port 3074.) This is why you cannot use a layer 3 tunnel for system link. It must use a layer 2 tunnel or l2tp to make it work.

So remember to make the distinction that the stock xbox dash can set Xbox live IP addresses, etc. That's not true for anything else. If you set an IP in XBMC, when you load a game it doesn't have that ip anymore.

yeah it's true no matter what. That's how the xbox works. The underlying operating system is loaded from the bios, but the shell or interface you deal with is whatever xbe is currently loaded. The previous one is completely flushed from memory so nothing you've changed will have any effect. The only exception is modifying the eeprom, etc. Any IP address you set though, is totally gone when you load up a game. It will request its own if it's Xbox Live aware. If it's using system link, it is not using the ip addresses you set. You can verify this yourself by pinging the ip address you set in your dashboard. Load up a non Xbox Live xbe and watch your ping disappear.

It will allow you to pop in an auto installer disk and fix it.

Just to verify it would work I set up an xbox in various rooms and various network drops on various switches. Here is the result.

Any time my friend. Good luck with your troubleshooting. I will say though, if one xbox is not receiving an IP address, that proves you have something wrong on that link. If you know dhcp is set up and working, you could have a bad switch port, bad cable, or bad nic in the xbox. Check to make sure you have link lights near the NIC on the back of the xbox.

I don't softmod. Never have. They all have xbmc.... but that doesn't matter. Once you load a game, the dashboard is completely flushed from memory as well as any settings it set such as IP address, etc.

I'm quite literally just stopping the hosting, unplugging power and ethernets from the switch. Plugging in power and ethernets to the new switch. Then starting hosting. Then the second xbox sees it. I've joined on a few. Enter the game. Kill the other player. IGR on both xbox's. Fire up brute force and test again.

I tested A trendnet, linksys, netgear, 2 dell 2824's, 2 dell 2808's, 1 dell x1052p, and a dell 5524.

1.0 xbox + 1.6 xbox. Switch is just a dell x1026. I have also tested with 10 other switches since then of various makes and models. They all work exactly the same.

Brute Force - The second xbox saw the host xbox's game instantly. literally 0 delay in finding it.