[Announcement:] Several New Gen 3 Jirachi Events Found by me!!

[Sabresite]

@Purin You were able to generate negaiboshi jirachi?  Does it have a held item? Because that is the part of the algorithm I do not have enough information to determine.
I would love to figure out how that is determined.

[St. GIGA]

2 minutes ago, Sabresite said:

@Purin You were able to generate negaiboshi jirachi?  Does it have a held item? Because that is the part of the algorithm I do not have enough information to determine.
I would love to figure out how that is determined.

If and when you get the multiboot file from Purin, can you pm it to me, as I started the thread? I also want to test it.

[Guest]

-

Edited December 22, 2019 by Guest

[St. GIGA]

OK, Got it. 

On a side note, is it possible to get WISHMKR Jirachi to distribute to FRLG and Japanese games. I know @shiny quagsire did, but he never shared, and @ajxpk, you know enough to help me. Can you send me a patch for client.bin that makes it distribute to those games? I also want to see if that patch is able to be ported to Meteor Jirachi's client.2003_1112.bin, and if Meteor Jirachi has the same Shiny-check bug as the released Wishmaker Jirachi does, which allows 9/65535 to be shiny. Does anyone also know how to make the ripped Jirachi MB rom work on emulators, so that people do not need the full disc?

Edited April 5, 2017 by St. GIGA
Added question.

[Soniktts]

2 hours ago, Purin said:

I've researched this about 5 years ago.
If I remember right, the file has the 2003 ネガイボシ Jirachi in it.

I was about to comment this, I forgot who researched it.

If I recall, this Jirachi is identical to the Wishing Star Jirachi event from the 2003 movie. I have a few of these in 3rd Gen files and everything looks identical from what I can see. Might be worth asking @ajxpk just to be 100% sure. It's been a while since I've seen this come up though. 

[Sabresite]

I would love to disassemble the actual negaiboshi code because my negaiboshi follow a different generation method for berry than the ones @Purin has.

Also @Bond697 is having issues finding the generation code for sample0519.

[St. GIGA]

8 minutes ago, Sabresite said:

I would love to disassemble the actual negaiboshi code because my negaiboshi follow a different generation method for berry than the ones @Purin has.

Also @Bond697 is having issues finding the generation code for sample0519.

Ok. Got it. Hopefully @Bond697 is luckier.

[suloku]

@InsaneNutter the app is originally made for savegame dumping, all I did was change the rom that gets send to the gba, after that it was expected that no kind of gba-wii comunication would take place.

So, we have the file that gets sent over to the gba and it is the same as the official distro rom Purin has? Then as Purin said the sample0519_bin might actually expect some kind of host-client response to do its distribution magic. Also, as InsaneNutter said, the wii app actually got some kind of communication (that of course failed) so the other files might be incomplete or send different response.

[St. GIGA]

This is why a disassembly is needed. Also, I am confused as to whether or not Mew always has an item in Emerald. I know it by default can only hold a Lum Berry, but in all clips I saw of a capture, it never has had one. My question is, @suloku, was adding the single Lum Berry I got legitimately from the HaxAras save via trade a good idea, as you supposedly did say Mew had used one during battle but, I want to know how rarely (if ever) Mew holds one. I know it is programmed as the only valid Wild held Item for Mew, and that it is in Emerald, so there is a higher chance than other GBA games, and that Mew is a normal Method 1 Wild Encounter, so by all means, it should rarely show up (possibly 5% plus Emerald's bonus) when a Mew is caught in a Master Ball, (or caught quickly with False Swipe, and no Status Moves, plus Entrap ability).  I have heard Mew has a 5% chance of holding its signature and only held item of a Lum Berry, but I want to confirm it, so that I can know if legitimately adding a Lum Berry would "touch" an otherwise untouched Faraway Island Mew that supposedly held one beforehand. 

Back to the topic at hand. 

I discovered that the ROM entrypoint, and the other important parts of the header in the client and sample .bin files actually match those on the colbtl.bin save uploader mod I uploaded (at least in certain areas). This, along with the string "FLASH 1M V2" in all the ".bin" files, along with both sets crashing on a white screen in the EXACT same way on NO$GBA makes me think that, due to the JP bonus disc being integrated into US colosseum, maybe we could mod Colbtl.bin to load these Jirachi binary files when we try to trade with GBA games. They do have similar issues. 

Edited April 6, 2017 by St. GIGA
Added theory about colosseum.

[Invader TAK]

19 hours ago, Purin said:

Yeah, it holds one of the usual berries!
I was using the Japanese distribution rom for which I don't have permission to share, sorry. However, iirc the multiboot binary matches sample0519.bin. There might be special things (i.e. handshake?) going on after the slave boots.

Just wondering, is the Negaiboshi Jirachi distribution limited to one per save like WISHMAKR/Channel or is it unlimited like Shiny Zigzagoon and the various 10th Anniversary events?

[Guest]

4 hours ago, Invader TAK said:

Just wondering, is the Negaiboshi Jirachi distribution limited to one per save like WISHMAKR/Channel or is it unlimited like Shiny Zigzagoon and the various 10th Anniversary events?

Unlimited!

[Invader TAK]

2 hours ago, Purin said:

Unlimited!

Nice! And since you said it matches sample0519.bin, then that means we just need to figure out how to use these multiboots.

[King Impoleon]

I tryied the rom on My EZ Flash IV

works fine, until receiving the pokemon, nothing happend 

 

 

[Guest]

On 7.4.2017 at 11:24 AM, King Impoleon said:

I tryied the rom on My EZ Flash IV

works fine, until receiving the pokemon, nothing happend

The multiboot roms are waiting for a handshake from the distribution server/master rom (via link cable), so you cannot use them directly.

[King Impoleon]

Just now, Purin said:

The multiboot roms are waiting for a handshake from the distribution server (via link cable), so you cannot use them directly.

I connected via Link cable

Distro with cable 1 and Pokemon Sapphire with cable 2, like the other distributions...

[Guest]

It won't work that way. The .mb files must be executed on the GBA with your Pokemon Sapphire inserted.
But just executing won't work either. A handshake must be received from another distro GBA. But since this handshake/master rom is not public, the .mb files need a patch.

[jojo12100]

11 hours ago, Purin said:

It won't work that way. The .mb files must be executed on the GBA with your Pokemon Sapphire inserted.
But just executing won't work either. A handshake must be received from another distro GBA. But since this handshake rom is not public, the .mb files need a patch.

I try to understand what can be the patch you talk about.

We're very close to the aim in a way but it's a bit obsur for me all that technical terms.

 

But I have a theory: if we compare the 10ANNIV Rom structure, the Aurora ticket rom structure and that Jirachi test rom structure can we "fix" it?

And after that can we imagine finally unlock all that distrib for every language?

[Guest]

I imagine the program flow like this:

1. Master rom (not leaked) transfers multiboot rom (sample0519.bin) to the receiving GBA in multiboot mode
2. Receiving GBA boots multiboot rom
3. Multiboot rom waits for the master rom to make a connection, checking whether booting was successful (handshake)
   → If no (or invalid) communication occurs, it will keep waiting indefinitely at this point and cannot proceed (UI also isn't fully rendered yet)
4. Check if there's a cartdige inserted (*0x80000B2==96h) and if it's the correct game
   → If not, quit and show an error
5. Check if there's a free slot in the party
   → If not, quit and show an error
6. Read some data from the game cartridge and use it as seed for Pokémon generation
7. Put generated Pokémon into the savegame and write it back to the cartridge
8. Show animation and success message

If my theory is correct, I think point 3 is what needs to be patched to make it run without the master rom.
My skills are insufficient, but maybe @Bond697 would be able to help?

[Sabresite]

@Purin, @Bond697 got back to me and said the slave payload simply copies what is in RAM in PKM format to the save game.  So your list has to be changed a little.  The first thing it does is copy/generate the fields used to make the PKM.  The slave payload does the checking and such, and then copies those fields in PKM format to the save game.

Unfortunately, unlike the newer standard multiboot roms, the generation is not done on the slave payload.

Bond, can you confirm other details?

[Bond697]

On 4/10/2017 at 7:02 AM, Purin said:

I imagine the program flow like this:

1. Master rom (not leaked) transfers multiboot rom (sample0519.bin) to the receiving GBA in multiboot mode
2. Receiving GBA boots multiboot rom
3. Multiboot rom waits for the master rom to make a connection, checking whether booting was successful (handshake)
   → If no (or invalid) communication occurs, it will keep waiting indefinitely at this point and cannot proceed (UI also isn't fully rendered yet)
4. Check if there's a cartdige inserted (*0x80000B2==96h) and if it's the correct game
   → If not, quit and show an error
5. Check if there's a free slot in the party
   → If not, quit and show an error
6. Read some data from the game cartridge and use it as seed for Pokémon generation
7. Put generated Pokémon into the savegame and write it back to the cartridge
8. Show animation and success message

If my theory is correct, I think point 3 is what needs to be patched to make it run without the master rom.
My skills are insufficient, but maybe @Bond697 would be able to help?

If you want to change what ROMs you can distribute to, you can just change the strings it checks against to use any rom:

Spoiler

Note the AXVJ and AXPJ.   Changing those to the game you want will fix it.  Or changing the 2 "BEQ     loc_201E410" to "B     loc_201E410"  will make it work no matter what game you use. To make those work, change "23 D0" @ 201E3C6 to 23 E0 and "1C D0" @201E3D4 to 1C E0.  You really only need to change the first one, but might as well be thorough.

I'm not sure why you would want to make the ROM run without a master.  How would you get it to write to a GBA cart if you had to have a flashcart in to launch the mb ROM or.. something..? 

Also, something to think about regarding moving the mb ROMs between master GBA distro cart ROMs:

Each GBA distro cart has its own set of global variables it writes to in IWRAM(0x3000000-0x3008000).  The mb ROMs use matching global variables in order to "inherit" data from the master cart.  Things like seeding the RNG are done in all the distros in that way.  The multiboot ROMs don't make their own RNG seed, they just get it from their master.  Take this example:

3 multiboot ROMs, 3 different RNG locations.  That's just an example, all the variables are like that in each one.  So if you move a mb ROM from one distro cart to another distro cart, the resulting pokes you get may not be "legit" since they may not normally be able to exist since the mb ROM may read and use incorrect data from an IWRAM location that is incorrect.  I think you mentioned that you got a lot of identical(almost identical?) Jirachis when you moved a distro ROM to a different cart in order to generate them and that may be why.  They may not be "real" Jirachis that could have been generated at the original event.

The oldest ROM, sample0519, gets more data from the master distro cart than any of the others.  Things like OT name and gender seem to be passed to it via IWRAM, not determined via RNG in the mb ROM.  There's probably other data done the same way but I haven't looked.  Really the only way to figure that stuff out would be to have the original Negaiboshi(sp?) distro ROM to look at.

[Sabresite]

@Bond697, you did confirm that there is no LCRNG in sample0519, which indicates that most likely most, if not all data for the PKM is in IWRAM.  This would include species, PID, moves, etc.  Which makes sense since for example with the 5th anniversary eggs, there is a random pokemon chosen, with a % chance of a shiny pichu.  They probably set the data in IWRAM, and then the slave simply copies it via PKM format. That means sample0519 in both of those events are interchangeable/universal.

[Bond697]

No I didn't, I said the seed came from the master cart.

[Sabresite]

EDIT: I made a mistake.  @Bond697 said the item is determined by a number in the master ROM.  I think this is the seed, right?

@Bond697 said the algorithm for the held berry is
 

(x << 0x10 & 0x30000) >> 0x10 & 1

which essentially boils down to x & 1, where 0 is ganlon, and 1 is salac.

This is supported by all except for one of the negaiboshi that I have.

[Sabresite]

So to confirm what @Bond697 said, if someone magically is able to get the slave payload to work with another master ROM, the jirachi would (at the very least) have the wrong PID algorithm result due to how the seeding works.  That is granted we can get the global variables to match up, which sounds difficult (impossible?) using a master ROM from the wild.

[Bond697]

yeah i think we're out of luck here unless someone has the actual gba distro cart for the negaiboshi.  to figure out how it works anyway. 

if someone does actually have it and is weary about giving it to anyone, remember, no one knew i had the 10anniv rom for more than 5 years, and even then it became known only because other people let it out. 

 

e: same goes for pcjp2003 and anything else we need info on.