Registered memory write callbacks get called too early

[GoogleCodeExporter]

Memory write callbacks (starting with trace_write_byte, etc.) currently get
called before the memory is actually written. I put a hack in on the Lua
side of the callback stuff to let the callback see the new value, but
there's still a big piece of functionality missing here: The memory write
callback is unable to write to the region of memory that triggered the
callback. For example, if I run the following Lua code:

memory.register( 0xFFD010, 2, function(addr,size)
    if(memory.readword(0xFFD010) == 2560) then
        memory.writeword(0xFFD010, 4096)
    end
end)

I expect that whenever the game would normally set the word at address
0xFFD010 to exactly 2560, it will instead set it to 4096. This should work,
however, currently (because of the order writes happen in) the value will
immediately be set back to 2560 again as soon as the function returns.

I think this problem might only exist for writes triggered by the M68k.

I tried fixing this by moving the calls like emit_hook("_hook_write_byte");
to later lines in Star.c, but then the callbacks stopped getting called at
all, and I'm not really sure why.

Original issue reported on code.google.com by nitsuja-@hotmail.com on 16 Feb 2009 at 3:31

[GoogleCodeExporter]

I was actually in the process of testing the fix when this issue got posted.

Original comment by Upth...@gmail.com on 16 Feb 2009 at 4:03

• Changed state: Fixed

[GoogleCodeExporter]

Great. One thing:
"since lua can only hook the main 68k at the moment"
I think that is actually not true, since the memory hooking is 
processor-agnostic
right now.

Original comment by nitsuja-@hotmail.com on 16 Feb 2009 at 4:25

[GoogleCodeExporter]

Err, that's a bad idea, since the Main68k (genesis processor) memory map and the
Sub68k (sega cd processor) memory map are _totally_ different, having it call 
the
same callback in the case of either processor accessing the address, with no 
way to
tell which one did so could lead to some seriously unexpected script behavior.
I'm divided on whether the immediate fix is to temporarily disable sub68k 
calling
back, or to properly implement specifying it as an alternate processor.

Original comment by Upth...@gmail.com on 16 Feb 2009 at 10:28

• Changed state: Started

[GoogleCodeExporter]

Oh... in that case, I'm not divided on it. The function signature is now:

memory.register(int address, [int size=1,] [string cpuname="main",] function 
func)

Right now a cpuname of "sub" or "s68k" will tie into the hooks from 
tracer_cd.cpp,
and everything else is assumed to refer to the main 68k.

Original comment by nitsuja-@hotmail.com on 16 Feb 2009 at 11:33

• Changed state: Fixed

[GoogleCodeExporter]

Awesome. I was just trying to figure out how the tieredregions you set up 
worked so
that I could do this.

Original comment by Upth...@gmail.com on 16 Feb 2009 at 11:46