Bond697

Wild Pokémon and stationary legendaries without a shiny check have their PIDs created in the same way. It involves using the TID and SID to evaluate the seed being used for the PID and whether or not it should be OR-ed with 0x80000000 on creation. ---------------------------------------------------------------------------------------------------- standard 0x8 decision pid generation(btw, r6 is sidtid for basically this entire thing) 020056FC F096ECB6 blx #0209C06C //switch to ARM, to 0209C06C (umul64()) -return to 02005700 02005700 6922 ldr r2,[r4,#0x10] // load value at 2216254 into r2(00269EC3) 02005702 6963 ldr r3,[r4,#0x14] // load 02216258 into r3(aka, zero-out r3) 02005704 1810 add r0,r2,r0 // add together r0 and r2, finish l32 advancement 02005706 414B adc r3,r1 // new upper seed 02005708 6020 str r0,[r4] // store the lower half-rng back to the state offset 0200570A 6063 str r3,[r4,#0x4] // store the upper half-rng back to the state offset 0200570C 2D00 cmp r5, #0x0 // this is 0 for pid creation only 0200570E D101 bne #0x2005714 // false, no branch 02005714 6860 ldr r0,[r4,#0x4] // load the value of the upper half of the rng state into r0 02005716 2100 mov r1, #0x0 // set r1 to 00000000 02005718 2300 mov r3, #0x0 // set r3 to 00000000 0200571A 1C2A mov r2, r5 // move contents r5(0x0) to r2 0200571C F096ECA6 blx #0209C06C // no branch 02005720 1C08 mov r0,r1 //save that u32 02005722 BD38 pop {r3-r5,r15} //jump to 20186F8 020186F8 1C04 mov r4,r0 //save the seed to compare 020186FA E024 b #0x2018746 02018746 9807 ldr r0,[sp,#0x1C] // value @ 2FE3604(0x2) 02018748 2800 cmp r0,#0x0 0201874A D019 beq #0x2018780 0201874C 2801 cmp r0,#0x1 0201874E D002 beq #0x2018756 02018750 2802 cmp r0,#0x2 02018752 D01E beq #0x2018792 ;true 02018792 2001 mov r0,#0x1 02018794 9906 ldr r1,[sp,#0x18] 02018796 0400 lsl r0,r0,#0x10 //prepping for base 0x00010000 xor 02018798 1C22 mov r2,r4 0201879A 4002 and r2,r0 //not understanding why it ANDs u32 by 10000, but r2 now == 0 0201879C 0409 lsl r1,r1,#0x10 0201879E 428A cmp r2,r1 // same as with the legendaries, 10000 vs. 20000, not equal(this is ability-setting junk) 020187A0 D000 beq #0x20187A4 // false, no advancement 020187A2 4044 eor r4,r0 // base xor by 00010000 020187A4 1C20 mov r0,r4 // store this half-ready pid to r0 and save it... 020187A6 BDF8 pop {r3-r7,r15} 021A9DB2 79A1 ldrb r1,[r4,#0x6] //2FE36C4- pull a byte out of a local array- this byte determines the type of PID- HL, standard, gift, etc 021A9DB4 2902 cmp r1,#0x2 // r1 = 0 021A9DB6 D012 beq #0x21A9DDE // false, no branch 021A9DB8 6A2C ldr r4,[r5,#0x20] //load sidtid to r4 021A9DBA 0401 lsl r1,r0,#0x10 //set the lower half of the temp pid to r1(u16 of r1, need to fix) 021A9DBC 0C0B lsr r3,r1,#0x10 // move the lower half temp-pid to the lower half of r3 to prep 021A9DBE 0421 lsl r1,r4,#0x10 // separate tid and sid; this is tid 021A9DC0 0C22 lsr r2,r4,#0x10 // sid is ready 021A9DC2 0C09 lsr r1,r1,#0x10 // tid is ready 021A9DC4 4051 eor r1,r2 // tid ^ sid 021A9DC6 1C1A mov r2,r3 // move lower 16 of pid to r2, get ready for next step 021A9DC8 404A eor r2,r1 l16 pid ^ (tid ^ sid) 021A9DCA 2101 mov r1,#0x1 // r1 = 1 021A9DCC 4211 tst r1,r2 // (tid ^ sid ^ l16 pid) & 1 (= 0 in my case) 021A9DCE D004 beq #0x21A9DDA // resolve to 0, skip this 021A9DD0 2102 mov r1,#0x2 // set up 0x8 or 021A9DD2 0789 lsl r1,r1,#0x1E // r1 = 80000000 021A9DD4 B002 add sp,#0x8 021A9DD6 4308 orr r0,r1 // this is an OR, not XOR 021A9DD8 BD70 pop {r4-r6,r15} //return 021A9DDA 4902 ldr r1,=#0x7FFFFFFF // set up to finish the pid 021A9DDC 4008 and r0,r1 // unset the highest bit, though it's probably not set as it is 021A9DDE B002 add sp,#0x8 021A9DE0 BD70 pop {r4-r6,r15} // return

ok, i think we have it down now. the code is copied and pasted straight from r/s where they had it optimized down to a series of shifts.

there is no rng seeding code anywhere in there. if that's a guess based on the code from the original games, then fine, but i'm pretty sure it's not there.

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.

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

If you want to change what ROMs you can distribute to, you can just change the strings it checks against to use any rom: 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.

I think you got confused. 10anniv otg is: (rand() >> 7) & 1 if 0, ot gender is 1, if 1, ot gender is 0 so take the highest bit of the lower byte of rand(). if it's 0, ot gender is 1, if 1, then otg is 0. 0x31 is the ot gender field in the pkm RAM:02013A66 FC F7 D9 FE BL rand RAM:02013A6A C0 11 ASRS R0, R0, #7 ; rand >> 7 & 1 RAM:02013A6C 38 40 ANDS R0, R7 ; gender decision RAM:02013A6E 00 28 CMP R0, #0 RAM:02013A70 0C D0 BEQ loc_2013A8C RAM:02013A72 00 20 MOVS R0, #0 RAM:02013A74 41 46 MOV R1, R8 ; r8 is sp+0x15 RAM:02013A76 08 70 STRB R0, [R1] ; set sp+0x15 to 0 RAM:02013A78 0A E0 B loc_2013A90 RAM:02013A78 ; --------------------------------------------------------------------------- RAM:02013A7A 00 00 ALIGN 4 RAM:02013A7C A0 B7 01 02 off_2013A7C DCD pp_name ; DATA XREF: createPkm+Er RAM:02013A7C ; createPkm+58r RAM:02013A80 14 60 00 03 dword_2013A80 DCD 0x3006014 ; DATA XREF: createPkm+14r RAM:02013A84 00 00 FF FF dword_2013A84 DCD 0xFFFF0000 ; DATA XREF: createPkm+2Cr RAM:02013A88 FF FF 00 00 dword_2013A88 DCD 0xFFFF ; DATA XREF: createPkm+30r RAM:02013A8C ; --------------------------------------------------------------------------- RAM:02013A8C RAM:02013A8C loc_2013A8C ; CODE XREF: createPkm+C0j RAM:02013A8C 40 46 MOV R0, R8 ; r8 is sp+0x15 RAM:02013A8E 07 70 STRB R7, [R0] ; set sp+0x15 to 1 RAM:02013A90 RAM:02013A90 loc_2013A90 ; CODE XREF: createPkm+C8j RAM:02013A90 30 1C MOVS R0, R6 ; pkm RAM:02013A92 31 21 MOVS R1, #0x31 ; ot gender RAM:02013A94 42 46 MOV R2, R8 ; this is the data ptr with the ot gender decision RAM:02013A96 FE F7 83 FA BL setPkmPartyData RAM:02013A9A 07 B0 ADD SP, SP, #0x1C RAM:02013A9C 38 BC POP {R3-R5} RAM:02013A9E 98 46 MOV R8, R3 RAM:02013AA0 A1 46 MOV R9, R4 RAM:02013AA2 AA 46 MOV R10, R5 RAM:02013AA4 F0 BC POP {R4-R7} RAM:02013AA6 01 BC POP {R0} RAM:02013AA8 00 47 BX R0

i have no doubt they're exactly the same aside from the obvious changes to ot and whatever else.

This might sound dumb, but the first thing to do might be to see if any of the trash is actually thumb code. If so, those are probably the first ones generated. Could the ones with none have been traded to a gamecube game and back? The trash bytes for the 10anniv pokes exist because GF does a copy of the pokemon's name from a global constant to a local buffer, then copies the local buffer to the .pkm "file" in memory. The problem is, the first copy is just a strcpyFF(local_buf, global_const) which ends at the 0xFF terminator, so if the name in the variable was 'LUGIA'\xFF FF FF FF, they would only copy 'LUGIA'\0xFF, leaving the last 3 or however many bytes as whatever was on the stack before because they don't zero-out the full size of the local variable before the copy. Then they would copy the name using strncpy(&pkm.name, local_buf, 10) without caring about the junk past the FF-terminated name. The thumb code on the stack that makes up the trash is because of a function that 's basically memcpyFF(dest, src) that copies until it hits an 0xFF that I think is copying waaay too far and is coincidentally not breaking anything so they either didn't notice or left it.

salac or ganlon

This is the info for it: You can see the text is (poorly) translated and not localized. https://dl.dropboxusercontent.com/u/13004170/meteor_jirachi.zip

I don't remember what I did anymore, actually, aside from pulling the roms out of the game cart. I think I decompressed it, but I'm not sure.

Ohh, ok. I was told none of them had items. The one I was looking at was the lugia rom and that one has the light ball in it. I'll have to pull out the other ones.

Fun fact since you brought this up: the 10ANNIV multiboot roms have unused code in them to give all 10ANNIV pokes a light ball. Must be a leftover from another event somewhere or something since the 10ANNIVs have no item.