Swizzy

Mobile connections aren't good for playing games online, it actually makes the experience for everyone else involved go down... i would get a proper connection before trying to go online, this also means you have less headaches... Also, Lmodir you REALLY need to work on your patience man...

It's probably done as basic as possible, A, B, X and Y are digital while RT/LT is analog, digital means 1 or 0 while analog has a range 0 - 100%

That looks like it's listing all folders within subfolders etc. as if they're in the root, which they're not...

Sure, but most that go online to ask things like these questions will not have much of a clue what they're doing, and more often then not we neglect to think about that and give advice that might damage your console, even so, even if you know what you're doing it's easy to be tired and miscount the pins or whatever and connect it the wrong way and damage it regardless...

The jumper should be avoided as if placed incorrectly it can cause damage to the console, the nodvd patch is much much safer

There's also a chance that there's a solder ball underneath the motherboard which connects points together, which is something we can't see in your picture(s) it's very rare that a NAND-X breaks, even with shitty soldering...

All it takes on any system is to catch the controller input buffer prior to any game reading it and patching it with the remapping rules effectively it'd be a universal trainer for the controller mapping only

It's more of a you didn't pay attention kind of deal, but... perhaps we need to make it verify the passcode once you've entered it once (if we don't already do that) that'd make it virtually impossible for you to set a passcode without meaning to do so... unless of course you completely ignore what it says, which defeats the purpose of a warning anyways (and it's a better method anyways as it requires you to put in the passcode 2 times exactly the same way)

http://www.realmodscene.com/index.php?/forum/63-aurora-compatible-trainers/ I've added the forum here

Feel free to figure out how to communicate with the MMC controller to write to it, we can only read with XeLL at this time, and that only really works when you do NOT boot from the kernel, this is done using a virtual address that the bootloaders setup which the kernel kills when it boots The way i do read/write of the MMC with Simple 360 NAND Flasher is by opening a raw file handle and having the kernel do the under the hood communication...

I'm not your personal support assistant, i'm very busy with work lately which means i have a very limited amount of time to give to others, besides that there's plenty of information about your particular issue in the forums and on the internet if you just bother reading it... you just can't be super specific, you must be a little bit more open minded and read what information is available about various badblock related issues etc. none of that stuff is private or hidden, it's all public and easy to find as long as you try hard enough I've also grown very tired of people demanding answers without bothering to read and people posting multiple times in the same site about the same issue in multiple threads or multiple different sub forums, it's just annoying... take your time and read up on how all of this stuff works, RGH/JTAG isn't for non-technical people... really... it's easy to mess things up, but just as easy to fix if you have a little bit of knowledge or have the will to search for it

Actually, there is... you just fail to read it... the last line is where it should popup every couple of cycles

Yeah, the NAND/Dump features require you to dump your NAND/MMC, the other features do not... (such as reading save information)

I'm about ready to ban you right now, you're making new thread upon new thread upon new thread about the same issue and you failed to read what the page says in the past, if you don't shape up and start trying to do something yourself other then expect to be spoonfed you WILL be banned from this site

Carefully read what the message says at the end of booting XeLL, if it says it's skipping updflash.bin it's because it's a MMC corona (it'll tell you something like that aswell) If you have a 4GB console, or even if your dump is 48MB it's a MMC corona

Thanks, but we already have translators for both german and spanish, if they're not able to translate the new version we'll contact you about it

You can't "fix" them, you can however deal with them... Bad blocks/ecc errors are normal and quite common, you just have to remap the blocks where they occur to the end of the NAND

Ahh, right... well, the one i'm talking about i ripped and posted online somewhere, can't remember where tho

Actually, there was a test disc i found in a brand new console once, it works on any system, however... iirc it's primarily for DVD Drive tests

The beta updates did have xeBuild patches most of the time, but they were never made public as they were often released with about a week between them, we did however test them most of the time until the final version was released (pretty much always the last beta to be released in each beta cycle) GXArena hosts all updates that i've been able to get my hands on so that they're available to those that need 'em, it's especially important for those whom used xk3y's or burned discs on old iXtreme firmwares (where the update was started to the point where the console restarts/flashes the drive), the beta firmwares aren't really useful for those cases, but, there are other errors that have to be resolved using a USB drive with the appropriate update on it, which is another good reason to have all updates available Some of the earlier beta updates i extracted myself, if memory serves me right i was in the first 2 major beta runs, extracting the every update as they came and published after the beta was over (didn't want to get into trouble during the beta)

You did by calling all of us rude and whatnot, also, NOVA is NOT dead... we haven't forgotten about Xbox 360... If you don't like us here, feel free to find some other site to visit!

Microsoft aren't leaking them, someone else is leaking them...

http://xebuildtut.xeupd.com it's pretty easy to memorize, "xebuild tut dot xeupd dot com", the hardest part is my domain name i guess, it was meant for "xebuild update" kind of thing

Np, glad you got it sorted It was probably the writing that failed, just, windows didn't know it as there is no verification done beyond what the MMC controller responds with, which was probably that it was a success despite the data being partially mangled somewhere (most likely the write address) which would explain it all... When i checked your dumps you sent me, i only really checked the per-console data, the really important one (fully that is) the other checks i did was to check that the filesystem looked to be OK and that stuff looked to be where they're supposed to be, but i didn't go into nitty gritty detail to check the hashes of the files within the nand etc.

That dashboard is actually very old now... It's atleast 3½ years old...