atari2600land's Blog

Using pfclear wastes cycles anyway. It would probably be better to do something like this:

---

 

   if z <> 88 then goto __Skip_PF_Clear

   asm
   LDA #0
   STA var0
   STA var1
   STA var2
   STA var3
   STA var4
   STA var5
   STA var6
   STA var7
   STA var8
   STA var9
   STA var10
   STA var11
   STA var12
   STA var13
   STA var14
   STA var15
   STA var16
   STA var17
   STA var18
   STA var19
   STA var20
   STA var21
   STA var22
   STA var23
   STA var24
   STA var25
   STA var26
   STA var27
   STA var28
   STA var29
   STA var30
   STA var31
   STA var32
   STA var33
   STA var34
   STA var35
   STA var36
   STA var37
   STA var38
   STA var39
   STA var40
   STA var41
   STA var42
   STA var43
   STA var44
   STA var45
   STA var46
   STA var47
end

__Skip_PF_Clear

But that code is enormous! How could that possibly be better? I'll try it.

How is pfclear otherwise implemented, as a loop using either X or Y regs? Generally unrolled loops (like above) are faster than traditional loops, though as noted they take more ROM space.

As for debugging and troubleshooting, I use what some call "Zen Debugging": a more intuitive approach, analysing the problem and building assumptions on it, rather than focusing on a direct solution.

 

Check out this article and see if it aids in your approach. A few salient points to consider:

• Right off the bat, start with the assumption that the problem is in your own code. Accept that or risk looking for the problem in the wrong place.
• Assume that you can solve the problem. That the fact that you haven't yet, is merely temporary. You will find the solution.
• Relax, look away, go for a walk, think, meditate, and stop staring at the code. Do not stress about the problem.
• Focus on the problem, not the solution. Try to understand and recognize the conditions which could lead to the behaviour you are observing.

 

To me, that last one is the key. Rather than trying to jump to solutions, patching the code here and there to see if the problem is fixed, concentrate on the problem itself. Try to understand the behaviour that you see, and what could cause it.

 

In my own experience, this is the hardest thing to do, but the most conducive to a proper solution: Once I recognize what I see, I make assumptions of how it could happen. It doesn't matter how silly or stupid or improbably it is, the fact you are experiencing that faulty behaviour means that your code is doing something silly or stupid or improbable.

 

Once you understand which conditions could cause that behaviour, then trace it backwards from the observed behaviour to its cause.

 

For instance, I once had a problem which caused a sprite to move in an erratic way. I couldn't find what was causing it, there was nothing in the code that could move it that way. NOTHING, and it was driving me crazy. I then thought of that behaviour and considered what could cause it: it looked EXACTLY as if I were updating the position register of the sprite with random values.

 

So I accepted that assumption: something, somewhere is updating the position register -- but what and how? I put a watch on the register and indeed saw it being updated with random values. But there was no code that did so!

 

I made a mental list that could explain the behaviour and went through it one by one:

• My code updated the register -- Nope.
• My code updated the buffer that gets copied into the register -- Nope.
• I used the wrong variable or address when updating something else -- Nope.
• The register is updated by itself -- ???
• Something is corrupting that buffer in memory -- Possibly.

OK, so the last one seems the likely candidate. What could corrupt the buffer in memory? It turns out that the buffer was the very first variable allocated in RAM, right after the CPU stack!!! IT'S A STACK OVERFLOW!

 

That must be the answer. I could not trace it or directly observe when it happened in the debugger, but a race condition looked to be causing a stack overflow.

 

So my new assumption: the stack overflows and writes some strange value into the very first variable in RAM, which happens to be the position buffer of the sprite. Considering that none of the other values were corrupted it seemed the stack overflowed by a single address.

 

The solution was to find the race condition which caused the stack overflow and prevent it or work around it. That fixed the problem.

 

I could have put code to try to fix the problem till the cows came home and NEVER would have hit on the actual problem. Only by focusing on the behaviour and the problem rather than reactive solutions was the issue actually solved.

 

-dZ.