Debugging question - is there a way to count cycles in a subroutine or loop?

[+Propane13]

Hi folks,

 

I've got one more head-scratcher that I figured I'd ask about.  I am pretty sure that some of my code is subject to being "too slow".  This means that calculations are still ongoing, but then MARIA has no choice but to interrupt and draws what it can before handing the process back to finish calculations.  I'm curious to learn just how "over the limit" I am in some areas, since that could help me determine which subroutines are worth aggressive pruning.

 

So, the questions I have are:

 

1) Is there a way I can track how many cycles it takes to go from MainLoop back to MainLoop (or from a subroutine to its RTS call)?

 

2) Is the number of available cycles known before MARIA interrupts things?  I'm guessing it's different on PAL vs. NTSC, but that'd be a good number for me to learn/know.

 

3) Is there any magic with dasm where it spits out certain labels as addresses, so as to help with debugging?  (e.g. "mainLoop after compile is $D328")

 

Thanks!

[RevEng]

#1 - Nothing automated right now. You can do it a bit coarsely by checking and setting the RIOT timer at the top of your mainloop. You'll need some kind of way to get the values on to the screen, and then just multiply by the riot timer cycle size used.

#2 - You can get the theoretical max cycles (without dma) by having a look at the frame timing diagram and multiplying the total number of lines by 113.5 cycles/line. So for NTSC it's 29850.5 and PAL it's 33255.5 cycles. But you need to account for Maria's DMA, and that is highly variable depending on the game display. As a ballpark estimate I usually just go with 10000 cycles, unless I know a particular game design is going to be extra heavy or light.

#3 - you can get a list of all symbols by using "-sfilename.symbol.txt" in your arguments. You might also find it convenient to see the dasm list file, which shows the addresses and opcodes that assembly produced, by using "-lfilename.list.txt"

 

You may care to give the 7800heat profiler a try. You run the game in the a7800/mame debug mode, and play a bit while tracing all of the executed 6502 instructions to a file. Then you run 7800heat against the trace file, and it will create a "heatmap" html report that indicates which bits of code were run the most. There's a sample heat report in this thread.

 

This sort of profiling has it's limitations - the report is based on instructions, and not loops or subroutines - but I've found it quite useful before, and @PacManPlus has been known to give it a run every now and then too.

 

For subroutine based profiling, I like to use the background colour. Set the background color uniquely at the beginning of a subroutine you're trying to measure, and then set the background color to black at the end. If the routine runs during the visible screen (hopefully most routines will do so, except for DL manipulation stuff) you can see what percentage of the visible screen cycles are being used by your subroutine just by looking at how much of the screen is taken up by the color strip.

[PacManPlus]

I can vouch for '7800heat' - it has helped me in quite a few instances where I needed to see how much time a set of commands took.

[+Propane13]

These are interesting options; I'm definitely going to have to ponder a bit more.  Thanks for providing them!

 

I can see how the heatmap output could be really useful.

 

One follow-up-- I can successfully generate the symbols and list file now, which are both great!  Somehow, I was never doing that before.  Can the symbol file perchance be piped into a7800's debugger?  Or is it still up to me to do the breakpoint translation (guessing the latter, but never hurts to ask).

 

[RevEng]

You're welcome!

 

It never hurts to ask, indeed. Unfortunately it's up to you to do the translation.