Re: A86: Loading data from a "variable" address. . .
[Prev][Index][Thread]
Re: A86: Loading data from a "variable" address. . .
It helps, but it won't quite do. . . The screen will be displayed with a
number of sprites. After the labels, i have the screen set up something
like this:
Screen01:
.db %00000101,%00000011,%00100010. . . up to 12 bytes across
.db %00000000,%01010100,%01010001
(and up to 8 down)
The program may interpret %00000000 as ground, and %00000101 as a tree,
etc. -- it's more like a compressed level than strings. . .
What I need to do is load something like "Screen01" into a variable (again,
I think OP1) and make the "a" register point to the label -- The program
will check the first bit, interpret what to put there (rock, tree, ground,
block, path, water, cliff, enemy, etc.). Then I use "inc a" to get the next
byte, which is in turn interpreted and a is set to the next byte -- up to 84
(12*8) squares per screen -- the real game uses 10*16, but that's using
16*32 full color sprites on a TV screen -- I've just got my measly little
8*8 black and white guys on a 64*128 screen. . . =)
Now that you've got all this, SOMEONE has to know how to do it (I hope =)
I'd rather not have something like:
FindScreen:
cp OP1,Screen01 ;I don't think this is allowed with OPs, but bear with
the idea
jp z,SetAToScreen01
cp OP1,Screen02
jp z,SetAToScreen02
. . . ;This whole sequence is WAY to much
. . . ;If I want a world more than 1 screen
big =)
. . . ;I was hoping 10*10 Screens or larger
for the outer world
SetAToScreen01: ;Then Dungeons and stuff -- I really
don't know how big it'll be
ld a,Screen01 ;But I think it's like 85
bytes/Screen -- so 2K or 3K
ret ;seems reasonable for data storage
(for the 1st version)
SetAToScreen02
ld a,Screen02
ret
ALSO -- I'm still not clear on the call's, jp's, and ret's -- If jp doesn't
require a ret, then how does it know when the subroutine is DONE???
Thanks again. . .
>Scott Noveck (SMN) wrote:
>>
>> I've been following this list for two or three weeks now, and found it to
>> extremely helpful (well. . . most of the time =) Anyways, I'm working on
an
>> RPG similar to the original Legend of Zelda for the old NES (not quite an
>> "RPG", but close enough). The problem I'm having is the way the data is
>> stored. Since the map is split into many sections (one at a time), I have
>> all the data stored for them in Sections labeled Screen1, Screen2, etc. .
.
>> So every time you move right a screem, the number is increased by one,
left
>> decreases one, and up or down decreases or increases by the number of
>> screens in a row.
>>
>> For example:
>>
>> Screen01 Screen02 Screen03 Screen04 Screen05
>> Screen06 Screen07 Screen08 Screen09 Screen10
>> Screen11 Screen12 Screen13 Screen14 Screen15
>> . . . etc., etc. . .
>>
>> What I want to do is have the "a" register pointing to the data.
Assuming
>> you start in Screen01 and move down a screen, you'll be at Screen06. What
I
>> want to do is set "b" to be equal to 6 (or, if possible, use OP1 to store
>> the string "Screen06"), and do something like "ld a, [the label in
b/OP1]".
>> I've been trying to find a way to do this, and I think it may involve
>> _ABS_DEST_ADDR (is that absolute destination address?) and
>> _SET_ABS_DEST_ADDR -- but I have no clue how to use them. . .
>
>Here's what you need to do:
> ld hl,string6
> rst 20h ;op1 has the sting
>
>string6:
>.db "Screen06",0
>
>I'm not sure what you want to do with it from there... If I were you, I
>would use a hex number to represent each screen, set up a data table
>with each of the of the strings in order, and then multiply your hex #
>by 9 to get the string (each string is 9 characters) when you need to
>display it. If a contains the hex # and ix points the start of the
>table:
>
> ld h,a
> ld l,9
> call _mul_hl
> add hl,ix
> call _puts
>
>something like that...
>
>>
>> I could also use "cp b,1 / jp z,SetAToScreen01 / cp b,2 / jp
>> z,SetAtoScreen02" etc. (and have those labels do just what they say), but
>> that's at least 2 or 3 times the memory, and not flexible enough (if I
use
>> other labels -- like Dungeon01, or Cave02) -- so i anyone could help me,
I'd
>> appreciate it. . .
>>
>> And, does anyone have any clue how the Zelda enemy AI works? I was
watching
>> the game; half of what the guys did was completely random (Firing in the
>> opposite direction from me, moving straight random amounts of time before
>> turning), and half was actually moving TOWARDS me and aiming AT me (not
an
>> easy feat -- I've got a few ideas as to how I'll program them, but They
may
>> be pretty dumb =) I got the Gameboy Zelda ROM image and decompiled it,
but
>> It's impossible to find ANYTHING in 120K of decompiled Z80 source code --
>> and it's only legal to have these things 24 hours without owning the
actual
>> game. . .
>>
>> I've also got a few other ASM questions:
>> 1) When do I need to use "ret", and when don't I??? I've seen source code
>> for some programs that jump, do a routine, and go back but don't use
>> "ret" -- When does it know to return?
>
>If the instruction before the ret is a call, then jp does the same
>thing:
>
> call _puts
> ret
>
>is the same as
>
> jp _puts
>
>The ret at the end of the _puts call functions as your ret when you use
>jp.
>
>> 2) I've seen cases where "call" was used exactly like "jp" -- and NOT for
>> ROM calls?!? Am I allowed to use it for anything else???
>
>You can use calls to your own code, it simply returns to the instruction
>following the call after the subroutine is finished
>
>> 3) While I'm at it, is a TI-89 list going to open soon?
>> 4) Since the 89 will use a Motorola 68000 like the TI-92, the assembly
will
>> be like Fargo, not the 82, 83, 85, 86, or any of the others that use a
6MHz
>> Z80, right? If so, does anyone here know of a good Fargo reference
source?
>> (again, it's the wrong list, but I'm not on the TI-92 list and this is
more
>> convenient).
>>
>> Anyways, that's enough for one E-Mail -- I'd appreciate any help I can
get.
>> Thanks!
>>
>> S___________________________________________________C
>> | The FIRST SimCity 3000 Site ~~ By Scott Noveck |
>> 3_ http://sc3k.home.ml.org OR http://sc3k.base.org _K
>> ______
>> | |\ /| |\ |
>> |_____ | \ / | | \ |
>> | | v | | \ |
>> ______| | | | \|
>> -SMN
>> noveck@pluto.njcc.com (preferable)
>> SMN@geocities.com (slower)