Tracer ideas - NESdev BBS

Tracer ideas
by Disch on 2012-07-01 (#96336)

I'm starting to get serious about the debugging features in my emu so that I can.... well.... debug my emu. Focusing on the tracer right now. I find that when scouring trace logs, I often want to log things other than just the instructions that are executing.

So I came up with an idea to have a user-configurable formatting string that the trace logger uses.

The idea would go something like this...

Example format string:

Code:

{c.pc}: <{trace}> {c.a} {c.x} {c.y} [{c.flags}] {c.sp} - {p.line}:{p.dot}

Example output:

Code:

F95B: <91 00       STA  ($00),Y  [0138=FF]>  00 01 38  [...I..]  FD - 123:210

The gimmick is, with custom tags like that, I could easily add them for all sorts of stuff, like RAM locations, ppu/apu/mapper registers, etc. It would be super useful for me. Would probably be useful for hackers/homebrewers too.

Do any emus out there already do something like this?

by zzo38 on 2012-07-01 (#96339)

Perhaps some function that if you push a certain key it makes a mark in the debug log (including conents of any RAM addresses which have been configured to be recorded when this is selected), may sometimes be useful.

I do not know if other emulator has such functions.

by rainwarrior on 2012-07-02 (#96340)

Yeah, customizable trace output would be pretty awesome actually. I've never seen it done, but I've definitely wanted it before (and have sometimes hacked in a custom output for a temporary purpose).

If you wanted to get really fancy you could allow some calculation and conditional output, something like {(c.a<(c.x+30))?{A}:{B}} but even just the ability to customize a static output line is great.

Re: Tracer ideas
by cpow on 2012-07-02 (#96344)

Disch wrote:
Do any emus out there already do something like this?

This is sort of where I was headed with my Tracer, which uses a spreadsheet-like table view as its UI. Idea: click on the header bar to add/remove columns for whatever you want to see in the log. It's not as real-time-malleable as your idea. Given that my emu already sucks performance-wise, I haven't been too excited about adding anything else that would require processing. But then again, the processing for the UI is done only when the UI needs updating, and even then only on the elements currently visible...so it may not be that bad.

BTW I'm also realizing the cons of my spreadsheet-like approach when it comes to searchability. That would be solved by providing either the table view or a "raw text" view, I suppose.

by Disch on 2012-07-02 (#96348)

zzo38:
can you elaborate? It seems like it would be difficult to press a key at the exact right time when a emu is running. If you had to do something like that, it seems like a more interactive approach (breakpoints) would be more suitable? But maybe I'm misunderstanding.

rainwarrior:

That conditional bit is very interesting, but would add a whole new level of complexity. I'll keep it in mind, but it probably won't go in for a while (if ever).

It did give me another idea though -- about indirection. If you wanted to read from a pointer. Something like {m.01}{m.00}={*m.00}. But that also seems like it'd be more complicated.

Not for round 1 anyway. I'll stick with original basic idea for now and will work in that stuff later if there's need. Very, very interesting though!

cpow:

I don't particularly care about performance when tracing, as tracing already completely destroys performance.

The main benefit I see from a spreadsheet is the ability to sort by columns.. but in a tracelog that isn't very useful because you'd always want it to be listed chronologically.

Anyway I'll definitely work on this tracer stuff this week. Thanks for the feedback everyone.

by zzo38 on 2012-07-02 (#96359)

Disch wrote:
zzo38:
can you elaborate? It seems like it would be difficult to press a key at the exact right time when a emu is running. If you had to do something like that, it seems like a more interactive approach (breakpoints) would be more suitable? But maybe I'm misunderstanding.
Breakpoints would certainly be useful. The way I suggested might or might not be useful in all cases, although cases in which it would be used are either those where it is already paused, or where a RAM value is going to keep the same value until you do something later in the game at which you record it again and you keep track of the change in a spreadsheet or a graph or something like that (if you output CSV or TSV you can do this easily).

Another approach is to use MIDI (it is one of the things Famicom-MIDI is designed to be used with). Channel 10 (which is currently undefined) could be used for CPU status. You could then use a MIDI sequencer or processor (including Pure Data) and/or MIDI Yoke in order to manipulate this data and play it back to the emulator, in order to test the program with the same input if you use channels 0-3, or to use channel 8-9 to test other things that would be store in RAM, video, audio.

by cpow on 2012-07-02 (#96362)

Disch wrote:
I don't particularly care about performance when tracing, as tracing already completely destroys performance.

Then I don't feel so bad for adding a "debugging" button to my toolbar that toggles various intensive debuggers.

Performance is much better without them. But there's always that power user that wants full-on crisp audio while debugging (:roll: tepples) on his netbook.