Well, whilst we are here, I have a quick question about the SRAM for Sonic 2. I have enabled SRAM in my header: Code (ASM): 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: Code (ASM): 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: Code (ASM): 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 is my Header: Code (Text): 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.
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.
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 (Text): 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 (Text): 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 (Text): 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 (Text): 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!
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: Code (Text): 30 30 44 44 41 41 59 59 = 00DDAAYY He's also got this for some reason: Code (Text): 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.
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 Taken from S3K SVN disassembly, to change Sonic's set speeds, go to "loc_10AFA:" and you should see this in the code: Code (ASM): 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: Code (ASM): 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.
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.
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...
I see my query from Basic Questions and Answers somehow polluted this thread within a move, anyway thanx.
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.
YES! I get that as well. It always seemed glitched up whenever I took dumps. So I use debugens for doing stuff like that. But it never occured to me that the glitch is similar. AamirM posted in the SSRG topic about this, I would quote his psot, but I'm at work and my workplace has blocked all of SSRG (same with Retro, but I can enter the forums for some reason). But long story short, he will look into it.
This is too implausible on general grounds to be plausible as a potential cause: Not only are the x86 and x86-x64 architectures little endian by specification, but Regen is closed source and distributed as binaries. Even if there were big endian versions of x86 or x86-x64 architecture (there aren't), you would still need separate executables for each architecture -- executable for one would not run on the other.
Yes they are still swapped with both manually opening the ROM or double clicking on the ROM. Although I only checked with VRAM.
Spoke to OrdosAlpha, and he's also running the latest version of Regen, although, he cannot get this SRAM glitch to occur. He's running on Windows XP SP3. Whereas I'm on Windows 7, and can get the glitch to occur on the same version on Regen Anyone else on WinXP SP3? Can you reproduce this bug with the latest on Regen?