Re: A86: Loading data from a "variable" address. . .

[Prev][Next][Index][Thread]

Re: A86: Loading data from a "variable" address. . .


I'll start with the jumps/calls/rets.  When you jump (JP or JR), you are
just running the instruction following the label you jump.  The program
keeps going from there.  When you call a subroutine, it ends with a
RET.  The RET returns the the instruction right after where you called
it.  Here's an example:

call MySub
ld a,0

MySub:
; your subroutine code goes here
ret

In this one, call runs MySub, then returns to "ld a,0" and runs it, then
keeps going.  Another:

jp Skip:
;code you want to skip
Skip:
ld a,0

This time you just skip over whatever and run the "ld a,0", but you
don't need a ret, since you're just jumping.  A RET returns from a call. 
That's how ROM calls return to your program right after you call them. 
If you used JP to call a rom call, it wouldn't return to your program
(it would almost certainly crash the calc), since it wasn't CALLed.



Now on to the map problem...
You don't need OPs or anything like that.  Just use this code:


  ld b,CURRENT_SCREEN		; like 1, 2 -- starts at 1, 0
  ld hl,Screen1-SIZE_OF_SCREEN  ; added once always, once==Screen1
  ld a,SIZE_OF_SCREEN ; how much to add to get right screen
ScreenLoop:
  add hl,a
  djnz ScreenLoop

Screen1:
;your map goes here
Screen2:
;your next map here--all screens must be right after each other


When you get done, HL points to the screen you want.  When drawing the
sprites for each one, just draw the sprite for (HL), then move to the
next byte by "inc HL".

I've attached a little program that demonstrates drawing a single tile
map (screen).  You'll have to add the code to pick which map you want.


--------------
David Phillips
electrum@tfs.net


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. . . =)
> 
> 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. . .
Follow-Ups: References: