Jump to content
OGXbox.com

calebTree

Members
  • Posts

    37
  • Joined

  • Last visited

Recent Profile Visitors

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

calebTree's Achievements

Newbie

Newbie (1/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

2

Reputation

  1. @Donnie-Burger Thanks again for your help. Okay, so realizing it loads disks, and also to rule out some 3D rendering issue I attempted to load a 3D game from disk. That worked fine so then I had the confidence to run the factory reset from OG-XBOX Installer. That also worked and it took me to the default XBOX dashboard, so SUCCESS ! I'll keep this posted on the 128MB ram functionality or any other bugs I run into.
  2. Thanks for your thoughts @Donnie-Burger. Well, I reflowed all the RAM. I even reseated one of the chips which was a little crooked and which I believed to be the culprit. I got them all passing the XBlast tests. The IND-bios flubber comes up which is a start. Only now it cuts to a black screen as soon as I hear it trying to load the dash from the HDD. The LED is solid green. Also, it does load a disk ex. OG-XBOX Installer. When I hit the eject button at the black screen the iND-bios splash logo appears again briefly then it goes black again. I was very satisfied with my reflowing results. I'm back to the same dilemma. I could quadruple check the RAM. Before this, I kind of believed if XBlast says all 4 RAM pass then it's a done deal.
  3. Thanks for the reply @SS_Dave. In my experience I've not been able to boot XBlast (cromwell) from OpenXenium on a 1.0. I attribute that to Issue #6 on the OpenXenium GitHub. So far, I've tried different cables (A/V, IDE) and even a different HDD. I also reflowed a little (not every chip yet). All chips still pass XBlast testing, and it is still not booting to a normal dash. This thread I found useful https://forums.afterdawn.com/threads/xbox-flashing-green-only-green.505446/. I still have not found anything conclusive yet.
  4. I have a 1.0 and I flashed XBlast to the TSOP then tested each chip as I went. Once all 4 were passing I reinstalled OpenXenium and attempted to boot iND-BIOS-5003. Only, the LED flashes green and it doesn't boot. I tested several homebrew BIOS loaded from OpenXenium and they all have the same problem. I'm considering triple-checking for shorts (or reflowing with hot air) yet I'm surprised because XBlast boots and says all 4 RAM passes. I found a couple of Reddit posts with the exact problem: https://www.reddit.com/r/originalxbox/comments/7fppvw/attempted_128mb_upgrade_wont_boot_flashing_green/ https://www.reddit.com/r/originalxbox/comments/epel27/no_soundvideo_flashing_green_light_after_128mb/ I'd like to avoid doing anything drastic as XBlast finally states all 4 RAM are passing. The only other oddity is (even before this above error) when FTP to OpenXenium the drives (C, E, F) do not show up. Yet, the drives were available when FTP to a homebrew dash like UnleashX. Tested a different XBOX and FTP to OpenXenium all drivers were available.
  5. Yeah, I have also never seen this solid green related to RAM upgrade either. One thing I did notice is that XBLast 0.53 BIOS in an OpenXenium bank says "unsupported modchip" in the top left info on the main menu. Of course otherwise XBLast seems to work fine.
  6. I have seen those troubleshooting steps too but they don't seem related as it does boot fine w/o additional RAM installed. I found some new RAM online but it was K4D263238F-QC50 and it did the same thing so I haven't eliminated the compatibility question yet. I haven't found K4D263238D-QC50 available anywhere yet.
  7. I've had the "solid green/no-video" with 3 different RAM chips in two different slots. I've reflowed and re-soldered a bunch of times throughout my troubleshooting sessions and as soon as I've got all the pins down I get the "solid green/no-video". I've got good equipment and flux including a magnifying glass. I got a full 128MB RAM working my first try on a 1.0 rev. board so getting RAM down and working is not a hat trick and since then I've had tons more practice so the likelihood there is a short which I am somehow not seeing is small. The other thing I kind of wonder is if this is expected behavior using an OpenXenium chip (even though it should be booting directly to XBlast). I'm not sure because the first time I did a RAM upgrade I had XBlast on the TSOP. This famous video explicitly uses a Xenium chip but not the one I have.
  8. Why does it sound like shorted pins? What specifically about my post would lead one to believe the pins are shorted? I am familiar with shorted pins I get Red-Green blinking LED. I've never seen solid green related to shorted pins.
  9. I wonder if it's a RAM compatibility issue or indicating definitely damaged RAM IC? Does anyone know the max temp the RAM ICs are rated for? I am working with a 1.4 revision board and an OpenXenium which should be booting straight to XBlast. I haven't seen much info anywhere about a solid green LED in the process of a RAM upgrade. However when I've got a chip installed it power cycles twice then goes to solid green LED but no video and the OpenXenium LED is yellow whereas if XBlast were to have booted the OpenXenium LED would be green. The board has default K4D263238D-QC50 and I have tested adding K4D263238M-QC50 (salvaged from a 1.0 revision board) and K4D263238F-QC50 (bought new on eBay but I used them). No additional RAM boots and works fine. Does the yellow LED on the OpenXenium indicate anything useful? What about the solid green LED on the console? Thanks
  10. Yeah, with the 1.2 I'm not sure as much about Red-Orange. With the 1.4 it is possible to bridge the solder pads too even though the RAM is removed - if you're getting Red-Green^. I like a no-clean flux pen (still requires some cleaning), plus it just takes allot of practice.
  11. @KaosEngineer was wondering what colors the LEDs are? Green-Red LED debug code is going to be bridged solder on the RAM. Orange-Red LED debug could mean different things. Is it the TSOP or a modchip booting to XBlast?
  12. Apparently the NDURE exploit is able to "patch" the kernel. See Rocky5 "Softmodding Tool" explanation of NKPatcher Settings: https://github.com/Rocky5/Xbox-Softmodding-Tool#nkpatcher-settings
  13. For those of you playing at home I continued (and I believe concluded) this question here: https://www.ogxbox.com/forums/index.php?/topic/4721-why-did-flashing-a-kernel-file-with-xblastos-break-the-xbox
  14. I hypothesis there must be damage to an internal layer of the PCB from when I was impatiently trying to install the pin header using a heat gun because I didn't know how to use solder wick correctly. Eventually I learned from this video how to use solder wick correctly: https://youtu.be/xty1G5UBYb0 In the "Soldering Techniques" section of Appendix B in "Hacking the XBOX" by Andrew "bunnie" Huang, Huang does talk about removing components on a budget with a heat gun. In my experience I don't recommend it (and it's obvious from the damage) because for example my heat gun specs were: Low - 50 - 350 C, High - 200 - 500 C, Air Flow: 450L/min. As soon as a SMD would come loose it would just blow away. Compared to a proper hot air rework station which is much more gentile: 100 - 480 C, 20 - 130L/min. I am not aware of an economical way to repair damage to an internal layer of a PCB. I had fun though and learned a ton! Unless anyone has any other ideas I will have to add this board to my sacrificial pile. For those playing at home this thread was where I started this question: Open Xenium Install Question (damaged board) - Modchips - OGXbox.com
  15. I am really surprised at how quickly the culprit could be tracked down with some strategic use of the multimeter. Honestly, the voltage test was the next thing I was going to do when I was ready to start probing the xbox with it plugged into the wall. Yes, the IC was on the board. Now, I decided to remove it again though and check and there is no change. When I'm talking about continuity I have to use the resistance setting on my multimeter so when I say I have continuity I mean I get a (significantly low) ohms reading. I don't get continuity between GND and A or B. Yet, I do on all the other pads of the IC and I do on the working board. I do get continuity between A (the via) and B (the IC pad). I should also get continuity between B and all the other pads of the IC but I don't.

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.