Jump to content
OGXbox.com

calebTree

Members
  • Posts

    37
  • Joined

  • Last visited

Everything posted by calebTree

  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.
  16. Yeah, I don't have a buzzer type continuity multimeter so for sure on my working board like you say the black lightning is 0.0 ohms and the other pins have resistance. There's also the question of black lead on pin and red on component to test or vice versa which I haven't figured out yet.
  17. Right, I get 101.3 ohms on one side and 1.3 ohms on the other side of R7R5. Good to know pin 5 connects to Q7R1. I'll have to probe around that and see what I can learn. Okay, so I have continuity between pin 5 and all the legs of Q7R1 other than the circled leg pictured above and I should which I know because I am comparing to a known working board. In the image above Q7R1 and C8R2 are missing because they fell off before I took that picture but I have since put them back on. Apparently I might have to work on Q7R1 though.
  18. Yep, I still get 0.19 on pin 5. Everything else was the same other than pin 1 was 0.0 w/o mod chip.
  19. Great, yeah, yep, I have an issue on pin 5, RST. I already reflowed the solder twice on that pin with good Chip Quik flux to no avail. I'm just getting 0.19 v every time. I could reflow the solder on all the pins later but for all I know there is internal damage at this point too. I'm just getting closer I guess. This was a board as you can see I learned some solder lessons on the hard way. Wouldn't it be nice if it got up and working again though. I also want to be more specific that my data tables above were read from D0 (bottom) to the LPC pins (bottom).
  20. Awesome replies everyone, and exactly the answers to questions I have accumulated from browsing the vast XBOX mod scene content everywhere on the internet. Apparently 1BL is the secret boot ROM that was discovered to exist on the MCPX (bunnie) before booting is handed off to 2BL which exists on the TSOP. Then, 1.1+ revisions introduced an additional security measure between 1BL and 2BL which is FBL. Apparently the digiex files are 2BL software which include the compressed and encrypted kernel that also resides on the TSOP and which is decrypted with the help of the MCPX. Correction above was that I had the 128MB RAM mod working before I flashed the file from the digiex forum. The XBOX I have in question here is a 1.0, 3944 original kernel until I flashed probably 5713 and broke it. Thanks @feudalnate and @KaosEngineer for consolidating and clarifying so much on the size of the .bin kernel/bios files and the ROM size differences across revisions. I would like to get my OpenXenium mod chip working to recover from this but I haven't been able to since the bad flash and I am still investigating. I would have had iND-BIOS 5.003 (F only) running at the time from the HeXEn 2018 disk. Which was why I wanted to get stock BIOS back because shortly after using that BIOS for a minute I got a kernel panic, then the blubber intro got goofed and was over zoomed in, then also for some strange reason I couldn't copy the dashboard audio files to my HDD from Rocky5's Softmod Extras - I would only get empty folders. Now at least I understand how the kernel/bios files are compatible or incompatible across mainboard revisions. Here were the ohms Ω readings from black on D0 to red on each pin. The broken board had the TSOP write protection points R7D3 (top) and R7R4 (bottom) joined. It also had the OpenXenium chip hopefully installed correctly with a wire going from D0 to the mod chip's D0. I don't know what this data means yet but at least it's consistent. Here is the % increase data from the broken board to the working board. I don't think I have the "coma console". I have blinking lights frag exactly as described in this GitHub issue. My unit does have the identically described frag but as far as I can see it doesn't look like it is caused by OpenXenium in my scenario.
  21. I disagree with the total truthfulness asserted above. Rather, it is only fair to allow the troubleshooter or OP, to determine when they believe they have beat an area of research dead and when it is probably a good time to give attention to something else that they may have missed. In my case, such as what exactly happened when I flashed the file? Therefore, I would like to explore the software end of this question which has not been thoroughly addressed yet. As I mentioned it was after a software change when the XBOX began failing. I politely suggested the search for how I could use a multimeter in this scenario and more specifically what I might look for on specific test points. A more scientifically sound endeavor. I will suffice to add that in comparing my multimeter values on random points on the broken board with a known working board I have found all values are very similar so far. I am attempting to source sophisticated and matured responses and information rather than immediate replies. I do not typically expect immediate replies from forum posts.
  22. Again, replies that attempt to tell me what isn't perfect in the pictures are less helpful right now.
  23. "It doesn't look perfect" is not novel feedback for me at this point. If someone really wants to be helpful please help me find or guide me on using a multimeter on relevant test points or components such as what the continuity or resistance should be on them. I want to reiterate that it was after a software change when the behavior in my YouTube videos above demonstrating the problem (fragging in xbox lingo apparently) started.
  24. Did game disks update the kernel? I thought they just updated the dashboard. My understanding is that the kernel is basically the part of the OS that is closest to the hardware and thus has the least abstraction. In XBOX terms I would imagine the kernel is mostly the whole OS and then dashboards are simply on top of the kernel. You're saying you believe XBlastOS could have flashed that kernel file to something other than the TSOP? Yep, I had ind-BIOS working with 64MB RAM and at the time I inadvertantly didn't make the distinction between kernel and BIOS thinking I was going to flash that file and it was going to bring back stock BIOS.
  25. I grabbed a Kernel file from this page and I flashed it with XBlastOS. Does the kernel have to match the original kernel? What is the kernel relative to the BIOS? Normally kernel and BIOS are two very different components of a computer. I shouldn't have been able to flash the TSOP with the kernel correct? How are those kernels meant to be used? I was looking for the default BIOS. 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.