I've concluded that by using 8x qimonda hyb18h1g321af-10/11/14 and a method to run 17150 xdk kernel on your 360 with whatever method u desire, u will end up with a functional 1GB xbox 360 that of an XNA kit Spoiler: OP I have an idea for my Jasper 4.1 motherboard. But i'm lacking some things required to (i think) utilize my theory on this specific motherboard revision from a retail 360. Here are my requests. [1] some pictures of the underside on the XNA model kits. (several if possible, close ups if also possible of the motherboard in 4 sections, like top left, top right etc.) [2] a nand dumb of the XNA kit w/ key, or the filesystem contents of the nand if not desired to include cpu key. ALONG with all the "staged" bootloaders, smc, smc_config, pretty much everything minus the KV cuz thats not required.. [3] all the XDK related files and resources off the XNA kit's side car hard drive. dont need games, betas or sdk samples etc. Optional [4] If the owner of the XNA kit could provide any extra info on any possible top side hardware not found in non XNA kits. if its all sidecar related you may disregard this request. This is just a theory so im keeping the specifics on the low for now cuz i feel its a 50/50 chance of a bust (the failure would only be result of specific hardware). The rest would be software patching related. Im sure users will know or eventually figure out the theory. if so i just ask you not post back to this thread trolling or w/e would be the case. I would prefer all the requests be sent to me via pm. If successful findings will be documented and everything released here on assembler. Thanks a milli
I can take pictures of my XNA's board for you. What exactly are you trying to do? add the extra 512mb ram to the underside? curious and interested. XNA dump, not including 1bl and kv <
A VERY big thank you my friend . and yes. In theory any GDDR3 1Gb IC with (4096 K x 32 I/O x 8 banks) specifications should work. they all need the same CAS latencies and Write latencies. It would be easiest to just replace all the oem ones with same batch ordered units, for a total of 8 new ic's. My 4.1 mb is using 4x 14ns speed grade ic's. https://www.dropbox.com/s/6c0ptvceagumv98/qimonda-hyb18h1g321af_0a037cbc11.pdf?dl=0 the dump is to check for the possibility of the XNA kit using diff sw features to utilize the xtra 512. its entirely possible just physically adding the xtra 512 and using a post XNA kit dev/retail hybrid nand to make it usable. But since i dont know if the os has this functionality built in, i need to check hence the dump. should be possible on any mb revision if replacing all ic's. SMC and bootloaders are the first to check for 1GB support may i ask what sw version your xna kit is running? nvm got it
Afraid i don't know what sw means hahah i'm not so technical when it comes to this sort of stuff do you mean the recovery/flash? if so, 21256.13 Im certain the xna kits have a different bootup stage in the smc, id look into what xshell looks for to tell if the kit has 512mb or is an xna with 1gb, slims could help as well, im sure xshell isnt just detecting the ram, id imagine its getting info from smc saying hey this kit supports 1gb of ram
sw = software, but xshell could point to it, and i noticed in the SC.bin Code: Xbox 360 Devkit 2.0.17349.0.....H...HWINIT 090504a..,..',..(H.......H...BL Ready looking at smc atm Update: Only difference between this dump's smc and my retail jasper 4.1 smc is the following: top is retail, bottom is xna dumps I've attached a 6k partial dump of xshell from 17150. it explicitly says its using 8X of the same exact ram ic's in my jasper. The zipped bin also describes xshell's internal macro and some possible sdk functions to enable / disable / check for the 1GB system ram. Check op
If i remember correctly someone just only added the 512mb of ram and the 4 10k resistors next to the ram chips, running the dev kit kernel on a modded xbox and it showed the 1gb in xshell. i have a trinity that i want to do but no one in my area can ball the 4 chips i needed to do.
Speaking from experience, I attempted this back in 2011-2012. I shipped a few broken boards with the exact RAM chips found on the XNA units and dedicated a spare Jasper stress kit to the cause. The appropriate resistors were added, and all the RAM chips were swapped. Unfortunately, it's not as simple as that. With the additional chips on, the unit simply RROD'd. I can try to dig through old emails if you guys really want, but I think all four lights were flashing and it simply wouldn't boot. No secondary error code. Removing the chips from the bottom (512mb), the unit returned to normal. I didn't bother to dig too deeply into it, but there's definitely some fields in the KV or SMC that define the physical console properties. I'm guessing you'll have to flip at least a few bits for the console to accept the transplant. Ended up removing the additional chips and selling the unit, so the project never pushed through to completion. Best of luck, -Doom Edit: Following up on what @ddxcb said, I do remember some mention of this. I heard of someone doing this with a retail unit, running Fusion. I think the console booted, and was functioning. The 1GB of ram was selectable, but the entire time it was on it was throwing 4 RROD like the stress unit I put together.
Thanks for that input. i had a hunch that minor smc change wasn't random. ill have to play with mine after i get another set of 4 chips.
I remember someone did it to a jasper with RGLoader and all the user did was add the 4 ram chips as well the 10k resistors next to the chips. this was also a couple years ago.
A friend of mine said xshell just checks the board to see if it has 512 or 1024, then based on the answer you will be prompted with the message asking which you would like to use.. he knows a lot more about it than me.