Quick Research & Development Thread

JPAN · Aug 26, 2010

Ok, I finished a preliminary version of a replacement for the unsafe Variables. Depending on if you want, or not, to replace the Variable system, there are two features you can get.
First, the new block saved at the end of the Flash ROM, that contains 4096 bytes of usable, saveable space. That block is located at 0x0203e000 (as it seems free on both Fire Red and Emerald), and can be accessed alone by the use of the byte manipulating commands (in the 0x10 range).
Second, the ability to use that new area as Variables. The current solution destroys the access to the old ones, So if you're not OK with it, I'm sure we can work something out (after all, we still have 0x9000-0xffff to work with).
Installing informations are inside the Zip below, as well as the source code.

Before you go and install that directly in your Hack, I only tested it slightly. The save-load function alone is harmless, but the Variable one needs further testing. So, if you could, please test it in a normal ROM and see if it doesn't break anything.

Sierraffinity · Aug 26, 2010

JPAN said:
Ok, I finished a preliminary version of a replacement for the unsafe Variables. Depending on if you want, or not, to replace the Variable system, there are two features you can get.
First, the new block saved at the end of the Flash ROM, that contains 4096 bytes of usable, saveable space. That block is located at 0x0203e000 (as it seems free on both Fire Red and Emerald), and can be accessed alone by the use of the byte manipulating commands (in the 0x10 range).
Second, the ability to use that new area as Variables. The current solution destroys the access to the old ones, So if you're not OK with it, I'm sure we can work something out (after all, we still have 0x9000-0xffff to work with).
Installing informations are inside the Zip below, as well as the source code.

Before you go and install that directly in your Hack, I only tested it slightly. The save-load function alone is harmless, but the Variable one needs further testing. So, if you could, please test it in a normal ROM and see if it doesn't break anything.

The hack (the one that makes the new variables work) broke my ROM. I couldn't start the game (once I pressed Continue, it crashed), I couldn't load my save states (take one step, it freezes) and other stuff.
My ROM is Emerald.

JPAN · Aug 26, 2010

diegoisawesome said:
The hack (the one that makes the new variables work) broke my ROM. I couldn't start the game (once I pressed Continue, it crashed), I couldn't load my save states (take one step, it freezes) and other stuff.
My ROM is Emerald.

Sorry about that. It seems I forgot to include some steps in the Emerald aplication. The problem comes from the Emerald Var_decrypt function being too simple, and not pushing r4-r6. Fixed instructions are posted.

Sierraffinity · Aug 27, 2010

JPAN said:
Sorry about that. It seems I forgot to include some steps in the Emerald aplication. The problem comes from the Emerald Var_decrypt function being too simple, and not pushing r4-r6. Fixed instructions are posted.

There, it seems to be working fine now. :D
I was testing this out awhile, and so far, it seems to be working fine.
Of course, all of my variables (0x5000 and up) were set to 0x0, which told me it was repointed.
It works great! :D

Sierraffinity · Sep 1, 2010

JPAN! I have a HUGE problem!!
It appears that the RAM address you specified (0x0203E000) is used by the D/N system!!
What would be a good RAM address to use instead? (This is using BPEE)
EDIT: Also, the RAM address I changed it to doesn't seem to get refreshed upon starting a new game, with a game already having been saved!

JPAN · Sep 1, 2010

diegoisawesome said:
JPAN! I have a HUGE problem!!
It appears that the RAM address you specified (0x0203E000) is used by the D/N system!!
What would be a good RAM address to use instead? (This is using BPEE)
EDIT: Also, the RAM address I changed it to doesn't seem to get refreshed upon starting a new game, with a game already having been saved!

Well, 0x0203e000 is the start, but in Emerald, all up to 0x0203ffff seems free. So, just choose 0x1000 area or Ram from where the D/N lets up and use that.
Also, Emerald appears to load Flash-to-RAM only once, at the start of the first screen. Previously unused areas of the RAM shouldn't be deleted by themselves on New Game. So, use a script that only happens on the new game (set by one of the old 0x40xx variables, that the game clears for you) that clears the entire memory area for you.

Sierraffinity · Sep 1, 2010

JPAN said:
Well, 0x0203e000 is the start, but in Emerald, all up to 0x0203ffff seems free. So, just choose 0x1000 area or Ram from where the D/N lets up and use that.
Also, Emerald appears to load Flash-to-RAM only once, at the start of the first screen. Previously unused areas of the RAM shouldn't be deleted by themselves on New Game. So, use a script that only happens on the new game (set by one of the old 0x40xx variables, that the game clears for you) that clears the entire memory area for you.

Okay then. Thanks for the fast response.
But, my question is:
How would I go about writing a script (or an ASM routine, if necessary) that clears the RAM?
I remember seeing something about ldstia or something like that in some ASM routines, and heard it does something with an increasing value... Would that help?

JPAN · Sep 2, 2010

You can use this routine to clear 0x1000 bytes. Just replace the last pointer for the one you will be using.

Code:

.align 2
.thumb
Fill_memory: push {r4-r7, lr}
    mov r4, #0x10
    lsl r4, r4, #0x8 /*value = 0x1000*/
    ldr r5, start_addr
    add r4, r5, r4
    mov r0, #0x0
    mov r1, #0x0
    mov r2, #0x0
    mov r3, #0x0
fill_loop:  stmia r5!, {r0-r3}
    cmp r4, r5
    bgt fill_loop
    pop {r4-r7,pc}
.hword 0x0000    
start_addr:  .word 0x0203f000 /*change as needed*/

or, in byte code, this:

Code:

f0 b5 [B]10[/B] 24 240205 4d 2c 19 00 20 00 21 00 22
00 23 0f c5 ac 42 fc dc f0 bd 00 00 [B]00 f0 03 02[/B]

The last bolded bytes are the pointer you wish to use. replace for your own. The bolded number above is the instruction needed to replace to make different sizes. For instance, if your replace 10 with 20, you will clear 0x2000 bytes. This code will always cover 0x100 bytes minimum (0x1).

Shiny Quagsire · Sep 2, 2010

Alright, this question is mostly directed to JPAN, but anyone can answer.
In your berry system, you said htis:

JPAN said:
There is a limit of 256 different berry slots, each identified in the person id by the table number 0xfe.

What exactly does that mean? I've tried everything I could to understand, but the sentence is kinda smeared out in my mind. :\

JPAN · Sep 2, 2010

shiny quagsire said:
Alright, this question is mostly directed to JPAN, but anyone can answer.
In your berry system, you said htis:

There is a limit of 256 different berry slots, each identified in the person id by the table number 0xfe.

What exactly does that mean? I've tried everything I could to understand, but the sentence is kinda smeared out in my mind. :\

This means that each of the variables is linked to a specific OW number (person ID wasn't the best choice of words in this one, here it means the Sprite OW) And as OW sprite numbers are limited to a byte (0xfe, the table number, indicating that it is a berry tree), you only have 256 slots where you can have berries.

Shiny Quagsire · Sep 2, 2010

JPAN said:
This means that each of the variables is linked to a specific OW number (person ID wasn't the best choice of words in this one, here it means the Sprite OW) And as OW sprite numbers are limited to a byte (0xfe, the table number, indicating that it is a berry tree), you only have 256 slots where you can have berries.

So to turn the overworld into a berry tree, I'd use your OW hack, set the table # to 0xFE. But where does the variable come in? I'm not quite sure what you mean by the OW number. (Sorry if I'm frustrating you, it's just harder to understand when there's just text :p)

Wait, do you mean set the sprite to the desired variable index?

Sierraffinity · Sep 4, 2010

JPAN, what about the flags? Is there a way to fix the flags above 0x900 or something?

HackMew · Sep 5, 2010

JPAN said:

You can use this routine to clear 0x1000 bytes. Just replace the last pointer for the one you will be using.

Code:

.align 2
.thumb
Fill_memory: push {r4-r7, lr}
    mov r4, #0x10
    lsl r4, r4, #0x8 /*value = 0x1000*/
    ldr r5, start_addr
    add r4, r5, r4
    mov r0, #0x0
    mov r1, #0x0
    mov r2, #0x0
    mov r3, #0x0
fill_loop:  stmia r5!, {r0-r3}
    cmp r4, r5
    bgt fill_loop
    pop {r4-r7,pc}
.hword 0x0000    
start_addr:  .word 0x0203f000 /*change as needed*/

I really don't understand why would you push r6 and r7 when they're not even used, and not pushing r0-r3 instead, which might be needed depending from where the routine is called. Either way, there are better and faster ways to do that:

Code:

.text
.align 2
.thumb
.thumb_func
.global EraseMemory

main:
	push {r0-r3, lr}
	ldr r0, .START_ADDRESS
	mov r1, #0x0
	str r1, [r0]
	add r1, r0, #0x0
	ldr r2, .LENGTH
	swi #0xC
	pop {r0-r3, pc}
	
.align 2
.START_ADDRESS:
	.word 0x0203F000
.LENGTH:
	.word 0x01000400

In the code above, 0x01000400 stands for 0x400 words, and the 1 is for memory filling, rather then copying (the default behavior). Note that due to the way the SWI 0xC works, the word count (total amount of bytes / 4) must be a multiple of 8.

diegoisawesome said:
JPAN, what about the flags? Is there a way to fix the flags above 0x900 or something?

FYI, the address of the hypotetical flag 0x900 overlaps the one used by variable 0x4000. I guess I'll be able to tell you more when I implement the safe variables myself (sorry JPAN, but your code is just too messy).

EDIT: I did some research, and I think I found some safe areas to store the new variables in. For FR/LG, the whole area between 0x0203C000 - 0x0203EFFF appears to be totally unused. I somewhat confirmed it by putting a breakpoint on read/write on the whole area. I wasn't able to get the debugger to break yet. Also, here's a list I made, which clearly shows my theory:

Code:

As for Emerald, the whole 0x0203XXXX area is mostly used by the game already. So my suggestion is to try the 0x0202XXXX area, in particular anything between 0x02027000 - 0x02027FFF, or 0x0202A000 - 0x0202AFFF, or 0x0202D000 - 0x0202DFFF, or 0x0202F000 - 0x0202FFFF.

Code:

As for R/S, the whole are between 0x0203B000 - 0x0x0203DFFF should be safe.

Code:

Although I made those lists as accurate as possible, please note that they're only approximative; testing is always a must. Especially if you're using R/S/E, because I didn't test them.

Wichu · Sep 6, 2010

Not really that advanced compared to what you guys have been up to, but I was asked whether I knew where Steven's double battle team in Emerald was located. A bit of digging later, and I found it. It's not quite in the same format as normal trainers.

Metang: 0x5dd6d0
Skarmory: 0x5dd6e4
Aggron: 0x5dd6f8

Format:
Species (2 bytes)
IVs (1 byte)
Level (1 byte)
Nature? (1 byte) - unconfirmed; check this (Metang should be Lonely, Skarmory Impish, and Aggron Adamant)?
EVs? (6 bytes) - unconfirmed; check this?
Padding (1 byte)
Moves (8 bytes)

Unlike ordinary trainers (as far as I can remember), Steven's data appears to include nature and EVs. I bet this could be used to add opposing trainers with stronger Pokémon somehow.

Anyway, a question: this isn't really useful for ROM hacking, but it's related. Could somebody find the formula used to calculate the PIDs of eggs in Emerald if the mother is holding an Everstone? I know the formula without the Everstone already, but I'm stumped as to what happens when one is used.

colcolstyles · Oct 9, 2010

If anyone's interested, here's a tiny little morsel of information that I found recently. At the address '0x3A72A0' in Fire Red, you will find two bytes: '0xCD' and '0xFF'. These two bytes are used whenever the player is given two or more of some item using the 'giveitem' construct. The '0xCD' corresponds to an uppercase 'S' while the '0xFF' is the terminator byte, signifying the end of the string. If you change the byte from '0xCD' to '0xE7', the 'S' will become a lowercase 's'. I figure this might come in handy for those de-capitalization patches because it's really annoying to see "Player received the Poké BallS!" every time the player receives more than one of an item.

slawter666 · Oct 11, 2010

Realistically, how much work would be needed to change the 64x64 pixel limit in the 3rd generation games to the 80x80 pixel limit used in the 4th generation games? Please don't tell me it's hard or a lot of work. I'm genuinely interested in what would have to be done to increase the limit as it would be extremely beneficial to lots of people, especially as it would allow much higher quality sprites to be used as well as being able to import the 4th and 5th generation pokémon without (too much) resizing.

Sierraffinity · Oct 11, 2010

It appears that the offsets Hackmew posted a while back that were safe (for Emerald) are wrong..

Shiny Quagsire · Oct 11, 2010

slawter666 said:
Realistically, how much work would be needed to change the 64x64 pixel limit in the 3rd generation games to the 80x80 pixel limit used in the 4th generation games? Please don't tell me it's hard or a lot of work. I'm genuinely interested in what would have to be done to increase the limit as it would be extremely beneficial to lots of people, especially as it would allow much higher quality sprites to be used as well as being able to import the 4th and 5th generation pokémon without (too much) resizing.

You would need to modify the games ASM code, which would be a pain and would be way too hard. And, the sprites would go outside the picture box in the status screen. In other words, it's really hard, and it's just not worth it.

Gamer2020 · Oct 11, 2010

diegoisawesome said:
It appears that the offsets Hackmew posted a while back that were safe (for Emerald) are wrong..

How's about putting a reason as to why you believe that?

HackMew · Oct 12, 2010

diegoisawesome said:
It appears that the offsets Hackmew posted a while back that were safe (for Emerald) are wrong..

That's right, but like I said, I did not test them. What about 0x0203D800?

Quick Research & Development Thread

More options

JPAN

pokemon rom researcher

Sierraffinity

Desperately trying to retire from ROM hacking

JPAN

pokemon rom researcher

Sierraffinity

Desperately trying to retire from ROM hacking

Sierraffinity

Desperately trying to retire from ROM hacking

JPAN

pokemon rom researcher

Sierraffinity

Desperately trying to retire from ROM hacking

JPAN

pokemon rom researcher

Shiny Quagsire

I'm Still Alive, Elsewhere

JPAN

pokemon rom researcher

Shiny Quagsire

I'm Still Alive, Elsewhere

Sierraffinity

Desperately trying to retire from ROM hacking

HackMew

Mewtwo Strikes Back

Wichu

colcolstyles

Yours truly

slawter666

Sierraffinity

Desperately trying to retire from ROM hacking

Shiny Quagsire

I'm Still Alive, Elsewhere

Gamer2020

Accept no Imitations!

HackMew

Mewtwo Strikes Back