Thank you but I need sections.

It works! :) Thank you I really need to do much work studying 68k assembler options and features. Is there any good book or site for this?

EDIT. With basereg I don't need a separate linker invocation. :)

Your code looks very strange. No big sense for me.

The mostly used 68000 version is next:

lea tab,a6 ; base
add.w D0,D0 ; offset seems to be only 0 for your example
move.w (a6,D0.W),D2

if is 0, then
lea tab,a6
move.w (a6),D2
is enough.

Yes, BASEREG is powerful, but be warned, a6 in Amiga is used for library call.
Anyway define an address register used to access a heap with near displacement.

So you generally does

lea haep,a4

and from here all is a relative access.
Then another lea to your tab with a

(off,a4,dx.x)

or

(tab,a4)

reference.
And then use this new base to access the array with a relative, indexed or not or displaced,

move

.

You can have different heap, or you can use for small (and not so small..) program fast pc relative mode (do not underestimate it, is very very powerful).


EDIT: Don_Adan precedeed me :)
That's why I told him to rethink the code.
Sure not a good way to write for 68k..

I have a lot of tables in my Data section (tab, tab1, tab121, ...). Thus I need to use a register as a section base(a6), I need also an offset to a particular table (tab, ...) and an index to it (d0). For example,
Is there any sense to use d1.w instead of a plain d1 in lea (a3,d1),a6? The generated code is identical.

BTW I bought my A500 in Warsaw in 1989. It was an adventure. I am sure you know a "gielda" which worked on weekends that time. ;)

EDIT. I have added a line with [b]a3[/3] to the start of my code.

ahem.. I dont want to be rude but too much to correct here, better if you stop a bit and re-start studying 68k base properties.
And maybe forget what you have learned for other processors that does not apply here.

You're dealing with a powerful ISA :)

In case this is part of what you want to create (border having a separate colour from the background), there is a way achieve this effect. I used this when I wanted a black border, but a copper-changing background.

What you could do is use colour 0 for the border (give it whatever colour you want the border to have). Then you fill the bitmap to display with colour 1 and give that whatever colour you want the background to be. For a tilemap, you'd have to create tiles with colour 1 as background.

This way you can have both a 'border' and a 'background', including copper effects. And should you have picked a useful colour for the border, there's nothing stopping you from using that on screen as well.

Hope this helps.

Most assemblers default to word sized for the index so you don't have to add the .w. As such, lea (a3,d1.w),a6 and lea (a3,d1),a6 would indeed assemble to be the same. If you change this to lea (a3,d1.l),a6, I expect the generated code to be different.

Or you can use copper to sync to DIW registers and gain COLOR0 for copper gradient.
A more advanced technique, used in some games masterpiece.

And always remember that you have to handle the upper indexed bits, before a .w if you insert a .b or before a .l if you insert a .w.
(not done in proposed example)

Very true, never forget the flexibility of the copper - it's such a nice tool to have :great

Ok, perhaps i understand, what you need, use next code:

lea Base,A6

move.w tab1213-Base(a6), d2
move.w tab1011-Base(a6),d3

Base
....
tab1011 dc.w 0
...
tab1213 dc.w 0
tab1214 dc.w 0
....

btw. if you use move.b (a4),d1 and add.w d1,d1, be sure than high byte in D0 is 0, or you can set to wrong pointer later.

for assemblers lea (a3,d1),a6 is equal to lea (a3,d1.w),a6.
lea (a3,d1.w),a6 is not equal to lea (a3,d1.l),a6

lea (a3,d1.w),a6
works as next:
move.l a3,a6
add.w d1,a6

lea (a3,d1.l),a6
works as next:
move.l a3,a6
add.l d1,a6


d1.w (16 bit) can be diiferent than d1.l (32 bit)

@roondar Thank you. But your idea takes one color from the main screen. IMHO it is possible to use copper to change the value of color register 0 but it will require not very easy coding, we need to change the register two times for horizontal borders and one time for vertical.
@ross Thank you but please be more specific. Indeed I did moveq #0,d1 - I thought it is obvious for everybody.
Your code skips the usage of index in D1. :(

Using the copper is indeed the better option if you need colour 0 to be different for the background and border part. Do note that in my idea you can still use colour 0 on the main screen, though it does indeed mean choosing a border colour that is 'useful' for the main screen as well.

To try and help you a bit more, the copper 'trick' you're referring to here really isn't hard. It's essentially the same thing as is done when you create a copper rainbow but instead of having one wait and one move command per scanline, there are two.

The copper list would look something like this for a PAL Amiga (I did this from memory, so there may be bugs :p):
Note that the waiting positions do need to be correctly chosen. I haven't put any values in as the exact positions depend on how wide the screen is. Also note that this method requires the screen edges to be on multiples of 4 pixels due to limits in the Copper wait command.

Hope this helps, as I said - the copper is very nice and can be used for all sorts of tricks.

Thank you very much. :) I like the copper and I also would like to use blitter. However your code is about 1100 lines in size and it should be different for PAL and NTSC machines. I am also going to use several other copper coding and it will be not easy to combine the both codes... Thus it would be better to have a separate color for borders.

This is, sadly, usually unavoidable for copper lists that have to work in the screen part that only exists on PAL systems. One of the few things in the Copper I don't like, though I understand why it is.

I stuck in a problem. Please help me again. Is there a way to save CPU arithmetic flags (C,Z,N,X,V)? MOVE SR,D0 doesn't work for applications with 68020 and later 68k CPU. Is there any other way?

Use CCR instead of SR. Or just keep track of the condition codes once you use any instruction which might change them.

Move ccr, d0 dont exist for 68000.
move sr, d0 works for 68040/68060 only in privillage mode.
If he want, he can set privillage mode and use move sr, d0. he can use superstate and userstate calls from exec.

If you want a generic way that work on every 68k use the exec function SetSR
Or for the interested bits use Scc and after rebuild the CCR in the stack and use RTR instead of RTS.

But the real question is: WHY? :shocked
There is no reason to save all the flags!

Use the ones you need in the right way (or put them aside with Scc) and you're good in all cases.

All correct! :) But ultimately, what Ross said here:

Indeed, it's not usually a big necessity on 68k based machines. I remember stacking/restoring the status register somewhat frequently on the 6502, but I've not really missed it on the 68k. More so since it's not a requirement for exception processing unlike 6502.


@litwr
However, if you really want to (though I'd be very interested in knowing why you want this, like most here) - there is another option. You can run the whole program in supervisor mode if you want. This will allow you use of the move to sr <ea> and move from sr <ea> instructions as you see fit.

You can do this using the Exec function SuperState(). Remember to leave at the end of the program using UserState(). See here: http://amigadev.elowar.com/read/ADCD.../node0385.html for documentation.

Note that it's not really the recommended way to run entire OS legal programs and shouldn't really be required considering what Ross and others wrote above, but it can be done.

For some reason (that I don't remember precisely anymore) was a problem for me using a whole program in SuperState() mode.
Probably something to do with KS1.x dos.library (Tripos legacy..) that messes up with the stack
(be warned! SuperState enter in supervisor mode while running on the user's stack).

No big problems with Supervisor().

Or is the opposite? Need to check it :p
Take with a grain of salt, too much time passed :)