Author Topic: Usable Savemap  (Read 3763 times)

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Usable Savemap
« on: 2014-11-21 00:21:35 »
This is my attempt at providing a safe list of writable bytes for modders.  It takes into consideration what (F=Field, W=World Map, B=Battle, M-Minigame, U=Menu, H-Hard-code) is reading/writing from/to a particular address.

I have also added addresses that I am going to be using for my own mod, and hopefully every other modder here will let me know which bytes they plan on using, so I can add the information accordingly.  This will help modders avoid conflicts.

PLEASE SEE THE REUNION DATABASE ON THE REUNION THREAD for the Savemap documentation
Quote
Key:
Fuchsia: In use by a modder. Unless you want to conflict with their mod, avoid!
Red: In use by original game. Considered unsafe to edit, unless modder edits the game.
Blue: Considered unsafe to edit, but currently being updated and checked.
Orange: In use by original game, but considered safe to edit. Or has editable bits.
White: Whole byte is free to edit.
Yellow: Conflict. A Byte/ Bit is being shared for two different purposes.

---------------------------------
Please note:

Although this list will include ALL known field, battle and world map bytes used, it is possible certain bytes are still used (or unusable) by Final Fantasy VII.  It is also possible that the modules make changes that we have not yet discovered.  If reverse engineering isn't feasible, you can use Ochu (see tools) to discover which addresses are being written to (using the memory logger option).

There may also be additional changes made directly from hardcode.

---------------------------------
A note on Banks:

People have gotten confused by how Final Fantasy VII uses memory.

The most basic explanation of how the savemap works is this:

It is a continuous list of bytes, and part of that list is a chunk of 1280 bytes (5 * 256). We have grouped this chunk of 256 bytes into five ‘Banks’.


See here: http://wiki.qhimm.com/view/FF7/Savemap

Code: [Select]
0 - 255 (0-FF): Bank 1 (offset BA4)
256 - 511 (100-1FF): Bank 2 (Offset CA4)
512 - 767 (200-2FF): Bank 3 (Offset DA4)
768 - 1023 (300-3FF): Bank 4 (Offset EA4)
1024 - 1279 (400-4FF): Bank 5 (Offset FA4)

So the first thing you need to do is to STOP thinking about the savemap of Final Fantasy VII as some sort of segregated/fragmented group of bytes.  It's ONE list of bytes, and 1280 of those bytes (which, as I have already noted, are continuous) can be changed by the modules (Battle, Field, World Map, Minigame, Menu), and by Hard-code. 

The second thing you need to do is realize that Bank 1 starts at address 0BA4 of the savemap.  So, although we use "0" for Bank 1's FIRST byte, it is infact the 2980th (0BA4) byte of the savemap as a whole.

The third thing to note is that the savemap itself starts at an address.  This address is the REAL address in actual memory used by Windows. Modders will not need to know this unless they are editing the executable/game memory directly. The savemap itself starts at address DBFD38, and so Bank 1 begins at DC08DC (DBFD38+0BA4 = DC08DC).

So what is the savemap?  It's simply a large list of bytes that can edited and saved, so the game can progress properly and so you can save/load that progress.

-----------------------------------
Further information:

The Field module can access all 5 banks, but it does so using its own identifiers.  This is the area modders get most confused. If you try to edit the 5 Banks in Makou, you will notice that there are all of a sudden 15 variable areas, each seemingly 256 bytes long.  This is NOT the case. The Field module is doing nothing out of the ordinary except accessing the Banks using a rather confusing script.

The Field module has two opcodes that it uses to write to the five Banks. One of those opcodes allows ONE byte values to be written, and the other allows TWO byte values to be written. The Field module differentiates between these two modes by using a different variable identifier for each, even though the SAME Bank is being used for both.  The Field module variables are related to the Banks as follows:

1/2 are Bank 1
3/4 are Bank 2
5/6 are temporary vars in game and not saved.  They reset to 0 every time you enter new field.
8/9 & 10 cannot be written to. 
11/12 are Bank 3
13/14 are Bank 4
15/7 are Bank 5

Field vars 1, 3, 5, 15, 11, 13 are for one-byte writes
Field vars  2, 4, 6, 12, 14, 7 are for two-byte writes

(Yeah, for some reason, variable 7 is for two bytes, and variable 15 is for one byte.  Just stop dreaming that FF7 will ever make sense).

Remember that 1/2, 3/4, 5/6, 11/12, 13/14 and 15/7 share the SAME 256 bytes.
So if you write to var [1][10] you are ALSO writing to [2][10] (Bank 1, Byte 10).
And if you write to var [2][10] you are ALSO writing to [1][10] and [1][11] (Bank 1, Bytes 10 and 11).
----------------------------

Special thanks:

NFITC1: Provided bytes that Battle AI uses.
« Last Edit: 2017-05-20 22:46:48 by DLPB »

Sega Chief

  • No life
  • *
  • Posts: 2482
  • Karma: 151
  • These guys is sick
    • View Profile
Re: Usable Savemap
« Reply #1 on: 2014-11-21 03:38:20 »
Mind giving me editing permissions? I'll update with variables used by the NT Mod.

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #2 on: 2014-11-21 06:42:31 »
Mind giving me editing permissions? I'll update with variables used by the NT Mod.

Sure, I'll PM you.  Also, it's incomplete still.  Seems the world map uses far more than the list Aali gave me.  Probably because ones he gave me are the script changes only.

or just tell me which you've used.  I won't add it yet because it's still possible there are conflicts.
The wiki savemap has a few errors too.

« Last Edit: 2014-11-21 08:23:20 by DLPB »

Roden

  • Crazy poster
  • *
  • Posts: 128
  • Karma: 20
    • View Profile
Re: Usable Savemap
« Reply #3 on: 2014-11-21 15:38:36 »
Thanks for this DLPB. it was tricky working out the empty spaces for the smaller gaps.  Damn, that's over 500 bytes unused. What criteria did you use to mark it as "unused" (at least as far it is possible to know)? I used Black Chocobo + many save games to see the null values for my own sheet, but didn't check all of them properly as of yet.

I have worked out quite a few known field vars if you want to add their info to the list? But that's a different purpose to "usable savemap" I think its still quite handy..

For example, here's some on 3-0 to 3-28 in your format that cover Chocobo Racing:

Note: These are ALWAYS set before races, except for 3-25 and 3-28 which are used after the race has concluded, so its rather pointless that the rest are saved IMO, its only because they're needed across the field to the minigame - so I just use them as additional temp fields)
3-0 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-1 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-2 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-3 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-4 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-5 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-6 (F): Controls who is the Chocobo rider in chocobo races, 0 = Cloud, 1 = Cid, 2 = Tifa.
3-7 (F): Sets the course of the chocobo race, long or short. 0 = long, 1 = short.
3-8 (F): Seems to control something about chocobo racing minigame, set before match, seen it to set 0
3-9 (F): Seems to control something about chocobo racing minigame, set before match, seen it set to 1
3-10 (F) (2 bytes): 1. In Corel Prison affects difficulty of Chocobo racing (stat values of your chocobo), values from difficult to easy: 3000, 3200, 3700, 4500.
              2. On Disc 2/3 set to match a value from the chocobo you entered into the race
                Note above for 2: If less than 1000, set to 1000 before race. Also cannot exceed 6000 unless you change field script
3-12 (F) (2 bytes): Same as above except the values are: 2200, 2500, 3000, 3500 for a different stat
3-14 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:248 (if racing chocobo 6))
3-15 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:249 (if racing chocobo 6))
3-16 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:250 (if racing chocobo 6))
3-17 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:255 (if racing chocobo 6))
3-18 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:251 (if racing chocobo 6))
3-19 (F): Seems to control something about chocobo racing minigame, set before match, seen it set to 7
3-23 (F): Holds the rank of your selected/registered chocobo for the chocobo racing minigame
3-24 (F): Something about chocobo racing minigame, before match begins set to random number + 15
3-25 (F/M): Your performance in Chocobo Racing minigame (Corel Prison part), if you win its set to 0, if you lose is set by minigame to increasing value depending on how badly you performed (the higher the worse).
Extra on above: Checked so Ester knows what to say to you "you were close" or "you suck!". Also records number of defeats in 2-76 with a +1 after every defeat so she can help you if you keep losing. 3-25 is set to 255 after you win and get letter from Dio. Is also set to 255 in elevator before racing. Does not seem to be used by regular races
3-26 (F) (2 bytes): 1. In Corel Prison affects difficulty of Chocobo racing (stat values of your chocobo), values from difficult to easy: 3200, 3400, 4000, 6000.
               2. On Disc 2/3 set to match a value from the chocobo you entered into the race
3-28 (F/M): Set to 255 before Chocobo racing match begins. Then checked after match concludes, based on the number, you receive a certain amount of GP and an item (you then choose between the two). There are many possible numbers to cover all items, from 0 to 23. This number is probably set randomly during minigame after you win (maybe something to do with 3-24 also?).

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #4 on: 2014-11-21 15:56:59 »
That's a nice idea.  Based on your comparison between start and end savemaps, which bytes changed?  How many were left on 0?

Roden

  • Crazy poster
  • *
  • Posts: 128
  • Karma: 20
    • View Profile
Re: Usable Savemap
« Reply #5 on: 2014-11-21 16:23:14 »
That's a nice idea.  Based on your comparison between start and end savemaps, which bytes changed?  How many were left on 0?
My notes were really crappy and done before I even used Makou.. I just wanted a rough idea of how many bytes were actually NULL compared to actual unknown so I could plan my mod a little better (the conclusion was I had plenty of space :P). I checked the z_ unknowns from that savemap link in black chocobo and marked the positions of the nulls across several saved games in the samples folder. I'm not sure how it matches up with your chart or Makou.

The format is basically:
0x0BAB    17   Z_8      Unknown 0, 3-8, 13-16 look null and unused

17 lists the number of unknown bytes, Z_8 is the unknown place in black chocobo, Unknown just means its Unknown (sorry, didn't bother removing it), then the numbers indicate which positions are NULL - I just noted them as "look null/appear null/unused"


0x0BAB    17   Z_8      Unknown 0, 3-8, 13-16 look null and unused
0x0BB4   16   Z_9      Unknown 0-3, 6-15 look null and unused
0x0C20    4   z_15       Unknown – Only 0 appears unused
0x0BD6    14   Z_10      Unknown, 0, 2-5, 10-13 look unused
0x0BF8    1   z_12       Unknown – looks unused
0x0BFD    2   z_13       Unknown – both look unused, 0 and 1
0x0C20    4   z_15       Unknown – Only 0 appears unused
0x0C24    97   z_16       Unknown – a lot seem null, but some are used inbetween. Null values: 1, 8-31, 44, 47-48, 54, 61, 65, 67, 72-95
0x0C87    29/45   z_17       Unknown[0-28] First 29 bytes of 45 (ENDS AT 0x0CB3 16 Bytes into next bank) 1, 7, 9-38, 41-44 look unused
0x0CA4    16/45   z_17       Unknown[29-44] Last 16 bytes of 45 , see above. 1, 7, 9-38, 41-44 look unused
0x0CB5    49   z_18       Unknown 10-46 look NULL and unused
0x0CE7    7   Z_19      Unknown (only 4 and 6 are NULL values)
0x0CF0    12   z_20       Unknown (1, 4-6 and 9 are NULL)
0x0D01    40   z_22       Unknown – 2-4, 9-17, 19-21, 33 appear NULL
0x0D2A    28   z_23       Unknown – 4-25 appear unused
0x0D47    31         z_24 Unknown  most used except 4, 13, 20, 24
0x0D67    12   z_25      Unknown  (1 to 10 appear NULL)
0x0D74    15   z_26       Unknown – Look All Used
0x0D84    32/64   z_27   Unknown[0-31] First 32 bytes of 64 (ENDS AT 0x0DC3 32 Bytes into next bank)  1-3, 5-8, 13, 16-31, 49, 50, 53-54, 56, 60-63 NULL
0x0DA4    32/64 Bytes    z_27       Unknown[32-63] Last 32 bytes of 64
0x0E28    17   z_29      Unknown (4-5, 7-8, 15-16 look NULL
0x0E3C    105   z_30      Unknown (0, 2, 9-32, 41-104 look NULL
0x0EA5    1   z_31       Unknown Data (used)
0x0EA7    3         z_32 Unknown only slot 2 appears unused NULL
0x0EAC    22   z_33       Unknown  All seem unused and NULL!
0x0EF5    23   z_35       Unknown  3 to 9, 11-12, 14-15, 21-22 appear NULL
0x0F24    5   z_36       Unknown  0 and 1 appear NULL
0x0F2A    50   z_37      Unknown  13-45, 47-49 appear NULL/unused
0x0F98    12 and 236   z_38       Unknown[0-11] First 12 bytes of 236 (ENDS AT 0x1083 224 Bytes into next bank) 0-2, 6, 15-43, 51-75, 82-85, 87, 90, 91, 99-123, 131-139, 142, 147, 150, 155, 163, 166, 170-188, 192-235 appear NULL
0x0FA4    224 and 236   z_38[12-235]      Unknown  Last 224 bytes of 236
« Last Edit: 2014-11-21 19:25:39 by Roden »

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #6 on: 2014-11-21 18:54:52 »
I'm updating the data top to bottom, starting with Field module.  This will take time.

Roden

  • Crazy poster
  • *
  • Posts: 128
  • Karma: 20
    • View Profile
Re: Usable Savemap
« Reply #7 on: 2014-11-21 19:29:00 »
I'm updating the data top to bottom, starting with Field module.  This will take time.
Cool, looking forward to it! Having it all setup in a Makou-friendly way would be a great step forward. I was actually just making a new Makou-only sheet recently as I didn't really know what I was looking at with the other one. ;D

Also corrected last post, at the end it should't say "Last 224 bytes of 236 appear null" but just "Last 224 bytes of 236". As the values (which I just checked again in Black Chocobo) are correct as  0-2, 6, 15-43, 51-75, 82-85, 87, 90, 91, 99-123, 131-139, 142, 147, 150, 155, 163, 166, 170-188, 192-235 appearing null in z_38 and not the entire last 224 obviously.

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #8 on: 2014-11-21 20:00:19 »
I'm afraid I can't decipher your post :P

But it doesn't matter because I'm going through every byte.  I need Makou updating for a lot of it though.

If you look at my savemap data at BC9, you'll see what I am aiming at.

Roden

  • Crazy poster
  • *
  • Posts: 128
  • Karma: 20
    • View Profile
Re: Usable Savemap
« Reply #9 on: 2014-11-21 20:19:32 »
I'm afraid I can't decipher your post :P

But it doesn't matter because I'm going through every byte.  I need Makou updating for a lot of it though.

If you look at my savemap data at BC9, you'll see what I am aiming at.
Yeah, I know what you mean. Looking at the area where you keep your WEAPON/SOLDIER stuff it relates to 0x0E3C 105 z_30 from my post. You'll see the "41-104" is actually the same as "192-255". Then the 9-32 in mine is 160-183 on yours. Though there are a lot of little differences elsewhere which is interesting, 0E3C itself is blank on mine and used in yours. As is 0E3E. My total of free bytes adds up to 599, while I think yours is 540 or something?

But as long as this is all sorted it doesn't matter how its done. Are you telling Makou to overwrite all values on a savegame or something?

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #10 on: 2014-11-21 20:22:52 »
No, I need Makou to help find all the vars in the game and at the moment it won't search for any and all references to a var.  When that's done, my job will be easier.

This savemap database is here so we don't conflict.  Any modders should tell me which bytes they are using, as follows

Example
Code: [Select]
EC4 to EC6
EC7
EC8
EC9

« Last Edit: 2014-11-21 20:26:00 by DLPB »

NFITC1

  • No life
  • *
  • Posts: 2755
  • Karma: 61
  • I just don't know what went wrong.
    • View Profile
    • WM/PrC Blog
Re: Usable Savemap
« Reply #11 on: 2014-11-21 20:25:28 »
Here's what I have from the battle module:

2 - Mystery Ninja (Yuffie's initial level)
49*-
50 - Love Points Aeris
51 - Love Points Tifa
52 - Love Points Yuffie
53 - Love Points Barret
54 - Caught Chocobo
5B - Ultimate Weapon's HP 1/3
5C - Ultimate Weapon's HP 1/3
5D - Ultimate Weapon's HP 1/3
5E - Dragon Zombie's Pandora's Box
7B - Emerald Weapon Defeated (0x10) Ruby Weapon Defeated (0x08) Ultimate Weapon Defeated (0x04)
1C4*-
1C5*-
1C6*-
1C7*-
1C8*-
1C9*-
1CA*-
1CB*-
1CC*-
1CD*-
268*-
26A*-
26C*-

The ones with asterisks have purposes that are used post PoNR (Mostly JENOVA and the last party Sephiroth battles) so it's probably not necessary to document their function in a savemap.

But, um, yeah...... After all these years I finally look at it and realize that BATTLE AI CAN READ/WRITE TO ANY BYTE IN THESE MEMORY BANKS! Who knew, right? All this time we've been telling people it was impossible. Imagine making certain monsters stronger based on how many chests you've opened or how many chocobos you have pinned.
« Last Edit: 2014-11-21 20:29:57 by NFITC1 »

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #12 on: 2014-11-21 20:27:46 »
NFITC, thanks!  Two Questions:

1. How is that possible?  I thought the opcode only allowed for one byte?  So it allows 16 bit values after all?

2. Is your list complete?

I will still document even post changes.

Roden

  • Crazy poster
  • *
  • Posts: 128
  • Karma: 20
    • View Profile
Re: Usable Savemap
« Reply #13 on: 2014-11-21 20:33:15 »
No, I need Makou to help find all the vars in the game and at the moment it won't search for any and all references to a var.  When that's done, my job will be easier.

This savemap database is here so we don't conflict.  Any modders should tell me which bytes they are using, as follows

Example
Code: [Select]
EC4 to EC6
EC7
EC8
EC9
Hmm, that's a good way to do it (if Makou can do that), but might take awhile. I'm going to see if I can overwrite every variable in the game, and see which ones affect my NULL values - and then I will have the Makou variables for every unused value for sure...

That's a great find NFITC1. I thought we were just limited to 4 bytes with those love points!

NFITC1

  • No life
  • *
  • Posts: 2755
  • Karma: 61
  • I just don't know what went wrong.
    • View Profile
    • WM/PrC Blog
Re: Usable Savemap
« Reply #14 on: 2014-11-21 20:38:31 »
NFITC, thanks!  Two Questions:

1. How is that possible?  I thought the opcode only allowed for one byte?  So it allows 16 bit values after all?
Apparently it is. It can take a 32-bit value I suppose, but we can't shove more than a 24-bit value in the AI.

Disassembly:
Code: [Select]
.text:005D9799 WriteByteToGlobal proc near
.text:005D9799
.text:005D9799 var_4           = dword ptr -4
.text:005D9799 write           = dword ptr  8
.text:005D9799 address         = dword ptr  0Ch
.text:005D9799
.text:005D9799                 push    ebp
.text:005D979A                 mov     ebp, esp
.text:005D979C                 push    ecx
.text:005D979D                 mov     eax, [ebp+write]
.text:005D97A0                 mov     [ebp+var_4], eax
.text:005D97A3                 cmp     [ebp+var_4], 0
.text:005D97A7                 jz      short ReadBattleGlobal
.text:005D97A9                 cmp     [ebp+var_4], 1
.text:005D97AD                 jz      short WriteBattleGlobal
.text:005D97AF                 jmp     short End_If
.text:005D97B1 ; ---------------------------------------------------------------------------
.text:005D97B1
.text:005D97B1 ReadBattleGlobal:
.text:005D97B1                 mov     ecx, [ebp+address]
.text:005D97B4                 mov     dl, byte ptr Memory_12_Start[ecx]
.text:005D97BA                 mov     BattleVar_2010, dl
.text:005D97C0                 jmp     short End_If
.text:005D97C2 ; ---------------------------------------------------------------------------
.text:005D97C2
.text:005D97C2 WriteBattleGlobal:
.text:005D97C2                 mov     eax, [ebp+address]
.text:005D97C5                 mov     cl, BattleVar_2010
.text:005D97CB                 mov     byte ptr Memory_12_Start[eax], cl
.text:005D97D1
.text:005D97D1 End_If:
.text:005D97D1                 mov     esp, ebp
.text:005D97D3                 pop     ebp
.text:005D97D4                 retn
.text:005D97D4 WriteByteToGlobal endp
Nothing limiting there. Memory_12_Start is the start of the memory block in the savemap and address gets passed in as a 32-bit value. There was never any limiter on that function, I just didn't notice when I first looked at it way way WAY back when.

2. Is your list complete?

I will still document even post changes.
This comes from my archive of AI scripts. Just searched them all for use of 2010 (the global variable which IS limited to 8-bits as seen above) and wrote down the addresses they access.

Roden

  • Crazy poster
  • *
  • Posts: 128
  • Karma: 20
    • View Profile
Re: Usable Savemap
« Reply #15 on: 2014-11-21 22:14:32 »
Here's my results from Bank 1 and very beginning of Bank 2 (where it overlaps in Black Chocobo):
These variables seem to be unused, I cross referenced them against a save game with a large amount of hours and DLPB's table:
Bank 1: 10-15   (6 bytes)
Bank 1: 32-35, 38-47 (14 bytes)
Bank 1: 52-55, 60-63 (8 bytes)
Bank 1: 89, 90   (2 bytes)
Bank 1: 136-159, 176, 189, 193, 200-223 (51 bytes)
Bank 1: 228, 234, 236-255 / Bank 2: 0-9,  12-15    (36 bytes)

Some of these were different when compared to DLPBs though, so they may need further checking, some of DLPBs were quite accurate so these could turn out to actually be used somehow:
Bank 1: 189, 193, 208, 209
Bank 2: 0, 1, 9

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #16 on: 2014-11-21 22:53:02 »
I haven't finished yet, either :)  I'm still running through them all.

There are a lot in Bank 3 that should be unused.

Roden

  • Crazy poster
  • *
  • Posts: 128
  • Karma: 20
    • View Profile
Re: Usable Savemap
« Reply #17 on: 2014-11-21 23:55:27 »
Here is rest of bank 2 and beginning of bank 3. Lots of oddities this time.

Here's the proven null variables (checked across three save games this time - which removed lots of false nulls) and compared to DLPBs chart:
Bank 2: 27-63 (37 bytes)
Bank 2: 71, 73 (2 bytes)
Bank 2: 82, 85-87 (4 bytes)
Bank 2: 95-97, 110, 112, 113, 114, 126   (8 bytes)   
Bank 2: 138-159 (22 bytes)      
Bank 2: 167, 187 (2 bytes)      
Bank 2: 196-205 used in convil2, lastmap and end game battles but are all null most of time - could use them at certain points I guess      
Bank 2: 226, 227, 242, 243, 246, 247, 250, 251, 254, 255  / Bank 3: 6, 18, 31   (13 bytes) *see note below about this row

These are the ones to be careful of (at least until we have more info):
Bank 2: 115-125 and 127-132 are listed as free/unused in DLPB's chart, but the savemap is stuffed with data here (lots of high numbers and such). Unless its some sort of garbage data? :P
*Bank 2: 240-255 are listed as being free when some of them are not. In fact I would be wary of using anything in that row (seems to vary tons across save games),  DLPB has Bank 3: 6 and 18 listed as not free also. 31 might be OK to use.

And the ones that DLPB listed as occupied but which also appear null:
Bank 2: 30, 31, 73, 82, 85-87, 96, 112, 126, 167, 187
« Last Edit: 2014-11-22 00:07:16 by Roden »

Roden

  • Crazy poster
  • *
  • Posts: 128
  • Karma: 20
    • View Profile
Re: Usable Savemap
« Reply #18 on: 2014-11-22 02:11:38 »
OK here's the final part.. As its the last two banks, I checked these with a save at the bottom of the final dungeon to rule out any false-nulls in there.

Bank 3: 136, 137, 139, 140, 147, 148   (6 bytes)   
Bank 3: 151, 153, 160-183, 192-255   (90 bytes)   
Bank 4: 3    (1 byte)   
Bank 4: 8-29   (22 bytes)   
Bank 4: 95, 102, 103 (3 bytes)   
Bank 4: 129 (1 byte)   
Bank 4: 147, 148, 149, 150, 151-179, 181-183   (36 bytes)
Bank 4: 244-246 / Bank 5: 3-6, 8-31, 39-63, 75, 78-79, 87-111, 119-127, 158-175, 180-223   (155 bytes)

Total approx bytes free: 529

Ones to be wary of:
Listed as occupied in DLPB's chart but found to be null:
Bank 3: 136, 139, 147, 148, 151, 153
Bank 4: 95, 102, 103, 129, 147, 148, 150
Bank 5: 175

Listed as occupied but look "very" NULL :P :
Bank 5: 96-104, 111

Ones listed as null in DLPB's chart but are not:
Bank 4: 180, 247, 254
Bank 5: 70-73 (tricky one, took a few saves to catch it)

Other notes:
6 possible single bytes in bank 5: 128-157 range but left them out.. packed in too tightly, I wouldn't mess with those in case its coords or something :P
Bank 5: 7 did not crash game.

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #19 on: 2014-11-22 11:23:02 »
All of the ones listed in mine should be used and likely are, since they come from analysis by Makou, Aali, NFITC1 and my memory logger Ochu...  but I'll be rechecking over the map too to be sure.  But with your check on top of mine, it will be a bit more air tight.

On the one's listed as null in mine, I'll colour those in and do some checking :)
« Last Edit: 2014-11-23 16:17:26 by DLPB »

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #20 on: 2014-11-23 18:51:01 »
I am going to go through this a little each day.  I have added Sega Chief's values to the database.  I still need Kuugen's and gj's changes, and anyone elses.

DLPB

  • No life
  • *
  • Posts: 8789
  • Karma: 251
  • My love is as sharp as a needle in your eye.
    • View Profile
Re: Usable Savemap
« Reply #21 on: 2014-11-24 18:18:06 »
progress update:

Bytes C44 to C6B
Bank 1 Completed
« Last Edit: 2014-11-24 18:42:48 by DLPB »

Roden

  • Crazy poster
  • *
  • Posts: 128
  • Karma: 20
    • View Profile
Re: Usable Savemap
« Reply #22 on: 2014-11-24 18:57:13 »
Good job :D That's a whole 16 bytes for Fort Condor, damn, think I'll be deleting all that. ;)