Re: [stella] Timing blues...

Subject: Re: [stella] Timing blues...
From: "Eckhard Stolberg" <Eckhard_Stolberg@xxxxxx>
Date: Tue, 31 Jul 2001 15:49:18 +0200
>   I'm struggling through the disassembled Kool-Aide Man code to try and
> figure out what about the code is unique and causes the mentioned
> on PAL systems, but am getting nowhere.  I think my understanding of
> to registers timing and cycle counting is too weak to tackle this.  Can
> anyone help?  Also, when exactly does this collision glitch occur during
> game?  Is it on the initial moving playfield wall thing where Kool Aide
> blows through the wall and exits stage right or is it on the next screen
> which is the actual game screen?  I need to know so that I know which
> section of code I should be studying?  Could someone with a PAL system and
> copy of Kool-Aide Man start it up and tell me when exactly the glitch
> during the game?  Also, does anyone out there have a SECAM system?  Again,
> let me know.  Thanks.

The problem occurs in the main game screen, so you already found
the right code. It positions the player graphics for the score display.
On a PAL VCS some numbers of the score will partly overlap with some
other numbers of the score. Therefore the game will see a constant
collision and make Kool Aide Man bounce uncontrolable around the screen.
You can see this effect in PCAE and Stella, even though the real
positions on PAL are different.

The key here is the HMOVE command. As you know this command will
apply the fine movement values to the position of all objects.
But it takes quite a while to finish. Therefore the programmers
guide tells us not to access the position registers within 24
cycles after a HMOVE.

For z26 we tried to figure out what happens when you change one
position register within this time and got the same predictable
results on PAL and NTSC. But as you saw yourself, Kool Aide Man
accesses at least two position registers within 24 cycles after
the HMOVE. This is what I think causes the problem.

The resulting positions seem to depend on what was in the fine
movement registers before the HMOVE, so you should set the VCS
into the same state as KAM before the scanline in question. Then
copy the problematical scanline, and you should get the same
strange positioning results on PAL systems.

Ciao, Eckhard Stolberg

Archives (includes files) at
Unsub & more at

Current Thread