10 replies to this topic

[Ze_ro]

I've noticed that a lot of people seem to use the timers to wait out the vertical blank, do whatever processing they need to do, and then watch INTIM until the time is up... I was going to do this myself, since I've been having some issues with overrunning a scanline during some of my calculations causing things to occaisionally shift by a single line... but what happens if you do a "sta WSYNC" (ie, to do an HMOVE, or time your sprite positioning) in the middle of this wait? The timer isn't in the 6507, so I'm guessing that while it's halted, the timer still behaves normally... is this correct?

Even assuming that the timer behaves as expected, I'm guessing you still have to be careful, since this will still lead to some wasted cycles (Up to 79 or so) depending on where the beam is when you happen to perform the sta WSYNC (which may change if you insert some code before it)...

--Zero

[johnnywc]

My guess is that the timer still works as expected even when you do a STA WSYNC, meaning that the timer will still count down even when the mircoprocessor is halted.

As for doing STA WSYNC's during the vblank - I believe this is common. It's done most often when reseting the horizontal position of sprites (RESP0, RESP1, etc). The calculation for this is generally done after a STA WSYNC and a certain delay so that you can calculate exactly where on the scanline the beam is.

You are correct - it does waste machine cycles but sometimes it's unavoidable. Of course, you can place your STA WSYNC's as close to the end of the previous scanline to reduce the amount of wasted cycles.

Hope this helps!!!

[Ze_ro]

Damn, I wish I had more time on my hands... once I get this worked into my program, it'll be quite literally done... Oh well, it'll have to wait until this weekend. Thanks for the advice!

--Zero

[EricBall]

STx WSYNC causes the TIA to hold the 6507 RDY active until the "start" of the next line. This causes the 6507 to halt processing. The timer is part of the RIOT chip (so named because it contains RAM, I/O and a Timer).

In my 2600 programs I often include a STA WSYNC in my INTIM test loop simply to make the Z26.log smaller! Just be careful that you calculate the TIM64T value correctly or INTIM will start counting the number of cycles since the timer expired!

[Cybergoth]

Hi there!

Ze_ro said:

since I've been having some issues with overrunning a scanline during some of my calculations causing things to occaisionally shift by a single line...

If you have no clue what causes the extra scanline, compare the Z26 log of a "good" frame with a "bad" frame.

If it appears to just "shiver" between 261/2 for example, try increasing either the VBLANK or the Overscan timer. Or if it's 262/3 try decreasing them. Just toy a bit with these values.

Reason: If the timer value is choosen "bad" so that the timer will end near the end of a scannline, you might just hit one of the two by random, since you have a 5 cycle wide "blind spot" in the timer checking loop.

Greetings,
Manuel

[Ze_ro]

Cybergoth said:

If it appears to just "shiver" between 261/2 for example, try increasing either the VBLANK or the Overscan timer. Or if it's 262/3 try decreasing them. Just toy a bit with these values.

Well, the way I have it working right now is that I initially had a loop that would just sta WSYNC 37 times... as I needed more processing done, I'd just decrease that, and use the extra scanline to do a specific task in. It always seemed like an ugly way to do things, but it worked.

Unfortunately, after adding a few things, I get a "shiver" between 262/263 every once in a while, and I can't for the life of me figure out what's causing it. My joystick handling routines seem quite long, but the shiver is happening even when the program isn't going through the joystick routines!

--Zero

[Cybergoth]

Hi there!

In this case: Switch to the timer. No other solution.

Greetings,
Manuel

[Thomas Jentzsch]

Cybergoth said:

In this case: Switch to the timer. No other solution.

And the better solution too.

[Ze_ro]

Aha, switched everything to the timer, and it now works perfectly. Now all I have left to do is test the game on a real system using my Supercharger...

--Zero

[johnnywc]

Ze_ro - what game are we talking about anyway?

[Ze_ro]

It's a Simon clone... I just announced it over in this thread if you're interested in trying it. It's not much, but it's my first attempt at anything at all really.

Wow, I ran into a bunch of weird problems when I went to run this through my Supercharger... for one thing, the sound had a whole host of issues (mostly due to fact that I was actually fiddling with the AUDxx registers in two seperate places, which could occaisionally lead to having two sounds happen in the same scanline. Stella only ended up playing the second one, but the actual Atari handled it a bit different. I also found a spot where I was doing an 'lda $0F' instead of 'lda #$0F' (which was then stored into COLUP0)... Strangely enough, every single time I ran my program with Stella, loading a value out of $0F always ended up giving me white, which was what I wanted... the Atari gave me different stuff entirely. The colors needed some tweaking too... getting good greens and yellows isn't easy.

--Zero