Debugging Options/Features

Discussion in 'no$psx Discussion' started by abystus, Mar 31, 2014.

  1. abystus

    abystus New Member

    Messages:
    6
    Likes Received:
    4
    I would love to see trace to file and trace to screen options in all your emulators (they seem to share a common layout). I'd say trace to window could display that last 2000 or so instructions executed before a breakpoint, and the file could support everything until the breakpoint. What I would like to see in such a file is below:

    Code:
    Address  Bytes  Instruction Literal  (optional register values)
    Also; if possible, could you have it classify loop executions into single entries with a numeric representation of the execution count above (see MESS trace logs)? You have a very rich debugger outside of these missing features (this is in my opinion one of the basic features a debugger should contain), and they are sorely missed at the moment by hacking communities (especially for NDS).

    The last feature would be a way to search the memory in most if not all your emulators. Currently we have to attach an external application that will resolve memory addresses within your emulator for cheat use, or use another emulator entirely (which results in the loss of the debugger). It would be nice to have such basic features built into a future release if you have time to implement it. Keep up the great work!
    Last edited: Mar 31, 2014
    47iscool and Demonic722 like this.
  2. NGEmu.com Advertisement

  3. nocash

    nocash Emu author Emu Author

    Messages:
    216
    Likes Received:
    81
    Worked on tracelog feature for no$sns last week. It's optionally logging main CPU or sound CPU address/opcode/registers to the "TTY" debug message window. It isn't yet released, but if it turns out to be useful, I'll probably add it to other emus, too.

    I've been quite afraid of the huge amounts of data, even the 3.58 MHz SNES can spit out around 80Mbytes of log data per second. But I've more or less solved it by allowing to select a 1MB/10MB/100MB buffer limit, optionally either stopping logging, or overwriting old data when reaching that limit. And, on the SNES at least, it might be even fast enough to keep the emulation run at full speed (on modern PCs that are 3-4 faster than my old Pentium 3).

    For the PSX, showing all cpu registers won't work out, but it should be very easy to extract the used register numbers from the MIPS opcodes, so the tracelog could automatically show the relevant/used registers for each opcode. I haven't seen MESS trace logs - how does that loop execution stuff look like, can post an example? It sounds like a nice idea (although probably more difficult to implement).

    Yes, I should add better memory search functions, too.
    Demonic722 and abystus like this.
  4. abystus

    abystus New Member

    Messages:
    6
    Likes Received:
    4
    Very nice to see you working on some sort of trace log implementation (hopefully you choose to implement a "to window" as an option as well). As far as MESS/MAME are concerned, their logs show loops as follows:

    Code:
    ...
    8802C6B8: andi  $t5,$t5,$0421
    8802C6BC: addu  $t3,$t3,$t4
    8802C6C0: or    $t3,$t3,$t5
    8802C6C4: bne    $v0,$t2,$8802c698
    8802C6C8: sh    $t3,$27e($v0)
    
      (loops for 4134 instructions)
    
    8802C6CC: addiu  $a1,$a1,-$1
    8802C6D0: bne    $a1,$0,$8802c690
    8802C6D4: addu  $v0,$v0,$a3
    8802C690: sll    $a2,$a0,2
    8802C694: addu  $t2,$v0,$a2
    
      (loops for 4160 instructions)
    
    8802C6CC: addiu  $a1,$a1,-$1
    8802C6D0: bne    $a1,$0,$8802c690
    8802C6D4: addu  $v0,$v0,$a3
    
      (loops for 487305 instructions)
    
    8802C6D8: addu  $t2,$v0,$a2
    8802C6DC: lh    $t3,$0($v0)
    8802C6E0: addiu  $v0,$v0,$2
    8802C6E4: bne    $v0,$t2,$8802c6dc
    8802C6E8: sh    $t3,$27e($v0)
    8802C6DC: lh    $t3,$0($v0)
    8802C6E0: addiu  $v0,$v0,$2
    8802C6E4: bne    $v0,$t2,$8802c6dc
    8802C6E8: sh    $t3,$27e($v0)
    
      (loops for 1272 instructions)
    
    8802C6EC: jr    $ra
    8802C6F0: nop
    88026C88: jal    $8802b18c
    88026C8C: nop
    8802B18C: addiu  $sp,$sp,-$8
    8802B190: lui    $gp,$8810
    8802B194: sw    $ra,$0($sp)
    ...
    I'm sure the source is freely available for how they are doing that since both are open source type projects. Do note that MESS/MAME unfortunately do not show the bytes that make up the instruction in any system they log, though I do hope you plan to include it within your implementation.

    Aside from the trace log, you say that you want to implement a "better" memory search functionality, though I have yet to find anything of the sort implemented previously in your debug enabled releases. Am I missing something? Thanks for the reply.
    Last edited: Apr 1, 2014
  5. Demonic722

    Demonic722 New Member

    Messages:
    5
    Likes Received:
    6
    I agree with Abystus on the trace log and memory search implementation. Coming from an avid NO$GBA user, it's sometimes a pain to manually trace the code and I tend to go back and forth between emulators (Desmume for searching and testing Action Replay Codes, NO$GBA Debugger for debugging) or attach an external application (Emucheat, Renegade, etc.) to search the memory for NO$GBA.

    The standalone emulator (NO$GBA, not the Debugger), has a great cheat engine; it's just lacking in the Debugger. Also, we have to use an external application (eNDryptS Advanced) to encrypt newly released games, then run the game in GBA BIOS mode for it to work in NO$GBA.

    I would appreciate it if you can implement these features.
    47iscool and abystus like this.
  6. nocash

    nocash Emu author Emu Author

    Messages:
    216
    Likes Received:
    81
    abystus, please explain that tracelog! I don't understand that loop feature at all! Those "(loops for nnnn instructions)" lines seem to be placed just at random locations!?
    Sometimes they are placed after branch-delays which makes sense, but sometimes they show up elsewhere (namely after 8802C694, but there seem to be a lot opcodes missing between 8802C694 and 8802C6CC, so maybe the confusion is just caused by that missing opcodes).

    Showing the opcodes as hex numbers isn't planned, what would that be good for? I think it would be mainly wasting memory, and tracelogs are huge enough anyways. Showing register values would make more sense to me (but that might be problematic for that loop feature, since registers are changing in each loop cycle).

    Searching works more or less in the CODE window, and very crappy in DATA window. In CODE window: It's doing a string comparision on your input vs disassembled code (downside is that it's insisting on exactly same space padding between opcode and operands) (on the upside: you also search for snippets like "NNNN" instead of "jmp NNNN" or "call NNNN"). The DATA window is working the same way: It's "disassembling" a 16-byte line, and then comparing it to your input, which is total crap since it can't find bytes/text that crosses 16-byte boundaries. Aside from that issue, there is no "cheat-search" feature for doing things like "search all bytes that have incremented since last time".

    A bit offtopic: I am not aware of any encryption issues in current no$gba version, and the cheat feature is implemented in no$gba debug version for quite a while, too.
  7. Demonic722

    Demonic722 New Member

    Messages:
    5
    Likes Received:
    6
    Yeah, sorry for going a little off topic, but where is it located? I've never seen the cheat feature in the debug version of NO$GBA. It isn't under "Utility" like it is in the non-debugger version.

    Edit: I forgot to mention that a save/load state feature for all NO$ emulators would be nice as well.

    nocashemu.png nocashdebug.png
    Last edited: Apr 2, 2014
  8. abystus

    abystus New Member

    Messages:
    6
    Likes Received:
    4
    I see what your saying about their trace log in how it seems to randomly skip around and doesn't continue logging at the correct address sometimes after a loop occurs. I've noticed that issue before, though I usually step through the code in the debugger while reviewing the log so everything in my view is correct, even if it doesn't align perfectly with the log (it eventually syncs up). It may be a bug on their end concerning logging, though I'm sure you get the overall picture of what is to be done with repeating code such as loops (definitely reduces the overall size of the trace log in question).

    As far as the bytes being displayed for the instruction, not all systems have a fixed arrangement of bytes (aligned) for all instructions such as NES, SNES, Genesis, etc..., so it is nice to see what byte variation (byte length varies between modes on common instructions that would log the same way) is used to make a specific modification to the instruction in question. I'd assume you could make this an optional feature due to it not really being as useful for systems that have a aligned byte length representation of their instructions (PSX, GBA, NDS, etc...).

    Having registers present within the code instead of listed to the side as in my example in the first post is fine, and will be quite useful to see the state of the system while moving through the log. However you choose to implement this is up to your better judgement, though if you could make it optional that would be great.
    Last edited: Apr 2, 2014
  9. Azary1977

    Azary1977 Member

    Messages:
    509
    Likes Received:
    34
    I hope all Nocash programs (Gameboy, GBA, DS, PSX etc...) will have search memory (or search the codes) features just likes other emulator soon. Normally, finding the codes was using external programs likes EmuHaste, Cheat Engine etc... :)
  10. abystus

    abystus New Member

    Messages:
    6
    Likes Received:
    4
    Any update on the status of the "Trace Logging" feature you were attempting to implement when we last spoke? Also, going off-topic, I have another idea that you may or may not have already attempted to implement previously. The idea is a "Dissect Data Structure" type option similar to Cheat Engine where you could input several structure base addresses, and compare the similarities and differences between two or more (can add new groups at runtime) similar structures by offset (color coded). Pointers located at certain offsets would become their own structure breakdown (again by offset), and could be expanded in a further comparison between all structures present. The value of these offset locations can also be manually updated on the fly through this screen. A picture of this feature can be found below (Google image result):

    [​IMG]

    Such a tool would be useful for easily breaking down shared routines that are common among games that interface with similar object types (Player/Enemies), and allow hackers to easily target or exclude specific objects within their hacks by value of object offsets passing through said shared routine. Do you think this is something you may be able to implement in the future?
    Last edited: Dec 31, 2014
  11. nocash

    nocash Emu author Emu Author

    Messages:
    216
    Likes Received:
    81
    Yes, it should be included in no$psx v1.9 (since May 2014), as part of the "TTY Window", supporting both the MIPS cpu, and the HC05 cpu (as selected in the window's "Enable" option). It's just logging all opcodes, without trying to resolve loops or such trickery.
  12. abystus

    abystus New Member

    Messages:
    6
    Likes Received:
    4
    Very nice. Do you think you could add a way to dump the contents of the log to a file (apparently you have to copy/paste it to a file at the moment)? Also, do you plan on adding this functionality (trace log) to some of your other emulators such as no$gba? Thanks for the implemented changes, and I hope to see more of these advanced tools integrated into your emulators in the near future.

Share This Page