Initial savemap?

  • Thread starter Thread starter Akari
  • Start date Start date
Status
Not open for further replies.
Careful about relying too much on Gears. (The doc) The information in there can get really flaky really fast.

The inital savemap was discoverd by comparing only the first few hundered bytes or so. I might be off by a planet or two.
 
It's the 4th file.
I thought 4th file are initial data for characters... and it seems to be true...

The inital savemap was discoverd by comparing only the first few hundered bytes or so. I might be off by a planet or two.
But such thing existed?
 
Oh... It looks like those are hardcoded. I can provide you with offsets where initialization takes place.
 
I somehow doubt this is hardcoded.

The inital menu colors should be in the character init overwrite in the 3rd file at the tail end of the cosmetic data.

I'll have to take a look. When I was looking at the 4th file. The data "jived" with the savemap. If anything, it might be skipping the charcater data. I only looked at a few hundred bytes and said "hey, this is matching the savemap". Then I wrote it in gears....
 
Initial colors:Code: [Select]
Code:
ff7.exeRAW offset: 524BF8Data:       B0 00 00 80 80 00 00 80 50 00 00 80 20 00 00 80
Savemap initialization:Code: [Select]
Code:
006CC446  /$ PUSH EBP006CC460  |  MOV BYTE PTR DS:[DC0E10], 80       ;10D8006CC467  |  MOV BYTE PTR DS:[DC0E11], 80       ;10D9006CC46E  |  MOV BYTE PTR DS:[DC0E24], 80       ;10EC006CC475  |  MOV WORD PTR DS:[DC0E12], 41       ;10DAfor(ECX=0; ECX<10; ECX++){006CC49C  |  MOV BYTE PTR DS:[ECX+DC0E14],CL    ;10DC+ECX}0060BB9B  /$ PUSH EBPfor(ECX=0; ECX<500; ECX++){0060BC20  |  MOV BYTE PTR DS:[ECX+DC08DC], 0    ;0BA4+ECX}for(ECX=0; ECX<3; ECX++){0060BC53  |  MOV BYTE PTR DS:[EAX+DC0230], 0FF  ;04F8+ECX0060BC60  |  MOV BYTE PTR DS:[ECX+DC09E5], 0FF  ;0CAD+ECX}0060BC69  |  MOV BYTE PTR DS:[DC0230], 0        ;04F80060BC70  |  MOV WORD PTR DS:[DC0DDE], 1        ;10A60060BC79  |  MOV BYTE PTR DS:[DC09E5], 0        ;0CAD0060BC80  |  MOV BYTE PTR DS:[DC0C44], 0FF      ;0F0C0060BC87  |  MOV BYTE PTR DS:[DC08F8], 0FF      ;0BC00060BC8E  |  MOV BYTE PTR DS:[DC08F9], 0FF      ;0BC10060BC95  |  MOV DWORD PTR DS:[DC08B8], 0       ;0B800060BC9F  |  MOV DWORD PTR DS:[DC08BC], 0       ;0B84004081E1  /$ PUSH EBP004081EE  |  MOV BYTE PTR DS:[DC0BDC], 1        ;0EA4004081F5  |  MOV DWORD PTR DS:[DC08C8], 0       ;0B90004081FF  |  MOV WORD PTR DS:[DC08CC], 1        ;0B9400408208  |  MOV WORD PTR DS:[DC08CE], 74       ;0B9600408211  |  MOV WORD PTR DS:[DC08D2], 0        ;0B9A0040821A  |  MOV WORD PTR DS:[DC08D4], 0        ;0B9C00408223  |  MOV WORD PTR DS:[DC08D6], 0        ;0B9E0040822C  |  MOV BYTE PTR DS:[DC08D8], 0        ;0BA000408233  |  MOV BYTE PTR DS:[DC08D9], 0        ;0BA10040823A  |  MOV BYTE PTR DS:[DC08DA], 0        ;0BA2
Anything else you doubt is hardcoded?

dziugo
 
Then the question are - what the hell is the 3rd file in kernel archive?

And.... could you write code that initialize savemap with initial values? I'm not good with asm =)
 
Thank goodness that the PC version was a port. Both Akari and I are taking our data from the PSX version, but core execution is pretty much a direct translation.

Now *I'm* cerious... what exactly *IS* the 3rd file. I'll play with it at home tonight going through a few PSX memory dumps.

I'm working on a psudo-side project too thatd good for a few giggles. I'll have it by monday ^_^

Hint... N-gears (hee-hee)
 
Both Akari and I are taking our data from the PSX version(...)
Guess I've forgotten about that...

Initialization:Code: [Select]
Code:
First step:Copy the character records to the savemapNext step:int i;char savemap[0x10F4];savemap[0x04F8] = 0x00;savemap[0x04F9] = 0xFF;savemap[0x04FA] = 0xFF;for(i=0; i<8; i++)   savemap[0x0B80+i] = 0x00;for(i=0; i<4; i++)   savemap[0x0B90+i] = 0x00;savemap[0x0B94] = 0x01;savemap[0x0B95] = 0x00;savemap[0x0B96] = 0x74;savemap[0x0B97] = 0x00;for(i=0; i<9; i++)   savemap[0x0B9A+i] = 0x00;for(i=0; i<0x500; i++)   savemap[0x0BA4+i] = 0x00;savemap[0x0BC0] = 0xFF;savemap[0x0BC1] = 0xFF;savemap[0x0CAD] = 0x00;savemap[0x0CAE] = 0xFF;savemap[0x0CAF] = 0xFF;savemap[0x0EA4] = 0x00;savemap[0x0F0C] = 0xFF;savemap[0x10A6] = 0x01;savemap[0x10A7] = 0x00;savemap[0x10D8] = 0x80;savemap[0x10D9] = 0x80;savemap[0x10DA] = 0x41;savemap[0x10DB] = 0x00;for(i=0; i<0x10; i++)   savemap[0x10DC+i] = (char)i;savemap[0x10EC] = 0x80;
It's not complete however... After copying over the character records, it is changed in few places (Cloud's Barret's & Tifa's HP/MP/...).

dziugo
 
I took a look at file 3 last night.

I have no idea what it is...

It appears to be some kind of lookup table. It's loaded into PSX memory and stays there. I couldn't find any context around it because all around it is a big bunch of nothing. It might be attached to battle, but I'm guessing again.

#### EDIT ####

Acoording to my memory dump, file 3 is copied into memory location 0x00082422 on the PSX. (Plus or minus, I don't know if my memdump has a header or not)

Like I said, there isn't really much around it in memory and appears to be a lookup table

Guessing wildy, it's for battle, but I might be on a controlled substanse too.

I'm going to toss this into tech related to get some nibbles....
 
Last edited:
N-Gears?

Nintendo-Gears?
I guess it's that obvious. I'm much better at 6502 assembly than C++

I was just going to program the stat menu and see how I feel ^_^

It's quite constrained. I'm going the MMC1 route for now and only have 16 banks of 16k (256k) for the game. This means the kernel *MUST* fit in 16k. The other modules must fit in thier 16k banks and still have enough space left over for graphics.

I migh have to move to a 1 meg cart if it gets too big.

Not only that, because of the power of the NES, the only compression I can use is RLE, a frame or dictionary method will be too much for the poor thing.

It's a weekend amusment, nothing more.
 
Sorry Triple-post... I know I'm kinda leading badly by example here......

Just letting everyone know, file three was decrypted by Terrence. It's the experiance curves and player AI
 
Just to make sure (and you can delete my post after reading this...), you do know that editing a message causes SMF to flag the thread as having new messages? :P

It won't bump it, but it will have the little 'new'-thingy next to the title. :)
 
Status
Not open for further replies.
Back
Top