Regen 0.972 and 0.972D

AamirM's Regen forum

Moderator: AamirM

User avatar
King Of Chaos
Very interested
Posts: 268
Joined: Fri Feb 29, 2008 8:12 pm
Location: United States

Post by King Of Chaos » Mon May 03, 2010 6:19 pm

Happens on real hardware. :P

Helder
Interested
Posts: 13
Joined: Sat Jan 22, 2011 4:59 pm

Post by Helder » Sat Jan 22, 2011 5:59 pm

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?

Helder
Interested
Posts: 13
Joined: Sat Jan 22, 2011 4:59 pm

Post by Helder » Thu Jan 27, 2011 10:13 am

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?

AamirM
Very interested
Posts: 469
Joined: Mon Feb 18, 2008 8:23 am
Contact:

Post by AamirM » Thu Jan 27, 2011 7:16 pm

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.

Helder
Interested
Posts: 13
Joined: Sat Jan 22, 2011 4:59 pm

Post by Helder » Fri Jan 28, 2011 5:51 am

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.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Fri Feb 04, 2011 8:21 am

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.

Helder
Interested
Posts: 13
Joined: Sat Jan 22, 2011 4:59 pm

Post by Helder » Fri Feb 04, 2011 8:24 pm

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.

colonthree
Interested
Posts: 18
Joined: Fri Aug 07, 2009 4:07 am

Post by colonthree » Wed Apr 20, 2011 12:31 am

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! :)

Helder
Interested
Posts: 13
Joined: Sat Jan 22, 2011 4:59 pm

Post by Helder » Wed Apr 20, 2011 5:58 am

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.

bahabulle
Newbie
Posts: 5
Joined: Fri Aug 19, 2011 8:34 am
Location: France

Post by bahabulle » Thu Jan 12, 2012 1:11 pm

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.

Helder
Interested
Posts: 13
Joined: Sat Jan 22, 2011 4:59 pm

Post by Helder » Thu Jan 12, 2012 4:03 pm

Try erasing the SRAM file associated with the game.

bahabulle
Newbie
Posts: 5
Joined: Fri Aug 19, 2011 8:34 am
Location: France

Post by bahabulle » Fri Jan 13, 2012 8:35 am

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.

Helder
Interested
Posts: 13
Joined: Sat Jan 22, 2011 4:59 pm

Post by Helder » Tue Jan 17, 2012 8:24 pm

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.

Gigasoft
Very interested
Posts: 88
Joined: Fri Jan 01, 2010 2:24 am

Post by Gigasoft » Sun Jan 22, 2012 9:08 pm

There is a bug in the YM2612 debugger window. The Octave field is displayed incorrectly.

Post Reply

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest