[JoseTB]

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.

00400000 - unknown --- Program data 

0057F0C4 --- Program counter (4 bytes)

0057F07F --- D0 register (4 bytes)
0057F084 --- D1 register (4 bytes)
0057F088 --- D2 register (4 bytes)
0057F08C --- D3 register (4 bytes)
0057F090 --- D4 register (4 bytes)
0057F094 --- D5 register (4 bytes)
0057F098 --- D6 register (4 bytes)
0057F09C --- D7 register (4 bytes)

0057F09E --- A0 register (4 bytes) 
0057F0A2 --- A1 register (4 bytes)
0057F0A6 --- A2 register (4 bytes)
0057F0AA --- A3 register (4 bytes)
0057F0AE --- A4 register (4 bytes)
0057F0B4 --- A5 register (4 bytes)
0057F0B8 --- A6 register (4 bytes)
0057F0BC --- A7 register (4 bytes)

0081A502 - 0082A4FF --- 68k memory
  0082A004 - 0082A084 --- Pallete (FB00)

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.

This post has been edited by JoseTheBest: 14 July 2004 - 05:07 PM

[drx]

Awesome! I'm going to make a tiny hack of Gens which will allow you to change this stuff 'normally'

[Quickman]

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.

[saxman]

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.

[JoseTB]

saxman, on Jul 14 2004, 03:48 PM, said:

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.

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.

[Quickman]

Recording the value of A7 is a little redundant - that's just the stack pointer.

[JoseTB]

Quick Man, on Jul 14 2004, 05:27 PM, said:

Recording the value of A7 is a little redundant - that's just the stack pointer.

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.

[Korama]

saxman, on Jul 14 2004, 03:48 PM, said:

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.

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".

This post has been edited by Korama: 14 July 2004 - 08:30 PM