|
Post by ripper713 on Mar 19, 2006 22:02:02 GMT -5
Does anyone know how to activate the log feature under the debug menu? When I try it, a window pops up with check boxes and a save file feature but no matter what I do or which items I select, pSX does not seem to do any logging. The saved files are always empty. Thanks in advance for any help.
|
|
|
Post by pSX Author on Mar 20, 2006 1:18:18 GMT -5
The log feature does not work in the release build, it is all compiled out (I should remove the menu item really - I forgot).
It is an internal debug feature that slows the emulator down quite a bit (it logs _everything_) - it wouldn't really be that useful to anyone but me.
What are you trying to do?
|
|
|
Post by ripper713 on Mar 20, 2006 18:55:52 GMT -5
I am presently trying to understand the compression/encryption methods used on some game files in Lunar Silver Star Complete. I would like to use the logging feature to track (and save to a file for later examination) cd data reads and sync them up with CPU instructions and DMA transfers. I presently know the contents of the first couple dozen ram to frame buffer dma/gpu primitives but have been unable to track down exactly where in RAM the data is coming from. Also, I know the exact sectors that contain the files in question and when they are being read but I can not figure out where the data is going to. I discovered all of this be creating a epxse logging combination plugin (it simply acts as a passthrough to real plugins) for the cdrom and gpu. The plugin is limited though because I only receive a pointer to the emulator application memory space, not the emulated RAM memory space. Once I am able to track down either location (although both would be better to attack the problem from both sides) I can reverse the code to figure out how the files are parsed and used. Would it be possible to get a copy of the debug version of the program or at least one that has logging enabled? I do not care about speed or performance (I never "play" games on emulators anyway) just the ability to easily look under the hood.
Also, I have two minor additional questions. First, when I set a breakpoint, how do I test memory conditions? I tried read_long(0xXXXXXXXX)==0xXXXXXXXX but this did not seem to work. Is my syntax wrong and are there other similar functions like read_byte and read_short? Lastly, is there anyway to jump to a memory address in the memory display or jump to the PC in the disassembly window. This is minor but it does take a while to always need to hold down page up and page down.
Thank you again for such a powerful development platform.
|
|
|
Post by pSX Author on Mar 20, 2006 20:14:00 GMT -5
I am presently trying to understand the compression/encryption methods used on some game files in Lunar Silver Star Complete. I would like to use the logging feature to track (and save to a file for later examination) cd data reads and sync them up with CPU instructions and DMA transfers. I presently know the contents of the first couple dozen ram to frame buffer dma/gpu primitives but have been unable to track down exactly where in RAM the data is coming from. Also, I know the exact sectors that contain the files in question and when they are being read but I can not figure out where the data is going to. I discovered all of this be creating a epxse logging combination plugin (it simply acts as a passthrough to real plugins) for the cdrom and gpu. The plugin is limited though because I only receive a pointer to the emulator application memory space, not the emulated RAM memory space. Once I am able to track down either location (although both would be better to attack the problem from both sides) I can reverse the code to figure out how the files are parsed and used. Would it be possible to get a copy of the debug version of the program or at least one that has logging enabled? I do not care about speed or performance (I never "play" games on emulators anyway) just the ability to easily look under the hood. Send me an email and I'll sort you out with a debug version... Also, I have two minor additional questions. First, when I set a breakpoint, how do I test memory conditions? I tried read_long(0xXXXXXXXX)==0xXXXXXXXX but this did not seem to work. Is my syntax wrong and are there other similar functions like read_byte and read_short? This is correct (assuming you are putting that in the condition part). What sort of breakpoint are you setting? The condition is "executed" when the breakpoint triggers - if the condition is false the breakpoint does not break, if its true it does. Yes - there is: read_long, read_word, read_byte (also write_long, write_word, write_byte - they are mainly only useful in combination with the ',' operator which works as in C [ie. you can join mulitple expressions, only the result of the last one is used to determne whether or not to break]). Lastly, is there anyway to jump to a memory address in the memory display or jump to the PC in the disassembly window. This is minor but it does take a while to always need to hold down page up and page down. Thank you again for such a powerful development platform. Press CTRL+G to go to a memory address in the memory and disassembly windows (enter a number in 0xXXXXXXXX format). In the disassembly window press TAB to go to the PC.
|
|