Modchip install help

Discussion in 'Xbox (Original console)' started by Korn16ftl3, Nov 5, 2017.

  1. Korn16ftl3

    Korn16ftl3 Robust Member

    Joined:
    Jun 26, 2017
    Messages:
    200
    Likes Received:
    19
    I have an issue and I know it's not the chip it's self as I installed a completel different chip (same chip make just a second one I had) on a different xbox and the same issues are occurring. The boot up is inconsistent entirely as in never the same twice, this happens after a successful boot up and the xbox has sat idle for a little while I've takes some video as well as pictures of the pin header install, everything appears to be correctly installed. One of the xboxs I've gone over the pin header soldering at least 2 more times as well with no change in performance.
    20171105_035922.jpg 20171105_035829.jpg 20171105_035810.jpg 20171105_035616.jpg 20171105_035535.jpg 20171105_035546.jpg 20171105_035507.jpg

    Videos:



     
    Last edited: Nov 5, 2017
  2. sarx

    sarx Member

    Joined:
    Nov 1, 2017
    Messages:
    21
    Likes Received:
    3
    recheck your soldering first. a few of the wires look dodgy to me.
     
  3. Bad_Ad84

    Bad_Ad84 The Tick

    Joined:
    May 26, 2011
    Messages:
    8,604
    Likes Received:
    1,375
    It's probably the ones connected to vias. Or that you are using D0 instead of lframe point

    I'd just ditch the 1.6 personally and use something else.
     
  4. sarx

    sarx Member

    Joined:
    Nov 1, 2017
    Messages:
    21
    Likes Received:
    3
    since you said the same make of chip has had the same problem, then its probably that kind of chip is dodgy lol :p
     
  5. Korn16ftl3

    Korn16ftl3 Robust Member

    Joined:
    Jun 26, 2017
    Messages:
    200
    Likes Received:
    19
    This is a 1.0 board.....actually both boards I'm having this issue with are 1.0

    Nah it was a problem with my x3 I recently installed on a 1.4 board had to go over the damn pin header solder points 3 or 4 damn times for some reason...what I don't get is the pin header connections here look solid same as all the others.....it makes no sense.

    The only wire that's in the images required is the d0 wire and I can run that strait to ground, the other 1.0 board I'm having the same issues with has the d0 put right to ground.....I was hoping someone could give me a more definitive idea of what pin I might be screwing up.

    Worst case I get the desoldering iron out and remove the whole damn header...and I guess try again??

    Also got the videos uploaded in the OP

    Also I noticed the xblast os says in the upper right corner unable to read first sector twice....not sure if that's because there are no BIOS imaged on the chips yet or what tho.
     
  6. Bad_Ad84

    Bad_Ad84 The Tick

    Joined:
    May 26, 2011
    Messages:
    8,604
    Likes Received:
    1,375
    Sorry, only looked at pin header install and assumed wires were lpc rebuild without much checking.

    You can't run D0 to ground with xblast modchip, as it controls that line for Booting from tsop or not.

    Probably work with it on ground, but that function won't work.
     
  7. sarx

    sarx Member

    Joined:
    Nov 1, 2017
    Messages:
    21
    Likes Received:
    3
  8. Korn16ftl3

    Korn16ftl3 Robust Member

    Joined:
    Jun 26, 2017
    Messages:
    200
    Likes Received:
    19
    Well that could be the issue on the other console but still this one had the d0 wired to the chip (Look at the pads on top of the chip in the image) the other 2 wires are for tsop splitting and the 3rd I believe is tsop recovery optional wire as well if I recall correctly.

    Suppose I will get the desoldering iron out and reverse everything and see wtf is exactly going on here.....I'm not excited to say the least, how the hell can a pin header install look like that and not be functional I don't get it.......

    Either way I look at it it's an install issue....the board with the d0 to gnd wont even boot an aladdin chip either it does the same crap.

    I'll post some images of my board after the Uninstaller and see if anyone sees anything wrong there as well.

    Other thoughts:
    D0 has got to be right because when D0 is directly grounded it frags in the same manner 2 reboots then a frag......that tells me the D0 should be soldered correctly.....any ideas what could go wrong with a pin header install? To much solder? Not enough?? I can't have solder gathering under the black piece on the top of the board making bad connections could i?
     
    Last edited: Nov 5, 2017
    sarx likes this.
  9. sarx

    sarx Member

    Joined:
    Nov 1, 2017
    Messages:
    21
    Likes Received:
    3
    just make sure all connections arent touching anything else shorting or bridging anything.
     
  10. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    477
    Likes Received:
    181
    Hi, thanks a ton for the pictures and videos. It's always easier to help people when they provide those!

    OK, I'm not sure I'm following here.

    Basically you have two 1.0 boards that have issues booting with either of your 2 Xblast Lite modchip? Whichever chip you put on either of the 2 1.0 motherboards, you have inconsistent boot issues? Is that it?

    Furthermore, what I understand is that installing a Xblast Lite on a non 1.0 board (in your case 1.4) does not show any of the issue you experience.

    It does seem all your issues are involving Xblast Lite modchips on those 2 1.0 motherboards. Am I right?



    As everyone suggest, check your wiring; you've got a few wires where the insulation coat doesn't look to be in the best of shape. Maybe the conductor inside the insulation is partially cut. If you have a multimeter, check the conductivity of the wire on both ends while wiggling the wire a bit. Resistance value shouldn't change.
    The most important wire to have a successful boot is the D0. The other 2 do not interfere with the boot process unless you have them shorting something on the motherboard! Tying the motherboard's d0 point to ground is a effective way to always enable the modchip for testing purposes(like to check if the d0 pad on XBlast Lite is defective). You should still use the appropriate pad on the XBlast Lite for normal operation.

    Have you tried any other type of modchip on those 1.0 boards?
    If so and if they work fine on those 1.0 boards, we could certainly rule out the soldering. I might alsohave a clue as to what's going on.

    1.0 boards require some part of the console initialization process to be executed very quickly as the console powers ON (or resets). I thought I had it all covered in XBlast OS as I did have a picky 1.0 board I could test it on. Turns out yours might be even more capricious. What I find odd is you'd have 2 of them.

    If you can test other types of modchips on these 2 1.0 boards and report here if they're working flawlessly or not, it will help narrow down the problem. In the meantime, I will try to cook up a more optimized version of XBlast OS that will init 1.0 consoles faster.
     
  11. Korn16ftl3

    Korn16ftl3 Robust Member

    Joined:
    Jun 26, 2017
    Messages:
    200
    Likes Received:
    19
    2 seperate xblast chips both 1.0 boards acting the same way, 1 board had d0 tied directly to groud.

    Ignore the 1.4 board it has an X3 that I installed I brought it up because I had similar issues and had to go over the pin header 4 times to get consistency as well.

    I've also tried an aladdin I have lying around as well, same issue and random patterns again I feel it's an error somewhere in how I install the pin headers.



    This is an excellent idea I can also check the resistance from the pin header to the other points on the board, this is a thought that never cane to mind and honestly should have

    D0 should be working correctly, when I have no chip on the header and the d0 grounded it turns on off on off then on to a frag a lot like the symptoms described and shown in the videos I will of course check it as well.

    yep as mentioned above I have tried an aladdin with the same behavior.

    So this version board is picker than the others? Either way I'm almost convinced it's install related.

    Again like I said I don't have any success with the aladdin chips either they go threw the same boot cycle as the xblast chip. I know that your an intelligent person when it comes to the original xbox and am greatfull for you taking your time to help me sort this, I in no way think this is tour product I think I'm doing something wrong when installing the pin header tho in not certain what. I'll run threw and check resistance on the pin header pins where I know they lead to and the wires as well perhaps that will give us some answers?
     
    Last edited: Nov 6, 2017
  12. billcosbymon

    billcosbymon Guru Meditation Error

    Joined:
    Dec 31, 2009
    Messages:
    660
    Likes Received:
    48
    If I can get this chip to work with zero hitches on a 1.6 with a wire lpc rebuild. Then I'm sure you are having an oversight like when I forgot to remove a pin from the pin header.
     
    Korn16ftl3 likes this.
  13. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    477
    Likes Received:
    181
    Yes, without going into too much details, every Xbox revision includes a cryptographic challenge very early in the boot process. If that challenge isn't solved before the timeout, the PIC controller will reset the Xbox (up to 3 times then FRAG). For some reason, the 1.0 boards have a shorter timeout than any other revisions. I've also noticed that not all motherboards of a same revision will solve it at the same time. I probably has something to do with power stabilization and subsequent startup delay of the CPU.

    Thanks for the kind words. I wouldn't take it personal if the XBlast chip were to be faulty, it's a possibility and these kind of things happen. That said, I've hand soldered and tested every XBlast Chip I sent out for the past 2 years. I never had any feedback of faulty chips. You'd be the first and on top of that, you've got 2 of them! Anyway, I think there are a few more things we can try to solve your problem. At the moment, as you point out, I don't think the Xblast Lites are at fault here.

    Just to be sure, the Aladdin chip you speak of is a stock Aladdin XT? Not a Aladdin XBlast because just as a XBlast Lite, both of them boot to XBlast OS, they are certain to exhibit the same behavior if the issue is related to Xblast OS.

    If the Aladdin chip in question is indeed not a Aladdin XBlast and you have the same boot behavior with it as with your XBlast Lite, I'd suggest you then rework your LPC header and d0 point. The first pins I'd check are Ground or 3.3V; check if they are not properly soldered. These 2 pins are harder to solder because they are connected to internal conductive layers in the motherboard. Those layers act as a heatsink and diffuse the heat of your soldering iron, making the applied solder not hot enough to form a good bond on the motherboard.

    Since it looks like the issue is not related to boot timing of XBlast OS, I will refrain from uploading experimental XBlast OS builds. At this point, it looks like they wouldn't do any good and I wouldn't want people to flash them thinking it's a real update.

    Finally, have you tried using a XBlast Lite on a motherboard you know modchips boot flawlessy?
     
  14. Korn16ftl3

    Korn16ftl3 Robust Member

    Joined:
    Jun 26, 2017
    Messages:
    200
    Likes Received:
    19
    For the sake of curiosity and since you say the 3.3v and gnd pins are the hardest points to make on the header is it possible to use a jumper wire from another 3v source or would that effect a timing issue? I wouldn't leave the jumper as a permanent solution, it would just be a test to see if it is indeed the problem.

    Also the aladdin used was in fact a stock chip.

    Can I simply plug the xblast lite onto my X3 pin header and ground the d0 point even tho the x3 header has 4 more pins?

    Another note that might be worth mentioning in the trouble shooting here is that when the xblast lite does boot up successfully when I attempt to flash the chip no communication happens over the http process the flash screen will load but if I attempt to flash nothing happens, upon restart the chip acts up like the above listed problems. No idea if that bit of information is helpful or not but perhaps it is.
     
  15. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    Connecting an additional bridge to another 3V3 point and GND point will not influence timings as the supply is a DC voltage.
    The 4 upper LPC header pins of the xbox mobo are unused by the modchips.
    Just make sure you plug the modchip correctly on the lpc pins.
    It's better to use kynar (wire wrap) wire for the connections with the xbox mobo.
    They give less stress on the pcb traces and via's, so there is less chanche of damaging them. (I didn't say you did damage them)
    I also fix the wires to the pcb with a small dot of super glue. This again protects against mechanical stress.
    I seem to remember that during the early development of xblast OS Benny had problems to be fast enough on 1.0 mobo's. He also had issues that sometimes the xbox flashed red once but booted fine afterwards. Do you see that behavour sometimes, or is a power cycle always needed when it doesn't start?
    Having a frag when you GND D0 doesn't mean D0 is fine. I am sure, if you GND D1, it will frag as well but it won't load a modchip bios.
     
  16. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    I just looked at your first video and noticed that it flashes red once before it boots.
    Maybe Benny can tell us if that's the expected behavour or if that one red flash is indeed the first frag?
     
  17. KaosEngineer

    KaosEngineer Robust Member

    Joined:
    Jun 7, 2016
    Messages:
    227
    Likes Received:
    98
    The video Korn16ftl3 posted does show the power ring flash red once then goes off for a short time to finally turn green and the XBlast OS screen is visible on the TV.

    Sometimes the Xbox FRAGs.
     
  18. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    Maybe it's programmed in the xblast OS and suposed to flash red once, even when it's working normally.
    If that's not the case, it can be the 1.0 pic challenge timing issue.
    I seem to remember Benny used some slower ram timing parameters that are compatible with the 1.6b slower hynix ram chips.
    Obviously, this makes the timing more critical for 1.0 xboxes. An xblast OS with faster ram timings would be incompatible with 1.6B mobo's. Another thing that might slow down the OS startup is the check for the focus and excalibur video encoder chips in the xcodes. If the chip isn't there, the IIC communication will wait for a timeout. Maybe it checks the conexant video encoder chip first. In such case, it wouldn't slow down startup on mobo's with a conexant video encoder. It's been a while ago that I studied the xcodes.
     
  19. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    477
    Likes Received:
    181
    Taking 3V3 and GND from another source is indeed possible. I would suggest tapping onto the pads of one of the big tantalum capacitors on the bottom side of the motherboard, near the LPC header, and solder it straight on the appropriate pins of the LPC header, again on the bottom side of the motherboard. Having long wires going from the bottom to the top of the motherboard is a bad idea as they might pick up noise along the way. Even though the Xblast Lite should have sufficient filtering on board to cope, it's not a good idea when trying to debug inconsistent boot behavior. Tantalum capacitors are the yellow rectangle components that look like this:
    [​IMG]
    You should easily find one that has both 3V3 and GND on its 2 pads. With a multimeter, check for a pad that has close to 0 ohms with 3V3 on the LPC header, do the same for ground.

    Yes 1.0 are tricky but I feel this isn't the issue here. At least it looks a bit early to say it's a timing issue. I've worked a lot to make sure PIC challenge would be answered with a bit of buffer before the timeout on my 1.0 boards. I can push it a bit further but I'd like to avoid it as it would mean I'd have to do it before initializing some other key components.


    It must be d0. d1 - d7 points won't force the MCPX to switch to LPC, it'll just make the Xbox FRAG.

    This is expected behavior from XBlast Lite. Front panel LED will turn red for a second or so to indicate you can press the eject button to bypass Quickboot in case you have it set up. It turns red even if Quickboot isn't enabled.
    If the front panel turns red for a second, it means the PIC challenge was already answered successfully.

    At that point in the boot process, RAM timings aren't much of an issue. The PIC challenge isn't ressource intensive and very deterministic so initial calculation values are loaded from RAM and then it all stays in the CPU cache and registers. A couple load from memory instructions and then it's pretty much sequential execution from then on. Taking a couple extra nanoseconds to load up instructions and values isn't that significant when the PIC challenge timeout is in the order of milliseconds. What did influence the timing is the extra amount of time required to interpret the xcode sequence that satisfy all types of encoders but there's no way around it. At least none that I saw if you want to support all revisions.
    The problem as you point out is that you'll have to wait for a timeout on Xcalibur encoder as the only way to properly identify them is to go through a process of elimination starting with XCalibur then moving on to Focus and finally connexant.
     
  20. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    126
    Likes Received:
    37
    Are you sure about that last part? Connexant, Focus and Excalibur all 3 have different iic addresses. If you check and find a connexant, why would you even check further for an Excalibur or Focus? If the 1.4 and 1.6 timings are less critical, it would make sense to perform the check for their video encoder chip afterwards. I seem to remember that the SMC chip is monitoring the video encoder chip communication traffic as well, and also reboots the system if it detects some strange behavour in that. Maybe that's the reason why excalibur and focus are checked first.
    You are probably right it's to early to say that timing is the issue. After all, you sold many unit's and haven't encountered any problems before.
    The fact 2 1.0 mobo's show similar behavour obvious make things confusing.
     

Share This Page