Jump to content

Recommended Posts

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.  B|

 

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

  • Like 3

Share this post


Link to post
Share on other sites

@Bond697 please correct me if I am wrong on any if this.

I read through most of the code last night and the rng looks like it is seeded by the result of a calculation of magic numbers, possibly time related? X =(1440 * A) + (60 * B) + C. This number is changed before used as a seed by doing this: (X >> 16) ^ (X & 0xFFFF).

Held item uses the same number X. Question is, does A,B,C change? Like from an RTC? Also even if it doesn't, the seeding creates data loss so we can't link held item to the seed regardless.

  • Like 1

Share this post


Link to post
Share on other sites
37 minutes ago, Sabresite said:

@Bond697 please correct me if I am wrong on any if this.

I read through most of the code last night and the rng looks like it is seeded by the result of a calculation of magic numbers, possibly time related? X =(1440 * A) + (60 * B) + C. This number is changed before used as a seed by doing this: (X >> 16) ^ (X & 0xFFFF).

Held item uses the same number X. Question is, does A,B,C change? Like from an RTC? Also even if it doesn't, the seeding creates data loss so we can't link held item to the seed regardless.

days*1440m/d + hrs*60m/h + m

standard initial seeding for R/S from the RTC storage

  • Like 1

Share this post


Link to post
Share on other sites

Yeah, so this is what it looks like it is doing (roughly) is this:

seed (RTC minutes like R/S, with the xor high and low bits)
pidh
pidl
if pidh is 0, or it with 0x2003
if pidl is 0, or it with 0x327
-- pid is not used
pidh (again)
pidl (again)
if new pid is shiny, increment pid until not shiny. Increment maxes out at 8.
iv1
iv2

item is based on the original RTC seed calculation, which is indeterminate based on the seed because the RTC seed is xor'd before its sent to seed the RNG.

I never dived into R/S seeding, so I am not sure how the RTC is calculated, like based on minutes from an epoch, a random date, etc.  I also don't know the seed period of GBA games, so maybe someone can chime in with that info.

  • Like 3

Share this post


Link to post
Share on other sites

The latest commits of PKHeX support viewing of the saved RTC values, a dry battery yields 5A0 which is 1 day.

Basically it's just an elapsed time since initial power on (iirc).

Wouldn't surprise me if those debug pid values are a date :) 03/27/2003

  • Like 1

Share this post


Link to post
Share on other sites
11 minutes ago, Kaphotics said:

The latest commits of PKHeX support viewing of the saved RTC values, a dry battery yields 5A0 which is 1 day.

Basically it's just an elapsed time since initial power on (iirc).

Wouldn't surprise me if those debug pid values are a date :) 03/27/2003

Yeah they are a date.  It probably corresponds to when they were writing the code.  I think that was around a month before the first gen 3 event (5th anniv eggs).  We know the first distribution used the same code too.

Also Bond found in R/S a binary encoded decimal representation of the date.  It was in IRAM ~0x3000460.  It looks something like 0x17 0x04 0x19 0x11 0x40 0x00 (for example).  This is used to generate that RTC value you mentioned.

Share this post


Link to post
Share on other sites

Meaning 65535 "days" are possible and 65535 possible Jirachis exist because of this logic... Meaning if we can reconstruct the algorithm from what we've got, we could recreate one of the Negaiboshi Jirachi... unless @Purin wants to share us one, that is...

Edited by coltonsmogon

Share this post


Link to post
Share on other sites
10 minutes ago, Kaphotics said:

Are you sure day is constrained to 31 days? The rtc doesn't store months elapsed, so the day value keeps incrementing. It's a 16bit value!

Yeah I am stupid, its day of the year, so 1 -> 365 (leap years?)

Share this post


Link to post
Share on other sites
1 minute ago, coltonsmogon said:

Meaning 65535 "days" are possible and 65535 possible Jirachis exist because of this logic...

If the seed is 16bit then all that has to be done is brute force seeds from day 1 to see the minimum time for a seed. I'm pretty sure it'll be low enough such that all seeds are possible to obtain prior to the event.

Share this post


Link to post
Share on other sites
Just now, Sabresite said:

Yeah I am stupid, its day of the year, so 1 -> 365 (leap years?)

Doesn't store years either, just keeps ticking. It screws up after 366 days, hence the need for the berry glitch fix (read up on bulbapedia).

Share this post


Link to post
Share on other sites
Just now, Kaphotics said:

Doesn't store years either, just keeps ticking. It screws up after 366 days, hence the need for the berry glitch fix (read up on bulbapedia).

Since this particular distribution was in 2003, to find original redemptions, I shouldn't have that issue.

Share this post


Link to post
Share on other sites

My question is, can we see about writing some code with this knowledge and our currently known trash byte Info that either takes an RS save and generates a Jirachi based on the RTC value, or B, checks and bruteforces all 65536 Jirachi spreads to see if the  incremental shiny check could ever have hit a wall of 9 or 10 failed incremental PID modifications, resulting in shinyness like on Wishmaker???

Share this post


Link to post
Share on other sites

OK. That IS sad, but we DO have Wishmaker (maybe even meteor.)

BTW can someone write this code into an online repl.it? Also, are any Jirachi flawless-capable???

Edited by St. GIGA
Added questions

Share this post


Link to post
Share on other sites

Next up, let's figure out how we're supposed to get a shiny Channel Jirachi since we debunked the shininess of Negaiboshi Jirachi... First, let's see if we can put that data to good use with getting one of them...

Edited by coltonsmogon

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...