saving banks for my hack

As of now, Sonic 1 Reutiliation has been undergoing a lot of extra work. A palette update has been made, a new Splash screen is used. And the spindash has been eliminated from my copy of the ASM do to issues, but that isn't the point on why this topic is here.


How could I utilize the system to use the saving feature to the SRAM spaces? I ask of this because I am unsure if it is supposed to be written in Macro, ASM68k, Sn68k. Could you help out?

 

I created a tutorial that explains how to work with SRAM a little under two years ago. My understanding of this system has drastically improved since then, but I still hope it will help you out:


http://sonicresearch.org/forums/index.php?showtopic=2233

 

I thank you very much for this information, it works without a flaw. By the way, I couldn't understand why the memory was saved by twice the normal amount. Is it bacuse the actual sram saved in other games is further compressed, or is it that they don't require as much data?

 

This differs from emulator to emulator, some seem to pad the SRAM file to specific values (like multiples of 4 bytes). From my understanding, there's no way to prevent that.

 

Oh, well no biggy then. Thanks again.

 

Well, whilst we are here, I have a quick question about the SRAM following your guide, Selbi. Although my hack is Sonic 2.


I have enabled SRAM in my header:



ROMEndLoc:
dc.l EndOfRom-1 ; ROM End


dc.l $FF0000 ; RAM Start


dc.l $FFFFFF ; RAM End


dc.l $5241F020 ; Backup RAM ID ; Enable SRAM


dc.l $00200000 ; Backup RAM start address ; SRAM Start


dc.l $00203FFF ; Backup RAM end address ; SRAM End


dc.b " " ; Modem support


dc.b " " ; Notes


dc.b "JUE " ; Country


EndOfHeader:



I know that values have to be read from an odd address in SRAM.


In my game, when you finish a level, a byte get's added to a RAM address called "logos". And that's what I want to save/load.


When moving one to logos, I do this at the end of the level:



SavelogostoSRAM:
movem.l d0/a1,-(sp) ; Move d0 and a1 to stack


move.b #1,($A130F1).l ; enable SRAM (required)


lea ($00200001).l,a1 ; base of SRAM


moveq #0,d0 ; Clear d0


move.b (logos).w,d0 ; move current logo RAM address to d0


move.b d0,0(a1) ; save logos to SRAM


move.b #0,($A130F1).l ; disable SRAM (required)


movem.l (sp)+,d0/a1 ; Move d0 and a1 from stack


rts



I see no problem with this.


To load it, I do this when you press start at the title screen:



movem.l d0/a1,-(sp) ; Move d0 and a1 to stack
move.b #1,($A130F1).l ; enable SRAM (required)


lea ($00200001).l,a1 ; base of SRAM (use odd address)


moveq #0,d0 ; Clear d0


move.b 0(a1),d0 ; load logo off SRAM into d0


move.b d0,(logos).w ; and move the data to Logos' RAM address


move.b #0,($A130F1).l ; disable SRAM (required)


movem.l (sp)+,d0/a1 ; Move d0 and a1 from stack


rts



Seems good, right?


Well, here's the thing, it works perfectly, until you close the emulator down (Regen). When you reload, it will either do one of three things:

• Load what was saved there like it's meant to [rare]
  
• Loads the previous data from before (if it's written to the same SRAM twice, it will load what was first written there [most common after second level complete])
  
• Loads a complete random number [rare]

Gens emulator does the exact same thing, and Kega seems to ignore the SRAM altogether (even though SRAM isn't disabled on Kega)


Where can I be going wrong? Any ideas?


Cheers


EDIT: Here's a funny story. I delete the s2built.srm file so there is no more save data, and as soon as I load the hack again, it immediately returns, and when I press start of the title screen, it loads the previous data from before. How does that work out?

 

Loading SRAM with one emulator will fuck up the SRAM data and cause it to become incompatable with another emulator.

Regen will only accept the address up to 002003FF, if it attempts to load an SRAM file from say KEGA or GENS that had output 4000 bytes, Regen will only take the first 400 into account and will remove the rest.


It is also an interesting fact that blank bytes will be saved as 00 in one emulator and FF in another upon first reading, one emulator will assume 00 is a blank spot and convert it to FF or vis versa, or at least something along them lines, it's really really stupid...


One day I will run some major hardware tests, and find out the real way to use it, all this vagueness with SRAM and its capabilities, is pathetic really.

 

Thanks, I have set the maximum to $002003FF, but it still doesn't explain why the SRAM is going wrong. You don't think that the emulators are shifting data around the SRAM file when opening it? It may explain why it works perfectly until I close the game and reload it.


Also, other emulators can't be interrupting it, as they output their own SRAM files (Regen has a SRAM in the Regen folder, Kega has one in it's own Kega folder, etc).


I heard that too some emulators read blank ones as 0, or as FF, that why I change the loading code to this:



movem.l d0/a1,-(sp) ; Move d0 and a1 to stack
move.b #1,($A130F1).l ; enable SRAM (required)


lea ($00200001).l,a1 ; base of SRAM


moveq #0,d0 ; Clear d0


move.b 0(a1),d0 ; load logo off SRAM into d0


beq.s + ; If logos are 0, skip loading SRAM


cmpi.b #$FF,d0 ; Is d0 $FF?


beq.s + ; If logos are $FF, skip loading SRAM


move.b d0,(logos).w ; Otherwise, copy logos from SRAM to RAM


+


move.b #0,($A130F1).l ; disable SRAM (required)


movem.l (sp)+,d0/a1 ; Move d0 and a1 from stack


rts



But still no luck =/


EDIT: It's definitely the emulator shifting it. When I close the emulator down, the SRM file is created. I open the file in a hex editor, and it's all FF's except for that one write I did, but it's at location 0x000002 (not 0x000001). When I reopen the game, as suspected, it doesn't load it (because it's now loading FF which is at 0x000001).


I closed and rep-open the emulator and game. I then closed and re-open the same SRM file in the hex editor (which hasn't been touched by the game yet), and now the one write I did earlier which was at 0x000002 is now at 0x000003! Did the same thing again, now it's at 0x000001 (this is when the game loaded the data correctly). Did it again the data is back at 0x000003, etc, etc.


So the emulator is shifting it all the time. But then again, Regen, Kega and Gens all do this, maybe I've gone wrong at the header...

 

EDIT: Actually, I'm gonna let you figure this one out...

 

You're cruel =P


Anyway, let's see if I'm looking in the right direction. I know it's the beginning of the ROM that is wrong. I know this because the game loads in the correct position and saves in the right position. When I write the data to SRAM and close the ROM, and open the SRM in hex, the data is at 0x000001 (that's perfect). But according to the hex editor, the byte I wrote to SRAM moves over another byte every time the ROM is loaded (before SEGA even appears). Say, as soon as I open the ROM, the byte is now at 0x000002. Now, when the game tries to load $00200001, it's FF (as the data i wrote is at $00200002. So it fails to load.


Close and reload the game, it will move again to 0x000001 (when it's moved here, the game loads the data correctly). It keeps moving every time you open the game. So it's definitely the header and I know my load/save routines are okay.


When resetting the game (not closing/re-opening the emulator/game), the SRAM remains unnaffected, so the game loads the data fine.


First, I was meant to put this "dc.l $5241F820" in the header (I accidently left $5241F020 in):



dc.l $5241F820 ; Backup RAM ID ; Enable SRAM
dc.l $00200001 ; Backup RAM start address ; SRAM Start


dc.l $002003FF ; Backup RAM end address ; SRAM End



I've now tried making the SRAM start with an odd address like Shobiz said (also tried $00200000 as the start but still make the save/load routines stay as $00200001). Also, put "$002003FF" as the end of SRAM.


I know people have aid you should use the "movep" command so the data written on the SRAM is always on the odd address, but there's no point for writing a byte as I can just set it on the odd address (there's no such thing as movep.b anyway).


I've read this topic over and over, and same with this one. The only difference in the retro topic was this:



ExRAMSupport: dc.b 'RA', %11111000, %00100000



Which according to shobiz's post, is the same as what we are doing (plus I get 'RA' as an overrange error)


So, all I know is that all emulators, as soon as the ROM is loaded, the bytes in the SRAM file is shifted by one to the right or left, every time it starts, making the game sometimes load, and sometimes not. The only two things I can think of is:

• I've missed something... somewhere... no matter how many times I read these guides
  
• Because mine is a Sonic 2 game, maybe the data is meant to be different

Looking at the S3K disassembly, is header is similar to what these guides are doing. So.... what am I missing?


What really doesn't make sense, is if I delete the SRAM file, then re-open the emulator and game, before the SEGA logo appears, the SRAM file is back from the dead, with the data I wrote earlier in it (still shifted it's byte)


EDIT:



ExRAMSupport: dc.b 'RA', %11111000, %00100000



They put ' instead of ", that's why I got range overflow. Anyway, tried this, and same problem persists.

 

When you look at the ascii table, $52 is equivalent to R and $41 is equivalent to A. %11111000 is $F8 and %00100000 is $20, so they're essentially the same thing, as it leaves you with $5241F820


Just thought you'd like to know.

 

Yeah, that's how shobiz explained it.


Found another error. It seemed that the header was slightly unaligned. The two nop's from ErrorTrap had moved from $200 to $1D0. It seemed that I put tabs instead of spaces. I've now aligned the header completely, the way it was meant to be, with the nops back at $200.


Also, I lowered the amount of SRAM:



ROMEndLoc:
dc.l EndOfRom-1 ; ROM End


dc.l $FF0000 ; RAM Start


dc.l $FFFFFF ; RAM End


dc.l $5241F820 ; Backup RAM ID


dc.l $00200000 ; Backup RAM start address


dc.l $00200200 ; Backup RAM end address


dc.b " " ; Modem support


dc.b " " ; Notes


dc.b "JUE " ; Country


EndOfHeader:



Still not working...


MJ, am I actually looking in the right place?


EDIT: Discovered the problem. It's Regen. Now discovered that the SRAM works perfectly with Kega, Gens and the MESS emulator. I even tried the emulator on my phone. The SRAM works fine on there.


It seems, it's Regen that shifts the SRAM every time I open the ROM. It will shift all bytes to the right once. When you next open the ROM, back to the left. Then back to the right, etc. ValleyBell pointed out that Regen does this with Phantasy Star 4 too. Any solutions?


EDIT2: ValleyBell explains it better. Every time you open the ROM with Regen, all the odd bytes swap with the even bytes. It does this all the time you open the game (that's why it goes right , then left). But, whenever you try to read/write to the SRAM, it's always doing it at an odd address. That's why half the time, it works and half the time, it doesn't.

 

Double post, but thought it might be important to anyone who has a save feature in their hack! The save I did for S2R was working all this time, it was Regen being lame.

No idea, at least I finally know I wasn't going crazy with the save feature in my hack, and I was actually heading in the right direction. And I always thought Regen was the closest to real hardware.


Asking Psy, I tried his 30 day project game with Regen. After the save, I got this in the SRAM file created (which loads correctly):

Code:

30 30 44 44 41 41 59 59 FF FF FF FF FF FF FF FF

00 00 00 06 00 00 00 00 FF FF FF FF FF FF FF FF

Close and reload Regen with the game, and the SRAM immediately becomes this (try to load anything, the game will actually crash):

Code:

30 30 44 44 41 41 59 59 FF FF FF FF FF FF FF FF

00 00 06 00 00 00 00 00 FF FF FF FF FF FF FF FF

I also tried Sonic 1 Megamix (Version 3.0 (793KB, released 06/30/07. Last Genesis build and latest stable version)), and the same thing happens.



After save (game loads correctly):

Code:

00 00 03 04 00 00 00 00 00 01 FF 01 00 00 00 00

00 0C 00 26 FF 01 FF 01 FF FF FF FF FF FF FF FF

Close, then reload Regen with Megamix (game doesn't freeze when you try to load, but it simply won't load anything either):

Code:

00 00 04 03 00 00 00 00 01 00 01 FF 00 00 00 00

0C 00 26 00 01 FF 01 FF FF FF FF FF FF FF FF FF

Every time you close and reload the emulator, it will keep switching the odd bytes with even bytes (so after the first close and load, if I close and load the ROM, it will work again (because they've all switched back).


Sonic 3 and Knuckles is the same, try it!


I used 3 save slots and did some shit in the game. After it saving, this is it:





Close Regen, then reload it with S3K, then you get this:





Close Regen, then reload it with S3K, then you get this:





Close Regen, then reload it with S3K, then you get this:





Etc, etc...


A new discovery!


How to fix it though, no idea!

 

lmao!! That's a bizarre and, actually, pretty bad glitch >_O ...makes me glad I use Kega

 

It also is capable of doing that on real hardware if not paying any attention. That's why I lose so much data. Thought the reason could lie internally in the cart its'self Maybe the ports need something to give it power? I'm not entirely sure.

 

To be perfectly honest, I don't know what is wrong or where the bug lies. Regen internally byteswaps SRAM (for efficient memory handling optimization) but it also converts it back before writing it out so this should not be happening. But it seems that either while loading or saving, the operation is not performed. I am guessing there is some sort of compiler optimization trick that is happening as stepping through the program in a debugger does not produce this problem (I just checked quickly). Anyways, will investigate and post updated build if fixed. Thanks for the report anyways.

 

Thanks for your reply, mate. We have made a further discovery.


This bug seems to happen when you open Regen, File, Open Genesis ROM, whatver.bin


But Alriightyman at SonicRetro, pointed out that if you have set .bin files to open with Regen, when you double click the BIN file, Regen will load with the game, without the SRAM error.


So, opening Regen then file, open rom, will cause the SRAM glitch. Double clicking the bin file to open Regen, won't cause the glitch.


Just thought this might help solve any problems.

 

Really? What version Regen you on? I tried the recent versions on the Regen Page and they all do it with me. Remember, it won't do it when resetting the game. Only by closing and reloading the emulator with the game (unless you double click the bin file to open the game with regen, it won't do it then either). Tried it with a few save games and they all do it.