Prehistoricman

I have been looking and thinking about this topic @sweetdarkdestiny I basically repeated what others have done with PC drives and got some random LG drive to load DVDs and game copies but not original discs. I took a brief look at the original and hacked drive firmware images and decided to save myself the pain of looking at it further. The problem for me, someone who doesn't have experience with drive firmware, is that the system is totally unknown and hard to probe. The main DVD drive chip from MediaTek doesn't have public documentation. I don't think we've had any source code leaks related to the Xbox DVD drives so that's a dead end too. It's possible to reverse-engineer almost anything but the effort that takes on this level could be hundreds of hours depending on the hacker's experience. A close example to me is the TMS57070, a digital audio processor chip from the 90s that was also 100% undocumented. I spent around 400 hours investigating and got a very good understanding of it over a span of 3 or 4 years https://github.com/Prehistoricman/TMS57070. If I could be sufficiently motivated, then I suppose I could do the same for the DVD drives. There are still people in the scene with a decent base knowledge of the drives, so not all hope is lost. But screaming into the void YEAH LET'S DO THIS won't get the hard work done. Sorry to be a pessimist

That kind of boot loop usually happens when booting Xblast with some RAM soldering mistake. It occurs because the xblast bootloader fails to load the main xblast image correctly. The bootloader has already passed the SMC check (so it will not FRAG) but due to the check fail, xblast requests a reboot.

The clock cap will leak regardless of it showing any signs of bulging. I don't think it's related to your problem - as you said - but you should remove or replace it.

I made that mistake when I was a kid. I hot glued a fan to a heatsink in my PC and a few weeks later it fell off

If the CPLD is replaced, the new one would need programming with the open-source R3DUX code at https://github.com/ChimericSystems/R3DUX The original Xecuter code isn't available for extraction from the device, nor available online.

"Xbox one original" is like an oxymoron. This forum is for the 2001 Xbox and it sounds like you have Xbox One.

Do you know if the Aladdin is flashed?

I have a 1.6 with teal/gold coloured caps, very similar to hastings'. I'm 99% sure it's not been recapped.

Are you sure it's the PSU that's faulty? Could be the motherboard.

If it runs hot without a PSU, you may have discovered free energy.

This is Cromwell but it should be the same file https://github.com/XboxDev/cromwell/blob/master/drivers/pci/pci.c#L283 Of course the memory size detection routine is in the PCI driver... You can change line 319 to be if (true) { or you could change line 314 to be xbox_ram = 64;

Are you able to recompile xromwell? It is a trivial code change to make it think the console is 64MB only

Every multimeter model will have a different threshold for continuity and a different current/voltage to probe the resistance. Getting the beep doesn't mean it's a short circuit. Use resistance mode and see if the value is near SS_Dave's result.

I believe you two are talking about different things. Hastings is talking about the LCD contrast (or backlight?) and the control pot on the X3 chip. Bowlsnapper is talking about the X3 switches and status LEDs which are unaffected by the potentiometer. I also have a stability issue with the X3 controls, but it's with the small black one that you stick to the front of a normal panel, not the whole custom front panel. I believe it's the wires breaking after too many stresses and bends. Mine has flickery or dim LEDs very often but rarely boots from the wrong bank.

I once did a bad flash to the TSOP. So I desoldered it, wrote an arduino programmer and soldered it back in. Then I fucked up the flash again to see what went wrong the first time

What BIOS are you using? I have seen some similar stuff from EvoX before.

The type of flux is also important. Ryzee is using some ChipQuik which I can also vouch for. It looks like you have a lot of flux all over the board, but it doesn't look like the right kind of flux for drag soldering.

The missing pad wasn't connected to anything. Pads like that are more likely to rip off.

dust08 has it right: if RAM speed becomes an issue when increasing the FSB too much, you can reduce the memory clock independently. XBOverclock can be modified to do this. Go to its main.c file and after line 93 put bios_data[i+6] = 0x33; to reduce the memory clock by 33%.

If RAM speed ever becomes an issue, you can reduce it by 33% by increasing the frequency divider from 2 to 3. On a normal Xbox, that reduces the clock from 200MHz to 133MHz. The memory frequency divider is the '2' digit in the PLL register that usually has the value 0x00230801.

Is this the first time the heatsinks were removed? Did you apply a lot of force to remove them? Any crunching noises?

Easy

No display with FlashBIOS on a 1.6 is a known issue. It happens to me too. I'm not sure what causes the issue. I replaced the backup BIOS on my X3 with XBlast OS 0.56. Display always works and it does a quicker flash over network.

Cutting LFRAME on a 1.6 is the same as shorting D0 to ground on 1.0 to 1.4. It will work with any modchip that is enabled.

Flashing yellow/red is actually normal when xblast OS doesn't detect an xblast or aladdin modchip.