PDA

View Full Version : Emerald Clock Fix!


Gamer2020
March 6th, 2013, 10:26 AM
Hi everyone. Today I bring you a clock fix for Emerald (BPEE). You may remember that there was an rtc patch made for R/S that allowed the clock to be based on playtime. A patch like this was never made for Emerald. I took the one for Ruby, disassembled it, and made it work for Emerald. Keep in mind that while this does work it has not been fully tested.

Memory address 0x0200F024 may not be safe. It is the same one used in the Ruby routine. This can be changed without affecting functionality.

Just assemble the code below and follow the included instructions.


.text
.align 2
.thumb
.thumb_func
.global emeraldclockfix

/*At 80005e6 write 01B400480047xxxxxxxx01BC with xxxxxxxx being the offset for this routine.
To disable the error code text write C046C046 at 0802FB06
Offset 0200F024 may not be safe in emerald but this can be changed to anything desired.
This code seems to work but is not fully tested. Use at your own risk.*/
main:

push {r0-r7}
ldr r0,.PLAYER_DATA
ldr r0, [r0]
add r0,r0, #0x11
str r0,[sp]
ldr r4,.PLAYER_DATA
ldr r4, [r4]
add r4,r4, #0x9A
add r3,r4,#0x1
ldr r7,.SUM_BUFF
ldrb r5,[r7]
ldrb r0,[r0]
add r2,r7,#0x1
cmp r5,r0
beq Game_Code_and_Return
strb r0,[r7]
ldrb r0,[r2]
add r6,r0,#0x1
lsl r0,r6,#0x18
lsr r0,r0,#0x18
strb r0,[r2]
cmp r0,#0x3B
ble Game_Code_and_Return
mov r6,#0x0
strb r6,[r2]
ldrb r6,[r3]
sub r6,#0x1
lsl r1,r6,#0x18
lsr r1,r1,#0x18
cmp r1,#0xFF
bne SOMETHING3
mov r6,#0x3B
strb r6,[r3]
ldrb r6,[r4]
sub r6,#0x1
and r1,r6
cmp r1,#0xFF
bne SOMETHING2
mov r1,#0x17
bl SOMETHING4

SOMETHING2:

strb r1,[r4]
b Game_Code_and_Return

SOMETHING3:

strb r1,[r3]

Game_Code_and_Return:

pop {r0-r7}
ldr r0,.SUM_GAME_OFF
ldrh r1,[r0]
ldr r2,.SUM_VAL
mov r0,r2
mov r3,r0
eor r3,r1
ldr r0,.RETURN_OFFSET
bx r0

SOMETHING4:

push {r0-r2}
ldr r0,.PLAYER_DATA
ldr r0, [r0]
add r0,r0, #0x98
ldrh r1,[r0]
sub r1,#0x1
ldr r2,=.SUM_VAL2
cmp r1,r2
blt SOMETHING1
ldr r1,.SUM_VAL3

SOMETHING1:

strh r1,[r0]
pop {r0-r2}
mov r15,r14

.align 2

.PLAYER_DATA:
.word 0x03005D90
.SUM_BUFF:
.word 0x0200F024
.SUM_GAME_OFF:
.word 0x04000130
.RETURN_OFFSET:
.word 0x080005F1
.SUM_VAL2:
.hword 0x8000
.hword 0x0000
.SUM_VAL3:
.hword 0xFFFF
.hword 0x0000
.SUM_VAL:
.hword 0x3FF

If you feel that this can be optimized in any way then please post on here and let me know.

FBI agent
March 6th, 2013, 01:48 PM
Cool, I'm glad you decided to post this for everyone. I personally don't hack Emerald, so I don't know much about the functionality and such.

Isn't this a counter? So if I were to say save at 4 hours 15 mins and 12 seconds, and then go do something else for from arbitrary amount of time, when I continue playing it will read as if no time has passed. I think in the FireRed RTC which ZodiacTheGreat and interdepth created, they used system time. Maybe you can try something like that?

Also, if you want people to help you with code efficiency, you should use meaningful variables and label names (as opposed to "something").

Gamer2020
March 7th, 2013, 07:18 AM
Cool, I'm glad you decided to post this for everyone. I personally don't hack Emerald, so I don't know much about the functionality and such.

Isn't this a counter? So if I were to say save at 4 hours 15 mins and 12 seconds, and then go do something else for from arbitrary amount of time, when I continue playing it will read as if no time has passed. I think in the FireRed RTC which ZodiacTheGreat and interdepth created, they used system time. Maybe you can try something like that? This is intended for flash carts that don't have RTC chips so there is no "System time".

Also, if you want people to help you with code efficiency, you should use meaningful variables and label names (as opposed to "something").

You may remember that there was an rtc patch made for R/S that allowed the clock to be based on playtime. A patch like this was never made for Emerald. I took the one for Ruby, disassembled it, and made it work for Emerald.

Maybe you should read before posting. I didn't write this, I just ported it.

FBI agent
March 7th, 2013, 08:05 AM
Maybe you should read before posting. I didn't write this, I just ported it.

I don't see why you couldn't rename those "something"s into more meaningful names. Right now those might as well be hex offsets, since they give about the same information as "something".

The point is that if you are asking people for suggestions to optimize your code, you should not make them have to re-research everything themselves.

At the very least you could comment what you're trying to do. If you just changed some pointers at the end and don't really know whats going on, that's a different story.

Gamer2020
March 7th, 2013, 10:15 AM
I don't see why you couldn't rename those "something"s into more meaningful names. Right now those might as well be hex offsets, since they give about the same information as "something".

The point is that if you are asking people for suggestions to optimize your code, you should not make them have to re-research everything themselves.

At the very least you could comment what you're trying to do. If you just changed some pointers at the end and don't really know whats going on, that's a different story.

You keep saying it's my code. I told you that I ported it and that's it. I called those offsets "SOMETHING" because they needed a name for me to make it so it could be assembled. I only put the "suggestions to optimize" thing because there may be ways it can be improved, not because I am looking for ways to improve it.

It's people like you why I hate posting stuff on here. Either read and understand what you read or don't bother posting. Bye now. "Clicks on ignore."

ShinyDragonHunter
March 7th, 2013, 11:08 AM
Gamer2030, I don't understand how I'm suppose to assemble this, I mean you put "Offset 0200F024 may not be safe in emerald but this can be changed to anything desired." What is that suppose to even mean? If it's not safe, then why can be changed to anything 'desired'? I'm confused...

Gamer2020
March 7th, 2013, 11:59 AM
Gamer2020, I don't understand how I'm suppose to assemble this, I mean you put "Offset 0200F024 may not be safe in emerald but this can be changed to anything desired." What is that suppose to even mean? If it's not safe, then why can be changed to anything 'desired'? I'm confused...

Memory address 0x0200F024 may not be safe. It is the same one used in the Ruby routine. This can be changed without affecting functionality.



It means that if it turns out the offset isn't safe it can be changed to a different RAM offset and the routine will still work. The offset is the same one used in the Ruby fix but APPEARED to be free in Emerald.

dkp
April 11th, 2013, 01:19 PM
Is there a DAN that is able to work with this, perchance? A flashcart friendly DAN would be a little more than perfectly awesome. Thanks for this port, by the way.

To be honest, I'm trying to see if there's a way to make primedialga's read this clock's status byte (with his tool installing the RTC, then the DAN, then uninstalling the RTC (which leaves the DAN in place) and compiling this to use the same status byte) - I'm pretty sure that the way interdpth's rtc (and thus primedialga's DAN) works though that it will be stuck at midnight forever this way. I lack the understanding to move beyond this point.

Gamer2020
April 11th, 2013, 02:17 PM
Interdpths RTC would not work properly on flash carts even if they did have RTC. The only exception would be if the flash cart let you set the time of the chip. I really wouldn't recommend trying to make this routine work with interdpth's since it wouldn't keep track of the date that way.

dkp
April 11th, 2013, 02:45 PM
Not what I meant - I know that, quite well actually. There is no RTC because even in the one or two insane flashcarts that include it, it doesn't work the way interdpth's does. I'm not using interdpth's rtc at all at this point; I just felt the need to explain that I already know I can't wrap some random person's (in this case, primedialga's) day and night to this clock fix, by having it read the values this routine sets. And I lack the experience to write a dan from scratch that reads from the bytes this sets.

So, I take it there's no DAN that would be compatible with this?

Gamer2020
April 11th, 2013, 03:30 PM
Not what I meant - I know that, quite well actually. There is no RTC because even in the one or two insane flashcarts that include it, it doesn't work the way interdpth's does. I'm not using interdpth's rtc at all at this point; I just felt the need to explain that I already know I can't wrap some random person's (in this case, primedialga's) day and night to this clock fix, by having it read the values this routine sets. And I lack the experience to write a dan from scratch that reads from the bytes this sets.

So, I take it there's no DAN that would be compatible with this?
If by DAN you mean the changing of colors then no (At least not anything available publicly). If one were developed using the rtc Emerald already has then it would work with the clock fix.