Re: [stella] subpixel joustpong

Subject: Re: [stella] subpixel joustpong
From: KirkIsrael@xxxxxxxxxxxxx
Date: 3 Feb 2004 15:09:30 -0000
> > If you want to play with the physics numbers yourself,
> > I made a javascript tool to convert decimal numbers into
> > binary, since figuring the two's complement stuff was getting
> > to be a serious pain, you can see and use that at
> >
> > (oops, I just noticed that Window's calculator now lets
> > you do some kind of specification of how many bytes...
> > well, it still seems fiddley to use. and the javascript thing was kind
> > of fun to slap togehter.)
> Nice, but un-necessary.  Let the assembler do the work....
>     lda #<NUMBER
>     sta var
>     lda #>NUMBER
>     sta var+1
> Now set NUMBER to whatever you want.  The two-byte variable "var" will hold
> the low byte (in var) and the high byte (in var+1).  But what about negative
> numbers in two's complement form?  The assembler automatically does it!

I was thinking about this.  Actually, despite what the javascript
tool implies, I strongly prefer thinking about the two bytes for
movement as two seperate numbers, that I like seeing the integer
part and the fractional part, both preferably in binary.  I guess
I could just take it as a single integer and divide by 256 or so, 

Arguably to support this view point there should be a binary number
input to the javascript tool, since I do find "flipping the bits and
adding one" to be a bit fiddley.  

> By the way, to negate numbers (single byte)...
>     clc
>     lda var
>     eor #$FF
>     adc #1
>     sta var
> or, for two-byte negation, easiest is to subtract the number from 0
>     sec
>     lda #0
>     sbc var
>     sta var
>     lda #0
>     sbc var+1
>     sta var+1

Yeah, some of my old code used the subtract from zero trick.
Re negating singlyh byte numbers, I guess that's good to do with
variables, though I think things that can be precomputed at compile 
time should be, rather than taking cycles in runtime.
> Subpixel joustpong is looking much better, but i think the gravity should be
> roughly 4x as strong, and the flapping should be about 1/4 of the power.  So
> you really have to flap to keep your position, and going up is major flap
> time.
> One other thing... had a brief look at your code.
> Instead of..
> NUMBER = #8
> it's more standard to just go
> NUMBER = 8

Heheheh.  You know where this comes from, right?  It's a side effect 
of being previously burned by leaving out the # sign when using the 
constants (i.e. LDA NUMBER when I meant LDA #NUMBER).

How bad is that?  I know it probably hints at a poorish mental model,
8 is 8 whether you plan to use it as a constant or as a memory location,
and you select which use you mean *at* the time of memory access, but 

Don't know what was up with the ORG etc issues, it always compiles fine
for me w/ DASM.

Thanks for all the help!  I always feel really bad when I don't take 
every bit of advice you give...I have to balance what seems "right" 
for me (i.e. keeping the high/low bytes seperate) though it might not 
be the most common, vs. the fact I've resisted some ideas before and 
sometimes get, I don't want to seem ungrateful!

Every man is working out his own way [to ordination] and nobody can be 
of help except by being kind, generous, and patient. --Henry Miller

Archives (includes files) at
Unsub & more at

Current Thread