RAM search, watch, and cheats for alternate CPU contexts

[GoogleCodeExporter]

While working on implementing memory.register for LUA, it occured to me
that for SegaCD games, and 32X games, it would be very helpful to be able
to specify which CPU's memory space you want to hook.
Which, in turn, made me realize that there is literally no visibility of
the SegaCD sub68k memory space in current RAM search, and there's only one
small region of the 32X SH2 memory space currently included. Additionally,
the Z80's memory space, while almost entirely included in the 0xA0xxxx
region, could benefit from being separated from the Main68K memory.
My proposal is to turn the ram search dialog into a tabbed interface.
1. the 68000 tab, including: 
    *the game SRAM (SRAM_Start - SRAM_End) when applicable
    *the portion of SegaCD PRG-RAM viewable by the Main 68000 (020000 -
03FFFF; no change necessary)
    *the SegaCD Data RAM (200000 - 23FFFF; no change necessary) when applicable
    *the cartridge battery ram (400000 - 7FFFFF; trimmed to emulated BRAM
size) when applicable
    *the 32X frame buffer (840000 - 85FFFF) when applicable
    *the 32X frame overwrite buffer (860000 - 87FFFF) when applicable
    *the Z80 RAM (no change necessary)
    *the I/O region (A10000 - A1002F; perhaps) when applicable
    *the 32X register region (A15100 - A151FF) when applicable
    *the Main 68000 work RAM (no change necessary)
2. the Z80 tab, including:
    *The z80 RAM (0000 - 1FFF; same region currently shown at A0xxxx)
    *The YM2612 region (4000 - 4004)
    *The PSG region (7F11 - 7F12)
    *The z80 window into Main 68000 memory (8000 - FFFF)
3. the Sub 68000 tab (when SegaCD is active) including:
    *the PRG RAM (000000 - 01FFFF; same memory as shown in m68k tab)
    *the Data RAM (080000 - 0DFFFF; same memory as shown in m68k tab, but
mapped differently)
    *the system battery RAM (FE4000 - FEFFFF; not shown currently)
    *the segaCD registers area (FF8000 - FF81FF; not shown currently)
4. The SH2 tab (when 32X is active) including:
    *the registers (00004000 - 000041ff; larger set than m68k can access)
    *the frame buffer (04000000 - 0401FFFF; same as m68k sees)
    *the frame overwrite buffer (04020000 - 0403FFFF; same as m68k sees)
    *the SDRAM (06000000 - 0603FFFF; currently displayed)

I do intend to work on this myself, but suspect I will require Nitsuja's
assistance to make sure that I don't fuck anything up in the process.

Original issue reported on code.google.com by Upth...@gmail.com on 4 Nov 2008 at 4:02

[GoogleCodeExporter]

Additionally, ram watch should be updated to include a column indicating what 
CPU
context the address being watched belongs to, and ram cheats (when implemented)
should  also support specifying CPU context.

Original comment by Upth...@gmail.com on 4 Nov 2008 at 4:04

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I liked the tabbed window idea for this.  That would be really nice to see this
implemented.

Original comment by andres.d...@gmail.com on 5 Nov 2008 at 1:10

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Since this seems like a major undertaking, maybe it should be pushed off to the
version after the next release? How easy would it be to implement (stopgap) 
support
for "add cheat" and memory.register() without this?

Original comment by nitsuja-@hotmail.com on 8 Feb 2009 at 7:00

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

The hooks in the core CPU emulation which would be used by the lua 
memory.register
and add cheat are already present in corehooks.cpp, it's just the LUA interface 
that
needs to be done. Unfortunately every time I've tried to start on the LUA 
interface,
I've become lost in how incredibly confusing and unhelpful the LUA<->C interface
reference documentation is.

Add Cheat requires the creation of a whole new UI dialog, but in the past I had 
the
functional part, where the cheats behaved more reliably and had variable size, 
and
that would be easy enough to recreate.
I made a mockup of the desired dialog, which is visible here:
http://dl.getdropbox.com/u/75343/ChtDlgMock_expln.png but I think you're right 
about
knocking it a release and just switching cheats from being applied on 
frame-boundary
to being applied immediately, and when the address is written to.

Original comment by Upth...@gmail.com on 8 Feb 2009 at 11:13

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Oh. Since the hooks are already there I put in the Lua side of memory.register 
and it
seems to be working well. I used a simpler interface than the one that was 
partially
implemented... some of that can be restored later but I'd like to keep it this 
simple
for the common case. In particular, adding more specific hooks ideally should 
not
change the behavior of the current memory.register/registerread/registerexec
functions in any way.

Original comment by nitsuja-@hotmail.com on 16 Feb 2009 at 12:29

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

There's really no reason that the LUA interface should have been as complicated 
as I
was making it. qfox has suggested, and I agree, that the call should be
"memory.register(address,func[,processor])" where processor would be a string
identifying the CPU context which should be hooked.
IE: "main", "sub", "sound", "32X", "32Xmain", "32Xsub".

The only thing I was doing differently from how it works in dehacked's is that I
wanted to be sure each script could have multiple functions registered
simultaneously, and it looks like you've taken care of that.

Original comment by Upth...@gmail.com on 16 Feb 2009 at 1:55

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Actually there's something I couldn't get working right that should really be 
fixed,
but I've made a separate issue for that (issue 55).

Original comment by nitsuja-@hotmail.com on 16 Feb 2009 at 3:32

• Added labels: ****
• Removed labels: ****