Bond697

Super Moderator
  • Content count

    1319
  • Joined

  • Last visited

Community Reputation

34 Excellent

3 Followers

About Bond697

  • Rank
    Super Moderator
  • Birthday 09/24/84

Recent Profile Visitors

18179 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. i have no doubt they're exactly the same aside from the obvious changes to ot and whatever else.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. When I was given the 10ANNIV rom 3 1/2 years ago, the person who gave it to me asked me not to give it out or anything to preserve the cart's value. The same goes for a few others. Some of the stuff isn't even private, there just hasn't been anyone who has really cared, as far as I knew. Like this for example: It's an unreleased gen 3 event, METEOR Jirachi. I found its multiboot rom in.. some game. I've told people about it and given out archives, but nobody really seemed to care that much. I spent awhile gathering the multiboot roms and checking them out and to be honest, I didn't realize there was much interest in them anymore until Sabresite mentioned them not too long ago.
  13. All rise for Judge Guested in the Project Pokemon People's Court. [ATTACH=CONFIG]13789[/ATTACH] What's the case today? [ATTACH=CONFIG]13790[/ATTACH] Two dummies, who may be the same person, having a slapfight on the internet, your honor. [ATTACH=CONFIG]13787[/ATTACH] And the verdict is... [ATTACH=CONFIG]13788[/ATTACH] Guilty! Of being stupid on the internet. I think we're done here. So help me if we have to do this again after the judge's ruling, I will start ending careers so fast. ( ͡° ͜ʖ ͡°)