> >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:
lsr
tax
lsr
lsr
lsr
lsr
asl
asl
asl
becomes
lsr
tax
lsr
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...
Thanks!
--
KirkIsrael@xxxxxxxxxxxxx http://kisrael.com
"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 http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
