WSYNC?

[+grafixbmp]

Have a question that has been nagging me for a few days. Is it always necessary during kernel code to WSYNC every scanline? And also to do so just like the stella guide say to especialy have one before an HMOVE? Given that the code could be timed so that the HMOVE would fall exacly at the first cycle of a new scanline without a WSYNC. This omition alone can save a few cycles for more precious code.

[cd-w]

Have a question that has been nagging me for a few days. Is it always necessary during kernel code to WSYNC every scanline? And also to do so just like the stella guide say to especialy have one before an HMOVE? Given that the code could be timed so that the HMOVE would fall exacly at the first cycle of a new scanline without a WSYNC. This omition alone can save a few cycles for more precious code.

 

It is indeed possible to omit the WSYNC, provided that you count 76 cycles for each scanline. A lot of home-brew games use this technique to free up kernel cycles. The HMOVE can also finish on any cycle between 74 and 4 (on the next line). If you finish the HMOVE on exactly cycle 74 then the black bar won't be shown, although all the sprites will be shifted 8 pixels to the left.

 

Chris

Edited September 4, 2009 by cd-w

[SeaGtGruff]

Have a question that has been nagging me for a few days. Is it always necessary during kernel code to WSYNC every scanline? And also to do so just like the stella guide say to especialy have one before an HMOVE? Given that the code could be timed so that the HMOVE would fall exacly at the first cycle of a new scanline without a WSYNC. This omition alone can save a few cycles for more precious code.

You do not need to do a WSYNC if your code is carefully timed. The main reason for doing a WSYNC would be to keep the timing properly aligned for each scan line, because timing can fluctuate due to branches taken or not taken, subroutines called or not called, whether or not a given instruction crosses a page boundary, etc. Also, you may have a lot of free cycles on a scan line but there's nothing else you need to do on that scan line, so doing a WSYNC would be like typing on an old-fashioned typewriter and hitting RETURN to do a carriage return and line feed so you can begin a new line, whether or not the line you just typed went all the way across the paper or only part of the way across. In fact, that's how I like to think of WSYNC-- as a sort of video CR-LF (even though the scanning beams keep scanning like normal, and it's the CPU that is affected). Anyway, it is not at all uncommon for 2600 programmers to get rid of a WSYNC if they can keep their code precisely timed just right. In fact, sometimes you have to remove a WSYNC so you can squeeze in one more instruction!

 

Michael

[+grafixbmp]

That's about what I figured. I just wanted cold hard confirmation before I wasted time confirming this for myself.

[e1will]

In fact, sometimes you have to remove a WSYNC so you can squeeze in one more instruction!

 

Michael

 

Yep, the main kernel in the game I'm working on takes exactly 228 cycles, and the WSYNC was the first thing that got dropped once I started needing to squeeze more code into it.

 

Granted, you have to be much more careful about branches that cross page boundaries (and branches in general, since they have to "meet up" in both the same point in code AND the same elapsed cycles without WSYNC) and any indexed data (without a WSYNC you'll usually be able to tell really quickly if something's unexpectedly crossing a page boundary since the screen will be completely out of whack from that line down, especially if you use HMOVEs.)

 

But it definitely can be done.

 

--Will