[redhotsonic]

Well, whilst we are here, I have a quick question about the SRAM for 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
	moveq	#0,d0			; Clear d0
	move.b	0(a1),d0		; load logo off SRAM into d0
	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

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?



EDIT2: It's 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...

This post has been edited by redhotsonic: 01 July 2012 - 04:22 PM

[Alriightyman]

This is my Header:

ExRAMSupport:
	dc.b	"RA"		; external ram                    	
	dc.b	$F8			; don't clear + odd bytes                    	
	dc.b	$20			; sram
ExRAMAddr:                    	
	dc.l	$200001, $203FFF	; start, end
	dc.b "        	"	; Modem support
	dc.b "                                    	"	; Notes
	dc.b "JUE     		" ; Country

EDIT: Never mind that idea won't do anything. But, try this for your header and see if it does anything.

This post has been edited by Alriightyman: 02 July 2012 - 12:08 AM

[redhotsonic]

Alriightyman, on 01 July 2012 - 11:44 PM, said:

This is my Header:

ExRAMSupport:
	dc.b	"RA"		; external ram                    	
	dc.b	$F8			; don't clear + odd bytes                    	
	dc.b	$20			; sram
ExRAMAddr:                    	
	dc.l	$200001, $203FFF	; start, end
	dc.b "        	"	; Modem support
	dc.b "                                    	"	; Notes
	dc.b "JUE     		" ; Country

EDIT: Never mind that idea won't do anything. But, try this for your header and see if it does anything.

Already tried that, mate. Same problem persists.

redhotsonic, on 01 July 2012 - 05:53 PM, said:

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 unaffected, 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), so I've now changed that:

    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 said 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. Anyway, I gave that a go and still no difference.





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)

[redhotsonic]

Double post, but it's important... ish =P




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 (that's when the save/load data works okay). Then back to the right, etc. ValleyBell pointed out that Regen does this with Phantasy Star 4 too. Any solutions?



EDIT: 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.

This post has been edited by redhotsonic: 02 July 2012 - 01:27 PM

[flamewing]

So the question now is why does Regen do this in the first place.

[redhotsonic]

flamewing, on 02 July 2012 - 03:10 PM, said:

So the question now is why does Regen do this in the first place.

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):

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):

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):

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):

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!



EDIT: A possible fix.... is to maybe in hacks, check if all odd bytes are $FF (incase Regen has switched them around), and if so, switch all the bytes in the SRAM around again. That way, if Regen has switched them, the hack itself will switch them back.

EDIT2: Actually, scratch that, it can't read even bytes, duh!

This post has been edited by redhotsonic: 02 July 2012 - 04:21 PM

[flamewing]

What I find interesting is that Psy's 30-day project has several odd bytes replicated in even positions, but not all. Was this from a clean SRAM? If so, it may be the key to getting SRAM to work in Regen until/if it is fixed.

[redhotsonic]

flamewing, on 02 July 2012 - 04:45 PM, said:

What I find interesting is that Psy's 30-day project has several odd bytes replicated in even positions, but not all. Was this from a clean SRAM? If so, it may be the key to getting SRAM to work in Regen until/if it is fixed.

Yeah, this is because he's written this at the beginning of the SRAM:

30 30 44 44 41 41 59 59   =   00DDAAYY

He's also got this for some reason:

46 46 55 55 43 43 4B 4B   =   FFUUCCKK

The rest seem fine. I think the reason why there were more even writes was because:

• I saved data.
  
• Closed the ROM and reloaded it (so now all bytes have been shifted and now all odd bytes are $FF).
  
• Didn't load the data (otherwise it will crash) and started a new game
  
• Because of that, it saved data to the new odd bytes....
  
• Making both odd and even bytes being written

This sort of thing can happen with any game. Theoretically, in S3K if I come to this from closing and opening the ROM:




I can start a new game, and have two different game slots. Basically, having 16 game slots in S3K instead of 8. Just close and reload the game to use the other 8 slots for S3K. Pretty cool, actually!

This post has been edited by redhotsonic: 02 July 2012 - 05:26 PM

[Alriightyman]

redhotsonic, on 02 July 2012 - 05:24 PM, said:

flamewing, on 02 July 2012 - 04:45 PM, said:

What I find interesting is that Psy's 30-day project has several odd bytes replicated in even positions, but not all. Was this from a clean SRAM? If so, it may be the key to getting SRAM to work in Regen until/if it is fixed.

Yeah, this is because he's written this at the beginning of the SRAM:

30 30 44 44 41 41 59 59   =   00DDAAYY

He's also got this for some reason:

46 46 55 55 43 43 4B 4B   =   FFUUCCKK

The rest seem fine. I think the reason why there were more even writes was because:

• I saved data.
• Closed the ROM and reloaded it (so now all bytes have been shifted and now all odd bytes are $FF).
• Didn't load the data (otherwise it will crash) and started a new game
• Because of that, it saved data to the new odd bytes....
  
• Making both odd and even bytes being written

This sort of thing can happen with any game. Theoretically, in S3K if I come to this from closing and opening the ROM:




I can start a new game, and have two different game slots. Basically, having 16 game slots in S3K instead of 8. Just close and reload the game to use the other 8 slots for S3K. Pretty cool, actually!

Strange, but I don't seem to have that problem with Regen. It works just fine. Are you using an older version? I am using v0.97D.

[redhotsonic]

Alriightyman, on 02 July 2012 - 11:36 PM, said:

Strange, but I don't seem to have that problem with Regen. It works just fine. Are you using an older version? I am using v0.97D.

Remember, if you reset the game, it will be fine. It's when you close the emulator and reload it. I am using the same version. I just tried the non-debugger version and same thing exists. I tried I tried all these version on the page with Sonic 3 and Knuckles and get the same glitch. I haven't tried previous versions though.


This seems to happen with every game I try.

Looks like we will have to put warnings for people when using Regen for our hacks =P

E-122-Psi, on 02 July 2012 - 07:42 PM, said:

Does anyone know how to edit Sonic and Knuckles' speed/acceleration stats separately in the S3K disassembly? There seems to be a character speeds section near the bottom, but when I edit it, nothing seems to change. Other coding seems to be labelled for both characters.

Taken from S3K SVN disassembly, to change Sonic's set speeds, go to "loc_10AFA:" and you should see this in the code:

		move.w	#$600,(a4)
		move.w	#$C,2(a4)
		move.w	#$80,4(a4)

In order of Sonic's top speed, acceleration, and deceration.



Tails set speeds are at "loc_136CA:"

Knuckles is at "loc_164AA:"



His shoes speeds are at "loc_10CE8:" loc_1394E: loc_1669A:

His in water speeds are at "loc_10E2E:" loc_1463A: loc_166F6:

His out water speeds are at loc_10EA6: loc_146BA: loc_1676E:

His super set speeds are at loc_11A6A: loc_151A4: loc_17912:

His revert to normal speeds are at loc_11BA8: not sure not sure




Unlike Sonic 1 and Sonic 2, each character right at the beginning of their object code set their speed RAM to a4 and does this every frame:

lea	(Sonic_Knux_top_speed).w,a4

Then, instead of setting the speeds directly to the RAM address (like it does in S1 and S2), it sets it to a4 address register.

[flamewing]

E-122-Psi, on 02 July 2012 - 07:42 PM, said:

Does anyone know how to edit Sonic and Knuckles' speed/acceleration stats separately in the S3K disassembly? There seems to be a character speeds section near the bottom, but when I edit it, nothing seems to change. Other coding seems to be labelled for both characters.

If I am not mistaken, that section is for the 2p stats. The in-game stats are set in several places, and I think that there is common code for all characters in some locations. If you search for "#$600,(a4)" and "Sonic_Knux_top_speed" you can find most locations where it is set.

Edit: should have read RHS's reply before putting my own; his is more complete.

This post has been edited by flamewing: 03 July 2012 - 07:53 AM

[Alriightyman]

redhotsonic, on 03 July 2012 - 07:34 AM, said:

Alriightyman, on 02 July 2012 - 11:36 PM, said:

Strange, but I don't seem to have that problem with Regen. It works just fine. Are you using an older version? I am using v0.97D.

Remember, if you reset the game, it will be fine. It's when you close the emulator and reload it. I am using the same version. I just tried the non-debugger version and same thing exists. I tried I tried all these version on the page with Sonic 3 and Knuckles and get the same glitch. I haven't tried previous versions though.


This seems to happen with every game I try.

Looks like we will have to put warnings for people when using Regen for our hacks =P

I finally got it to work. (Or is it not work?). I had to load the rom from the emulator to make this happen.
What I normally do is I set Regen as a default program for MD binaries so all I need to do is double click them to run. When doing it this way, the SRAM bug does not occur for whatever reason. I tried it with S3K and others and this way loads it fine every time.

[redhotsonic]

Alriightyman, on 03 July 2012 - 09:02 AM, said:

I finally got it to work. (Or is it not work?). I had to load the rom from the emulator to make this happen.
What I normally do is I set Regen as a default program for MD binaries so all I need to do is double click them to run. When doing it this way, the SRAM bug does not occur for whatever reason. I tried it with S3K and others and this way loads it fine every time.

Wow, how interesting. That's weird if you open it from the ROM itself, it's all fine, but going to File > Open, it fucks it all up.


Looked for any settings in the emulator to see if anything may cause this. But all I can find is to switch the SRAM off, or to change the path where the SRAM is loaded from.



Strange, strange...

[E-122-Psi]

I see my query from Basic Questions and Answers somehow polluted this thread within a move, anyway thanx.

[qiuu]

Regen also saves VRAM/RAM dumps with bytes swapped, at least for me. Alriightyman, can you check whether saving these exhibits the same behavior as saving SRAM, I.e., swapping bytes when manually opening the ROM vs not doing so when starting Regen via double click on the ROM?

Savestates on the other hand seem fine. (Unfortunately they are not compatible with the typical gsx savestates; the CRAM format is really strange, though I think the incompatibility is actually related to sound emulation. But that's a different story anyway.)

I'd have suspected it to be some issue with the endianness of the machine Regen runs on, but as it seems right now the behavior is too inconsistent for that to be plausible.

If we can track down what exactly happens when, perhaps AamirM can fix this.

This post has been edited by qiuu: 04 July 2012 - 07:35 AM