A big issue I had with my original E-Reader events was space. I did not have enough of it!
The gen 3 games have a few defined spaces in the players save file for info obtained externally.
These are things like secret bases from other players, other players battle tower teams, and yes, information from the E-Reader.
The space defined for the Eon Ticket, specifically, is called RamScript. It’s 995 bytes in size.
For my first 6 events, I stored all my data in that location. This includes text, script commands, and assembly code. This is hardly ideal.
I played around with other storage solutions, but today I’m going to write about the best one I’ve found, and how to utilize it.
When a Gen 3 game saves, it transfers data from the GBAs RAM to the flash memory chip on the cartridge.
They also divided this flash memory chip into several sectors. Each sector is 4096 bytes, although some are lumped together.
Sectors 0-13 are for your save file.
Sectors 14-28 are for the backup of your save file
And sector 29 is for your hall of fame data.
In Ruby & Sapphire, 30 and 31 are entirely unused.
In Emerald, 31 is used for the battle record feature. But 30 is still unused. Or, it is, but only in international copies.
30 is used in Japanese Emerald & FRLG to store the custom trainer hill data from E-Cards.
This space is both unused & never written to normally by the game. This means it’s 4kb of space the player can’t accidently write to by using the battle tower!
The game has premade functions to read from and write to the flash chip, so we don’t have to do a lot of work to use it.
Let’s talk about writing, first.
I use TryWriteSector, & it has 2 arguments.
- Which flash memory section are we using. In our case, 0x1E, aka 30.
- Where is the data in RAM to flash?
Then, when called, it writes 4096 bytes from the location you input in as the argument are written to that flash sector.
When RSE connects to the E-Reader the entire e-card gets sent through the link cable into RSEs WRAM.
The game then looks for what’s called a “preload” script in the e-card. This is a section that runs the games scripting language commands, meant to check if the data is okay to send over.
The Eon Ticket, for example, checks if you already have an Eon Ticket in your bag.
Crucially, though, it does not have a size limit.
So, what I do is store tons of data in the preload script. One of those being a small assembly program that sets up then calls TryWriteSector.
Let’s take a look at what that looks like for me. This is all done using the Eon Ticket disassembly by hacky.
After DataStart, I set up the preloadscript.
DataStart:
db IN_GAME_SCRIPT
db 24,11 ; petalburg gym
db 2 ; norman
GBAPTR NormanScriptStart
GBAPTR NormanScriptEnd
db PRELOAD_SCRIPT
GBAPTR PreloadScriptStart
db END_OF_CHUNKS
PreloadScriptStart:
setvirtualaddress PreloadScriptStart
PreloadScriptStart is where we’ll be working from, from now on.
PreloadScriptStart:
setvirtualaddress PreloadScriptStart
callasm $02000045
virtualloadpointer GoSeeYourFather
setbyte 2
dw $0000
end
WriteFlashMemory
This is the start of my preload script. callasm $02000045 jumps the game to WriteFlashMemory. Crucially, it’s after “end”, so the thumb code never gets read as script commands.
WriteFlashMemory is the thumb assembly code I wrote to actually call TryWriteSector. It’s stored as machine code in an include file with the macros for the script commands.
I’ll note that in Emerald, if you copy this code, the callasm should be 0201C045 instead. Emeralds spot it loads the E-Reader into is slightly different.
Here’s what the actual code looks like:
WriteToUnusedFlashMemoryLocation:
movs r0, #0x1e ;1E is the index of the unused flash memory block.
ldr r1, [pc, #0xc];Loads WRAMLocation into r1.
ldr r2, [pc, #0xc];Loads TryWriteSector into r2
bx r2
.align
WRAMLocation: ;This is where the data I want in the unused flash memory section is stored.
0200005C ;This is 0201C054 in Emerald
TryWriteSector: ;this will change depending on game version and revision!
08125441
It’s a very simple bit of code since I’m just setting up the registers for a built-in function of the game.
After WriteFlashMemory, I have a bunch of code & data I want to store in the unused flash memory section.
PreloadScriptStart:
setvirtualaddress PreloadScriptStart
callasm $02000045
virtualloadpointer GoSeeYourFather
setbyte 2
dw $0000
end
WriteFlashMemory
FillMapPattern ;Everything on this line and after is what gets put into the save sector.
PatternStruct
MOVEDOWN
DEOGAMEORIGIN
DEOMETLOC
DEOEVENTLEGAL
CLEFAIRY
CLEFGAMEORIGIN
CLEFMETLOC
CLEFBALL
CLEFAIRYSCRIPT
MOVEDEO
DEOXYSSPRITE
DEOXYSSPRITEPOINTER
DEOXYSSPRITESETUPSCRIPT
CLEFAIRYSCRIPT2
After this the usual ramscript information begins! This is what triggers when you talk to an NPC, and it’s labeled “NormanScript”, because it’s a hack of the Eon Ticket, and you receive that from Norman.
This script uses several “callasm” calls, which relies on info that is within the unused flash memory section.
That data is not loaded into RAM anywhere by default, so we have to run a function to pull it from the flash memory section!
In Ruby & Sapphire, since there is no Address Space Layout Randomization, I store the thumb code I need directly in RamScript near the top, like so:
NormanScriptStart:
setvirtualaddress NormanScriptStart
db $43 ;This checks if your party is bigger than 0
compare LASTRESULT, 0 ;It's so I can store thumb code in static spot.
virtualgotoif 2, Start ;It should never fail.
FAKEMAPHEADER
READFLASH
Start:
callasm $02028DF9 ;This calls READFLASH
lock
Let’s take a look at READFLASH. It works similarly to WriteFlashMemory, as we’re just setting up a different in-game function. It’s called DoReadFlashWholeSection in PokeRuby, & ReadFlashSector in PokeEmerald.
movs r0, #30 ;Index of the unused flash memory section
ldr r1, WRAMLocation ;where in ram I load the flash memory section to
ldr r3, DoReadFlashWholeSection ;actual function
bx r3
.align
WRAMLocation:
.long 0x0201b201
DoReadFlashWholeSection:
.long 0x08125bf9
I chose 0201b201 as it doesn’t seem to be a space the game uses, but I can’t guarantee!
But once this thumb runs, all my code & data is loaded to that space and my script can continue.
Obviously, in Emerald, this won’t work. What I do instead is store this code as writebytetoaddr commands. This, in a way, builds the thumb code live somewhere in Emeralds RAM that isn’t in ASLR space.
Each command does what it says on the tin-- it writes the byte specified to the address specified.
I tend to choose gEnemyParty for this, since it’s usually not in use when I’m talking to an NPC!
writebytetoaddr $1E, $2024744
writebytetoaddr $20, $2024745
writebytetoaddr $01, $2024746
writebytetoaddr $49, $2024747
writebytetoaddr $01, $2024748
writebytetoaddr $4B, $2024749
writebytetoaddr $18, $202474A
writebytetoaddr $47, $202474B
writebytetoaddr $BC, $202474C
writebytetoaddr $AB, $202474D
writebytetoaddr $03, $202474E
writebytetoaddr $02, $202474F
writebytetoaddr $4D, $2024750
writebytetoaddr $31, $2024751
writebytetoaddr $15, $2024752
writebytetoaddr $08, $2024753
callasm $02024745 ;readflash
This is what that looks like!
It does eat 96 bytes into my payload, but I’m not really sure there’s a better way for Emerald.
Speaking of Emerald, I’ve actually taken to storing most of my events in this space, rather than ramscript. Since all the data at 0201b201 isn’t subject to ASLR, I can have the player get into battles & do other things without the typical worries I’d have.
My Celebi event, for example, only has code in RamScript to init the unused flash memory section. All the dialogue, script, etc, is stored in the unused flash section.
NormanScriptStart:
writebytetoaddr $1E, $2024744
writebytetoaddr $20, $2024745
writebytetoaddr $01, $2024746
writebytetoaddr $49, $2024747
writebytetoaddr $01, $2024748
writebytetoaddr $4B, $2024749
writebytetoaddr $18, $202474A
writebytetoaddr $47, $202474B
writebytetoaddr $BC, $202474C
writebytetoaddr $AB, $202474D
writebytetoaddr $03, $202474E
writebytetoaddr $02, $202474F
writebytetoaddr $4D, $2024750
writebytetoaddr $31, $2024751
writebytetoaddr $15, $2024752
writebytetoaddr $08, $2024753
callasm $02024745 ;readflash
goto $0203abbc ;this is a jump command but in the scripting language for gen 3.
That’s RamScript for Celebi. Nothing else!
Here’s what’s in the Preload Script! It's the full source to my Celebi Event in Emerald. In Ruby & Sapphire, all of this would be within RamScript itself.
PreloadScriptStart:
setvirtualaddress PreloadScriptStart
callasm $0201C045
virtualloadpointer GoSeeYourFather
setbyte 2
dw $0000
end
WriteFlashMemory
CelebiScriptStart:
setvirtualaddress CelebiScriptStart
db $00
dw $0000
virtualmsgbox Poor
waitmsg
db $6E, $17, $8
release
compare LASTRESULT, 0
virtualgotoif 1, Changemind
virtualgotoif 5, CelebiEvent
db $00
TEMPCELEBI
STRUCTURETABLECOMPRESSED
LOADSTOREPARTYAMOUNT
CelebiRNGAlgo2
CelebiEvent:
db $43
compare LASTRESULT, 5
virtualgotoif 2, NoRoom
copyvar $800B, $800D
setwildbattle $F4, $30, $00
callasm $0203AC5D ;Colo RNG
special $13F
sound $13
waitstate
playmoncry $FB, $0
virtualmsgbox Celebi
waitmsg
waitmoncry
waitkeypress
release
special $145
playsong $0166, $0
waitmoncry
waitstate
db $43
comparevar LASTRESULT, $800B
virtualgotoif 3, FlewAway
virtualgotoif 2, Catch
Catch:
callasm $0203AD19
killscript
NoRoom:
virtualmsgbox NoSpace
waitmsg
waitkeypress
release
end
Changemind:
virtualmsgbox Change
waitmsg
waitkeypress
release
end
NoRoomToGive:
virtualloadpointer PartyFull
setbyte 3
killscript
FlewAway:
db $97, $01
db $97, $00
virtualmsgbox Flew
waitmsg
waitkeypress
release
end
PartyFull:
Text_EN "You need space in your party\n"
Text_EN "to play this MYSTERY EVENT!@"
Poor:
Text_EN "A Pokemon is rustling around\n"
Text_EN "in this tree.\p"
Text_EN "Would you like to investigate?@"
Change:
Text_EN "Maybe another time.@"
Flew:
Text_EN "The CELEBI flew away!@"
NoSpace:
Text_EN "You need space in your party\n"
Text_EN "to capture CELEBI!@"
Celebi:
Text_EN "CELEBI: Biyoo!@"
GoSeeYourFather:
Text_EN "A bright flash was seen in\n"
Text_EN "PETALBURG WOODS!\p"
Text_EN "Ever since, a rare Pokemon has\n"
Text_EN "been seen healing thin trees.@"
I think, generally, using the Unused Flash Memory section is superior to storing data elsewhere in R/S/E, and if you’re going to do any Eon Ticket hack like I have, try to use this technique for storage instead!
Feel free to contact me if you’re trying to use this and have any questions. I can be reached @blisy on discord, @blisy.net on bsky, and imablisy@gmail.com via email!