Page 13 of 13

Posted: Mon May 03, 2010 6:19 pm
by King Of Chaos
Happens on real hardware. :P

Posted: Sat Jan 22, 2011 5:59 pm
by Helder
Is there anyway to do breakpoints in the debug version and actually break on the address I input? I had issues since the debugger was first released in previous and even recent revisions. Basically this is what happens for me: I load the rom aka Beyond Oasis I then set a break on the health code ram address FF1A73 and set the to break on write,obviously nothing breaks since its not a 16bit address so I use FF1A72. Then it keeps breaking on the same 2 instructions non stop and never get a chance to break like if I make a change in health like taking damage. Is there a fix or a way for it to break ONLY when I actually make a change to the specified address so it breaks to the rom address causing change?

Posted: Thu Jan 27, 2011 10:13 am
by Helder
Sorry for double post, ok I read the read me and it says that if the main processor has some error or illegal operation it will break and show the window. I also notice that it says break at adress 0000000 at the bottom of the debugger screen everytime it breaks. So what I should be asking is is there a way to set a breakpoint on a RAM address so it will point to a ROM address that issued the change?

Posted: Thu Jan 27, 2011 7:16 pm
by AamirM
Yes, you use the breakpoints on write. And no, address doesn't have to be 16-bit. If it's not breaking, you're not setting in the correct address. It breaks correctly for me here. And yeah, it will keep breaking as long as the conditions you give to it are true.

If you want to check what writes to that address when taking damage, you should enable the breakpoint just before taking the damage. That's why there is the "Frame Advance" option.

Posted: Fri Jan 28, 2011 5:51 am
by Helder
Thanks for the reply but it doesn't work for me on this game or any game. I have used other emulators with breakpoints and I know how to set them up. Maybe this one is different for whatever reason. So let me tell you what I'm doing and you tell me what you did different to get some kind of results.

Game I am playing is Beyond Oasis in bin format USA region, I am using the health ram code FF1A73. When I setup the breakpoints with that address and check off the write I hit "OK" on lower right hand of debugger screen which returns me to the game I take damage and no breaks,I use a healing Item and no breaks. I next try FF1A72 and set the same options like previous breakpoint. Now I get the debugger breaking constantly whether I take damage or not and I see it says on the bottom left of the screen says "Break on write address = 00000000" ,not sure what that is and at the very top of the screen the first PC address is 0055CA. I know the ROM health instruction is at 005886 from decrypting an existing GG code. So what am I doing wrong in this setup?


Edit: After trying to setup a breakpoint on FF1A72 and having to hit the "ok" button a good fifteen or so times the address of the PC changed to the correct instruction that was subtracting health as I was taking damage. Can you in a future update make it so it only breaks on actual changes. I dont see why it would be constantly breaking on the health if I'm just standing there doing nothing.

Posted: Fri Feb 04, 2011 8:21 am
by tomaitheous
Edit: After trying to setup a breakpoint on FF1A72 and having to hit the "ok" button a good fifteen or so times the address of the PC changed to the correct instruction that was subtracting health as I was taking damage. Can you in a future update make it so it only breaks on actual changes. I dont see why it would be constantly breaking on the health if I'm just standing there doing nothing.
That's a different kind of break. You're setting a break point for any read or write at the address, not if the value has changed. That'd be nice, but I haven't seen any debuggers with that feature. The usual method is the set a break on writing the address. Then trace back the code that wrote it. Then figure out the conditional logic, and if you still need breaking - break on an instruction address of the conditional logic, so that you're not getting false positives.

Posted: Fri Feb 04, 2011 8:24 pm
by Helder
tomaitheous wrote: That's a different kind of break. You're setting a break point for any read or write at the address, not if the value has changed. That'd be nice, but I haven't seen any debuggers with that feature. The usual method is the set a break on writing the address. Then trace back the code that wrote it. Then figure out the conditional logic, and if you still need breaking - break on an instruction address of the conditional logic, so that you're not getting false positives.
I know I'm setting a break for any read or write, but if you use any other emulator with a debugger you will see that it will break only on change if its set to break on write. I don't know why this one is different or maybe its the genesis in how it checks data. A good example of what I'm saying is just try the fceux NES emulator, set a break on a ram address it will break only when thee is change and not have false breaks. Either way I have figured it out where I can use it but it's just a little annoying to have to refresh the break screen a ton of times till I actually see a different set of instructions which is where I usually want to be looking at. It just a little complaint and if the author has n reason to change it I can live with that, I appreciate the work put into it and all the features incorporated.

I would like to have change made that would help me out in future revisions if its possible, nothing major I think:

1.When the system break to an instruction I would like to be able to scroll up or down to see what is before or after the break.

2.Cheat support isnt really working,If I put in a known ram value or ROM address with its value it doesnt work most of the time.

3.Be able to click and edit the left side of the RAM viewer window with the values,sometimes i click on the field and it reset back to ram address 0000.

These are my requests and I dont expect any of this to be done or added but I'm throwing it out there,thanks for the hard work of making this emulator.

Posted: Wed Apr 20, 2011 12:31 am
by colonthree
Probably isn't worth making a new thread for:

I'm just wondering if the image display is meant to go grey when you go into either of the CPU debuggers or ROM editor. Is this the expected behaviour for the current version?

Additionally program sometimes terminates when clicking OK in the 68k debugger, perhaps this is already known.

Thanks for all your work, great emulator! :)

Posted: Wed Apr 20, 2011 5:58 am
by Helder
Ive had issues with the emulator closing when activating cheats, I have a few requests which should be simple to implement.

1. Could the ram viewer not reset to the beginning of the addresses after i make an edit to the rom editor, it always resets after I make a change and its a little annoying having to scroll back to the ram area I was monitoring.

2. An option to add ram cheats on the fly instead of relying on a cheat text file, which seems to make the emulator crash and the codes don't seem to work when I do use a cheat file.

Other than that it's a great emulator and have learned to overcome some of the breakpoint issues I had but still wouldn't mind some improvement on that. Great emulator in all aspects.

Posted: Thu Jan 12, 2012 1:11 pm
by bahabulle
Hi.

I have a problem with the game Phantasy Star 4 and Regen 0.972D (same with 0.972 or 0.971D).

I can't save my game with the game menu (start button) and there is 2 slots filled with Level 8 and 20.

Posted: Thu Jan 12, 2012 4:03 pm
by Helder
Try erasing the SRAM file associated with the game.

Posted: Fri Jan 13, 2012 8:35 am
by bahabulle
I already tried.

I have the problem even when I run the rom for the first time so the SRAM file doesn't exist.

And with all versions of the rom (J, U).

It's strange.

Posted: Tue Jan 17, 2012 8:24 pm
by Helder
Yes I just tried it myself and it has the same issue as you described, perhaps using a different emulators SRAM file will fix it? but seems like an Emulator issue.

Posted: Sun Jan 22, 2012 9:08 pm
by Gigasoft
There is a bug in the YM2612 debugger window. The Octave field is displayed incorrectly.