How many ticks per instruction...?

[Mairtrus]

Hi guys, first post here , and this is something that was in my head by the lastest few days: Right now, I'm working on a project that is partially finished (just a few tweaks here and there and it's done), and as a personal achievement, I want to keep all under the 64KB, but I'm currently having troubles with this, since I cannot down it from the 68KB...
So, all we know that there is differents ways to load data from the RAM (or ROM, why not?), but I was worried about how this will affect the speed (it's executing a LOT of code, and I need to preserve the 60 FPS).
Anyway, my question(s) is:
1) Exist a document or something wich shows the speed of each instruction on the M68K?
2) Lets say at certain point, I need to read and manipulate a lot of bytes in RAM, and I'm accesing them one by one (that is: move.b (var1),d0 / move.b d1,(var2) , etc). Those vars are in a range of 100 bytes. Is fastest if I put an offset in an An register and then I manage each value like "move.b var1(An),d0 / move.b d1,var2(An)"?

Well, I thinks that is all, I can not remember more question right now. Thanks for your replies, guys...

[HardWareMan]

1) Exist a document or something wich shows the speed of each instruction on the M68K?

Yes. It's called "MOTOROLA M68000 FAMILY Programmer’s Reference Manual" (2,2MBytes).

2) Lets say at certain point, I need to read and manipulate a lot of bytes in RAM, and I'm accesing them one by one (that is: move.b (var1),d0 / move.b d1,(var2) , etc). Those vars are in a range of 100 bytes. Is fastest if I put an offset in an An register and then I manage each value like "move.b var1(An),d0 / move.b d1,var2(An)"?

There are many various addressing modes in M68K. All of them described in "MOTOROLA M68000 FAMILY Programmer’s Reference Manual". For example, you can use move.b d0,(d8,An,Xn) for access 2D arrays.

[Stef]

Hi guys, first post here , and this is something that was in my head by the lastest few days: Right now, I'm working on a project that is partially finished (just a few tweaks here and there and it's done), and as a personal achievement, I want to keep all under the 64KB, but I'm currently having troubles with this, since I cannot down it from the 68KB...
So, all we know that there is differents ways to load data from the RAM (or ROM, why not?), but I was worried about how this will affect the speed (it's executing a LOT of code, and I need to preserve the 60 FPS).
Anyway, my question(s) is:
1) Exist a document or something wich shows the speed of each instruction on the M68K?
2) Lets say at certain point, I need to read and manipulate a lot of bytes in RAM, and I'm accesing them one by one (that is: move.b (var1),d0 / move.b d1,(var2) , etc). Those vars are in a range of 100 bytes. Is fastest if I put an offset in an An register and then I manage each value like "move.b var1(An),d0 / move.b d1,var2(An)"?

Well, I thinks that is all, I can not remember more question right now. Thanks for your replies, guys...

They are many ways of speeding up code generally, using An indexing + 8 bits offset should be faster than using direct 32 bits adressing var if i remember correctly. Can't you group some similaries byte vars (attached treatment in same portion of code) in a dword var ?

[mic_]

There should be websites with info on 68000 optimization if you google for it.

Another way to get the code size down is to compress your code/data. Prepend the compressed binary with a depacker that unpacks it to RAM and runs it from there (this assumes that the uncompressed size is < 64kB). You'll have to fiddle a bit with your linker script to get the addresses right.

There are plenty of packers that have 68000 depackers available, because it was such a widely used processor family (Amiga, Atari ST etc).
For example this one and this one.

[Gigasoft]

You should use RAM locations above $ffff8000 for your variables. This ensures that the addresses will be 16 bits if the appropriate assembler option has been given. In Snasm68K, the option -ow+ enables this.

[Charles MacDonald]

You should use RAM locations above $ffff8000 for your variables. This ensures that the addresses will be 16 bits if the appropriate assembler option has been given. In Snasm68K, the option -ow+ enables this.

For some reason I can never get SNASM to respect the options passed to it, but if you want to do it manually:

To fit an address into 16 bits, use the .w extension, like this:

move.w $02E8.w, d0 ; reads 0002E8
move.w $EFF0.w, d0 ; reads FFEFF0

For labels define them with the upper bits of the 32-bit address set to $FF, like this:

label = $FFFF8001 ; not $FF8001

Then you can do:

move.w (label).w, d0

I find you need parenthesis around the label, just 'label.w' will not always work.

[HardWareMan]

Charles MacDonald says about "Absolute Short Addressing Mode" wich described in "MOTOROLA M68000 FAMILY Programmer’s Reference Manual". It use WORD value, then sign extend it to LONGWORD and use it as pointer. Sign extend is copying most bit in WORD (D15) to each bit of high word of LONG WORD. So, if D15=0, then high word will be $0000, and if D15=1, high word will be $FFFF. So, there are quick way to access high 32KBytes of RAM and low 32KBytes of ROM (usefull for placing constants).

[Gigasoft]

This is what my command line looks like:

@..\snasm\snasm68k -p -o ow+,os+,oz+ gm.asm,gm.bin,,gm.lst

Make sure you have the -o switch in front of your options. Then it should work.

[Chilly Willy]

Or you could use a relatively newer assembler.

There's The Macro Assembler AS (not to be confused with GCC's Assembler AS), it's often called ASL (AS for Linux - showing which platform it was compiled for). It's available for DOS, WIN32, OS/2, and source which can be compiled for linux and BSD.
http://john.ccac.rwth-aachen.de:8000/as/

This is the assembler virtually all Sonic hackers user. It's pretty ubiquitous in that area.

For smaller snippets of assembly I use with my Genesis stuff, I usually use GCC's AS. The syntax is a bit different compared to "normal" assemblers. Most folks prefer the older style of assembler, which is why they prefer ASL.