Basic ASM Pointer Table Help

[DanielAllsopp]

Hey! I'm back again with some simple questions that my C and Swift orientated brain can't get around!

I've successfully got an AGA screen up and running with 64bit fetch and 16 colour 64bit wide attached sprites. All good so far, works great.

Now I'm trying to animate said sprites and have the sprite data in one file, with offsets calculated by hand for now. One step at a time :-)

The code below should show how I've got that all set up:

  move.l #SpriteTableOffsets,a2   ; load first address into a2
  move.l 4(a2),d2                 ; move 4 bytes in from start of table in a2 into d2, effectively the 2nd offset
  add.l #SpritePointer,d2         ; add start sprite address to offset value in d2
  move.l d2,a0                    ; move d2 into a0 and we'll all good!

*******************************************************************************

SpriteTableOffsets:
  dc.l  $00000000,$00000640

SpritePointer:
  INCLUDE "data/sprite.ctl.64x48x4.asm"     ; sprite with control words and termination

So I can manually change the

move.l 4(a2),d2

to get the correct offset in the table, but can I hell find a way to do that with a simple frame variable.

Say, I have

frame dc.w 0

... how do I use that in my code to get the correct offset in my table?

I've tried

move.l frame*4(a2),d2

but get an illegal relocation error from VASM. My brain is telling me there's got to be a simple way around this but it won't let on!

Any help would be appreciated. Thanks.

[a/b]

  lea frame(pc),a0  ; or without (pc) if it's in a different section
  move.w (a0),d0
  eor.w #4,(a0)  ; this will cycle 0,4,0,4,... use addq.w #4,(a0) to increment 0,4,8,...
  move.l SpriteTableOffsets-frame(a0,d0.w),d2

SpriteTableOffsets:
  dc.l  $00000000,$00000640
frame:
  dc.w 0

[roondar]

As an alternative to the code above, you can also consider using something like

	move.w frame(pc),d1
	move.w 0(a0,d1),d0
	; now simply update the contents of frame as needed
	; etc

frame:
	dc.w 0

This has the advantage of not changing A0, but might cost more cycles.

[DanielAllsopp]

Thanks for the answers lads. I guess off the back of that I have a couple of simple ASM questions. I always like to know how, or why something does what it does instead of just slamming working code in there :-)

move.w frame(pc),d1

What does the (pc) bit actually mean here in relation to the frame variable?

move.w 0(a0,d1)

Could someone explain in layman's terms what this actually does? I mean I haven't seen two registers in parentheses before.

Thanks again!

[roondar]

Originally Posted by DanielAllsopp

Thanks for the answers lads. I guess off the back of that I have a couple of simple ASM questions. I always like to know how, or why something does what it does instead of just slamming working code in there :-)

move.w frame(pc),d1

What does the (pc) bit actually mean here in relation to the frame variable?

This means the instruction doesn't use a fixed address, but rather an offset to the PC (program counter). This is similar to using bra label, which also doesn't use an address but rather an offset. The main reason for doing this is essentially that it makes the resulting program a bit smaller (and often run a tiny bit faster). You can normally use move frame,d1 as well.

(there are some other reasons to use PC relative code as well, but they're probably not be relevant right now)

move.w 0(a0,d1)

Could someone explain in layman's terms what this actually does? I mean I haven't seen two registers in parentheses before.

Sure: move x(a0,d1) takes the address in A0, adds x and then adds the value of D1 to get to the final address the instruction will use. It then loads in the value at this modified address. A0 is not altered.

Thanks again!

No problem

[hooverphonique]

Originally Posted by DanielAllsopp

move.w frame(pc),d1

What does the (pc) bit actually mean here in relation to the frame variable?

The processor addresses frame relative to the address of the move instruction, i.e. an offset - this offset is always 16 bits and thus smaller than the full 32 bit address, i.e. a smaller resulting instruction, and it also has the advantage of the assembled code being relocatable (due to not using an absolute address).

Originally Posted by DanielAllsopp

move.w 0(a0,d1)

Could someone explain in layman's terms what this actually does? I mean I haven't seen two registers in parentheses before.

The resulting source address of the move in this case is 0+a0+d0. It can be interpreted as 0 being a fixed offset, a0 the base address (e.g. of a table), and d0 the index (into the table). You can also use the the following syntax for the same thing, which may make more sense:

move.w (0,a0,d1)

In many cases you will also see the "d1" part as "d1.w" (16 bit index) - you can also use "d1.b" and d1.l" for 8 and 32 bit indexes.

[ross]

Originally Posted by hooverphonique

In many cases you will also see the "d1" part as "d1.w" (16 bit index) - you can also use "d1.b" and d1.l" for 8 and 32 bit indexes.

Unfortunately there is not an 8 bit index available (which would have been very useful!)
You can use .b only on registers data usage.

[mcgeezer]

Also, don't forget that as you are on AGA you can use multiples in the indexed addessing.

for example...

lea Table(pc),a0
moveq #1,d0
move.b (a0,d0*4),d1

Table:
   dc.b  0,2,4,6,8,10,12,14

That will result in moving 8 into d1.

You can multiply up to *8 and this is extremely useful on AGA.

Geezer

[sparhawk]

It's not related to AGA, but to the CPU. I think 68020+ probably.

Is there some good M68k instruction manual? The one I currently use (M68000PRM.pdf) doesn't seem to mention this multiplier even though it mentions some additional MC68020+ modes.

[roondar]

Originally Posted by sparhawk

It's not related to AGA, but to the CPU. I think 68020+ probably.

Is there some good M68k instruction manual? The one I currently use (M68000PRM.pdf) doesn't seem to mention this multiplier even though it mentions some additional MC68020+ modes.

I use https://www.nxp.com/files-static/arc.../M68000PRM.pdf. I think that might actually be the same file, considering the name. It does mention the scaling on the pages about addressing modes though, check page 2.2.7 and 2.2.8 for instance.

[grond]

Originally Posted by ross

Unfortunately there is not an 8 bit index available (which would have been very useful!)
You can use .b only on registers data usage.

Why? One of the strong points of 68k vs. x86 is the word-aligned code. An 8 bit index mode would either have resulted in padding and been completely useless or would have made 68k to only be byte-aligned. With the 16bit ALU available right from the start the 8bit index wouldn't even have been any faster, just one byte code size saved.

Originally Posted by sparhawk

Is there some good M68k instruction manual? The one I currently use (M68000PRM.pdf) doesn't seem to mention this multiplier even though it mentions some additional MC68020+ modes.

There isn't a thing about 68k that isn't in the PRM. It just takes a little getting used to...

[hooverphonique]

Originally Posted by grond

Why? One of the strong points of 68k vs. x86 is the word-aligned code. An 8 bit index mode would either have resulted in padding and been completely useless or would have made 68k to only be byte-aligned. With the 16bit ALU available right from the start the 8bit index wouldn't even have been any faster, just one byte code size saved.

It isn't about alignment/padding, but about only considering the low byte when adding the numbers, which is useful if the index register contains other data.
I had a recent case where I needed to move the low byte to a clear register to use the low byte only as index - like this:

move.w (a0)+,d0
moveq #0,d1
move.b d0,d1
move.w (0,a1,d1.w),d2
.. do something else with the rest of d0

[Galahad/FLT]

Originally Posted by mcgeezer

Also, don't forget that as you are on AGA you can use multiples in the indexed addessing.

for example...

lea Table(pc),a0
moveq #1,d0
move.b (a0,d0*4),d1

Table:
   dc.b  0,2,4,6,8,10,12,14

That will result in moving 8 into d1.

You can multiply up to *8 and this is extremely useful on AGA.

Geezer

Personally, I try and avoid using byte sized tables on 020+, and on 68000 for that matter as whilst both processors can access bytes, its at its most efficient working on word sizes.

Same reason I avoid using odd addresses on 020+ and longwords. Yes the 020 can read them, but its not optimal processor performance for it to do so.

[ross]

Originally Posted by grond

Why? One of the strong points of 68k vs. x86 is the word-aligned code.

Originally Posted by hooverphonique

It isn't about alignment/padding, but about only considering the low byte when adding the numbers, which is useful if the index register contains other data.

This

And small arrays in memory are an added value.

[mcgeezer]

Originally Posted by Galahad/FLT

Personally, I try and avoid using byte sized tables on 020+, and on 68000 for that matter as whilst both processors can access bytes, its at its most efficient working on word sizes.

Same reason I avoid using odd addresses on 020+ and longwords. Yes the 020 can read them, but its not optimal processor performance for it to do so.

yes good point.

If I was doing it properly on 020/AGA I would have a CNOP 0,4 to align it.

Byte size tables are useful though, an example being sine / cosine where you can just cycle through the byte space for sine and +64 for the cosine.

[DanielAllsopp]

Many thanks to all of you who've contributed to this thread and the other ones to aid in my ASM learning. You're all very welcoming and patient with us beginners :-)

I've gone from this manky white line and green screen:



to this:



It might not look like much to you veterans but I'm well chuffed. Especially in the space of a month!

Now I'm slightly more motivated, I'm sure this will just be the start of many more questions over the coming months.

Thanks again

[sparhawk]

Cool! Your are farther than me. I'm working on helper functions, but drawing a line and going to an animated BLOB from there, is next on my list.

[a/b]

If you are starting to learn asm, here's a random advice (since I noticed it in some of the examples above): if there's more than one possible operand size, always specify what you want.
For example (this is my opinion, of course):

  move d0,d1    ; bad (.b/.w/.l? usually ends up being move.w)
  move.b d0,d1  ; ok
  move.w (a0,d0),d1    ; bad (d0 is .w/.l?)
  move.w (a0,d0.l),d1  ; ok
  moveq.l #42,d0  ; it works, but .l is not need since it's always .l