Past Gen RNG Research

for anyone keeping score at home, 3 hits.

OD, i'm at 19 billion searched at this point. am i wrong in doing the math out and thinking there might be 9 or so trillion values to search? i mean, we're flying through, but there's just so many to go through. do you actually want to wait the months for this to finish? i take it we don't. when would you like me to stop? 10 hits?
 
for anyone keeping score at home, 3 hits.

OD, i'm at 19 billion searched at this point. am i wrong in doing the math out and thinking there might be 9 or so trillion values to search? i mean, we're flying through, but there's just so many to go through. do you actually want to wait the months for this to finish? i take it we don't. when would you like me to stop? 10 hits?

Given the fact that you have 3 hits already, and after I changed my program to check only the top 32 bits of the seed like RNG reporter is doing I have 6 "hits" (none of which are correct), I'd hazard that there are a whole lot of false hits overall.

Anyway, it might be good to get some extra verification that what I calculated as my initial seed really is such. I did the working backwards from TID thing that was posted here some time back, and the numbers check out (including generating a 5th TID and advancing the MTIVRNG by walking and verifying those ivs match as well), but as I said, no AR to really verify it. I'd hate to be leading everyone on a wild goose chase here.

Maybe I should look into the Chatot voice technique for seed verification...
 
Huh never heard of that. If you do look into it there are ways to extract the .wav file played for a Chatot, if that helps (PokeStock).

For HGSS, if you have a Chatot that knows Chatter, and you record your own cry for it, it can be used to advance the RNG or check your seed just like Prof. Elm calls. On the status screen, it will cry a low, medium, or high sound. The supposed math is described here.

If you have two of them next to each other in the party, you can go through frames fairly quickly by flipping back and forth.

Unfortunately, in BW it seems that it's not a simple low / middle / high split, but a full 8192 value range, so it doesn't look like you can use it to check your seed. You can still use it to advance the PIDRNG frame in the same way, though.

Note I haven't actually tried any of this, just reading various pages.
 
Yay, another new advancement method for PID RNG :P
Unfortunate about the large range.

Had to stop midway for the international egg PIDs, but it looks like Everstones change the call positioning. moar needed later

==

Heh, magnemite was pretty quick at "picking up" the keypress encryption stuff. I bet he didn't get the complex presses!

Tell (^) us how abilities are calculated :S
 
seconds|vcount|rwtimer|gxstat|vframe
24 203E 85C8 0 0
6a6af7e45d36b012 != 6a6af7e4be9ef132

24 8047 E395 F 5
6a6af7e4ab045bfc != 6a6af7e4be9ef132

24 C077 4DEF B 4
6a6af7e40e750dda != 6a6af7e4be9ef132

24 6096 A7E7 2 C
6a6af7e48fa0f23f != 6a6af7e4be9ef132

24 E0EF E4B1 4 9
6a6af7e4dadee00e != 6a6af7e4be9ef132

24 6114 8B9C 3 9
6a6af7e474d6d681 != 6a6af7e4be9ef132

24 E156 B4B9 F 0
6a6af7e458508289 != 6a6af7e4be9ef132


And for informational purposes, here's some of my false hits:
Code:
6a6af7e4c5264a00 - Sec = 27  vcount = 3c0  Timer = a67  Frame = 0  GxStat = 8
6a6af7e4e561d4fb - Sec = 26  vcount = 85f  Timer = f72  Frame = 9  GxStat = f
6a6af7e4e667bf0b - Sec = 25  vcount = 1bdb  Timer = e36  Frame = 4  GxStat = 7
6a6af7e4f0548a9b - Sec = 26  vcount = 1dc1  Timer = e15  Frame = 9  GxStat = 1
6a6af7e49e6f863b - Sec = 26  vcount = 21d3  Timer = df0  Frame = 5  GxStat = e
6a6af7e424c60297 - Sec = 26  vcount = 3a2a  Timer = b83  Frame = 4  GxStat = 6
6a6af7e4dbe36163 - Sec = 26  vcount = 4745  Timer = f2f  Frame = 2  GxStat = 5
6a6af7e4f77c8237 - Sec = 26  vcount = 56ba  Timer = 9bc  Frame = 9  GxStat = a
6a6af7e47fb2dce5 - Sec = 25  vcount = 676c  Timer = f5a  Frame = a  GxStat = 5
6a6af7e424b5e66c - Sec = 25  vcount = 702d  Timer = 874  Frame = 7  GxStat = 0
6a6af7e4a15ddc5f - Sec = 27  vcount = 76e7  Timer = bf4  Frame = 9  GxStat = 1
6a6af7e47fe68018 - Sec = 26  vcount = 9617  Timer = d81  Frame = 2  GxStat = d
6a6af7e47e672cb2 - Sec = 27  vcount = b840  Timer = ecb  Frame = 5  GxStat = d
6a6af7e4f12bf7f1 - Sec = 25  vcount = c235  Timer = 853  Frame = 5  GxStat = c
6a6af7e4e33cd798 - Sec = 27  vcount = cf79  Timer = 88d  Frame = 8  GxStat = 3
6a6af7e4c0951e97 - Sec = 26  vcount = d08b  Timer = b10  Frame = 0  GxStat = b
6a6af7e407a58716 - Sec = 27  vcount = dc4f  Timer = fbe  Frame = 6  GxStat = b
6a6af7e4324bec32 - Sec = 26  vcount = ebc8  Timer = a29  Frame = d  GxStat = a

It's a big search space!
 
we're gonna start another one with a different version of rng reporter that will show me the results so i can post them as they happen. 9 trillion parameters to search is gonna take awhile, to say the least.


just out of curiosity, what app are you using to get so many results so fast? also, what parameters are you searching? the same as me?
 
just out of curiosity, what app are you using to get so many results so fast?

As I mentioned before, I wrote my own app. It's a C++ cmd line app so probably runs faster than C#. On the other hand, you've got more cores... It's very ugly at the moment, and it's single threaded, so sometimes I run multiple instances.

Anyway, I've verified for a few sets of parameters that it's generating the same seeds as RNG Reporter 9b3 (some kind anonymous soul slipped it to me).

also, what parameters are you searching? the same as me?
Those were the results of searching:
vcount : 0000 - ffff
timer : 0800 - 0fff (I don't have the starting point of this, but almost positive it was 0800)
** EDIT ** Actually, it was 0 - 0fff
frame: 0-f
gxstat: 0-f (00000000 - 0f000000, stepping by 01000000)
second: 25-27

That took just about one day to cover (one thread, something different crunching in a separate process on a dual core machine).
 
Inheritance IV calculated with u32*6>>32
Inheritance parent calculated with u32>>31
Using the convention from Gen3/4: A is deposited first, B is second.

Code:
[U]IV Inherited[/U]
HABCDS
012345

-----------------------------

[U]Regular/International Breeding[/U]
A is first in, 1
B is second in, 0

[U]Dittos and IV breeding[/U]
Male is 0, Female is 1
Ditto assumes the opposite value of what is present

Female // Male (everstone not calculated)
A=1 is first, B=0 is second
inter%20mf%20noe.png
Female // Ditto -- No Everstone
For Male // Ditto, flip the (M/F)/(D)
This is also the same result for a M+F with Everstone, except with the A/B convention.
F%2BD%20noE.png
Male+E // Ditto
For FemaleE // Ditto, flip the (M/F)/(D)
M%2BD%20everstone.png

Translating the observations:
Code:
0   n-2 initial
1   n-1 seed advancement to get egg
2   n   estone calc
3   n+1 nature calc
4   n+2 dw calc, consume if ditto present (do not calculate)
5   n+3 if everstone, consume 1, if ditto, consume 1. If both, consume 2
~a      iv calcs: (IV+p)^n, until 3 sets of unique IVs
*a+1   PID=u32-1 Inter1 / if Same Nationality 
*a+2   PID=u32-1 Inter2
*a+3   PID=u32-1 Inter3
*a+4   PID=u32-1 Inter4
*a+5   PID=u32-1 Inter5
*a+6   PID=u32-1 Inter6

If Inter# is shiny, stop
 
Masuda method now calculates 6 PIDs and checks for shinies, effectively increasing the shiny rate six fold as opposed to four fold.

Code:
Method         Rate       Odds          Everstone Works?
Normal:        1 / 8192   [1 in 8192]   Yes
Masuda(4th):   5 / 8192   [1 in 1639]   No
Masuda(5th):   6 / 8192   [1 in 1366]   Yes

inter%20pids.png
 
Determination if the 0x80000000 XOR is used in Wild Pokemon PID Generation
Refined and Corrected

Code:
Undetermined PID is already XOR'd with 0x10000
Lowest Bit of ID ^ Lowest Bit of SID = X
Highest Bit of UPID ^ Lowest Bit of UPID = Y

if 
X^Y == 0
Do not XOR with 0x80000000.

else (when X^Y ==1)
XOR with 0x80000000.

Restated...
Code:
All PIDs from the RNG must follow this pattern:
LPID^HPID^LSID^LTID == 0

Example of a proper PID generated:
Code:
[u]EDB6F252[/u]1C52D215 -- The Seed in which the PID is taken from.
EDB6F252         -- Upper32 of the PID's seed.
EDB7F252         -- 0x10000 XOR'd PID (0x8* Undetermined)
========
TID: 26727 SID: xxxx9 (Sephirona's)
Lowest  Bit of  TID = 1
Lowest  Bit of  SID = 1
Lowest  Bit of UPID = 0
Highest Bit of UPID = 1
1^1^0^1 =/= 0. Therefore 0x80000000 is applied.

Resulting PID: [U][I]6DB7F252[/I][/U]
Lowest  Bit of  TID = 1
Lowest  Bit of  SID = 1
Lowest  Bit of  PID = 0
Highest Bit of  PID = 0
1^1^0^0 == 0. This is the PID received.


Out of date. Refined to 98% prediction accuracy here.
Keeping this data here just because it proves somewhat of an ID relation, meh
Determination if the 0x80000000 XOR is used in Wild Pokemon PID Determination

IDs censored for obvious reasons :)
Test One
Code:
TID:CXXX    1xxxxxxxxxxxxxxx
SID:BXXX    1xxxxxxxxxxxxxxx
Th^Sh = 0
Test 1 with xElite's IDs
Code:
Seed:       E30831B9D7A03302
PID:        9DC1[u]00E6[/u]
PID Seed:   9DC000E6[s]195778769[/s]
Calculation One     Calculation 2
0   (6) High        0000000011100110    L16PID
1   (9) Low         1xxxxxxxxxxxxxxx       TID
0=1 (F) =>1         1xxxxxxxxxxxxxxx       SID
                    0                         
          1=0 is false                    no 8

======

Seed:       A0DD6EF77C2906D0
PID:        82B7[u]1A5F[/u]
PID Seed:   02B61A5F[s]02CF35B64[/s]
Calculation One     Calculation 2             
0   (0)  High       1010010111110000    L16PID
1   (A)  Low        1xxxxxxxxxxxxxxx       TID
0=1 (F) =>1         1xxxxxxxxxxxxxxx       SID
                    1                         
          1=1 is true                  apply 8

======

Seed:       BD5C8FAFF4ACEA4E
PID:        6309[u]31B9[/u]
PID Seed:   E30831B9[s]D7A03302[/s]
Calculation One     Calculation 2             
1   (E) High        0011000110111001    L16PID
1   (9) Low         1xxxxxxxxxxxxxxx       TID
1=1 (T) =>0         1xxxxxxxxxxxxxxx       SID
                    0                         
          0=0 is true                  apply 8

======

Seed:       5B8C9EC382EBDCFC
PID:        20DC[u]6EF7[/u]
PID Seed:   A0DD6EF7[s]7C2906D0[/s]
Calculation One     Calculation 2             
1   (A) High        0110111011110111    L16PID
1   (7) Low         1xxxxxxxxxxxxxxx       TID
1=1 (T) =>0         1xxxxxxxxxxxxxxx       SID
                    0                         
          0=0 is true                  apply 8

============

Test Two
Code:
TID:7XXX    0xxxxxxxxxxxxxxx
SID:3XXX    0xxxxxxxxxxxxxxx
Th^Sh = 0
Test 2 with Bond697's IDs
Code:
Seed:       9b25fae19a4f8feb
PID:        88A9[u]C444[/u]
PID Seed:   08A8C444[s]C095B76E[/s]
Calculation One     Calculation 2             
0   (0) High        1100010001000100    L16PID
1   (4) Low         0xxxxxxxxxxxxxxx       TID
0=1 (F) =>1         0xxxxxxxxxxxxxxx       SID
                    1                         
          1=1 is true                  apply 8

======

Seed:       32AF84E2824D77BD
PID:        E2FB[u]3562[/u]
PID Seed:   E2FA3562[s]DF8155A8[/s]
1    (E) High       0011010101100010    L16PID
0    (2) Low        0xxxxxxxxxxxxxxx       TID
1=0  (F) =>1        0xxxxxxxxxxxxxxx       SID
                    0                         
           1=0 is false                   no 8

============

Code:
Decision for 80000000 XOR

PID[1] = U32^0x10000
    if      (HB+LB)%2 == (LTSh)%2
            PID[2] == PID[1]^0x80000000
    else    PID[2] == PID[1]

===

PID[1] = Undecided Generated PID
PID[2] =   Decided Generated PID
HB     = Highest Bit of PID
LB     = Lowest Bit of PID
LTSh   = Highest Bits XOR'd: L16(PID), TID, SID
 
Code:
[size=3]3/4th generation: 
FullPID %2 = Ability
Fifth generation:
 U16PID %2 = Ability[/size]

Ability Calculation for Black / White originated Pokemon:
(PID >> 16) %2 = Ability.

Gen 3/4 Pokemon (Version ID in Hex) will still be checked with the Last Generation method upon evolving.
Thus no re-calculation upon evolving. Good news.​
Gen 5 Pokemon (Version ID in Hex) will always be calculated with this new method.
 
Determination if the 0x80000000 XOR is used in Wild Pokemon PID Determination

Code:
Decision for 80000000 XOR

PID[1] = U32^0x10000
    if      (HB+LB)%2 == (LTSh)%2
            PID[2] == PID[1]^0x80000000
    else    PID[2] == PID[1]

===

PID[1] = Undecided Generated PID
PID[2] =   Decided Generated PID
HB     = Highest Bit of PID
LB     = Lowest Bit of PID
LTSh   = Highest Bits XOR'd: L16(PID), TID, SID

How did you come to the conclusion that the TID and SID are involved? Are you looking at a disassembly? I ask because both of your TID/SID pairs have their high bits the same, which means that they cancel each other out in the XOR. Do you have any samples where the high bits of the TID and SID are different?

Also, in this example:
Code:
Seed:       A0DD6EF77C2906D0
PID:        02B61A5F
PID Seed:   02B61A5F[s]02CF35B64[/s]
Calculation One     Calculation 2             
0   (0)  High       1010010111110000    L16PID
1   (A)  Low        1xxxxxxxxxxxxxxx       TID
0=1 (F) =>1         1xxxxxxxxxxxxxxx       SID
                    1                         
          1=1 is true                  apply 8
Something is not right. There's not even the XOR with 0x10000 being applied.

What I've seen elsewhere is:
Code:
If high bit and low bit of PID are the same, XOR with 0x80010000.
Otherwise XOR with 0x00010000.
The data you give matches this behavior.
 
the xor with the 00010000 is always applied. it's sort of a "base" and then that formula is used to determine the 80000000 portion. i've tested this more against more IDs(some had mixed high tid/sid bits) and on both versions of the game and not had it fail once for any of them.

that formula you give at the end actually does seem to work, but is wrong for a lot of people(myself included). there was quite a bit of debate about it and whether there were 2 xors, because it seemed to work fine for some people and be the opposite for others. after doing a fair amount of reading, i was pretty sure there was only 1 xor, 80000000, and i started testing just xor-ing H16/L16 pid against tid and sid. that seemed to work, but failed a few times, so kaph added back in the high and low bit thing while assuming that PIDs have 2 "states", pre-80000000 testing and final. that worked every time across multiple IDs and both games, so it seems to be the right formula.
 
the xor with the 00010000 is always applied. it's sort of a "base" and then that formula is used to determine the 80000000 portion. i've tested this more against more IDs(some had mixed high tid/sid bits) and on both versions of the game and not had it fail once for any of them.

If that's how it works, cool. My point was that the data given doesn't support it (not enough examples).

Also, as I said, one of the examples has an error (XOR with 0x10000 not applied), or otherwise doesn't match the description.

that formula you give at the end actually does seem to work, but is wrong for a lot of people(myself included).
Is it failing on another set of IDs that you have, or for other examples? The two examples given for your IDs don't show that it fails for you.

I'm not trying to imply people are making stuff up or jumping to conclusions, and this isn't an academic journal (despite that 'University' in the title ;-) ). If you guys have worked through all the test cases, nice work!
 
they were just a couple of examples to show how it works, we weren't really trying to prove it. i have a few more, but they seem to pass that old calc if you use high/low of u32, so i guess it isn't really worth adding them in.

it(the old calc) does fail for me quite a bit. in fact, i have it implemented in PIDRNG(an app a few pages back in this thread) and it's been added into rng reporter and i've found that it fails for me most of the time. the same goes for xelite and alex, the person whose data this is above.

e: the one missing the 0x00010000 is a mistake, probably on my part. i probably copied and pasted the wrong thing.
 
Encounter Slots: Land

Code:
EXAMPLE:                     Water Monkey, In the range of 60-69. (Slot 4)
0    01F8E5F5E6DB9DBB        Initial Seed Before Encountering             
1    7BF30CE2D051EC8A        Highest Bit is 0, No Sync                     
2    2010F971B7D4CB35        ???
3    B45C04B3524D27AC        u16/0x290   =69  (slot 4)       
4    AA8CA97F6886519F        ???              
5    EFC01D0A6E2BE97E        PID Calculated (we know).
6    F0841C7D81E02B79        u32*0x19>>32=0x17 Careful

For implementation in RNG Reporter, shaking patch ESV is calculated one frame before the wild ESV, and will have the opposite sync.

Same slot structure, as before.
Code:
Slot      0     1     2     3     4     5     6     7     8     9  10  11
Rate    20%   20%   10%   10%   10%   10%    5%    5%    4%    4%  1%  1%
Value  0-19 20-39 40-49 50-59 60-69 70-79 80-84 85-89 90-93 94-97  98  99

3331199 is this post ID. Triple Double Doubles.
 
Dust Cloud Item/Pokemon Decision


==========================


Roamer NPID Regeneration Upon Beating the E4
The Roamer PID gets set right after all your Pokemon are deposited into the hall of fame machine, before the cutscenes start playing.

Tested with musicmeister:
Code:
0c2c0c275b720ab5    -    Seed before entering E4 
0931D18CD8B1FF64    -    Seed one step before the Champion 
                                 (you are forced to keep walking)
Roamer PID:  6BACF897
6BACF897C8C895D5    -    Seed the roamer's PID is from

0 (Pre E4), 25 (Pre Champ), 32 (Roamer PID).
If you are quick about it and seed abuse right before the Pre-Champ, the roamer PID should be 7 frames after your current seed. So much easier than the Rain release, but of course it takes more time to retry.

Too bad the IVRNG is separate. Since the MTRNG advances during battle inconsistently around 120/s, there's no way to reliably hit your IV frame in a champion battle. The only way to RNG your roamer IVs is on the first release. Regenerating it by beating the E4 only guarantees you a shiny, and you have basically random IVs.
 
Encounter Slots for Surfing (Spots) and Fishing (Spots) in Black and White
Code:
Pokemon found by Fishing use these slots:

Slot 0: 60%  (0-59)
Slot 1: 30% (60-89)
Slot 2:  5% (90-94)
Slot 3:  4% (95-98)
Slot 4:  1%    (99)

Same as last generation, yay!

Normal Fishing in Black and White

Bridge / Cave / Fishing (nonspot) have the same basic call structure. For regular fishing (not out of a spot), the 2nd frame calculation is used to determine whether to give a Pokemon, return the 'Not even a nibble...' response.

Most notably, the (4th frame) call after the ESV call is present as opposed to the Sand/Bridge patches, as these Pokemon can hold items. So it acts just like a regular shaking grass/water patch, except it has the 2nd frame calculation in effect.

Code:
Fishing Success Rate: 50%

Seed		  Test #	Frame	   PID	     Nature
C8087C68C53A6A59		-1
7B617875878B34E0  Test 1	 0	| e3b9fef2 | careful (23)
53F25764EB7E5B23  Test 2	 1	| none
55DB318DC9BB4E92  Test 3	 2	| 160e1581 | naughty  (4)
AFBA3CC49216C05D  Test 4 img     3	| ad93d42e | mild    (16)
7C6527334E9D4874  Test 5	 4	| none

Location: Wellspring Cave (Route 3)
Test 1: (lv 41) Basurao Blue
Test 3: (lv 43) Poliwag 
Test 4: (lv 43) Poliwhirl 

[U]Fishing Result Value[/U]
if Highest Bit == 1
     'Not even a nibble...'
else calculate ESV (pokemon will appear).

They will have the same 50-50 rate of being synchronized.
frv.png

===============

Fishing Water Spots in Black and White

Same structure as wild Pokemon, except with the fishing slots.

Code:
20EB33C665D6364A	1B4AC32D	Modest (15)
120ED59C27FD303D	86262FBC	Careful (23)
431C449F49300E40	4C5AE759	Timid (10)	
CBCDF695FB7C7E03	E7C60B3E	Hasty (11)	
B037EC1FB16AB56F	FE974212	Naughty (4)

Test 1: lv 42 Goldeen
Test 2: lv 54 Basurao Red
Test 3: lv 42 Goldeen
Test 4: lv 60 Goldeen
Test 5: lv 53 Basurao Red 	

0	Initial		20EB33C665D6364A	----
1	Sync		01515ABA84BDA3F5 	0  (no sync)
2	ESV		EDCFF5A3B3696B6C 	92 (slot 2, goldeen)
3	Item		???			----
4	PID		9B4BC32D6795173E	1B4AC32D
5	Nature		A308DDB0721AF839	15  Modest

Surfing and Surfing onto Water Spots

Same structure as wild. Fishing Spot will yield a Pokemon, always.
 
Assorted 5th Generation RNG Information

Code:
Definitions:
FullSeed = Entire 64 Bit Seed
u32 = Upper 32 bits of the 64 Bit Seed
L32 = Lower 32 bits of the 64 Bit Seed
Lowest Bit  =  Lowest Bit of the (64 Bit) Seed

FullSeed>>63 == 1   Pass Sync
FullSeed %4 == 0
           give Pokemon
     else give Item
FullSeed %5 == 0
           give 'Not even a nibble...'
     else give Pokemon

U32 ^ XOR  = PID
U32*6>>32           IV Passed
U32>>31             Parent Passing IV
U32*100>>32         Encounter Slot Value
                    Translate to Slot for Land/Water
U32*25>>32          Nature Calculation ([URL="http://www.smogon.com/forums/showpost.php?p=3229521&postcount=608"]Use Table[/URL])

=====

Code:
PID[1] = Undecided Generated PID
PID[2] =   Decided Generated PID
HB     = Highest Bit of PID
LB     = Lowest Bit of PID
LTSh   = Highest Bits XOR'd: L16(PID), TID, SID

===

Decision for 80000000 XOR

PID[1] = U32^0x10000
    if      (HB+LB)%2 == (LTSh)%2
            PID[2] == PID[1]^0x80000000
    else    PID[2] == PID[1]
Wild / Surf
Code:
0	Initial
1	Sync
2	ESV - Land / Surf
3	Held Item
4	PID
5	Nature

Water Spots (Fish / Surf)
Code:
0	Initial
1	Sync
2	ESV - Water
3	Held Item
4	PID
5	Nature

For surfing, you have to surf into it, with frame advancement. 
Surfing onto it uses the ESV for surfing spot, 
                    fishing it uses the fishing spot.

Fishing (No Spot)
Code:
0	Initial
1	Sync
2	(No) Fish
3	ESV - Water
4	Held Item
5	PID
6	Nature

Shaking Spots (Grass)
Code:
0	Initial
1	Sync
2	-----
3	ESV - Land
4	Held Item
5	PID
6	Nature

Shaking Spots (Cave / Bridge)
Code:
0	Initial
1	Sync
2	Item or Pokemon Calc
3	ESV - Land
4	PID
5	Nature
Zekrom/Reshiram
Code:
0	Initial
1	Sync
2	PID
3	Nature

Gifts / Fossils / Starters
Code:
0	Initial
1	PID
2	Nature

High Link, some of the time. Zoroark has a weird way of PID generation, which we aren't completely certain how it works. It's really unnecessary to completely document, just like Zoroark because these buggers cannot be shiny.

Zoroark / Zorua cannot shine.

Wonder Cards
Code:
0	Initial
22	 HP IV
23	Atk IV
24	Def IV
25	SpA IV
26	SpD IV
27	Spe IV
30	PID
32	Nature

There is something that can change the PID to make it give the opposite nature. Not sure, but it's noted here. Best bet is in between
Code:
Frame 0    n-1             Initial Seed [Start]
Frame 1    n               Everstone Check          r[n]*2>>32, if 1 pass nature
Frame 2    n+1             Nature                   (r[n+1]*0x19) >>32, nature value
Frame 3    n+2             DW                       (r[n+2] * 5) >>32 > 2, inherit DW
[u]Frame 4    n+3             consumed [/u]                Ditto related. Not sure what is done here.
Frame 5    n+4        m    IV1-Place                r[m]*6>>64, return 0-5 for what IV (HABCDS)
Frame 6    n+5        m+1  IV1-Parent               r[m+1]>>63, return 0/1 for what parent (A=1, B=0)
Frame 7    n+6+2r     m+2  IV2-Place                r[m+2]*6>>64, return 0-5 for what IV (HABCDS)        ...r=rejected frames for 2nd iteration, each rejection is +1 to r value
Frame 8    n+7+2r     m+3  IV2-Parent               r[m+3]>>64, return 0/1 for what parent (A=1, B=0)
Frame 9    n+8+2r+2s  m+4  IV3-Place                r[m+4]*6>>63, return 0-5 for what IV (HABCDS)       ...s=rejected frames for 3rd iteration, each rejection is +1 to s value
[u]Frame 10   n+9+2r+2s  m+5  IV3-Parent[/u]               r[m+5]>>64, return 0/1 for what parent (A=1, B=0)
Frame 11   n+10+2r+2s      PID Generated            r[n+10+2r+2s] - 1 = PID
Frame 12   n+11+2r+2s      Pokemon placed in party. [End]

For >>32, assume using upper32
For >>6*, assume using full seed
"Rejected": 0-5 value calculated matches one from a previous iteration. 
Discard and repeat calc until it does not match a previous 0-5, thus advancing 2 frames.

Please refer to the other Breeding resources that are in the list at the top of this post.
Roaming Pokemon
Code:
0	Initial
1	PID
2	Nature

SID / ID
Code:
Seed from Are you ready to enter the world of Pokemon
XXXXYYYY

XXXX = SID
YYYY =  ID
 
there is an XOR decision in the high link as well. PIDs are either u32 ^ 0x00010000 with the last 2 digits replaced with or just u32 with the last 2 digits replaced. it doesn't make a difference either way since PIDs have essentially no significance in the high link(abil is from the DW, nature is from a frame or 2 before, shinies can't happen), but i just wanted to document that it occurs. it's most likely based on ID somehow, possibly the same decision as the wild 0x80000000 XOR.
 
Thanks to Omega, I was able to look at the message building function for JP white. Not sure if it's helpful or not, but it sheds more light on where extra bits of the message for the DSi might come from.

Annotated message building code chunk, after nazo.
Code:
0208808C E92D4070 stmfd   r13!,{r4-r6,r14}    
02088090 E59F10B0 ldr     r1,=#0x4000006        ; r1 = VCOUNT address
02088094 E1A05000 mov     r5,r0                 ; r5 = &message[5]  (after nazo)
02088098 E1D160B0 ldrh    r6,[r1]               ; r6 = *VCOUNT    
0208809C E59F40A8 ldr     r4,=#0x2FFFC00        ; r4 = ptr to global var structure(?)
020880A0 EBFFFBFB bl      #0x2087094

02087094 E59F0004 ldr     r0,=#0x4000100        ; Timer0 address
02087098 E1D000B0 ldrh    r0,[r0]               ; r0 = *Timer0
0208709C E12FFF1E bx      r14

020880A4 E1800806 orr     r0,r0,r6,lsl #0x10    ; r0 = (*VCOUNT << 16) | *Timer0
020880A8 E5850000 str     r0,[r5]               ; message[5] = (*VCOUNT << 16) | *Timer0
020880AC E59F009C ldr     r0,=#0x21510F8        ; r0 = 0x21510F8 (...)
020880B0 E1D41FB8 ldrh    r1,[r4,#0xF8]            ; r1 = low part of MAC (M5, M6)  (*0x2FFFCF8 & 0x0000ffff)
020880B4 E5902000 ldr     r2,[r0]               ; r2 = *0x21510F8
020880B8 E5903004 ldr     r3,[r0,#0x4]          ; r3 = *0x21510FC (not used from r3)
020880BC E0221801 eor     r1,r2,r1,lsl #0x10    ; r1 = (MAC[M5,M6] << 16) ^ *0x21510F8
020880C0 E5851004 str     r1,[r5,#0x4]          ; message[6] = (MAC[M5,M6] << 16) ^ *0x21510F8
020880C4 E5902000 ldr     r2,[r0]               ; r2 = *0x21510F8 (not used)
020880C8 E59F2084 ldr     r2,=#0x4000600        ; r2 = GxStat address
020880CC E5901004 ldr     r1,[r0,#0x4]          ; r1 = *0x21510FC
020880D0 E59400F4 ldr     r0,[r4,#0xF4]         ; r0 = remaining MAC (M1-M4) (*0x2FFFCF4)
020880D4 E594303C ldr     r3,[r4,#0x3C]         ; r3 = *0x2FFFC3C (vframe?)
020880D8 E0210000 eor     r0,r1,r0              ; r0 = MAC[M1-M4] ^ *0x21510FC
020880DC E0233000 eor     r3,r3,r0              ; r3 = *0x2FFFC3C (vframe?) ^ (MAC[M1-M4] ^ *0x21510FC)
020880E0 E5853008 str     r3,[r5,#0x8]          ; message[7] = *0x2FFFC3C (vframe?) ^ (MAC[M1-M4] ^ *0x21510FC)
020880E4 E5921000 ldr     r1,[r2]               ; r1 = *GxStat
020880E8 E2840C03 add     r0,r4,#0x300          ; r0 = 0x2ffff00
020880EC E0231001 eor     r1,r3,r1              ; r1 = *GxStat ^ *0x2FFFC3C (vframe?) ^ (MAC[M1-M4] ^ *0x21510FC)
020880F0 E5851008 str     r1,[r5,#0x8]          ; message[7] = *GxStat ^ *0x2FFFC3C (vframe?) ^ (MAC[M1-M4] ^ *0x21510FC) ; (overwrite above)
020880F4 E59411E8 ldr     r1,[r4,#0x1E8]        ; r1 = date (*0x2FFFDE8)
020880F8 E2422E4D sub     r2,r2,#0x4D0          ; r2 = 0x04000130 (KEYINPUT)
020880FC E585100C str     r1,[r5,#0xC]          ; message[8] = date
02088100 E59431EC ldr     r3,[r4,#0x1EC]        ; r3 = time (*0x2FFFDEC)
02088104 E2841FEA add     r1,r4,#0x3A8          ; r1 = 0x2FFFFA8
02088108 E5853010 str     r3,[r5,#0x10]         ; message[9] = time
0208810C E1D0C9B4 ldrh    r12,[r0,#0x94]        ; r12 = *0x2ffff94 & 0x0000ffff
02088110 E5943390 ldr     r3,[r4,#0x390]        ; r3 = *0x2FFFF90
02088114 E023380C eor     r3,r3,r12,lsl #0x10   ; r3 = *0x2FFFF90 ^ ((*0x2ffff94 & 0x0000ffff) << 16)
02088118 E5853014 str     r3,[r5,#0x14]         ; message[0xA] = *0x2FFFF90 ^ ((*0x2ffff94 & 0x0000ffff) << 16)
0208811C E1D04ABA ldrh    r4,[r0,#0xAA]         ; r4 = *0x2ffffaa & 0x0000ffff
02088120 E1D03ABC ldrh    r3,[r0,#0xAC]         ; r3 = *0x2ffffac & 0x0000ffff
02088124 E1833804 orr     r3,r3,r4,lsl #0x10    ; r3 = (r4 << 16) | r3
02088128 E5853018 str     r3,[r5,#0x18]         ; message[0xB] = ((*0x2ffffaa & 0x0000ffff) << 16) | (*0x2ffffac & 0x0000ffff)
0208812C E1D220B0 ldrh    r2,[r2]               ; r2 = *0x04000130 (*KEYINPUT) & 0x0000ffff
02088130 E1D110B0 ldrh    r1,[r1]               ; r1 = *0x2FFFFA8 & 0x0000ffff
02088134 E1D039B8 ldrh    r3,[r0,#0x98]         ; r3 = *0x2ffff98 & 0x0000ffff
02088138 E1820001 orr     r0,r2,r1              ; r0 = (*0x2FFFFA8 & 0x0000ffff) | *KEYINPUT
0208813C E1800803 orr     r0,r0,r3,lsl #0x10    ; r0 = ((*0x2ffff98 & 0x0000ffff) << 16) | ((*0x2FFFFA8 & 0x0000ffff) | *KEYINPUT)
02088140 E585001C str     r0,[r5,#0x1C]         ; message[0xC] = ((*0x2ffff98 & 0x0000ffff) << 16) | ((*0x2FFFFA8 & 0x0000ffff) | *KEYINPUT)
02088144 E8BD8070 ldmfd   r13!,{r4-r6,r15}      ; unwind stack
02088148 04000006 streq   r0,[r0],-#0x6         ; ...
0208814C 02FFFC00 rsceqs  r15,r15,#0x0
02088150 021510F8 andeqs  r1,r5,#0xF8
02088154 04000600 streq   r0,[r0],-#0x600
02088158 E92D4010 stmfd   r13!,{r4,r14}
0208815C E59F0078 ldr     r0,=#0x2151158
02088160 E5902004 ldr     r2,[r0,#0x4]
02088164 E3520000 cmp     r2,#0x0
02088168 0A000003 beq     #0x208817C
0208816C E3A01000 mov     r1,#0x0
02088170 E5801004 str     r1,[r0,#0x4]
02088174 E5900000 ldr     r0,[r0]
02088178 E12FFF32 blx     r2

Summarizing the message parts.
Code:
message[0] - message[4] = nazos

message[5] = (*VCOUNT << 16) | *Timer0
message[6] = (MAC[M5,M6] << 16) ^ *0x21510F8
message[7] = *GxStat ^ *0x2FFFC3C (vframe?) ^ (MAC[M1-M4] ^ *0x21510FC)
message[8] = date
message[9] = time
message[0xA] = *0x2FFFF90 ^ ((*0x2ffff94 & 0x0000ffff) << 16)
message[0xB] = ((*0x2FFFFAA & 0x0000ffff) << 16) | (*0x2FFFFAC & 0x0000ffff)
message[0xC] = ((*0x2FFFF98 & 0x0000ffff) << 16) | ((*0x2FFFFA8 & 0x0000ffff) | *KEYINPUT)

The interesting values.
Code:
-- Hardware-related values?
All in 0x2FFFxxx section, which is generally referenced as an offset from 0x2FFFC00 (i.e. global structure ptr?)

Basically known:
*0x2FFFC3C: vframe(?) 
*0x2FFFCF4: MAC[M1-M4]
*0x2FFFCF8 & 0x0000ffff: MAC[M5,M6]
*0x2FFFFA8: (EXTKEYIN & 0xf) << 10 (put X, Y button just next to KEYINPUT bits when or'd)

Unknown Hardware
(seems always 0 on DSPhat/Lite, so DSi hardware stuff?):
32-bit values (full load)
*0x2FFFF90:

16-bit values (half load)
*0x2FFFF94:
*0x2FFFF98:
*0x2FFFFAA:
*0x2FFFFAC:

-- Data section values?
Referenced as offset from 0x21510F8.
*0x21510F8: Appears to be 0 on DS Phat/Lite, but may change when soft resetting.  See [URL="http://blog.livedoor.jp/ktxad/archives/1538967.html"]here[/URL].
*0x21510FC: Xor'd with GxStat, vframe, and MAC[M1-M4].  On DS Phat / Lite, considered to be 0.
 
Back
Top