[ASM & Hex] Fire Red berry system (Almost working)

xizqu · Jun 25, 2018

Edit: I have identified the problem to be Shinyquagsires berry bag hack. Link

Sometimes, like a 1/50 chance the bag will jump to an address containing FFEF. Sometimes it happens within 5 runs, sometimes I can run the routine 50 times.
I don't even know where to begin searching for this kind of error.

If youre trying to insert this into your own rom, don't yet. I will make a public post when this is all ready but right now there are several things I need to work out.

Hi, I have taken fbis berry system and modified it. I have a working berry system! There is one problem I cant figure out though. Some times it randomly causes resets. Mgba and VBA give no error code. Im trying to replicate it in nogba but its not happening. Note the resets happen when im in unbound turbo mode. I don't know it that would cause it.

I was hoping someone would be able to read over the routines and check whats happening.

For all intents and purposes, it works. Right now I have 100 berries in my bag, starting at 5. It goes through all phases as it should. You can water it too. I just cant figure out these stupid resets.

The first routine is here: Link and im using the first routine. Not the ful bag hack.

getTreeData:

Code:

main:
	push {r0-r3, lr}
	ldr r0, =(0x20370BC)@get tree data
	ldrh r0, [r0]
	ldr r1, .SAVEBLOCK
	mov r2, #0x6
	mul r0, r0, r2
	add r0, r0, r1
	ldr r1, =(0x20370C2) @put values in vars
	ldrb r2, [r0]
	strb r2, [r1] @current stage
	add r0, r0, #0x2
	add r1, r1, #0x2
	ldrh r2, [r0]


Continue:
	strh r2, [r1] @time planted
	add r0, r0, #0x1
	add r1, r1, #0x2
	ldrb r2, [r0]
	strb r2, [r1] @was watered
	add r0, r0, #0x1
	add r1, r1, #0x2
	ldrb r2, [r0]
	strb r2, [r1]@times watered
	add r0, r0, #0x1
	add r1, r1, #0x2
	ldrb r2, [r0]
	strb r2, [r1]@PlantID

updateStage:
	@check time passed and update
	ldr r1, = (0x300500C)
	ldr r1, [r1]
	ldrh r2, [r1, #0xE] @hours
	mov r3, #0x3C
	mul r2, r2, r3
	ldrb r3, [r1, #0x10]@minutes
	add r2, r2, r3 @current time in minutes
	ldr r3, =(0x20370C4)
	ldrh r3, [r3]
	cmp r3, #0x0
	ble end
	sub r2, r2, r3
	mov r3, #0x0
	mov r1, #0x02 @CHANGE THIS TO CHANGE TIME BETWEEN PHASES

loop:
	cmp r2, r1
	blo setWater
	add r1, r1, #0x02 @CHANGE THIS TO CHANGE TIME BETWEEN PHASES
	add r3, r3, #0x1
	b loop

setWater:
	ldr r1, =(0x20370C2)
	ldrh r1, [r1]
	cmp r3, r1
	bge Check0
	b end

Check0:
	cmp r3, #0x0
	ble end

addToStage:
	add r3, r3, #0x1
	ldr r2, =(0x20370C2)
	strb r3, [r2]
	ldr r2, =(0x20370C6)
	mov r3, #0x0
	strb r3, [r2]


end:
	pop {r0-r3, pc}


.align 2
.SAVEBLOCK:
	.word 0x203C000

setTreeData:

Code:

.text
.align 2
.thumb
.thumb_func

main:
	push {r0-r2, lr}
	ldr r0, =(0x20370BC)@get tree data
	ldrh r0, [r0]
	ldr r1, .SAVEBLOCK
	mov r2, #0x6
	mul r0, r0, r2
	add r0, r0, r1
  ldrb r2, [r0]
  @cmp r2, #0x0 @added
  @ble end @added
	ldr r1, =(0x20370C2) @put values in vars
	ldrb r2, [r1]
  @cmp r2, #0x0 @added
  @ble end @added
	strb r2, [r0] @current stage
	add r0, r0, #0x2
	add r1, r1, #0x2
	ldrh r2, [r1]
	strh r2, [r0] @time planted
	add r0, r0, #0x1
	add r1, r1, #0x2
	ldrb r2, [r1]
	strb r2, [r0] @was watered
	add r0, r0, #0x1
	add r1, r1, #0x2
	ldrb r2, [r1]
	strb r2, [r0]@times watered
	add r0, r0, #0x1
	add r1, r1, #0x2
	ldrb r2, [r1]
	strb r2, [r0]@PlantID



end:
	pop {r0-r2, pc}


.align 2
.SAVEBLOCK:
	.word 0x203C000

setTime:

Code:

.align 2
.thumb
.thumb_func

main:
	push {r0-r3, lr}
	ldr r1, =(0x300500C)
	ldr r1 , [r1]
	ldrh r2, [r1, #0xE]
	mov r3, #0x3C
	mul r2, r2, r3
	ldrb r3, [r1, #0x10]
	add r2, r2, r3
	ldr r3, =(0x20370C4)
	strh r2, [r3]
	pop {r0-r3, pc}

.align 2

getYield: (just minus's 2 vars from on another, ill get this to generate a number eventually)

Code:

.text
.align 2
.thumb
.thumb_func

main:
	@push registers we use. Remember to push lr too.
	push {r0-r1, lr}

	@set our registers to be the pointers of the variables
	ldr r0, =(0x20370B8) @0x8000
	ldr r1, =(0x20370BA) @0x8001

	@load halfwords from each pointer
	ldrh r0, [r0]
	ldrh r1, [r1]

	@add values and store result in r0.
	sub r0, r0, r1

	@set register r1 to variable address and store into our sum (in r0)
	ldr r1, =(0x20370D0) @0x800D
	strh r0, [r1]

	@pop what you push, always.
	pop {r0-r1, pc}

.align 2

Script: You take this first paragraph, have each tree be a separate script calling the 'heavy script' set yield and tree id(id must be different) and the system does the rest.

Code:

#dynamic 0x801000
#org @Start
setvar 0x8000 0x7 'Max Yield
setvar 0x8001 0x3 'Min Yield
setvar LASTRESULT 0x9 'Tree ID
goto @HeavyScript



#org @HeavyScript
lock
copyvar 0x8002 LASTRESULT
callasm 0x8950031 'GetTreeData
compare 0x8005 0x0
if 0x1 goto @NonePlanted
compare 0x8005 0x1
if 0x1 goto @Fresh
compare 0x8005 0x2
if 0x1 goto @Sprouting
compare 0x8005 0x3
if 0x1 goto @Growing
compare 0x8005 0x4
if 0x1 goto @Blooming
callasm 0x8950131 'GetYield
buffernumber 0x0 LASTRESULT
bufferitem 0x1 0x8009
additem 0x8009 0x800D
msgbox @Received MSG_NORMAL
setvar 0x8005 0x0
setvar 0x8006 0x0
setvar 0x8007 0x0
setvar 0x8008 0x0
setvar 0x8009 0x0
callasm 0x89500D1 'SetTreeData
msgbox @Returned MSG_NORMAL
release
end


#org @NonePlanted
msgbox @None MSG_YESNO
compare LASTRESULT 0x0
if 0x1 goto @end
fadescreen 0x1
setvar 0x800A 0x7E
setvar 0x800E 0x0
callasm 0x80A1881
waitmovement 0x0
setvar 0x800A 0x0
compare 0x800E 0x0
if 0x1 goto @end
copyvar 0x8009 0x800E
bufferitem 0x0 0x8009
msgbox @addedberry MSG_NORMAL
setvar 0x8005 0x1
setvar 0x8007 0x0
setvar 0x8008 0x0
callasm 0x89501A1 'SetTime
callasm 0x89500D1 'SetTreeData
removeitem 0x8009 0x1
release
end


#org @Fresh
bufferitem 0x0 0x8009
msgbox @NewPlant MSG_NORMAL
compare 0x8007 0x0
if 0x3 goto @WaterPlant
msgbox @WateredAlready MSG_NORMAL
release
end


#org @Sprouting
bufferitem 0x0 0x8009
msgbox @Sprouted MSG_NORMAL
compare 0x8007 0x0
if 0x3 goto @WaterPlant
msgbox @WateredAlready MSG_NORMAL
release
end


#org @Growing
bufferitem 0x0 0x8009
msgbox @Tall MSG_NORMAL
compare 0x8007 0x0
if 0x3 goto @WaterPlant
msgbox @WateredAlready MSG_NORMAL
release
end


#org @Blooming
bufferitem 0x0 0x8009
msgbox @Bloom MSG_NORMAL
compare 0x8007 0x0
if 0x3 goto @WaterPlant
msgbox @WateredAlready MSG_NORMAL
release
end


#org @end
release
end


#org @WaterPlant
checkitem 0x1 0x1 'Checks if you have masterball Change to what your watering item
if 0x4 goto @end
removeitem 0x1 0x1 'Change masterball
msgbox @WantWater MSG_YESNO
compare LASTRESULT 0x0
if 0x1 goto @end
msgbox @FinishedWatering MSG_NORMAL
addvar 0x8007 0x1
addvar 0x8008 0x1
copyvar LASTRESULT 0x8005
callasm 0x89500D1 'SetTreeData
release
end


'---------
' Strings
'---------
#org @Received
= [player] found [buffer1] [buffer2]!

#org @Returned
= The soil returned to it's soft and\nloamy state.

#org @None
= The soil is soft here[.]\nPlant a berry?

#org @addedberry
= You planted a [buffer1] here.

#org @NewPlant
= A [buffer1] was planted here.

#org @WateredAlready
= It's been watered already.

#org @Sprouted
= The [buffer1] has sprouted.

#org @Tall
= The [buffer1] plant\nis growing bigger.

#org @Bloom
= The [buffer1] plant is in bloom!

#org @WantWater
= The plant can use some water[.]\nWould you like to water it?

#org @FinishedWatering
= You finished watering!

Koople · Jul 2, 2018

xizqu said:
Edit: I have identified the problem to be Shinyquagsires berry bag hack. Link

Sometimes, like a 1/50 chance the bag will jump to an address containing FFEF. Sometimes it happens within 5 runs, sometimes I can run the routine 50 times.
I don't even know where to begin searching for this kind of error.

Since you know the origin of the error, you could begin by disassembling the original game code around the hook location of the berry bag hack. I would guess that something in the bag's allocated memory is either being overwritten or not updated, causing the jump to the erroneous address. Since the berry bag sets a callback to the regular bag when you cancel, jumping from the berry bag straight to the overworld might not be freeing up certain data or setting the right tasks, for example.

xizqu · Jul 2, 2018

Koople said:
Since you know the origin of the error, you could begin by disassembling the original game code around the hook location of the berry bag hack. I would guess that something in the bag's allocated memory is either being overwritten or not updated, causing the jump to the erroneous address. Since the berry bag sets a callback to the regular bag when you cancel, jumping from the berry bag straight to the overworld might not be freeing up certain data or setting the right tasks, for example.

Sadly, it's not the berry hack itself. I've tested this on a clean rom. Opening the berry pouch via callasm (offset provided by SQ) is what's crashing the game. It's a vanilla function already in game.
I've tried calling the Berry crush routine to open the bag. Softlocks on select. I've tried the routine the game goes through when you click open on the bag, really thought this one would work.
Skeli gave me an offset a1820 which opens the pouch but on select closes into the main bag and then softlocks in exit.

Tldr, if someone knows how to open the Berry pouch from the Overworld, lmk!

Koople · Jul 2, 2018

xizqu said:
Sadly, it's not the berry hack itself. I've tested this on a clean rom. Opening the berry pouch via callasm (offset provided by SQ) is what's crashing the game. It's a vanilla function already in game.
I've tried calling the Berry crush routine to open the bag. Softlocks on select. I've tried the routine the game goes through when you click open on the bag, really thought this one would work.
Skeli gave me an offset a1820 which opens the pouch but on select closes into the main bag and then softlocks in exit.

Tldr, if someone knows how to open the Berry pouch from the Overworld, lmk!

You can register the berry pouch and have it open from and exit to the overworld, so it is doable. If it is freezing when you try to exit, the callback function might not be set when calling a1820. It looks like callback functions inside the berry bag are: callback1 function 08056534 (overworld func) and the callback2 function is 0813ce00. Look at 0x030030f0 to compare the callback functions when opening the berry bag normally vs. with other attempts.

xizqu · Jul 2, 2018

Koople said:
You can register the berry pouch and have it open from and exit to the overworld, so it is doable. If it is freezing when you try to exit, the callback function might not be set when calling a1820. It looks like callback functions inside the berry bag are: callback1 function 08056534 (overworld func) and the callback2 function is 0813ce00. Look at 0x030030f0 to compare the callback functions when opening the berry bag normally vs. with other attempts.

I haven't heard this word callback. Can you explain a little bit? 😁

Koople · Jul 2, 2018

xizqu said:
I haven't heard this word callback. Can you explain a little bit? 😁

Someone might be able to explain better, but essentially they are functions that are executed at a specific time, so the callback function tells the game what to do after finishing with the current task/function.

For example, when you select an option in the start menu, the callback2 function is set to the same routine that generates the start menu, so when you exit that menu, you return to the start menu.

xizqu · Jul 2, 2018

Koople said:
Someone might be able to explain better, but essentially they are functions that are executed at a specific time, so the callback function tells the game what to do after finishing with the current task/function.

For example, when you select an option in the start menu, the callback2 function is set to the same routine that generates the start menu, so when you exit that menu, you return to the start menu.

Just checked. Every single method of opening the bag, even the bugged ones have the same 2 callbacks ??????

Edit: So I have one more method to try tomorrow or the next day. If I can't get this working, I'm doing the cop out method and berries will need to be moved to the items pouch.

With that said, I'm always open to change back to the berry pouch if it can be figured out. I've tried callasm to these offsets if someone wants to take a look:
A1880
A1850
A1820
14BE50
10a448