Re: A86: Loading data from a "variable" address. . .
[Next][Index][Thread]
Re: A86: Loading data from a "variable" address. . .
Scott Noveck (SMN) wrote:
>
> 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. . . =)
It isn't possible to use the a reg (1 byte) to represent a two byte
address. You'll have to choose something else. The op registers are
only ten bytes ... so you can't load a 12 x 8 sprite there.
>
> 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
No, the z80 can only access one memory location per instruction. You'll
have to write a loop that checks each byte individually or use the cpir
instruction.
> 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???
jp isn't a subroutine. It doesn't return. If there is a ret
instruction at the end of the jp, then it will return to the last call
instruction, not the jump ... even if that call was not made in your
program (ie., it returns to the OS)
>
> Thanks again. . .
References: