Re: [stella] Line Labels/Memory Location...

Subject: Re: [stella] Line Labels/Memory Location...
From: "Joel Park" <joelp@xxxxxxxxxxxxxxxxxx>
Date: Mon, 5 Nov 2001 15:28:55 -0500
Sounds like what I need to do.  But about Line Tags VS actuall Memory
In the Game Data table for Adventure, I have stuff like:

Just an example of how it's setup:

.byte $04, $FF, $01, $03 ;Yellow Dragon
.byte $0F, $FF, $01, $03 ;Red Dragon

$04 = Color
$FF = High Byte of Memory Location (Graphics)
$01 = Low Byte of Memory Location (Graphics)
$03 = Which Animation Frame to Use.

In this case,  $FF, $01 would have to be repaced with a  Line Tag:
Is there some way to use line tags when just initilizing a byte.

The game engine would then loop through bytes above in the table thing and
draw each dragon accordingly using the same block of code.

I don't want to keep wasting you guy's time with this.    I'm sorry.

----- Original Message -----
From: "Thomas Jentzsch" <tjentzsch@xxxxxx>
To: <stella@xxxxxxxxxxx>
Sent: Monday, November 05, 2001 2:57 PM
Subject: Re: [stella] Line Labels/Memory Location...

> Joel Park wrote:
> >The thing is, adventure is designed in more of a game engine
> format, so it
> >draws it's graphics in a loop of sorts, pulling the graphics
> locations out
> >of a table which just stored the High and Low bytes of the
> graphic location.
> >At the end of each set of graphic bytes is a Null terminator
> thing, $00
> >which signals the last byte in the graphic definition.
> Therefore the
> >graphics are actually accessed by their start location in
> memory without the
> >ability to use Line Tags. I hope that made sense.. :-)
> The best (or most perfect) way is, to complete the disassembly.
> That means, replace all high and low bytes with the labels
> (that you'll have to define too!) they are pointing at. And
> you'll also have to find all other places in the code, where
> some pointer bytes are loaded directly (without tables access).
> I call those bytes "magic numbers".
> Every number (except maybe #0 or #1) that is loaded, compared,
> added etc. directly can be removed, when you understand what it
> is used for. Some magic numbers are constants, which can be
> defined, some are pointers for tables and some are hardware
> register values.
> If you look at my disassemblies of Starmaster, River Raid and
> Pitfall! you will see, how the result of "magic number removal"
> looks.
> That way, you'll will get the maximum flexibility to do with
> the code what you want. You won't have to worry anymore, that
> changes to some code will break other code somewhere else.
> And, as a bonus, you will learn a lot about how the code works
> and the Atari community will get another fine disassembly :-)
> Have fun!
> Thomas
> --------------------------------------------------------------------------
> Archives (includes files) at
> Unsub & more at

Archives (includes files) at
Unsub & more at

Current Thread