2nd tutorial on ASM- and HW-coding

[Vikke]

Thank you all for the great feedback regarding the first tutorial, here comes the next one.

Link: Vikke.net

This time it is a tutorial on doing horizontal shifting. Horizontal shifting is used for scrollers, but also as an effect in demos. You will probably recognize the effect once you see it.

If you have any questions about the code, just ask. I will try to explain everything as detailed as possible, but that isn't possible on the website.

The next codesnippet is already planned, and is yet another Copper-thingy, something very popular back in the day. Can you tell I really like the Copper?

And one more thing, I'm really sorry for the bad graphics. I wasn't this bad at doing graphics when only using an Amiga, but now making the graphics first in Photoshop and then converting to IFF isn't the best method.

[BippyM]

What is the order of precedence on the following:

move.w #384/8*200/4,d0

i'm guessing

384/8
48*200
9600/4
=2400

[Vikke]

Originally Posted by bippym

What is the order of precedence on the following:

move.w #384/8*200/4,d0

i'm guessing

384/8
48*200
9600/4
=2400

Yes, you're right.

Just to comment on why the values are what they are:

384px wide / 8 = 48 bytes per line

48 bytes/line * 200 lines = 9600 bytes total

9600 bytes / 4 bytes/longword = 2400 longwords (each 64 bits).

I chose to put the multiplications and divisions visible to be able to get a grasp on how the values are made (and it isn't any slower as the assembler calculates them at compile-stage anyhow).

[WayneK]

In this case it doesn't matter, but it's: (384/8) * (200/4).

[Vikke]

Originally Posted by WayneK

In this case it doesn't matter, but it's: (384/8) * (200/4).

You are also right, it can be put together in different forms, but in my previous post I explained the reasoning behind the "formula".

[BippyM]

why is it /8?

[Vikke]

Originally Posted by bippym

why is it /8?

320px equals 320 bits, to get that value to be in bytes we have to divide it by 8 (8 bits equals 1 byte).

With memory access the smallest possible alignment is one byte. The MC68k can address memory by alignments of bytes (8 bits), words (16 bits / 2 bytes) or longwords (32 bits / 4 bytes).

[Lonewolf10]

Originally Posted by bippym

why is it /8?

From what Vikke states below the screen is 384 pixels wide. A byte can only store the status of 8 pixels (8 bits in a byte, each representing a pixels status on one bitplane). Thus to get the number of bytes per line, for a one bitplane image/screen, you do:

width in pixels / 8 = number of bytes per line


Edit: Just beaten by Vikke

[BippyM]

I thought as much. I'm in the process of my first asm program to display a picture. Thought about using the copper to set all registers etc and then call the copper to show picture

[Vikke]

Originally Posted by bippym

I thought as much. I'm in the process of my first asm program to display a picture. Thought about using the copper to set all registers etc and then call the copper to show picture

That is a good place to start coding on an Amiga. Do you have the image in RAW format? I use IFFMaster to convert from IFF to RAW. Probably all graphics programs on the Amiga can save images in IFF, on windows Photoshop can do it and also Grafx2 (of these Grafx2 is way better as you can make the palette have the right amount of colors and in the correct order).

[BippyM]

I have not created a gfx yet. I have written some code, but am spending more time analysing each bit of code.

I've also got notepad++ looking a lot better and working more accurately with highlighting.