Bond697

even http://www.smogon.com/forums/showpost.php?p=3781405&postcount=776

oh, it's fine. just don't want to have people assuming the code is bad when it isn't. let's clean this up...

oh, i was way overthinking this. i thought he was making a hack and watned to have an ar code always on. i had assumed this was an intelligent question. apparently not.

this code works, everything was ported properly.

not sure how helpful this is, but overlay 114 in b/w contains a bunch of text related to this and is 98% code. here's a disassembly of all the code with the strings included. (i've not commented it yet, unfortunately) you can see the code actually references/accesses a good amount of the strings at some points. http://pokemon.thundaga.com/research/ram/overlay9_0114.7z

pokegen was able to convert it flawlessly back to a pkm file. it looks like you either missed a few lines or typed something in wrong. it also shouldn;t be an egg.

that doesn't help. what, specifically, is the code you used.

which code?

02250010 Encounter slots in RAM(Black) Bond697 go nuts e: encounter slots are laid out as words and it goes "level_min, level_max, species", so for an encounter slot with level 40-50 mews it would be: 0x28320097 (in memory 97003228, because the nds uses a little-endian-only arm setup)(this is 40d 50d 00151d in hex) slot 1 is 2250010 2 is 2250014 3 is 2250018 and so on up to 12

huh? still no idea what you actually want to do.

sort of. you would need to find what's being modified in memory within the rom and make the changes there. definitely possible, but potentially hard to find. what did you have in mind?

you need a code to activate the event flag too. try looking on cheats.gbatemp.net. http://cheats.gbatemp.net/GBA/

you need the ticket and an activator code, i'm pretty sure.

if you're talking about gen 5, the game does a lot more sanity checking than gen 4. you'll have those stats for like 2 minutes until you get into a battle or do something else that causes everything to be recalculated.

you want to set it to 0xWHEAT.

i'm not quite understanding this, to be honest. i get that you want to find your seed and delay(and i take it you mean gen 4 since the rng helper is for gen 4), but what does the arm9 have to do with it? the arm9 binary has the advancement routine, but not the rng buffer and learning armv5(the arm9 is an armv5 cpu) isn't going to help. e: oh, i see what you're talking about. you mean the spot on desmume's ram viewer where it says arm9/arm7, right? you don't have to worry about that past knowing that you should keep it set to arm9 because the memory is different in places between them. using the rng helper is really easy. for the frame finder portion, just go to the spot in ram specified by it and enter the number you find there with the ram viewer set to "words", not "bytes" and hit calculate. for the seed finder, enter the number listed in the initial seed location and the frame you're trying to get to from there.

521A9444 D1032800 121AA440 0000E001 D0000000 00000000 521A9444 D1032800 94000130 FEFF0000 121AA440 000046C0 D2000000 00000000 No Wild Pokemon (Hold R for Instant Encounter) i use it every time i play.

you know what? i just tried the backlight code on my ds with an ards. it's an ar code handler hack too. it doesn't work. i'm wondering if, when they updated the ar firmware, they changed where in ram the ar code handler sits to accomodate the new dtcm(and stacks) the ds sdk now uses so that the ar would stay well out of range of any nintendo code. that would explain it perfectly. and it means that that ar hack isn't usable any more. that code i had you test should work 100% of the time, but it doesn't. that explains it perfectly. and really screws this over.

try this to test: 94000130 FFFB0000 023FE074 012FFF11 E0000000 00000020 E92D0003 E59F000C E59F100C E5801000 E8BD0003 E12FFF1E 0223CDCC 01111111 023FE074 E3520003 D2000000 00000000 get in-game and hit select, then look at your money and it should have changed. it has to be on a real ards, though. the ardsi might have the address of the code handler changed, i'm not sure. i can't get my ar to work at the moment, or i would try it. if the ardsi's code handler address changed, then there ar hack to execute e-codes wouldn't work on them. also, asm to ards doesn't require a bin file. just type the assembly in and hit compile.

ok, what you want to do is something like this: 94000130 FFFB0000 023FE074 012FFF11 E0000000 00000044 E92D1002 E59F1024 E59FC024 E58C1000 E59F1020 E58C1004 E59F101C E58C1008 E59F1018 E58C100C E8BD1002 E12FFF1E 4EBAA14D 02234A40 B4E89F82 0E6C13CE AA1A10A6 00000000 023FE074 E3520003 D2000000 00000000 the ar just runs the code, so i think something like this should be good. e: also, desmume/no$ don;t keep the ar code handler at its normal spot. they just handle the ar themselves, so the ar hack to create executable code doesn't work on them, i don't think? i should try that now. also, you can use kodinator for branches and asm to ards to compile, no need for anything else. e2: yep! the ar hack doesn't seem to work. here's an example, the backlight adjustment code for white: 94000130 FCFB0000 023FE074 012FFF11 E0000000 000000A8 E28F0001 E12FFF10 A21AB5F0 88234C24 80138811 D02A428B 25803490 F0002000 1C06F82A F0002004 2703F826 21404007 D003420B 420B2180 E018D00C 4231210C 2F03D006 1C79D013 F0002004 E00EF816 E0094331 438E210C 2F001C31 1E79D004 F0002004 E002F80A F0002000 BCF0F806 4718BC08 30800000 88222100 D1FC422A 80224A08 88208060 D1FC4228 80220C12 88228061 D1FC422A 21FF8860 47704008 04000130 80028802 023FE074 E3520003 D2000000 00000000 you can see, yours is set up just like this code, so it should be working.

where are you trying this? desmume? e: here: .text .org 0 .arm _start: push {r1,r12} ldr r1, =0x4EBAA14D ldr r12, =0x2234A40 str r1, [r12] ldr r1, =0xB4E89F82 str r1, [r12, #0x4] ldr r1, =0x0E6C13CE str r1, [r12, #0x8] ldr r1, =0xAA1A10A6 str r1, [r12, #0xC] pop {r1,r12} bx lr .pool no need for that extra space in the literal pool.

nds roms are sized to powers of 2(8mb, 16mb, 32, 64, 128, 256, etc), but the padding to push them to that size is usually just junk data. it trims the junk data. trimmed roms work fine everywhere aside fro maybe an old flashcard that doesn't support them for whatever reason.

i have an ards and ardsi and have not had this problem. you're making a new cheat in the code list for b/w in the code manager, then carrying over the whole code list to the ar, right?

it does work with emerald, i think? anyway, here's some of the arm parsed into instructions: http://pastebin.com/uuaEzHht if you have any more arm dumped, feel free to pass it along. i would love to add to this.

apparently it's a timing issue between vba-m and dolphin? so say the devs anyway. yeah, myself and arcee have been able to dump a portion of the colo multiboot rom that creates the gba celebis, but not enough to get anywhere. we have the irq handler, a few functions that are incomprehensible with no context, some data, and more arm that doesn't seem to have anything to do with pkm creation. another 3 seconds of connectivity and we would have had the whole thing. e: we also tried to rip the rom from the iso, but it's in a million pieces.