Trying to implement joystick code in my stuff

[phx]

Originally Posted by Akira

Is there any guide anywhere that explains how to make an OBJ and how to link together?

Most assemblers generate object files by default. Export symbols with XDEF. Import them with XREF. Then link all objects into the final executable:

linker a.o b.o c.o -o myprogram

Note that program execution starts in the first object on the command line.

Also keep in mind I use Devpac, not a newfangled cross assembler

Makes no difference.

Originally Posted by StingRay

Includes can and should contain any kind of code. For example, I include the complete system-kill/startup code at the top of my source which makes it much more readable as the startup code is neatly hidden and not interesting to look at anyway when coding effects.

Exactly. That's the same reason for putting these routines into object files. The only difference is: with the object file I have a clearly defined interface (xdef-symbols), while you are cluttering your symbol name space and therefore have to remember all symbol names from your included sources.

Why bloat the source with "standard" code when it can be easily included?

Nobody wants to bloat the source with standard code!

Originally Posted by meynaf

ReadJoypad.s is probably too small to count for anything in assembly time...

Sure. But this will change when the project grows.

Using a linker has a small issue, it is that you'll generate slightly suboptimal code because some information (some of the offsets) will not be known at assembly time and therefore the assembler can't use its full peephole optimization power

Depending on what you put into the objects this may happen, but usually an object file will be a more or less autonomous part of your code. For example trackdisk-routines, protracker-player, joystick/kbd-handler, BOB-routines, etc.. There shouldn't be much references between them and optimization works as usual.

Otherwise I see no suboptimal code at all. You can still call these routines with BSR, or do PC-relative or small-data references, as if the exported symbols had been "included".

Your only issue will be that you might lose 2 bytes between object from time to time, because AmigaDOS hunk sizes are always a multiple of 4.

[meynaf]

Originally Posted by phx

Exactly. That's the same reason for putting these routines into object files. The only difference is: with the object file I have a clearly defined interface (xdef-symbols), while you are cluttering your symbol name space and therefore have to remember all symbol names from your included sources.

Cluttering the symbol name space is easy to fix by simple prefixing of symbols.
On the other hand, in object files you can not make adaptative code (i.e. code that will open only the libs the program really uses, etc). I mean, no if/endc depending on something defined in the main program.

Originally Posted by phx

Sure. But this will change when the project grows.

Not when the program grows ; only when the included file itself grows in a significative manner, which is unlikely to happen in this case (and with a fast enough asm on a fast enough machine, it needs to be really big to count : PhxAss on WinUae JIT can assemble a 1MB asm source in less than 1 second !).

Originally Posted by phx

Depending on what you put into the objects this may happen, but usually an object file will be a more or less autonomous part of your code. For example trackdisk-routines, protracker-player, joystick/kbd-handler, BOB-routines, etc.. There shouldn't be much references between them and optimization works as usual.

This is why i wrote "slightly" before "suboptimal"

Originally Posted by phx

Otherwise I see no suboptimal code at all. You can still call these routines with BSR, or do PC-relative or small-data references, as if the exported symbols had been "included".

Your only issue will be that you might lose 2 bytes between object from time to time, because AmigaDOS hunk sizes are always a multiple of 4.

If the linker generates different hunks for different objects, then it's more than 2 bytes from time to time. There is no possible BSR anymore, only JSR with a reloc for every call. If the included file is, say, a memory manager for example, every alloc/free will generate a long call with a reloc...

In addition, attempts to have them called with PC-relative modes may fail in big projects, where the called module is at the limit of the allowed range (a likely story in a large program where the included code can be called from anywhere). What happens if the linker wants to write 16-bit PC offset but the distance is >32kb ? A good asm can adapt to this. But even the best linker in the world can't do better than generating an error.

[phx]

Originally Posted by meynaf

On the other hand, in object files you can not make adaptative code (i.e. code that will open only the libs the program really uses, etc). I mean, no if/endc depending on something defined in the main program.

No, because there is an even better way: it's called linker-library!

Just put your routines, which you want to link on demand, in separate object files. Then put all these objects into a library - e.g. myroutines.lib. When linking your main program with -lmyroutines only those objects will be included where the linker has seen references to its symbols.

And for automatically opening/closing libraries there is a linker-feature called constructor/destructor lists. For example, your program references GfxBase and the linker pulls an object into the linking process which adds a constructor pointer for opening graphics.library. The only thing you have to do is processing the constructor/destructor function pointer lists in your startup code.

If the linker generates different hunks for different objects, then it's more than 2 bytes from time to time.

The linker only does what you tell it to do. Sections with the same name from two different objects will be merged.

There is no possible BSR anymore, only JSR with a reloc for every call.

Not true. See above. Just give all your code sections the same name and happily use BSR and PC-relative addressing between the objects.

In addition, attempts to have them called with PC-relative modes may fail in big projects, where the called module is at the limit of the allowed range (a likely story in a large program where the included code can be called from anywhere). What happens if the linker wants to write 16-bit PC offset but the distance is >32kb ?

The linker will generate an error. You will have the same error in a monolithic assembler source, as long as your assembler doesn't do automatic PC-relative to abs32 translations. But usually you want to know about these cases and fix them.

A good asm can adapt to this.

Right. Often it will be sufficient to shuffle some objects around on the command line.

As a conclusion for Akira I can only say he has to make his own experiences and find his personal best approach. As we can see there are several options, and as they are used by excellent coders like Stingray and Meynaf since many decades they cannot be all that wrong.

Everybody has to find his personal priorities.

[meynaf]

Originally Posted by phx

No, because there is an even better way: it's called linker-library!

Just put your routines, which you want to link on demand, in separate object files. Then put all these objects into a library - e.g. myroutines.lib. When linking your main program with -lmyroutines only those objects will be included where the linker has seen references to its symbols.

And for automatically opening/closing libraries there is a linker-feature called constructor/destructor lists. For example, your program references GfxBase and the linker pulls an object into the linking process which adds a constructor pointer for opening graphics.library. The only thing you have to do is processing the constructor/destructor function pointer lists in your startup code.

It's not only about routines put on demand and init/exit code. It's about real adaptative code, with constants set in the main program and used in the included part, that change something there. F.e. you call some of your internal API but don't use one of its feature - the entry point is there but the routine's code will change.

Originally Posted by phx

The linker only does what you tell it to do. Sections with the same name from two different objects will be merged.

That may spare some relocs but won't solve the problem for routines that end up out of reach with relative modes.

Originally Posted by phx

Not true. See above. Just give all your code sections the same name and happily use BSR and PC-relative addressing between the objects.

But I don't want to do that. I want the asm to choose between BSR and absolute JSR automatically.

Originally Posted by phx

The linker will generate an error. You will have the same error in a monolithic assembler source, as long as your assembler doesn't do automatic PC-relative to abs32 translations. But usually you want to know about these cases and fix them.

You don't need PC-relative to abs32 translations, actually, quite the opposite. Just write JSR and let the asm decide if it's BSR.S, BSR.W, BSR.L, or JSR abs32. This is what i'm doing, and in a macro. A linker can't replace that.

Originally Posted by phx

Right. Often it will be sufficient to shuffle some objects around on the command line.

May work for a project that's right at the limit. But not for very large projects. I prefer solutions that work everywhere.

Originally Posted by phx

As a conclusion for Akira I can only say he has to make his own experiences and find his personal best approach. As we can see there are several options, and as they are used by excellent coders like Stingray and Meynaf since many decades they cannot be all that wrong.

Everybody has to find his personal priorities.

Sure everyone has personal preferences.
But someone like Akira needs the simplest solution to start with. Fiddling with linkers is too much to learn at once i'm afraid - and looks overkill for simple ReadJoypad.s.

There is something to learn here though : no two programmers will ever agree on how things must be done

[Amiga1992]

Originally Posted by phx

As a conclusion for Akira I can only say he has to make his own experiences and find his personal best approach. As we can see there are several options, and as they are used by excellent coders like Stingray and Meynaf since many decades they cannot be all that wrong.

Everybody has to find his personal priorities.

Yes, and I appreciate the discussion you guys have had here over this matter. Truly each one has their way of doing things and despite most of this going over my head at the moment because my level of knowledge in the matter is very low, I like to read the conversation and will be able to reference back to it when I need it!

Maybe unlike other people, I don't like to get offered "the simplest solution" only, I like to read all the options and then do a comfortable average of what I researched as my solution. So this thread has been very educational with the perspective of three experienced programmers.

For the time being I will probably not deal with linking because I can barely compile :P but it seems like a powerful tool to consider in the near future.

[Crank]

I decided to learn how to use joystick. It required reading lots of manuals and hunting down some example codes before I managed to get anything working. To make life easier for the other newbies like me, here's a simple example how to read joystick:

------

#include <stdio.h>

#define REG_CIAA_PRA_R *((volatile const unsigned char*) 0xBFE001)
#define REG_CIAA_DDRA *((volatile unsigned char*) 0xBFE201)
#define REG_JOY1DAT_R *((volatile const unsigned short*) 0xDFF00C)


int main()
{
// Clear bits 6 & 7 in CIAA DDRA --> PRA0 bits 6 & 7 are in input mode (fire buttons)
REG_CIAA_DDRA &= ~((1 << 6) | (1 << 7));

while (1)
{
const unsigned short joystick_bits = REG_JOY1DAT_R;
const unsigned short joystick_vert_bits = 2*(joystick_bits & 0x0101);
const unsigned short joystick_up_down = (joystick_bits & 0x0202) ^ joystick_vert_bits;

if (joystick_up_down & 0x0200)
printf("UP ");

if (joystick_up_down & 0x0002)
printf("DOWN ");

if (joystick_bits & 0x0200)
printf("LEFT ");

if (joystick_bits & 0x0002)
printf("RIGHT ");

if (!(REG_CIAA_PRA_R & 0x80))
printf("FIRE ");

printf("\n");
}

return 0;
}

[OmegaMax]

I'm handling JoyStick Pressed very simply in a tutorial I'm writing

  move.w $dff00c,d0
  move.w d0,d1
JoyStickRight:  
  btst #1,d0
  beq JoyStickLeft
  add.w #2,Bob_XPosition
JoyStickLeft:
  btst #9,d0
  beq JoyStickUp
  sub.w #2,Bob_XPosition
JoyStickUp:
  lsr.w #1,d1
  eor.w d1,d0
  btst #0,d0
  beq JoyStickDown 
  add.w #2,Bob_YPosition
JoyStickDown:
  btst #8,d0
  beq JoyPressedDone
  sub.w #2,Bob_YPosition
JoyPressedDone:
  rts