don't click here

Gens memory info

Discussion in 'Engineering & Reverse Engineering' started by JoseTB, Jul 14, 2004.

  1. JoseTB

    JoseTB

    Tech Member
    716
    59
    28
    I made a list with some offsets in the memory process of gens,so with a debugger you can edit them in real time.You need to know that bytes listed here are all in Big endian.Also,these values have directly effect in the game,of course.Oh,and the list is based in 32 bit system,so the first byte of the process is 0x400000.

    Code (Text):
    1. 00400000 - unknown --- Program data
    2.  
    3. 0057F0C4 --- Program counter (4 bytes)
    4.  
    5. 0057F07F --- D0 register (4 bytes)
    6. 0057F084 --- D1 register (4 bytes)
    7. 0057F088 --- D2 register (4 bytes)
    8. 0057F08C --- D3 register (4 bytes)
    9. 0057F090 --- D4 register (4 bytes)
    10. 0057F094 --- D5 register (4 bytes)
    11. 0057F098 --- D6 register (4 bytes)
    12. 0057F09C --- D7 register (4 bytes)
    13.  
    14. 0057F09E --- A0 register (4 bytes)
    15. 0057F0A2 --- A1 register (4 bytes)
    16. 0057F0A6 --- A2 register (4 bytes)
    17. 0057F0AA --- A3 register (4 bytes)
    18. 0057F0AE --- A4 register (4 bytes)
    19. 0057F0B4 --- A5 register (4 bytes)
    20. 0057F0B8 --- A6 register (4 bytes)
    21. 0057F0BC --- A7 register (4 bytes)
    22.  
    23. 0081A502 - 0082A4FF --- 68k memory
    24.   0082A004 - 0082A084 --- Pallete (FB00)
    25.  
    26. 0082A500 - 0082A500+rom size --- Rom data
    The list is still incomplete,I will update it if I find more offsets.

    Updated:
    Added pallete address for sonic games.That address isn`t valid to all games,only sonic games,because actually is only the offset FB00 of the main 68k memory,that store the pallete in the sonic games.I know you can figure that by yourself but I added that because if you are thinking in doing something with this,realtime pallete editing would be a nice option too.
     
  2. drx

    drx

    mfw Researcher
    2,254
    350
    63
    :rolleyes:
    Awesome! I'm going to make a tiny hack of Gens which will allow you to change this stuff 'normally'
     
  3. Quickman

    Quickman

    be attitude for gains Tech Member
    5,595
    18
    18
    :x
    omg porjcet
    A hack with a window showing the contents of RAM would be good as well. Then we could ascertain whether X byte IS night mode or not.
     
  4. saxman

    saxman

    Oldbie Tech Member
    This is great.... but it doesn't help if we don't know the 'start' of the memory. Since it's probably 'random', it may vary on different machines as to the offset of that info compared to the starting offset of the memory first allocated by Gens. Every bit of that is in a savestate (obviously), but where does the memory 'start' in the x86 RAM is the question.
     
  5. JoseTB

    JoseTB

    Tech Member
    716
    59
    28
    But,some debuggers allow you to specific a process and view only the memory that the process uses,in that case is possible edit them.Also I tested that values with different roms (with different sizes) and they are always in the same offsets.
     
  6. Quickman

    Quickman

    be attitude for gains Tech Member
    5,595
    18
    18
    :x
    omg porjcet
    Recording the value of A7 is a little redundant - that's just the stack pointer.
     
  7. JoseTB

    JoseTB

    Tech Member
    716
    59
    28
    I know,but is a7 too.I mean that could be called as stack pointer or as a7,is the same thing.When you write a program in asm you use a7,so I selected that name,and because in gens it appears as a7,better use a7 in order to avoid confusions.
     
  8. Korama

    Korama

    Tech Member
    272
    2
    0
    The memory start address of a Windows program is actually fixed, although by design it could be variable. There's a field called "image base" in the EXE file header, it specifies the desired memory address which the program was compiled for. That address is usually $00400000. I've heard that EXE files are *always* loaded to their image base address by all 32 bit Windows versions to date. This is possible because each running "process" gets its own virtual address space, and it has the advantage that none of the program's absolute memory references have to be adjusted by the loader. DLLs, however, often have to be relocated in memory and can't be loaded to their image base address, for obvious reasons (just imagine an EXE using several DLLs that all have $00400000 as image base).

    So far about EXE loading mechanics. :(

    A while ago I wrote a program that allows you to edit the Genesis registers, memory and other stuff. It works on savestates though, not real time. If you'd like to try it anyway, then you can find it at Hacking CulT or sonicology. It's called "GSavestate".