>
>Okay, well, in lieu of XP2 and b/c DASM isn't compiled for the Mac, I've
>been having quite a time. But I think I have something now that will
>assemble 6502 programs. As a test program, I've been using Combat off of
>Nick Bensema's site. I've been getting pretty familiar with Combat, but
>wondered if you guys could help me with a few questions.
>
>My assembler is having a tough time with these two lines of Combat:
>
>SPRLO byte #<TankShape, #<PlaneShape, #<JetShape
>SPRHI byte #>TankShape, #>PlaneShape, #>JetShape
#< means the low byte of that address, #> means the high byte.
Tank shapes begin at $F64F, biplane shapes begin at $F6CF, and jet
shapes begin at $F68F. Therefore, these all resolve to:
SPRLO byte $4F, $CF, $8F
SPRHI byte $F6, $F6, $F6
Depending on how you compile the source, SPRHI may vary. Possible values
would be $16, $1E, $FE, possibly others.
>And I can't figure out exactly what they are doing. If I could, I think
>I could change them into something that my assembler understands.
>TankShape et al are the markers that deliniate the beginning of the
>respective player design data. That much I've got. SPEL0 is only seen
>one other time in this line:
>InitField LDX GAMSHP
> LDA SPRLO,X ;Appropriate something for velocity.
> STA SHAPES ;Velocity could double as sprite
> LDA SPRHI,X ;shape.
> STA SHAPES+1
Actually, I found the velocity elsewhere so those comments are misleading.
Velocity is determined by the joystick translation routines.
What this code actually does is, it places the total address into a 16-bit
section of memory labeled SHAPES. It puts the low byte into SHAPES,
and the high byte into SHAPES+1. This is in preparation for some
indirect indexing. Look where else SHAPES is used to see how this is done.
>Can I replace them with
>constant addresses?
Well, you CAN, but if you make any changes to the code, those locations
will still point to the same location. If the code is any larger or
smaller, the graphics might get garbled. You can compensate for this by
using another origin pointer right before the sprite data to keep it
anchored to $F64F, or you can use whatever means your assembler has for
evaluating the high and low bytes for labels. Example:
SPRLO byte TankShape % 256, PlaneShape % 256, JetShape % 256
SPRHI byte TankShape / 256, PlaneShape / 256, JetShape / 256
This assumed that % means modulo..... if your assembler can't evaluate
modulus or remainders with an operator like that, you'll probably have
to use some really stupid awkward equation, and if you have to do that,
well then I suggest you find a new assembler.
Your assembler has GOT to have some means of evaluating the high and low
bytes of variables, though. It's essential for many implementations of
indirect addressing. Try eliminating the # sign.
--
Stella list is Administered by krishna@xxxxxxxxxxxx <Glenn Saunders>
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
+-shameless plugs-------------------------------------------------------+
| Stella documentary at http://www.primenet.com/~krishna |
| Nick's VCS links via http://www.primenet.com/~nickb/atariprg.htm |
| Write the best game, win framed autographs of famous Atari alumni!! |
+-----------------------------------------------------------------------+
