StaticPulse

Nice!!

This would be pretty cool and would expand the capabilities of skinners I think. Should'nt consume too many resources.

Did you do the glitch and jRunner flash? Can't the temp settings be set from setting them on NAND itself in jrunner? Not sure if dashlaunch can override them or not but if you didn't do the glitch yourself and someone else did might that be whats going on? Yes heat damage can do it to.

Ohhh that... Usually what I do for that is press start, xbox marketplace, select what assets you want, set the ammount of screenshots you want and thenpress the download missing assets button.

You can select specific covers for titles via http://xboxunity.net Log in with your unity details and look up the title in question. you can then push the cover to your xbox via your unity account, or download it to disk. There is another method involving a cover editor but I don't know much about it other than it exists.

Use FATXplorer and copy it manually via folder or add it as you would in Horizon.

Here's the quick fix to just rule out anything you may or may have not done. Lets see if you have a background image set first and that it's dimensions are not any higher than 1920X1080 resolution. From aurora main screen press the B button and scroll down to Theme and see if you have a default background set. If default background isn't set and your screen is black then most likely the image file you are trying to use is either too high a resolution or it is corrupted. If you are trying to use just a default background and it is black then most likely it is corrupted and you'll have to replace it from one from a new download The file in question that you would want to replace is I believe Aurora.Assets.Background.png in the \Xbox360\System\Aurora\Media\Assets folder. It may be the skin which is loaded in \Xbox360\System\Aurora\Skins folder and is file Default.xzp ok... Now for the screen shot issue. Go back to the main AUrora menu and press start scroll down to plugin and check the "Screen Capture Combo to see if it is enabled and that the "activator" and "Trigger" buttons have been mapped to what you want them set to in order to take an on-the-fly screenshot. I'm assuming your main problem here is that you were having problems getting your screen captures to set as an Aurora background correct? OKAY THEN Custom backgrounds it is: Go to \Xbox360\System\Aurora folder and create a new folder named Backgrounds Cut/paste your screenshots from \Xbox360\System\Aurora\Media\Assets or FTP your custom backgrounds into that folder. Bear in mind, 1920x1080 resolution and I'm not sure if the file extension really matters, I use jpg,jpeg, and png. gif may or may not be supported, try and find out. When you've transfered what you wanted into that folder, go back to the main Aurora menu, press B, scroll to themes, and change background to what you want. If they don't display on the menu, hit X to refresh. If that didn't fix your problem then keep reading... Before I help you, I need to know. Did you do this RGH install yourself (Is it an RGH or JTAG?) and are you using fakeanim? Also, do you have all your files backed up in case of a failure? If not then you need to back your data up first (AUrora, dashlaunch, games database, etc, not games they'll be fine,) then, make a new folder for your replacement Aurora folder and place the new files there, afterwards you will want to go into dashlaunch, change your default Aurora path that Aurora uses for default.xex and direct it to the default.xex in the new Aurora folder. Save your dashlaunch config and exit. It should then instead load your new Aurora install, which you can then delete your old one, or if you so choose to move your games database (Located in: \Xbox360\System\Aurora\Data\Databases\content.db) to the new folder (providing that this isn't what is causing your problem) or you will have to reconfigure aurora with your file paths and rescan your system. You may also want to backup your \Xbox360\System\Aurora\Data\Databases\settings.db file also. This is just an overview to give you what options that would be available providing someone else here won't or can't help you troubleshoot your current Aurora install to restore the features that you're inquiring about.

Well, until I get a programmer and ribbon cable for the chip I'm dead in the water from that angle. I'll scan the board some more and look for damaged parts. I did pull the Time clock capacitor off though which shouldnt be an issue. I'll take a closer look at the caps on the board and make sure none are bloated/dry/blown.

Now that I've gotten some stuff taken care of (SR5T Short Air RAM intake, PTC nipple, vacuum lines replaced, and seafoam treatment to my Volvo 850R) as well as a 5 server VM install for a buddy (Solaris, WIndows Server 2012, FreeBSD, RHEL 7, CentOS) I can now get back to this project. I'll begin mapping out the pin header adapter in about 30 minutes or so from now. Just want to get a cup of tea and give my buddy a call so he can pick up his rig and get paid. ***EDIT*** No dice on the modchip by itself, I'm going to try grounding D0 as Swizzy suggested. ***2ND EDIT*** I grounded D0 on the bottom of the board and still nothing so it's not the BIOS apparantly..... So I guess now I go on to the TSOP mod or is there anything I may have overlooked?

lol thats the other half of the hardware that I need for this chip, I'll just have to check modchipcentral to see if they still carry it. =\ Hey, if I can still locate XenoGC chips, I shouldn't have a problem finding this stuff. Also, If I'm using BIOS from modchip won't I have to use a custom one built for 128MB systems?

Well.... I did manage to mount the partitioned drive in 360 explorer and copy over the retail dashboard; however, it still will not boot to it. I'm now in the process of looking for a *.bin extractor so that I can copy over the devkit dash from the recovery iso file that I extracted with xiso and extract the *.bin file that it is out of the iso and maybe copy that over instead.... (MagicISO failed to read the recdata.bin file T_T) That bin file is 189MB large, much larger than the retail dash so there may be some stuff in it that the BIOS is looking for. Xplorer360 refuses to mount the recdata.bin file as well. If this doesnt work then I guess I'll have to build a pin header extension for the cable for its stock pin header or build a new pin header and fit it with old PC jumper pins so that I don't have to remove the stock pin header in order to get the modchip correctly fitted. If that doesnt work then I'll explore the bios hack and see if maybe I can switch the bios and hopefully get a POST. I'll take some pics of my work or make a video of my progress. lol on a lighter note, I did manage to repair a retail console and softmod it with evoX so I have an okay understanding of what to do from that area. I'm thinking I have two options once I do get it working again: A. split the TSOP and put a modded BIOS on it to compliment the Devkit bios or B. put the modded BIOS on to the modchip itself. From what I gather from the guys who have helped me out so far, option B. is the safest. I'll keep hunting around for a method to dump the TSOP because if the TSOP is faulty then it might be a good idea to back it up and just replace the TSOP from one from a 1.0 board and flash it with the devkit BIOS.

unlock legit drive on modded console with superdisc and EEPROM decryption key then try it in the devkit?

It would still have to be an unlocked drive though. The locking is a form of encryption and without the key it'd be gibberish. Since the devkit needs no such key does for its own drive that wouldn't mean that it can read an encrypted volume. An easy enough fix though. I will try that this evening, gotta eat some food first as I just now got off work. That's a really good idea though.

I have it set as Cable Select as I see that all the stock retail consoles are configured that way. I am using an ATA133 rounded silicon cable though, if that is problematic I can always switch it out with a standard ATA133 or a stock ATA 66 one. Thanks man! I just want to get it going because it's a nice relic to have PLUS consolidating my MAME archive to it would be nice since from what I've read Classic Xbox has better rom support including chd's. Thats just it, I can't get it to even load superdisc, slayers, or the devkit recovery disc. This is why I suspect the BIOS and that it's not passing a POST.

It's not the EEPROM that I'm trying to scavenge. My EEPROM is just fine from what I know, but I do need an Operating system for this drive to rule out your thoughts on the drive first correct? I have no system files, the recovery disc doesnt boot with a partitioned // formatted drive via XboxHDM. So I'll need a dash. If that doesnt work then move on to the next piece of hardware that would normally fall into question, also I might want to consider putting this board onto my presto griddle since it was found literally in a garbage dumpster. Might need to bust out my multifmeter and maybe even order a few new scanning tools to go over the components if these basic fixes don't work. This doesnt bother me, I will fix it! I was planning on buying some more equipment anyways... =P I find that learning, fixing, and modding stuff is more fun than actually playing the video games that they were designed for. lawlz

HAHAHAHA HOLY CRAP!! I have that EXACT Vantec gpu cooler. I originally used it on a Radeon 9500 pro that I unlocked and overclocked to a 9700 pro. Funny... Overall a pretty damned good layout I think. I'm surprised you didn't do the 128MB memory upgrade on it. The copper heatsink on the MCPX3 chip was a good idea too. Were these consoles also prone to overheating like everything else Xbox? That is something I may have to consider once I get this thing up and fully running again. My biggest issue right now is scouring the junk pile for a working drive that I can dump its EEPROM from and clone the drive unlocked for the Devkit. I did tinker with it earlier today with XboxHDM and partitioned and formatted the donor drive, no dashboard files though so I'm going to have to really scour HARD through this crap and hopefully find something I can use. The Devkit still wouldn't boot even with a partitioned and formatted hard disk... T_T I also went through my old junk and found a working AMD system newer than that '98 box that has a serial port on it and I re-purposed it for this kinda stuff. Installed XP Pro Performance by TJ 2010 on it for efficiency. Not a bad bench rig with its 1GB of RAM, 1.2GHZ CPU and Gigabyte Geforce 6200 card in it. I'll keep it around for good this time as I think I'll need it with my BlackCat JTAG for Cable Modem firmware programming and anything else hardware related for older equipment.

I'll relay the info. If this guy doesnt bring me his GNS3 laptop to install 5 server OS's on it for him I'll probably start the unlock // drive clone procedure today.

That's what he wanted to do before he wound up at the hospital over that acidosis BS last month. I drove her over to visit him when I found out what happened. He's doing much better no though, got hella hammered on his birthday. That scoundrel was drinking Ten High Bourbon and I brought him a bottle of Crown Royal while I had my Grey Goose. It'd be good times for sure bro! I'm down for it! on the note of the xbox though, I'm real green with those things as during that time period I was modding my PC with overclocks and the such playing the hell out of Quake III Rocket Arena and Battlefield 1942 back when I still lived in Fremont.

I really really like his TSOP mod. Makes me wonder if you can piggyback it with a switch for more than 1MB for playing with different types of hacked bioses.I was actually wondering the same thing in regards to the Samsung memory chips on these old things. If its P3 architecture than you have a 3GB RAM capacity as long as you don't exceed the bus bandwidth on the motherboard you should be able to stack them in-line (No switch needed) I'd think. You could probably hack it to 2Gb safely. I'll mess with a couple one day and probably burn the test system up but it'll be fun to try. They're 128MB modules right?

Ok, so pre-partitioned drive first. I figured the XDK recovery disc would repartition and format it for me. I'm guessing I'll have to clone another drive that is unlocked which shouldn't be too dificult now that I have the EEPROM reader / writer, and a better understanding of how that X2 Pro chip works that Quattro gave sladez. I'm guessing that for any drive to work on it, it will have to have the partition info done first and that it will have to be unlocked as the devkit didn't lock its drive (great news when I get a 2TB internal and a SATA adapter for it!) If the devkit's relied on a 512k bios then that will be what I'll have to do. Don't take apart your console if you have a PITA build to undo to get to your work for dox. Not trying to make you bend over backwards and no sense in doing it if this calls for something different. As I said previously, I want to have it as stock as possible at first and when I know it's all good to go I'll mod it non-destructively. From how hard it has been to even find information on the silly thing I don't want to perma-brick it, but I'd like to know more on its hardware fundamentals before I tinker (Most likely on a junk 1.0 box in the pile first). I wouldn't know about a special default.xbe as I'm not even at that point yet; however, I'm sure if it does require one then booting a retail dash just to load the xdk recovery disc will restore it. From what I read on the information about the disc, it rewrites EEPROM, TSOP, and drive. If the drive is not a developement or debug kit it will blank the EEPROM and TSOP. So let me Round up a working hard drive, unlock it, clone it to my donor drive and see if that works. And I found a gem concerning TSOP reading. An MIT guy did it and here's a link that I guess would serve as a TuT, pretty cool actually, I like his TSOP socket for swapping bioses for expermental and developement purposes. http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html Here's his lab technical memo ftp://publications.ai.mit.edu/ai-publications/2002/AIM-2002-008.pdf I'm going to try to find his actual paper, should still exist but its no longer hosted at MIT.... He did a tear-down on his back in 2001 when he was working on his PhD on Supercomputer Architecture and noted some useful information. Also he was working with a semi-conductor company in San Diego and it took me some site crawling but I found his page on theory and mods and stuff full of his own designed TuT's concerning reverse engineering http://www.xenatera.com/hackingthexbox/index.html It looks to be a book that he wrote actually and these are sample pages of his work. ***EDIT*** Took some more site crawling but I found that he later released his publication as literary freeware. We should have a copy of this in our xbins Xbox section. Here's the URL save a copy definitely worth having I think. http://bunniefoo.com/nostarch/HackingTheXbox_Free.pdf

Thanks a lot for the input man, really anything at this point helps. I would like to test all the bioses as I'm pretty sure that might be my issue, the only other thing I'm concerned with is the fail boot where the sound distorts. Thanks a lot for the TuT, I do think that the 4-way method would most likely be best though since I can at least check them all this way and maybe if I ever do find a way to back them up I can write over the corrupted one if one is corrupted. That or use it as the flash space for the modded bios? SPDT switch wiring is pretty cut and dry so by looking at your solder points I could probably figure it out with no major issues. That and thats 4 chances instead of two of this working right? I never knew M$ had the forsight to implement redundancy like that and its a very pleasant surprise.\ ****EDIT**** So I'm reading the "Making TSOP split four ways" TuT and I'm halfway through it and from what I gather the points that they're referring to soldering is the same point I did the Coma Console fix correct? In this case I soldered C6R3 at point A19 bridging it with a small wire. So in effect the Coma Console fix just directs the POST to boot to a different TSOP copy correct? ***EDIT (again...) *** Nevermind, I soldered R7R2 to A18, not C6R3 to A19... ************************** If what I gather is true then this means one of my TSOP's is definitly corrupted causing the black screen boot, and this second one hangs at the splash screen. Or am I wrong in assuming that the patch point I used is not addressing a different bios to load? That sucks.... =\ It does seem like it can be fixed though and as long as the TSOP chip itself isnt physically damaged then if I find one copy of the bios that fully works, I might want to look into this potential method of dumping the bios found at this link http://www.theisozone.com/forum/viewtopic.php?f=33&t=53419 I'll keep researching it and reading up on it as much as I can before I do anything and I think the 4-way split is definitely the best method for recovering the stock BIOS. If all else fails, would just scavenging a donor TSOP from another 1.0 console with my rework station should work for this devkit, or was the BIOS on dev vs retail 1.0 different? Seems to me that the only difference in the BIOS would be the extra memory addressing but from what I've read I can get the custom BIOS for the memory hacked units and it should work right? After all, the BIOS is only to process the system POST, nothing software related on recovery disc should matter and once I can get it to boot to the DVD, with the XDK recovery disc it should rewrite all four BIOSes back to stock correct?

Now THAT is definitely something to look into. I'll research this further and post an update when I get more information on the matter. four copies. lol and I thought I was being redundant. lawlz. That's the best news I've heard on this so far. I'll definitely check it out THANKS A LOT MAN!!!! As far as dumping the TSOP the only thing I can think of to do it with would be something like this... (Theory only) http://www.ebay.com/itm/24CXX-24LCXX-Programmer-EEPROM-Reader-Writer-24C02-SOP-to-DIP-Block-USB-Port-/111871677709?hash=item1a0c12550d:g:53oAAOSwLN5Wk4F3

I followed the link and it is a v1.0 board. Is there any way I can go about backing up all the data (TSOP,etc...) using just hardware for now as the machine will not boot? Once again, not trying to sound like a redundant jerk but it's a Development Kit (Not debug) not sure if that matters at this junction or not but I really don't want to do anything to it that will perma-brick it. I know it's most likely damaged and this has become my newest hobby/project/obsession/nervous breakdown (hahahah) When I saw it I instantly wanted it because I'm a hoarder like that and I traded my buddy a fully working JTAG Falcon for it and the innards of the crystal case replacement console (Which I want for case parts to "make" work for this restoration.)

Its Connexant CX25871-14 and use the 256k debug and not GueuX-NeT Hack-devkit-GueuX-V2.rar ? TSOP is Hyundai, I think I'm going to edit this whole thread and put the important info at the beginning for good measure. These are things I never even thought of looking at since I never knew they existed or even mattered. Thanks for bearing with my ignorance on this one.

Which one would you suggest and do you think its the bios from what I posted above with the video? http://www.realmodscene.com/xbins/XBOX/Console%20Based%20Applications/bios/GueuX-NeT/ EEPROM version is XM2_3944