English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 22 January 2020, 01:21   #1
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 53
Basic ASM Pointer Table Help

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:

Code:
  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
Code:
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
Code:
frame dc.w 0
... how do I use that in my code to get the correct offset in my table?

I've tried
Code:
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.
DanielAllsopp is online now  
Old 22 January 2020, 02:01   #2
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 174
Code:
  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
a/b is offline  
Old 22 January 2020, 09:45   #3
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,724
As an alternative to the code above, you can also consider using something like
Code:
	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.
roondar is offline  
Old 22 January 2020, 11:08   #4
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 53
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 :-)

Code:
move.w frame(pc),d1
What does the (pc) bit actually mean here in relation to the frame variable?


Code:
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!
DanielAllsopp is online now  
Old 22 January 2020, 11:20   #5
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,724
Quote:
Originally Posted by DanielAllsopp View Post
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 :-)

Code:
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)
Quote:
Code:
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.
Quote:
Thanks again!
No problem
roondar is offline  
Old 22 January 2020, 11:27   #6
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,062
Quote:
Originally Posted by DanielAllsopp View Post
Code:
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).

Quote:
Originally Posted by DanielAllsopp View Post
Code:
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:
Code:
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.
hooverphonique is offline  
Old 22 January 2020, 12:16   #7
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,472
Quote:
Originally Posted by hooverphonique View Post
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.
ross is offline  
Old 22 January 2020, 12:51   #8
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,699
Also, don't forget that as you are on AGA you can use multiples in the indexed addessing.

for example...

Code:
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
mcgeezer is offline  
Old 22 January 2020, 13:41   #9
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 304
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.
sparhawk is offline  
Old 22 January 2020, 13:49   #10
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,724
Quote:
Originally Posted by sparhawk View Post
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.
roondar is offline  
Old 22 January 2020, 13:55   #11
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 741
Quote:
Originally Posted by ross View Post
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.

Quote:
Originally Posted by sparhawk View Post
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...
grond is offline  
Old 22 January 2020, 14:10   #12
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,062
Quote:
Originally Posted by grond View Post
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:
Code:
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
hooverphonique is offline  
Old 22 January 2020, 14:13   #13
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,511
Quote:
Originally Posted by mcgeezer View Post
Also, don't forget that as you are on AGA you can use multiples in the indexed addessing.

for example...

Code:
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.
Galahad/FLT is offline  
Old 22 January 2020, 14:47   #14
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,472
Quote:
Originally Posted by grond View Post
Why? One of the strong points of 68k vs. x86 is the word-aligned code.
Quote:
Originally Posted by hooverphonique View Post
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.
ross is offline  
Old 22 January 2020, 14:47   #15
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,699
Quote:
Originally Posted by Galahad/FLT View Post
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.
mcgeezer is offline  
Old 22 January 2020, 17:07   #16
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 53
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
DanielAllsopp is online now  
Old 22 January 2020, 17:12   #17
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 304
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.
sparhawk is offline  
Old 22 January 2020, 17:52   #18
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 174
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):
Code:
  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
a/b is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
very basic C/ASM/Visual Studio hand holding Sephnroth Coders. C/C++ 2 08 March 2016 20:15
Pimp up your Basic skills ! BASIC Tenliner Competition 2016 ! SkulleateR Retrogaming General Discussion 6 09 February 2016 23:58
Tool to convert asm to gnu asm (gas) Asman Coders. Asm / Hardware 6 12 October 2013 12:45
Manuals for GFA Basic and Hi-Soft Basic 2 ricky500 request.Apps 20 12 February 2013 21:06
Full table pinball spiff Retrogaming General Discussion 0 21 December 2006 23:46

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 16:59.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09253 seconds with 13 queries