(11-03-2011, 09:37 AM)skid Wrote: One easy way to cut down the time is to use save states.
In terms of the emulator code, I have a few ideas to speed it up. Just got to find the motivation to make the changes (unless you want to?)
I used the range 807542D0 to 807542E0.
To be honest, I know nothing of emulator programming (outside of the bare basics), but do hold a programming job that deals with database interaction (Oracle/MySQL), 911 Silent Dispatch, and NCIC/State information interfacing used by Sheriff Offices/Police Offices throughout the state (all connected via encrypted TCP/IP streams, using local server authentication at our office).
I would think the best strategy in implementing a proper break would be just to check the memory address being interacted with when an instruction is processed, and compare the instruction to a list of reads/writes instructions (switch) to set a break flag (which would just stop the game like normal highlighting the line currently being executed). Also every line passed that didn't break could be stored in a list (30 previous passes or so that) as a means of tracing this system (very helpful to know how you got to where you are). It seems that BPX, BPW, and BPR could all share this implementation along with keeping the speed of the emulator up to par with what is expected in debug mode. A live hex editor (threaded of course), would also be a great addition to aid in finding certain memory locations that would be tough to find via the current ram search.
I am unsure on the method being used currently, but whatever is going on is taking up too many cpu cycles to be worth the effort of using breakpoints (less than 1 fps on my system just doesn't cut it)... I would think the check system described above (even with an implemented trace) shouldn't slow emulation near as much as what is currently in place.