I have no idea how much code I can put into vblank without causing trouble. Are there any rules of thumb or guidelines that would give me an idea?
shawnleblanc wrote:
I have no idea how much code I can put into vblank without causing trouble. Are there any rules of thumb or guidelines that would give me an idea?
About 2273 CPU cycles. Depending on your instruction mix that's either a chunk of code (1136 2-cycle opcodes) or a little bit of code (324 7-cycle opcodes). So, I guess that isn't very helpful. You'll be somewhere between 324 and 1136, roughly.
262 total scanlines, 240 are visible.
1 scanline is the pre-vblank scanline and you can't use it unless you have IRQs or other timed code to know when that scanline is coming.
1 scanline is the pre-render scanline, you can use it as extra vblank time if you turn off the screen, then do a complete set of scroll writes after turning the screen back on.
If you just use the normal vblank lines, that's 21 scanlines at 341 PPU cycles (113.666 CPU cycles) each, for 2387 total CPU cycles. Of course, there's also the NMI interrupt triggering, and all your other code to get ready to start spitting out graphics, so there's less time than that actually available for your graphics display loop.
One thing I do is to set a breakpoint at the end of my VBlank routine in Nintendulator. It has this nice feature in e debugger that shows you what scan line and pixel you are on.
qbradq wrote:
One thing I do is to set a breakpoint at the end of my VBlank routine in Nintendulator. It has this nice feature in e debugger that shows you what scan line and pixel you are on.
I'd like to second this suggestion.
tokumaru wrote:
qbradq wrote:
One thing I do is to set a breakpoint at the end of my VBlank routine in Nintendulator. It has this nice feature in e debugger that shows you what scan line and pixel you are on.
I'd like to second this suggestion.
I'll put an alternative out there:
I set up the red execution marker in the nesyar source over its entire NMI routine, and the green marker over the jsr to the sound routine. The Execution Visualizer shows me where each marked code region is executing in the PPU frame and how many CPU cycles it took last time it ran. It's a bit hard to see in the image but the area to the right of the quotile shield is HBLANK (the red/green stretches into it. The image is 341x262 (or 341x312) pixels big, so you can see it covers the entire PPU clock domain and shows where the CPU is doing whatever you marked to see. I can add eight different marked regions and see where they are in relation to each other or how long they are taking. Plan is to add min/max/avg also to cycle counts. In the image, the top left (0,0) is the screen pixel (0,0), so VBLANK time is at the bottom (where it's all red). Obviously nesyar eats into the screen time a bit in NMI but only to do sound updates.
Yet another option is to use
NintendulatorDX with code like this:
Code:
nmi:
sta $4020 ; Start the timer.
; TODO: Do the vblank updates here.
sta $4030 ; Stop the timer.
rti
Then you can see the number of cycles taken by the vblank updates in the debugging window. As long as the "max" value is less than ~2270, you're in the good.
cpow wrote:
Plan is to add min/max/avg also to cycle counts.
With
sparklines?
Dang CPOW! That's awesome! Is that something you wrote? Where can I get it?
Aww cpow, reminding me of my Apple IIGS days where you'd change the system border colour to something of your choice at the start of your routine, then back to whatever it was previously at the end, effectively using the border as a way to tell how much CPU time something took. :-) So happy.
koitsu wrote:
Aww cpow, reminding me of my Apple IIGS days where you'd change the system border colour to something of your choice at the start of your routine, then back to whatever it was previously at the end, effectively using the border as a way to tell how much CPU time something took.
So happy.
You can do that on the NES with the $2001 register.
qbradq wrote:
Dang CPOW! That's awesome! Is that something you wrote? Where can I get it?
It's part of NESICIDE, which is something I wrote, yes.
tepples wrote:
cpow wrote:
Plan is to add min/max/avg also to cycle counts.
With
sparklines?
Funny you should mention that tepples! I attended Edward Tufte's "Information Design" seminar last year. As part of that I got signed copies of all four of his books and a poster. I am a strong believer in techniques for visualization of information. Sparklines are so obviously useful, concise, and unencumbered with need for prior knowledge of the visualization technique.
I could probably whip up a sparkline control in Qt pretty quick...so now that you've planted the idea, expect to see it.
qbradq wrote:
Dang CPOW! That's awesome! Is that something you wrote? Where can I get it?
It just struck me that you might have been referring to the game visual, not the tool. No, I did not write nesyar. That was authored by clueless. Haven't seen him around in a while though.
I was referring to the visualization. Can I run any ROM with timer writes in that or does it have to be a NESICIDE project?
qbradq wrote:
I was referring to the visualization. Can I run any ROM with timer writes in that or does it have to be a NESICIDE project?
You can run any ROM it doesn't have to be a NESICIDE project (the nesyar example shown is not a NESICIDE project). If you want to save the markers between runs you can just save the project from the ROM.
At the moment I don't have support for the in-code timers that Nintendulator uses (it's just using UI-marked regions of code, not actual code writing to NES "timers"). I'm going to add that though since it seems popular.
Cool! I'll have to fiddle with this some. I think it could really help my Zeldroidvania game