don't click here

Regen emulator glitch

Discussion in 'Engineering & Reverse Engineering' started by redhotsonic, Jul 1, 2012.

  1. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber
    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):
    1. ROMEndLoc:
    2.     dc.l EndOfRom-1     ; ROM End
    3.     dc.l $FF0000        ; RAM Start
    4.     dc.l $FFFFFF        ; RAM End
    5.     dc.l $5241F020      ; Backup RAM ID         ; Enable SRAM
    6.     dc.l $00200000      ; Backup RAM start address  ; SRAM Start
    7.     dc.l $00203FFF      ; Backup RAM end address    ; SRAM End
    8.     dc.b "            " ; Modem support
    9.     dc.b "            " ; Notes
    10.     dc.b "JUE             " ; Country
    11. 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):
    1. SavelogostoSRAM:
    2.     movem.l d0/a1,-(sp)     ; Move d0 and a1 to stack
    3.     move.b  #1,($A130F1).l      ; enable SRAM (required)
    4.     lea ($00200001).l,a1    ; base of SRAM
    5.     moveq   #0,d0           ; Clear d0
    6.     move.b  (logos).w,d0        ; move current logo RAM address to d0
    7.     move.b  d0,0(a1)        ; save logos to SRAM
    8.     move.b  #0,($A130F1).l      ; disable SRAM (required)
    9.     movem.l (sp)+,d0/a1     ; Move d0 and a1 from stack
    10.     rts

    I see no problem with this.



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


    Code (ASM):
    1.     movem.l d0/a1,-(sp)     ; Move d0 and a1 to stack
    2.     move.b  #1,($A130F1).l      ; enable SRAM (required)
    3.     lea ($00200001).l,a1    ; base of SRAM
    4.     moveq   #0,d0           ; Clear d0
    5.     move.b  0(a1),d0        ; load logo off SRAM into d0
    6.     move.b  d0,(logos).w        ; Otherwise, copy logos from SRAM to RAM
    7.     move.b  #0,($A130F1).l      ; disable SRAM (required)
    8.     movem.l (sp)+,d0/a1     ; Move d0 and a1 from stack
    9.     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...
     
  2. Alriightyman

    Alriightyman

    I am back... from the dead! Tech Member
    357
    11
    18
    Somewhere in hot, death Florida
    0101001101101111011011100110100101100011 00000010: 0101001100000011 01000101011001000110100101110100011010010110111101101110
    This is my Header:
    Code (Text):
    1. ExRAMSupport:
    2.     dc.b    "RA"        ; external ram                     
    3.     dc.b    $F8         ; don't clear + odd bytes                      
    4.     dc.b    $20         ; sram
    5. ExRAMAddr:                     
    6.     dc.l    $200001, $203FFF    ; start, end
    7.     dc.b "          "   ; Modem support
    8.     dc.b "                                      "   ; Notes
    9.     dc.b "JUE           " ; Country
    10.  
    EDIT: Never mind that idea won't do anything. But, try this for your header and see if it does anything.
     
  3. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber


    Already tried that, mate. Same problem persists.




     
  4. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber
    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.
     
  5. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    65
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    So the question now is why does Regen do this in the first place.
     
  6. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber


    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):
    1. 30 30 44 44 41 41 59 59 FF FF FF FF FF FF FF FF
    2. 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):
    1. 30 30 44 44 41 41 59 59 FF FF FF FF FF FF FF FF
    2. 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):
    1. 00 00 03 04 00 00 00 00 00 01 FF 01 00 00 00 00
    2. 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):
    1. 00 00 04 03 00 00 00 00 01 00 01 FF 00 00 00 00
    2. 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:

    [​IMG]


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

    [​IMG]


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

    [​IMG]


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

    [​IMG]




    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!
     
  7. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    65
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    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.
     
  8. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber

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

    Code (Text):
    1. 30 30 44 44 41 41 59 59   =   00DDAAYY


    He's also got this for some reason:


    Code (Text):
    1. 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:

    [​IMG]


    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!
     
  9. Alriightyman

    Alriightyman

    I am back... from the dead! Tech Member
    357
    11
    18
    Somewhere in hot, death Florida
    0101001101101111011011100110100101100011 00000010: 0101001100000011 01000101011001000110100101110100011010010110111101101110
    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.
     
  10. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber
    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):
    1.         move.w  #$600,(a4)
    2.         move.w  #$C,2(a4)
    3.         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):
    1. 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.
     
  11. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    65
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    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.
     
  12. Alriightyman

    Alriightyman

    I am back... from the dead! Tech Member
    357
    11
    18
    Somewhere in hot, death Florida
    0101001101101111011011100110100101100011 00000010: 0101001100000011 01000101011001000110100101110100011010010110111101101110
    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.
     
  13. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber

    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...
     
  14. E-122-Psi

    E-122-Psi

    Member
    2,470
    612
    93
    I see my query from Basic Questions and Answers somehow polluted this thread within a move, anyway thanx.
     
  15. qiuu

    qiuu

    Tech Member
    144
    9
    18
    Blue Ball & Blocks
    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.
     
  16. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber
    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.
     
  17. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    65
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    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.
     
  18. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber
    I'm home (finally):



     
  19. Alriightyman

    Alriightyman

    I am back... from the dead! Tech Member
    357
    11
    18
    Somewhere in hot, death Florida
    0101001101101111011011100110100101100011 00000010: 0101001100000011 01000101011001000110100101110100011010010110111101101110
    Yes they are still swapped with both manually opening the ROM or double clicking on the ROM. Although I only checked with VRAM.
     
  20. redhotsonic

    redhotsonic

    Also known as RHS Tech Member
    1,587
    10
    18
    United Kingdom
    YouTuber


    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?