GameShark - Vs. Mode Final Destination (For Real!)

[Mr. Bland]

One or two pardons if I'm not posting this in the right spot. Feel free to move it as needed.

Hi guys! Like the thread title no doubt informed you, I've been working on getting Final Destination to actually work in Vs. Mode without crashing the game. And I did it. And then I uploaded a video to YouTube and... well, only a handful of people have seen it. Considering the implications, I wanted to make sure the information got to the right people, and so I came here.

I actually registered this account in order to download some files posted by other users while researching for this project. I didn't intend to post anything, so I picked Mr. Bland as a placeholder name. Oops. (-: My name is actually Guy Perfect, and I do a lot of game hacking. So that's me!
__________

This is basically a repost from a different site:

The usual level switch code for the North American release of the game is as follows:

800A4D09 00XX​

Where XX is:

• 00 = Peach's Castle
• 01 = Sector Z
• 02 = Kongo Jungle
• 03 = Planet Zebes
• 04 = Hyrule Castle
• 05 = Yoshi's Island
• 06 = Dream Land
• 07 = Saffron City
• 08 = Mushroom Kingdom
• 0D = "Metal Cavern"
• 0E = "Battlefield"
• 10 = "Final Destination"

The problem is, trying to load level 0x10 in Vs. mode crashes the game. This has been the bane of the Smash community for eons now, and people have jumped through some serious hoops to get around this problem. Up until now, the best solution I've read about was to hijack the 1P Master Hand encounter to inject additional players and remove the boss character. It's not elegant, and the match doesn't necessarily end when it's supposed to, but it works, and for many people, that's A-OK.

The short version of the story is that the value at 0x800A4D09 is read a number of times while loading the level, and one particular read is executed at address 0x80104C14. For whatever reason, if a 0x10 is read prior to the ensuing function call in Vs. mode, the game crashes. It likely has something to do with the Master Hand scenario's behavior, presumably because of the graphics being tied to the boss's damage meter. In the event some bland, featureless level's index is loaded at this point instead (such as 0x0E, Battlefield's index), the level loads just fine in Vs. mode, but without the sparkly stars or changing background.

Fortunately, N64 games tend to load code into RAM and execute from there, so it's ripe for the GameShark picking. If 0x10 is in the level index variable, the instruction at 0x80104C14 can be replaced wholesale by something else that won't break. So instead of doing what it does--loads the value from RAM--how's about it just always loads 0x0E in the event the actual level index is 0x10? The CPU instruction can be overwritten by the GameShark, and the game program will reload it from ROM before the next match, so it won't break doing it this way.

There's also the matter of the music. By default, the level uses the "Master Hand is approaching" tune, which isn't the one you'd want to battle to. The tune has an index of 0x18, and the formal Master Hand battle music is 0x19. So, easily enough, a GameShark code can detect one and replace it with the other.

So for the main attraction... The following code is a fix-only code that enables Final Destination to be used through the usual stage switch code. It does not, in of itself, cause Final Destination to be loaded in Vs. mode:

D0099113 0018
80099113 0019
D00A4D09 0010
81104C14 2002
D00A4D09 0010
81104C16 000E​

I've tested this on the hardware and in Project64, as seen above, and the technique was discovered using Nemu's wonderful debugger. A link to a YouTube video demonstrating this on the hardware is as follows:

EDIT:
Heeeey, would you look at that. I can embed YouTube videos into my posts. Joy!

 

[SmasherEKZ74]

Stop stealing my codes or I'm going to report you to the brawlfags.

 

[tehz]

Great job, and nice explanation of what the code does. Do you think a similar approach would work for the target test levels?

 

[Mr. Bland]

Stop stealing my codes or I'm going to report you to the brawl****.

Thanks for pointing out that you're a fraud. I made a reply in your thread. Cheerio!

Great job, and nice explanation of what the code does. Do you think a similar approach would work for the target test levels?

I just looked into it, and the bonus levels don't follow the same loading path as the usual battle stages. I'm not sure if they can be accessed with the same level index as the usual stage switch code, but if you can come up with those numbers, I can take another whack at it.

 

[Madao]

Lol I was wondering why you'd post a thread but now it makes sense.

Anyway, now i feel better knowing it wasn't Smasher who beat me to it .

I did a small attempt in the past, but never thought your method would work xD. When I debugged the gameshark code posted, I was like "wow Smasher actually knows Assembly???". Smh still frauding I see. I should try these things more often, even if they likely do not work.

It's good to know that there are other people who actually knows MIPS assembly. Nemu ftw!

Y'know, I think I attempted doing a stage swap hack using a similar method to this, but it would crash ;/ . It would be cool to patch the rom and swap stages.

 

[Cobrevolution]

smasher is literally trash, it's so awesome

 

[BananaBolts]

It's good to know that there are other people who actually knows MIPS assembly. Nemu ftw!

I'm currently taking C++ programming right now and I'll be taking Assembly next semester. Hopefully I'll be able to contribute to these projects

 

[Morin0]

Is it possible to replace "random" in the stage select screen?

 

[Madao]

Anyway OP, you should check out my gameshark thread.

I'm currently taking C++ programming right now and I'll be taking Assembly next semester. Hopefully I'll be able to contribute to these projects

nice! I recommend you start learning ahead of time. It makes school a lot easier . Of course it depends how busy you currently are.

Is it possible to replace "random" in the stage select screen?

Probably. The first challenge is doing a proper stage swap without crashing the game though ;/ . Maybe I'll see about how the random stage selection would work.

 

[UNKN{OWN}iXi]

This map is pretty fun for TEAMS.

 

[Mr. Bland]

Y'know, I think I attempted doing a stage swap hack using a similar method to this, but it would crash ;/ . It would be cool to patch the rom and swap stages.

I did some work on the level select menu while I was trying to figure out where the level indexes come from, but didn't dig too deeply. Open up the North American ROM and seek to address 0x001501B4. There you will find nine 32-bit values containing the level indexes for the selections on the stage select menu (the top row, including Mushroom Kingdom, are 0-4 and 5-8 are the bottom row). As for which images and stage models to use, I haven't looked into that, but I did download some GameShark codes for it from some other thread here, part of why I registered the Mr. Bland account. (-:

In RAM while selecting the level, the cursor's index is stored at 0x80134BDB, so you can get a head start on this one.

I'm currently taking C++ programming right now and I'll be taking Assembly next semester. Hopefully I'll be able to contribute to these projects

I can help you or anyone else who wants to learn low-level programming and hacking. My methods vary from traditional academia, but what you'll learn from me is, I like to think, a better education than you'd get most places. (-:

Is it possible to replace "random" in the stage select screen?

With a simple GameShark code? No, I don't think so. Menu index 9 is hard-coded to run the randomizer, where the other nine come from ROM.

Anyway OP, you should check out my gameshark thread.

I shall do so on my lunch break. (-:

 

[tehz]

Is it possible to replace "random" in the stage select screen?

With gameshark, you can replace random with a set stage. Or, at least you can fake replace it by either changing changing the inputs into the RNG (so, for instance, you could make it randomly pick any playable in VS stage) or by altering the instruction that puts in result of the RNG into memory (so you could just give it a fixed stage to go to when you select "random", or change it so that you have only like 5 stages that it randomizes over).

I guess I never posted those codes here. I'll do that when I get home from work.

 

[Mr. Bland]

or by altering the instruction that puts in result of the RNG into memory

Or that. This is why they don't pay me to think.

 

[tehz]

Yeah, you can't touch the normal "stage value" for random (0xDE); there's just too many dependencies.

Open up the North American ROM and seek to address 0x001501B4.

Hm, if that's the list I'm thinking of, you can't change any of those values to anything >0x08 without the game crashing when you hover over the changed position. I think the crash happens because the SSS uses the values to offset pointers for loading literally everything else ("the button", the preview, the name, the logo, the x and y positions of all of those), and all of those are in lists of 9 or 10 32-bit offsets somewhere else in the RAM. So, when you try to offset (for instance) the stage preview pointer by 0x0D instead of 0x08, it goes past those lists into some random space in memory (probably just empty space as there's a lot of space around) and reads that offset, and then crashes. I think anyways. IDK if you could just "fill-out" the lists past there, and then it'd work. I know that those stage values are also put into register for navigation on the SSS (ie., if you're on peaches castle, the values 0x02, 0x05, and 0x08 [if unlocked] are all in registers, so when you hit right, it'll use the 0x02 value to reset the SSS: offset the cursor, change the stage preview and stage name etc.), so that might also lead to crashes.

Is @novakain still around? He's definitely amazing at this stuff, and his thread on changing the SSS is like required reading.

EDIT: LOL I forgot that Smasher was complaining in that thread too : ^ )

 

[Mr. Bland]

Anyway OP, you should check out my gameshark thread

I'm noticing a distinct lack of Final Destination fixer-patcher codes. What are you tryin' ta pull here!? (-:

Or, at least you can fake replace it by either changing changing the inputs into the RNG (so, for instance, you could make it randomly pick any playable in VS stage) or by altering the instruction that puts in result of the RNG into memory (so you could just give it a fixed stage to go to when you select "random", or change it so that you have only like 5 stages that it randomizes over).

When you press Start on the sage select menu, it checks the cursor value against a literal value of 9 to determine whether to load the stage by index or to roll a random number. The actual instruction is located at 0x80133BCC: BNE A0, AT, 0x80133C04. The bytes from 0x80133BD0 to 0x80133C03 are, at first glance, the code that processes the random stage selection (among those few instructions is a function call via JAL 0x80131BAC).

To override the behavior of the random stage selection, if nothing else, the next three instructions after the BNE can be replaced with the following:

ADDI A0, 0x00??
J 0x80133C04
NOP​

... where "??" becomes the desired level index. I have to go back to work now (yes, I just hacked on my lunch break), but if someone wants to put together a GameShark code by figuring out the binary codings of those instructions, be my guest. (-:

 

[tehz]

Nice work. Way better than my method of just loading the stage value over the returned result from the RNG. So, I'm guessing A0 is the actual stage index? I just hope it's not the cursor value!

If the website compiled my inputs correctly:

200400XX    # addi A0,r0, 0x00XX
0804CF01    # j 0x00133C04
20000000    # addi r0, r0, 0

Then, assuming that we'd want to replace that first instruction, these would be the gameshark codes (unless we could maybe get rid of the last one [...BDC 0000] depending on what instruction is already there):

811133BCC 2004
811133BCE 00XX
811133BD0 0804
811133BD4 CF01
811133BD8 2000
811133BDC 0000

I dunno what value to D0/D1 on, though. I think the debug code address' (0x800A4AD0) value can maybe be used as a screen ID, but I haven't really check this thoroughly.

 

[Mr. Bland]

So I wasn't wholly familiar with the MIPS branch delay behavior, but it's looking like the same effect can be achieved by moving the assignment instruction after the jump, then omitting the NOP altogether. But that's a bit moot right now because...

I dunno what value to D0/D1 on, though. I think the debug code address' (0x800A4AD0) value can maybe be used as a screen ID, but I haven't really check this thoroughly.

Weeeeeeeell, I jumped the gun a bit. The method I posted in my previous post will work, but only for other stage select indexes (which range from 0 to 8).

The applicable instructions are as follows:

80133BC0    8C 84 4B D8    LW     A0, 0x4BD8 (A0)     ; Loads cursor index
80133BC4    24 01 00 09    ADDIU  AT, R0, 0x0009
80133BC8    3C 11 80 0A    LUI    S1, 0x800A
80133BCC    14 81 00 0D    BNE    A0, AT, 0x80133C04  ; 0xD * 4 = 0x34

​

I don't know what exactly happens in the "if cusor index is 9" block, but it's 10 instructions--two of which are JALs. It's obviously related to the random stage selector. If I replace the contents of register A0 before the instruction at 0x80133BC4 executes, it correctly loads the stage at the stage select index that I choose. So there's that.

The cursor index is loaded again at 0x80133C2C/E during a function call. Inside the function, V0 is initialized either to the actual stage index corresponding with the cursor index if the cursor index was not 9, or 0xDE if the cursor index was 9. When the function returns, V0 is written as a byte to 0x800A4B11, but that doesn't matter here. What we want to do is force V0 to be a level index of our choosing, but only if the cursor index was 9.

Naturally, the best place to do this is in the block of code that runs initially in the event the cursor index is 9, and then skip the regular function call, since calling it will reset our V0 to 0xDE. This can be done in four instructions following the code posted above:

80133BD4    0C 04 C9 0C    JAL   0x80132430
80133BD8    20 04 00 00    ADDI  A0, R0, 0x0000
80133BDC    10 00 00 0B    BEQ   R0, R0, 0x80133C0C
80133BE0    20 02 00 ??    ADDI  V0, R0, 0x00??

Where "??" is the index of the level to load, such as 0x0D for Metal Cavern, 0x0E for Battlefield or 0x10 for Final Destination.

The main downside here is that we don't want to unconditionally overwrite the instructions at those addresses: other code is stored there when not loading levels, and if they're the wrong instructions, the game will crash. So we need to have the GameShark only put them there in the event we're in the process of loading a level. And since that's 16 bytes' worth of code, we regrettably have that many lines of GameShark to deal with:

D1133BE2 C6EB
81133BD4 0C04
D1133BE2 C6EB
81133BD6 C90C
D1133BE2 C6EB
81133BD8 2004
D1133BE2 C6EB
81133BDA 0000
D1133BE2 C6EB
81133BDC 1000
D1133BE2 C6EB
81133BDE 000B
D1133BE2 C6EB
81133BE0 2002
D1133BE2 C6EB
81133BE2 00??​

It's ugly as all get-out, but at least it works. Well, I think it works. It works in Project64; haven't tested it on the hardware.

But if nothing else, we now have a way to override the Random behavior on the stage select menu. (-:

 

[tehz]

Nice job. GS' code-handler is awful. I first "learned" how to do this type of stuff from Dolphin, and I miss Gecko so much. It's just so much more robust.

I just looked at some old NEMU bookmarks I add, just in case they're any help:

80133BD8    24040009    addiu    A0, R0, 0x0009    #Load range for RNG )

Immediately after (or during?) the jump instruction you pointed out, the range for the RNG is loaded. By changing that 0x0009, you can "change" which stages random returns (eg, setting it to 0x000F, you can get all of the stages from 0x00 to 0x0E)

80133BE0    JAL    0x80131BAC    #function checks if M.K. is unlocked and if selected by RNG
....
80133BF4    BEQ    S0, T1, 0x080133BD4   #if M.K. was selected + not unlocked, re-roll RNG
80133BF8    NOP
80133BFC    BEQ    R0, R0, 0x80133C18    # weird way to jump I guess, but...
80133C00    SB    S0, 0x000F (S1)    #store S0; this is the important part

S0 is the value returned from the RNG, which is a number between 0x00 and 0x08 (or N-1 for whatever you set at 0x80133BD8), which the game eventually interprets as the Stage Index. Changing S0 at this point will change whatever level is loaded (at least in NEMU).


So, those are my old notes, but I can take this further now. Thanks to that nice NOP (it's a true NOP of 0x00000000) after the BEQ check for the re-roll, we have an easy place to change the value of S0

So:

Put in:
201000??    addi    s0, r0, 0x00??
at 80133BF8
For GS:
81133BF8 2010
81133BFA 00??

Going with the first half of the SB instruction at 0x80133C00 as our D1:

D1133C00 A230
81133BF8 2010
D1133C00 A230
81133BFA 00??

This code works on both NEMU and my GS Pro 3.2, with less GS BS. I'd like to push it further to add in a custom random stage select (ie, pick randomly from like DL, PC, BF, and FD).

 

[Mr. Bland]

The last line of the code you posted should have an A at the end of the address, not an 8. Otherwise, it does work... which I find odd, because the instruction you're overwriting is the branch delay for a check that prevents the same stage from being selected randomly twice in a row. It loads the value of the previous stage and checks it against the new one, and if they match, the branch is taken. But because the branch delay is making sure it's ALWAYS the same, logic would dictate that it should always take the branch, but that's not what I'm seeing. |-:

Is it the case, then, that the condition in a branch instruction is evaluated first, followed by the execution of the delay slot, then lastly the PC is updated? If that's how it works, then everything makes sense. If not, then I need some MIPS tutoring. (-:
__________

I began researching your "add additional stages to the randomizer" problem, but got sucked into something else in the process... A closer inspection of the original crash problem has turned up a smaller GameShark code to fix Final Destination. The following instructions are causing the issue:

80104C34    2F 01 00 10    SLTIU  AT, T8, 0x0010    ; Set AT if level is < 0x10
80104C38    10 20 00 18    BEQ    AT, R0, 0x80104C9C

In other words, this is a branch to skip over some Final Destination specific code (technically anything at or over 0x10). If Final Destination was set, the function then jumps to 0x80104C84, which has two function calls: first to 0x80192764, then to 0x80104850. If Final Destination was NOT set, then instead the function jumps to 0x80104C9C, where there's another call to 0x80104850. The code paths then merge after that. Why they didn't merge before calling 0x80104850, who knows. It was probably in the source code that way.

Obviously, the call to 0x80192764 is where the crash is occurring. If we skip over that, we can make a shorter patch code:

D1104C84 0C06
81104C84 2000​

Doesn't fix the music still, but at least it's 2 lines instead of 4.

So what's at 0x80192764, anyway? I have no idea. It looks like broken code, or padding data of some sort, or most likely leftover work data that happened to be laying around in RAM. Whatever it is, it doesn't come out of ROM, and I have no idea how it wound up getting compiled as a function call. Maybe they used a literal function pointer like this:

(void (*)())0x80192764();​

... and then later removed whatever used to be there. This makes it look like Final Destination was originally planned for use as a Vs. mode battle stage, but later they decided to leave it out. And if they leave out that stage, they'd have to leave out Battlefield too (at least), lest the player base start asking questions about it. This whole hypothesis adds up under the notion that they couldn't get Final Destination's changing backgrounds to work correctly in Vs. mode, so they decided to ditch it and take a different approach in Melee.

Who knows. What's clear is that it's not code, so trying to execute it will result in not game. In any case, it's looking like we were all wrong: the crash certainly doesn't have anything to do with Master Hand. (-:

 

[Mr. Bland]

Okay, got it. I would have had this posted earlier, but the web host was having some issues... which it still is, but I got through.

Like tehz pointed out, the instruction paired with the first JAL under the random stage selector is the value to divide the random result by. That is to say, the number of different possible random results (0 to n - 1). The instructions look like this:

80133BD4    0C 00 62 8C    JAL    0x80018A30
80133BD8    24 04 00 09    ADDIU  A0, R0, 0x0009

If we wanted to add more stages to the random pool, we'd have to change that number. I'm going to provide an example using 12 levels: the normal 9, plus Metal Cavern, Battlefield and Final Destination. So we'll need to make that 0x0009 a 0x000C. GameShark can do that easily enough:

D1133BD8 2404
81133BDA 000C​

A few lines down, as tehz once again pointed out, is a function call that checks whether A) Mushroom Kingdom was rolled and B) Mushroom Kingdom has been unlocked. If its return value is non-zero, another random number is rolled:

80133BE0    0C 04 C6 EB    JAL   0x80131BAC
80133BE4    00 40 20 25    OR    A0, V0, R0
80133BE8    14 40 FF FA    BNEZ  V0, 0x80133BD4
80133BEC    00 00 00 00    NOP

I think the most graceful way to expand the feature is to hijack just that function call, pointing it somewhere else in memory where the GameShark can access data a little more freely (i.e.: without a ton of conditional checks in it). I believe I've found some otherwise unused bytes at 0x800A4D40. So if we point the function call there, we can play around with it a bit:

D1133BE2 C6EB
81133BE0 0C02
D1133BE2 C6EB
81133BE2 9350​

Now we need some code to put there. I've designed the following simple function:

800A4D40    3C 10 80 0A    LUI   S0, 0x800A
800A4D44    02 04 80 20    ADD   S0, S0, A0
800A4D48    82 10 4D 54    LB    S0, 0x4D54 (S0)
800A4D4C    03 E0 00 08    JR    RA
800A4D50    20 02 00 00    ADDI  V0, R0, 0x0000

This takes the result of the random number roll (which is stored in register A0 prior to entering the function), adds it to 0x800A4D54, loads the byte at the resulting address as the new level index, and clears V0 so that the branch in the calling function won't be taken (the one that re-rolls if Mushroom Kingdom hasn't been unlocked).

The GameShark code for this is the bulk of this demonstration, but here it is:

810A4D40 3C10
810A4D42 800A
810A4D44 0204
810A4D46 8020
810A4D48 8210
810A4D4A 4D54
810A4D4C 03E0
810A4D4E 0008
810A4D50 2002
810A4D52 0000​

Lastly, we need some data at 0x800A4D54 (which are the bytes immediately following the custom function). This is simply a list of level indexes to use in the random roll. Make sure there's the same number of these as there are RNG results. In our case, there need to be 12 level indexes, and the ones I want are as follows: 00, 01, 02, 03, 04, 05, 06, 07, 08, 0D, 0E and 10. So to GameShark it up:

810A4D54 0001
810A4D56 0203
810A4D58 0405
810A4D5A 0607
810A4D5C 080D
810A4D5E 0E10​

And there we have it. There are additional bytes at 0x800A4D60 that appear to be unused, so unless someone finds some reason we can't use bytes in this range, it should be just fine for adding more levels to the random pool.

 

[SmasherEKZ74]

None of these codes work, the codes I posted in the original thread do work however.

 

[NovaSmash]

None of these codes work, the codes I posted in the original thread do work however.

Stop stealing other people's work.

 

[SmasherEKZ74]

Stop stealing other people's work.

never stole anything, I just posted the working GS code without all the useless bs.

 

[caneut]

Stop stealing other people's work.

Stop stealing air.

 

[SmasherEKZ74]

"The thread on Smashboards has devolved into the aforementioned goon persisting that he was the original author and that subsequent discussion and GameShark codes are in fact falsified, and whether another member should or should not kill himself for wasting air. I wish I was joking"

Welcome to Smash Bros 64. Isai is god, and everyone else is a bunch of raging ******s like Cobre and Gav.

 

[THE_MAAFIA]

Yo you guys are modding geniuses, hopefully I can help you guys out some day

 

[obsidianchao]

This **** is incredible... kinda makes me want to learn ASM. Big step up from my barely-BASIC knowledge, but it'd be fun.

 

[Danny_SsB]

the old gameshark code for 1p mode had a code to choose the background of FD (stars, clouds and swirling) Is it possible to make this code version Vs mode? :O

 

[Mr. Bland]

The 1P encounter has hard-coded transitions between background types according to Master Hand's damage (which internally counts up to 300, where the HP meter displays it the other way around). Since the backgrounds are supported in 1P mode, you can trick it into switching to the haze or the vortex by setting the internal state variable, which is what the old codes do. In Vs mode, since the backgrounds aren't implemented whatsoever, there's no simple way to transition between them. Not even the sparkly foreground stars are present.

From a hypothetical standpoint, it should be possible to route the program loop to the same functions that control the backgrounds, but that's more a ROM hack than a GameShark thing. There are texture and animation assets loaded for the 1P encounter that aren't in Vs. mode, and all of that would have to be patched back in to get the backgrounds to appear. This is presumably what was going to happen based on what I saw in the Vs. mode stage loader, but as I found, the function call points to garbage data, so whatever used to be in the works was removed.

This **** is incredible... kinda makes me want to learn ASM.

Only kinda? )-:

 

[ZenBren]

Great code, works like a charm! Just tested it on my hardware. Came across a glitch when I first ran it, all the maps would redirect to the map in the code that was supposed to be FD. It went away once I removed my memory card from my controller. Now you just need to make a code that prevents the game from crashing when you play teams on how to play stage.

 

[KnitePhox]

i like how there are no foreground shooting stars, how refreshing

 

[HyperNuke]

I wonder when we'll get Target Test stages in VS mode, i heard about the 1P mode thing, but the codes don't work for me. And I would much rather play it by selecting in VS mode. One day... I'll replace Yoshi Island with Falcon' s Target Test.

 

[FGUG2021]

Managed to port the code for the final destination fix to the JPN release

Playable Final Destination:

D0098BD3 0018
80098BD3 0019
D00A2CC9 0010
81102834 2002
D00A2CC9 0010
81102836 000E

VS. Mode\Stage Select:

800A2CC9 00??

00 - Peach's Castle
01 - Sector Z
02 - Congo Jungle
03 - Planet Zebes
04 - Hyrule Castle
05 - Yoshi's Island
06 - Dream Land
07 - Saffron City
08 - Classic Mushroom Kingdom
09 - Dream Land Beta 1
0A - Dream Land Beta 2
0B - Level From "How To Play SSB Demo"
0C - Random ?
0D - Metal Mario's Stage
0E - Fighting Polygon Team Level
0F - Race to the Finish!
10 - Final Destination

Tested on emulator:

"Nintendo All-Star! Dairantou Smash Brothers (Japan)"

Photos:

https://imgur.com/gallery/YVnH2XN