Re: RE: [stella] Climber5 source and binary

Subject: Re: RE: [stella] Climber5 source and binary
From: Dennis Debro <ddebro@xxxxxxxxxxxxx>
Date: Thu, 17 Apr 2003 11:06:09 -0400
Hi Thomas,

> Hm, I have never heard that. Can anybody confirm this information?

I'm still looking for it and I can't find it. It may have been one of thos late night reads where all the words kind of run together.

> Those are not "mistakes". I am sure you can optimize nearly endlessly 
> and you (or somebody else) will always find at least one more byte. 
> :-)

True, I've found a couple today while fishing through the code again. Before I posted I went through commenting. As I was commenting I noticed little things and removed them as I came across them.

> 1. Why so complicated?
> 2. waste time efficient:
> You are often using two or more force extensions (.w) to waste a few 
> cycles. You can replace two of them with nop and save a byte.

What was I thinking? :)

> 3. interleave data
> And if you are sure both are in the same page you can save a few more 
> bytes. The same trick works for several other PAL/NTSC and animation 
> tables too.


> 4. superfluous code:
> ;   bcc .moveClimberRight
>    bcs .doneHorizontalCalculations  ; same as jmp but saves a byte
> .moveClimberRight

Maybe I need to code with my eyes open next time :)

> 5. use eor instead of cmp:

> 7. another bit trick:
I've seen that one and meant to implement it but forgot :( Thanks!

> 8. more tricks with bits:

> 9. if your random number generator is good and random is at least once 
> initialized to != 0 this code is superfluous:
>    lda random
> ;   bne .skipInit
> ;   lda #$FF

But if it's truely random, couldn't it eventually go to zero? Now that I think about it if I does ever produce a zero value then the values wouldn't be random anymore :)

> For the PAL/NTSC speeds I would suggest using fractional numbers for 
> playerMotion. This also allows much finer tuning of the speeds for 

I think I catch what you're saying. I really struggled with what a fractional value meant. The delays seemed fine so I just stuck with them. Fab, get ready to fire up the 2600 again :)

Thanks again Thomas! You are helping me improve my "Kung-Fu" :)

Take care,

Archives (includes files) at
Unsub & more at

Current Thread