Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Accessing to the save/load game data
#11
(11-17-2018, 02:15 AM)Loïc Wrote:
(11-17-2018, 02:07 AM)Flavor Wrote: ...
BUT, notice that Thor's code erases the block and writes the data.  This will work.  It's probably the easiest way, but it's not the "best" way to do it.
...

Ed, is it possible on neogeo pocket to change only the needed bits ?

All the commercial games I've disassembled uses clear/write process.

Loïc

I think that you can do it.  I don't know if this has been tested, but the chips should support it.  

THEORY of how it should work on the NGPC flash cart chips
For example, if you had a byte that was 0xFF
You could write 0xFE to that byte.  Then it would be 0xFE.
If you tried to write 0xFF to it, it would then be 0xFE
If you tried to write 0xFC to it, it would then be 0xFC
If you tried to write 0x00 to it, it would then be 0x00, and you could never change it again until you erased the block.

But, if you knew that your game only needed 10 bytes of savegame data, you could do something like this.
Put a header on the 10 bytes that's some sort of (non-0xFF) signature with an index, timestamp, etc..  Now the data is maybe 12 bytes.
Erase the block.

When you want to save, first check for your signature.  If it's not there, write your 12 bytes.  If it is there, jump ahead 12 bytes.  Is the signature there?  Keep going until there's an 0xFF (or 12 bytes of 0xFF to be more safe).  If you don't find an unused slot in the block, then erase the block and try again.  Then write your savegame.  

When you want to load, find the last/newest/etc. signature, and load that savegame.

I have also see something like this employed using 2 blocks.  You try to always keep a copy.  If something gets corrupt, you can use the other block as a backup.

In theory, you could also use the earlier "THEORY" bit to do something a bit more interesting.  Instead of a signature, you could have a bitfield that represents the used "slots" and turn a slot to "used" by setting its bit from 1 to 0.  This seems cooler, but it's probably not necessarily better or noticeably faster.
Card Fighters' Clash 2 English Translation ( http://cfc2english.blogspot.com/ )
Neo Geo Pocket Flash Cart and Linker Project ( http://www.flashmasta.com/ )
Avatar art thanks to Trev-Mun ( http://trevmun.deviantart.com/ )
Reply
#12
If I get it correctly,
the bios flashwrite can only turn 0 to 1 but it should to write starting from the offset address.
The smallest amount of data that can be written is 256bytes (ld brc3,1)

If my savegame is only 1 byte, and I decide that I'll use a full byte to locate where I need to save (let's say 9 saving possibility)

if my signature byte is 0xFF, I call the erase function, and I write 0x00 (signature) 0x??(data) the remaining bytes filled with 0x00
if my signature byte is 0x00, I write 0x01 (signature) 0x00(no data) 0x??(data), the remaining bytes filled with 0x00
if my signature byte is 0x01, I write 0x02 (signature) 0x00 0x00(no data) 0x??(data), the remaining bytes filled with 0x00
if my signature byte is 0x03, I write 0x04 (signature) 0x00 0x00 0x00(no data) 0x??(data), the remaining bytes filled with 0x00
and so on...

So I need to build a ram array of 256bytes (in this case, only 10 bytes relevant) with the first one containing the save position bit and then the data byte placed according it's position...

or use 2 write, one for the control byte/signature, a second for data, but with a different starting offset, keeping in mind that at least 256 bytes are written.
Reply
#13
(11-17-2018, 04:10 AM)Loïc Wrote: If I get it correctly,
the bios flashwrite can only turn 0 to 1 but it should to write starting from the offset address.

No, sorry. I think I didn't explain well. Erasing flash memory will set all the bits to 1 (all bytes to 0xFF).
Flashwrite can change 1s to 0s.

(11-17-2018, 04:10 AM)Loïc Wrote: The smallest amount of data that can be written is 256bytes (ld brc3,1)

I forgot about that, so my discussion of 12-bytes of savegame doesn't fit quite so well.

This is true, but it's only a limitation of the BIOS call, if I remember right. You can write your own function to do it, but it's a bit complex. The main problem is that the code can not run from flash memory while you are erasing/programming flash memory. Code running from BIOS can do it. Code running from RAM can do it. So, if you want your own erase/flash code, you need to copy the code to RAM and then execute the function from RAM.

Also, I think my discussion of the idea of the signature could be confusing.

If I were to use the BIOS call, then, maybe I would just make every bit of savegame data 0x100 (256) bytes long even if you only needed 10 bytes of savegame data for your game. Then maybe I'd just use 0x00 for a signature.

SAVE would look something like this.
- saveslot=0
- Read from SAVEOFFSET+(saveslot x 0x100)
--If it is 0, saveslot++
--else, write to SAVEOFFSET+(saveslot x 0x100) [include 0x00 at start of array]

RESTORE SAVE would look like
- saveslot=0
- Read from SAVEOFFSET+(saveslot x 0x100)
--If it is 0, read data from SAVEOFFSET+(saveslot x 0x100) into array
--else, return array

I'll try to find my ASM code that erases and writes flash mem. I have it somewhere.
Card Fighters' Clash 2 English Translation ( http://cfc2english.blogspot.com/ )
Neo Geo Pocket Flash Cart and Linker Project ( http://www.flashmasta.com/ )
Avatar art thanks to Trev-Mun ( http://trevmun.deviantart.com/ )
Reply
#14
I get It,
As I've no flash hardware knowledge, I was just wrong at thinking that default value of an erased byte was 0x00 instead of 0xFF.
Thus, the writing operation act as a logical "and".

Thanks Ed !
Reply
#15
I have been working this weekend with the save/load functions.

I tried with the Thor code and simple example. Load the game, save the data, restart and load the saved data (all this in NeoPop)

Apparently nothing happened. If I check a value in the data array, not has any value when I retrive the data. This should work on emulator? Or only on flash carth? I have a bung flash cart but I'm not tried it yet.

I'm doing this:

Code:
data[0] = 0;
data[1] = 2; //Future value to check
data[2] = 5;
data[3] = 1;
data[4] = 1;

flash(data); //Erase and save the data

data[0] = 0;
data[1] = 0; //Reset values to 0
data[2] = 0;
data[3] = 0;
data[4] = 0;

getSavedData(); //Load the data

if(data[1] == 2){ //Not equals? why?
   SetBackgroundColour(RGB2NGPColor(255,0,0)); //Red background color
} else {
   SetBackgroundColour(RGB2NGPColor(170,141,122)); //Brown background color
}
Reply
#16
(11-20-2018, 02:41 AM)KeiDash Wrote: I have been working this weekend with the save/load functions.

I tryed with the Thor code and simple example. Load the game, save the data, restart and load the saved data (all this in NeoPop)

Apparently nothing happened. If I check a value in the data array, not has any value when I retrive the data. This should work on emulator? Or only on flash carth? I have a bung flash cart but I'm not tryed it on it.

It should work on NeoPop and other emulator, but your romsize should be 2 097 152 bytes. you'll need to fill it with 0xFF to reach the required size.

When NeoPop save data, it create a .ngs file.

Loïc
Reply
#17
(11-20-2018, 02:58 AM)Loïc Wrote: you'll need to fill it with 0xFF....


Fill? Fill what? (sorry about my knowledge)

Actually, mi rom has 20Kb of size :-D
Reply
#18
(11-20-2018, 03:53 AM)KeiDash Wrote:
(11-20-2018, 02:58 AM)Loïc Wrote: you'll need to fill it with 0xFF....


Fill? Fill what? (sorry about my knowledge)

Actually, mi rom has 20Kb of size :-D

^^
If I remember right, you need to increase the size of your rom to 16mbit (2 097 152 bytes). It still my work if the size is greater.
The way Neopop works, it load the full rom in memory, and apply the savegame to the image in ram.
If the rom is not big enough, it won't be able to write your savegame in it.

If you don't see how to fill the difference between your rom size and the required size, I can send you a small perl code that could do the job.

You could also try to copy a full game after tours :
windows :
copy /b your_rom.ngp + kof-r1.ngp Your_big_enough_rom.ngp
unix :
cat your_rom.ngp kof-r1.ngp > Your_big_enough_rom.ngp

that should do the trick.
Reply
#19
(11-20-2018, 08:05 AM)Loïc Wrote: ^^
If I remember right, you need to increase the size of your rom to 16mbit (2 097 152 bytes). It still my work if the size is greater.
The way Neopop works, it load the full rom in memory, and apply the savegame to the image in ram.
If the rom is not big enough, it won't be able to write your savegame in it.

If you don't see how to fill the difference between your rom size and the required size, I can send you a small perl code that could do the job.

You could also try to copy a full game after tours :
windows :
copy /b your_rom.ngp + kof-r1.ngp Your_big_enough_rom.ngp
unix :
cat your_rom.ngp kof-r1.ngp > Your_big_enough_rom.ngp

that should do the trick.

hahaha ok, I didn't know that the minimum rom size would be 16Mb. Will you be able to send to me this perl code?

For the moment, I did the union of two roms like you explain here and it works, I generate a rom bigger than 2 097 152 bytes now. I want to try the save/load methods.

Thanks for your explanations, it's being very helpful. I have a programming knowledge in others languages but not of assembly, when I see something like this:


Code:
__ASM("rWDCR        EQU    0x6f");


The following happens to me:
[Image: 5333488-8748381247-200.g.gif]
Reply
#20
(11-20-2018, 06:30 PM)KeiDash Wrote:
Code:
__ASM("rWDCR        EQU    0x6f");

The following happens to me:
[Image: 5333488-8748381247-200.g.gif]

Assembly no Ken :-D

When I gave you savegame explanation, I totally forgot that size requirement...
On Bung flashcart, it's not needed, as the hardware will be able te write data to the right bloc.

The minimum 16bmits rom size is only because of savegame compatibility on bung/flashmasta.

Here's the perl code.
Place perl and rom in the same directory.
usage resize.pl <rom_file>
the result is named 2MB_<rom_file>


Attached Files
.zip   resize.zip (Size: 588 bytes / Downloads: 3)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)