Re: [stella] behold, i am become shiva, destroyer of kernals!

Subject: Re: [stella] behold, i am become shiva, destroyer of kernals!
From: Christopher Tumber <christophertumber@xxxxxxxxxx>
Date: Fri, 12 Mar 2004 00:42:00 -0500
>The code you suggested just freezes on 1.

Yeh, that was the post I was saying to ignore - I misread the BMI operation which determines if that section of
code gets executed and thought it was only exceuted when the pterry counter is -1 (rather than vice versa).

The use of the Y register there does seem to be extraneous and you could simplify the LSR/ASL sequence.

But that really neither here nor there...

>with your analysis making it look like a bajillion CMPs were just giving errnoneous results.

Well, it really looked like it was one problem that was manifesting itself in a couple places - They looked like some kind of offset calculation problem or indexing problem.

But if it aint broke...

It really looked to me like you were supposed to be initialising some variable to 0 and instead were initialising it to point to some memory location that just happened to be 0 (or even some other value) until your code started to overlap that spot and cause a problem.

But I could be completely off base there.


>bad news: I musta been relying on something in the old memory clear,
>because now I have some extraneous crap under the main sprites in my
>title screen kernal.  This shows up on 2600 (supercharger) but not
>Z26 or PCAE

Uhh, looks okay on my Supercharger (??)

Hrm, actually, I didn't have the latest macro.h so I replaced CLEAN_START and it was fine.

But I just grabbed the latest macro.h and dropped it in and now I see your problem.

But it's not CLEAN_START, it's another code-size problem - If I remove the SEI and/or CLD from CLEAN_START the problem goes away. But, if they're replaced with NOP it comes back.

It looks like either your draw loop is running too long ot you're getting junk pushed into GRP0/GRP1 (VDELPn problem)?

>other bad news: sometimes walls aren't going away when they
>should. I have a hypothesis that it's when the ball is at a 
>steeper angle, but I do the wall removal math BEFORE updating
>the ball position, so I don't know what would be wrong with it.

I just played around with it a bit and the only problem I saw was when the ball it the lower right corner block, it removed the upper left corner block.

However your data structure for the right wall comes after the left wall so it can't just be a rounding type error (ie: Removing the next block below the correct one). So... Could it be testing the ball when it's already out of bounds?

No, wait there does seem to be a rounding problem where every once and a while it removes the block that one block away from where it should.

I'll poke around...


Archives (includes files) at
Unsub & more at

Current Thread