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

Subject: Re: [stella] behold, i am become shiva, destroyer of kernals!
From: KirkIsrael@xxxxxxxxxxxxx
Date: 12 Mar 2004 06:13:21 -0000
> >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).

Ah, msgs came out of order, I thought you were talking about 
the score fix.
> The use of the Y register there does seem to be extraneous and you could simplify the LSR/ASL sequence.

Hmmm... oh, yeah, since I was just right shifting so much 
to lose the extraneous bits, divide by 32 then multiply by 8,
I can just divide by 4, and AND out the 3 rightmost bits:


	and #%11111000

and works just the same.

> But that really neither here nor there...
> 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.
> Anyway...
> >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
> 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)?

Weirdness. What are we missing here?  Any of the (other) 6507/TIA 
gods around have any thoughts?

> >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.

Ugh, that's a new one :-(

> 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?

?? it registers a Playfield/Missile hit, then checks the position...

> 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...

I appreciate it.

Hmmm...the commented-on "fix" was painstakingly hand debugged
*before* Paul Slocum's great new kernal in there...I had to 
make a few other adjustmens, maybe things have shifted, so the 
previous adjustments (esp where the ball was between two blocks)
might not work...previously i debugged it by formatting the bricks
in an every-other brick pattern, then sending the ball in at a 
flat trajectory, and trying different values of the ball vertical
position.  In some ways I'm more nervous about the other less 
explicable memory and/or timing glitches...


"I want to do to you what the spring does to cherry trees."
"I want to do to *you* what you do to chinese food." --tufts.general

Archives (includes files) at
Unsub & more at

Current Thread