Cycle Counting Using Emulators?

[Ze_ro]

While I was working on a project of mine, I came up with a neat idea that I think would be very useful: A graphical tool that showed (in real time) how many cycles a 2600 program was using on each scanline. I made a mock-up screenshot of what this might look like.

 

By looking at the graph, you'd be able to see how many cycles you had left on each scanline, or where you might need to optimize your code more.

 

I don't know a lot about emulator programming, but it seems to me that it wouldn't be too hard to work this into an existing emulator as an optional window or something. I think it would be very useful for homebrew authors... and it might also prove interesting to see how tightly coded some commercial games are.

 

What do you guys think?

 

--Zero

[Thomas Jentzsch]

What do you guys think?

Any working tool might be helpful for someone.

 

But I don't think, I'll need it. I am calculating the kernel myself and outside the kernel, there are hardly any WSYNCs (except for repositioning), so 100% of the CPU time is almost always utilized there.

 

IMO more useful would be sampling the *exact* free cycles outside the kernel by counting the INTIM loops (average, minimum, maximum, VBlank and Overscan).

[Heaven/TQA]

but this "profiler" would be nice to have for atari800win...

 

as i am not good in maths to count cycles... i need to have a graph...

[Blackbird]

I'd like a feature that disables the rendering of Sprites, Playfield, Missiles or Ball sprites, just to see how it's done, or where something's going wrong...

[Thomas Jentzsch]

I'd like a feature that disables the rendering of Sprites, Playfield, Missiles or Ball sprites, just to see how it's done, or where something's going wrong...

That's a feature you should ask the emulator developers for.

[Jacob Rose]

I had this very picture in my head earlier today. I think it *would* be a useful tool; it'd show you if you'd miscalculated somewhere, or on which lines you had extra cycles to spare. Although it couldn't really show you where your CPU overran the scanline, you could look for really short lines (assuming you were using WSYNCs), and it should be able to tell you (say, by drawing that line in a different color) when an instruction was still executing at the end of a line, which you could judge whether you were happy about. Of course, you'd want to have the game screen visible at the same time if you intended to analyze anything other than your game just sitting idle, which would make it a more complicated fix...

[Paul Slocum]

Those are awesome ideas. And they seem like they'd be easy to implement.

 

I tend to use a little more trial and error than Thomas, so something like that would be really useful to me.

 

-paul

[atwwong]

Before this utility gets created (terrific idea, BTW!), are there links that could help out newbies like me to figure out cycle problems when adding simple code to a hack? I'm not knowledgeable enough yet to do my own programming, so I thought I'd start out with hacking first (i.e., Adventure - I know the source code is commented; I'm trying to figure out how to get rid of screen jitters after adding code).