Unformatted text because lazy but has some important offsets and stuff
FE14~Elise (Colorz/Chroma&Luma)-Today at 2:35 AMOH CRAP@Wizards I THINK I FIGURED OUT WHERE WE CAN STORE AN ALMOST ARBITRARY AMOUNT OF SUSPEND DATAThe trap data --It just stores 0x1F9-ish consecutive bytes from 0203A610So you can sneak trap data in there that isn’t usedcircleseverywhere-Today at 2:37 AMshiiitFE14~Elise (Colorz/Chroma&Luma)-Today at 2:37 AMCheck out08031748Assembly codeIt’s a loop that just copies r3 bytes to the save datacircleseverywhere-Today at 2:37 AMso we can have arbitrary stat buff/debuffs tooFE14~Elise (Colorz/Chroma&Luma)-Today at 2:37 AMWellIt’s not infinite spaceBut yeahAlso you have to carefully flag itSo it isn’t mistaken for trap dataEach trap claims 0x8 bytescircleseverywhere-Today at 2:38 AMhm what’s the max number of units?all factionsFE14~Elise (Colorz/Chroma&Luma)-Today at 2:38 AMI’m not sureTHat’s stored elsewhereI think it was like50, 50, and 0x18 or something?I have it somewhere when i tried to ahck it for ENBut this is a different thingcircleseverywhere-Today at 2:39 AMI know a lot of the routines loop through 0x3f entriesFE14~Elise (Colorz/Chroma&Luma)-Today at 2:39 AMso 080D1866 is what calls the "copy this many bytes to suspend data"So we can just see what it copied verabim to suspend data0202BCF0 (4C bytes)
0203A958 (38 bytes)
0203E894 (460!! bytes)
0203ECf4 (C0 bytes)
0203A614 (200!! bytes)I’m omitting sectionsin the 3000000’s0203E894 seems to be some kind of map dataOr rn something?idkThe bytes near the statr seem to increment twice each time I select a unit0203A614 is the trap data sectiona bit before, in factomgthe suspend routine uses dynamic functionsplsThere are save sections at0x3FC4
0x4D8C (Hard save on 2nd slot)
0x5B54
(suspends?)
#0xD4 (when I just load a map or at the end of each phase?)
#0x204C (Suspend on file 1)
#0x691C
0x7400 (idk?)(edited)FE14~Elise (Colorz/Chroma&Luma)-Today at 3:01 AMThat’s in order of sorting by memory. The offsets are hardcoded. 0E000000 (pointer to start of save data) is at 0x8A1FAF4in order of offset, they’re
0xD4 (Section length 0x1F78)
0x204C (Section length 0x1F78)
0x3FC4 (Section Length 0xDC8)
0x4D8C
0x5B54
0x691C
0x7400(edited)So we can see the save files are DC8 long whereas the suspend data is 0x1F78Seems like we HAVE the space to make suspend on each file a reality…Or we can pawn off all that space to one thing to be able to keep more data
Less awfully formatted crucial data:
so 080D1866 is what calls the “copy this many bytes to suspend data”
So we can just see what it copied verabim to suspend data
0202BCF0 (4C bytes)
0203A958 (38 bytes)
0203E894 (460!! bytes)
0203ECf4 (C0 bytes)
0203A614 (200!! bytes)
2 Likes
In offsets after 0x0E000000
0x00D4 (Suspend Slot backup if checksum finds error. Section length 0x1F78)
0x204C (Suspend Slot. Section length 0x1F78)
0x3FC4 (Save File 1 Section Length 0xDC8)
0x4D8C (Save File 2)
0x5B54 (Save File 3)
0x691C (?? Some data towards the end? Section length 0xAE4)
0x7400 (Empty?)
So 0x7400 to 0x7FFF should be free space for us to use. We should also be able to remove saving to 0x204C and use that section as space for suspend data (larger maps with more enemies? Mag stats (with saved magic in 0x7400) (Or at least, recreate the current patch that Brendor has)? )
Checksum algorithm (same as in FE7)
[spoiler=checksum routine]
08000360 E92D00F0 stmfd r13!,{r4-r7}
08000364 E2411002 sub r1,r1,#0x2
08000368 E3A02000 mov r2,#0x0
0800036C E3A03000 mov r3,#0x0
08000370 E1D040B0 ldrh r4,[r0]
08000374 E0822004 add r2,r2,r4
08000378 E0233004 eor r3,r3,r4
0800037C E2800002 add r0,r0,#0x2
08000380 E2511002 subs r1,r1,#0x2
08000384 5AFFFFF9 bpl #0x8000370
08000388 E3A00801 mov r0,#0x10000
0800038C E2400001 sub r0,r0,#0x1
08000390 E0022000 and r2,r2,r0
08000394 E1A03803 mov r3,r3,lsl #0x10
08000398 E1A00002 mov r0,r2
0800039C E0800003 add r0,r0,r3
080003A0 E8BD00F0 ldmfd r13!,{r4-r7}
080003A4 E12FFF1E bx r14
[/spoiler]
Checksum check location: 080A6444
The first data is used (The one at 0xD4) when there’s no checksum check.
1 Like
For Items.
The first three items are saved separately from the last three. For the first three, enough space is allotted for the full 2 bytes each to be saved. For the last two… they’re packed against other things but not sure yet how it’s organized. But only durabilities up to 0x3F are saved for all of them. Checks for the first three are below:
080A623A loading mask (totally unnecessary…) (Constant at 080A636C)
080A5FCC saving mask (jsut as unnecessary) (Constant at 080A6110)
Seems like I was mistaken. Bits of the last supper(? byte 0x39) are chopped up and saved in the spaces here.
Would you translate this into a language that us, common mortals, could understand?
What are the implications of this?
Still working on it. It means we potentially have a lot of space to work with (at LEAST double of vanilla).
tbh I’m still mystified as to how Brendor made the Magic stat, but I’m just going to assume something happened with the space management here.
1 Like
@Brendor is simply epic.
But yeah, if you’re curious, he was struggling with space management and RAM the whole time for his Mag stat and (unfinished) skill patch.
I don’t get much of this so I can’t tell you more.
Well 0E000070 controls the mode and chapter data or something, because wiping the 0x8 bytes there made my main screen look like there’s no data.
(I treated suspend data like save data)
For the STR/MAG I used unused bits in the packed unit struct
Skills I put in where useless vars were being stored like the number of times a units stat screen was viewed which is the 460 block you mentioned in the OP
I also freed a shitton of space like 0xC00 bytes by breaking the link arena which I thought about using for a forging system
<3 I’m looking forward to that
