Mednafen vram breakpoints?

[SephirothTNH]

Can someone help me out with this.  I was using mednafen for the first time yesterday and trying to set a  read breakpoint on an area of vram.  I verified that this is the data I'm looking for by editing it in the memory editor and watching the graphics get messed up in game. 

The area of vram was from 0x4000 to 0x5400.  I tried adding an "*" to the address as well and tried every type of read breakpoint mednafen offers.  Nothing worked. 

Thanks for your time.

[ccovell]

Regular CPU read breakpoints are chosen with Shift+R... and I think VRAM (AUX) breakpoints are selected with CRTL+R.  That should do ya.

[SephirothTNH]

I tried the Aux breakpoints first ctrl-r.  Then I tried the IO breakpoints ctrl-shift-r and finally the regular breakpoints shift-r.  None broke. 

This address range is the font for the game if that makes a difference.  Like I said I could edit the memory there and blank out a character.  I could see this work in the game dialogue.  But I couldn't get mednafen to break. 

I've used this technique to make a table before on other systems.  By setting a read breakpoint on the font to see how the game addressed it.  I've already made a table by using a relative search program but I'm still curious why I couldn't get mednafen to break on font reads. 

[Mednafen]

The memory editor's view of VRAM is bytewise, but the breakpoints are specified in 16-bit units(i.e. divide the address in the memory editor by 2 to get the address to put as the VRAM breakpoint).

[ccovell]

Also, why would the CPU read a font from VRAM once it's already in there?

But if you mean Mednafen would break when the VDC itself accesses a specified tile. I don't think any emu has that functionality.

[SephirothTNH]

Thanks for the info mednafen.  I'll try it later.  Even if it doesn't work out that's still good info to have.

ccovell that makes sense.  I am curious though how does the alphabetical order font in vram go to dialogue order on screen? 

Your right though my method usually works a little differently.  I don't mess around with console hacking much but I've done this on an snes and genesis game before.  I find were the font is in memory and set a read breakpoint for it.  Then when dialogue starts popping up the system breaks and I can see what hex corresponds to what character. 

On this pce game the font is in three locations by the time the game loads up.  0x10000, 0x50000, and vram 0x4000.  Setting breakpoints or editing the values of either of the first two locations did nothing.  Editing the vram was able to blank out characters. 

[elmer]

The memory editor's view of VRAM is bytewise, but the breakpoints are specified in 16-bit units(i.e. divide the address in the memory editor by 2 to get the address to put as the VRAM breakpoint).

Hahaha ... so that's why I haven't been able to get them to work for the last 4 months! 

I always found a work-around, so it never bothered me enough to look at Mednafen's source code to see what was going on.

IMHO, changing the memory viewer's display of VRAM to 16-bit values and addresses would be a nice improvement.

As it is, I'm constantly having to remember to divide-by-2 or multiply-by-2, and it's been one of the few little niggles that I've had.

I'll see about making that change when I finally update my font patches to the latest version of Mednafen.

[Bonknuts]

I could be wrong, but I thought I remembered a bug in mednafen when using vram break points (read/write) and the cpu's Txx instruction. If the vram address breakpoint is aligned with the first vram read or write of the Txx instruction, then no there's problem. But if the vram breakpoint address is somewhere after the initial write of the Txx instruction, but within the range of the block transfer, it won't trigger. As if the debugger only checks vram write/read once per cpu instruction initial read/write to the port, rather than any direct access of the vram address itself (speed reasons?). It's been a quite awhile since I've used it, but I'm pretty sure that was an issue.