Error "No object" generating executable from ASM-One 1.20

[nandius_c]

Hi there,

I'm trying to generate an executable from ASM-One 1.20. I assemble the source ('a') and the write the object ('wo test.o') but it keeps saying "No Object". I have read this thread (eab.abime.net/showthread.php?t=37243&page=1) and it all works perfect with the moveq example... I have 'LOAD', 'ORG' and 'JUMPPTR' at the beginning of my source code and I use 'EVEN' and 'SECTION chip, BSS_C' also.

Can anybody help me with this, please?

Thanks!

[StingRay]

Remove the LOAD/ORG directives as ASM-One can't create an executable when these are used (there's no way to tell AmigaDOS to load to the specified address). If you really need to use absolute addresses you need to save your code as binary and then either crunch it with a cruncher that supports absolute address binaries or create the header yourself and generate the executable.

[nandius_c]

Originally Posted by StingRay

Remove the LOAD/ORG directives as ASM-One can't create an executable when these are used (there's no way to tell AmigaDOS to load to the specified address). If you really need to use absolute addresses you need to save your code as binary and then either crunch it with a cruncher that supports absolute address binaries or create the header yourself and generate the executable.

Thanks, StingRay! If I remove LOAD and ORG I get this error: "Relative mode error" pointing to this instruction (I've got plenty of these in the copper list):

dc.w $120,(Spr0_Pad>>16)&$ffff
...

As it is said in ASM-One manual:

"39. Relative Mode Error

If try to use a relativ value as a constant (e.g. word size or in
calculations other than »+ -«) this is the error message you will
get."

How could I solve this?

Thanks again!

[Photon]

Since you have removed the statements that fixate the program in a specific place in memory, the calculation on this line has no value for "Spr0_Pad". You have to poke it when the program is running.

To do this, remove the calculation causing the error and put a 0 instead. Add a unique label before that copper line, and put a # before the calculation and poke it to that label+2:

	move.w #(Spr0_Pad>>16)&$ffff,SprP00+2
...

SprP00:	dc.w $120,0 ;<--calculation was here

The line that pokes the copper must be put at the start of your program, so that it has been executed before you start the copper list.

[StingRay]

Originally Posted by Photon

Since you have removed the statements that fixate the program in a specific place in memory, the calculation on this line has no value for "Spr0_Pad".

Not really true, this is more or less an ASM-One bug/limitation. It doesn't matter where something is located, you can always divide by 65536 (i.e. swap) to get the high word of something. That this calculation has no value isn't true.

[phx]

Hmm... I tend to disagree with both of you.

It is neither true that the expression with Spr0_Pad cannot be evaluated nor is it correct that this is an AsmOne bug or limitation.

The problem only appears when creating an executable, because the AmigaDOS hunk file format has no relocation type to represent the high-word of an address (assuming Spr0_Pad is a label in this source and not an equate).

[Photon]

Evaluation, reloc, hunk... these are all pretty abstract to a new coder.

Starting to talk about them would make a simple problem confusing. It's better to explain the assembler doesn't know the value yet. Each assembler's different types of temporary internal work-values for its labels is pretty irrelevant to the problem at hand.

[nandius_c]

Originally Posted by Photon

Since you have removed the statements that fixate the program in a specific place in memory, the calculation on this line has no value for "Spr0_Pad". You have to poke it when the program is running.

To do this, remove the calculation causing the error and put a 0 instead. Add a unique label before that copper line, and put a # before the calculation and poke it to that label+2:

    move.w #(Spr0_Pad>>16)&$ffff,SprP00+2
...

SprP00:    dc.w $120,0 ;<--calculation was here

The line that pokes the copper must be put at the start of your program, so that it has been executed before you start the copper list.

Thanks Photon! However, it hasn't worked... I've done what you said but I get the same error, now in the line that pokes the addresses into the copper list... Any ideas?

[Photon]

Yes, how stupid of me. I did teach how to poke the Logo bitplane pointers in this same tutorial 11, though.

You do the same here, except if you only have a single pointer to poke you don't need a loop.

To set a sprite pointer, change to:

move.l #Spr0_Pad,d0
swap d0
move.w d0,SprP00+2
swap d0
move.w d0,SprP01+2

...

SprP00: dc.w $120,0
SprP01: dc.w $122,0

The logo bpl pointer poke loop was warm-up for the cleanup of the source. Be patient and await the next tutorials, because I'm very busy now.

[nandius_c]

Originally Posted by Photon

Yes, how stupid of me. I did teach how to poke the Logo bitplane pointers in this same tutorial 11, though.

You do the same here, except if you only have a single pointer to poke you don't need a loop.

To set a sprite pointer, change to:

move.l #Spr0_Pad,d0
swap d0
move.w d0,SprP00+2
swap d0
move.w d0,SprP01+2

...

SprP00: dc.w $120,0
SprP01: dc.w $122,0

The logo bpl pointer poke loop was warm-up for the cleanup of the source. Be patient and await the next tutorials, because I'm very busy now.

Now I'm able to assemble without errors and (after removing LOAD and ORG) generate the executable. BUT there must be something else because if I leave LOAD and ORG screen gets drawn and everything works perfect, but if I remove them I just get an empty screen (though I can still exit with keys and mouse). I'm trying to figure out the problem but any suggestion would be welcome.

[Photon]

What you're doing is adapting a whole source in the middle of its development. The reason it's doesn't work to write an object file from it is because it isn't made for that yet. I've briefly shown the SECTION statements to warm viewers up for the change. Likely you just need to add SECTION mydemo,CODE_C at the start and it will work. If you still get problems, you need to link or attach your source.

[StingRay]

Originally Posted by phx

Hmm... I tend to disagree with both of you.

It is neither true that the expression with Spr0_Pad cannot be evaluated nor is it correct that this is an AsmOne bug or limitation.

The problem only appears when creating an executable, because the AmigaDOS hunk file format has no relocation type to represent the high-word of an address (assuming Spr0_Pad is a label in this source and not an equate).

It is an ASM-One limitation because it can not resolve this properly even if absolute addresses are used and the data is in the same section. Other than that you are correct of course.

Originally Posted by Photon

Starting to talk about them would make a simple problem confusing. It's better to explain the assembler doesn't know the value yet. Each assembler's different types of temporary internal work-values for its labels is pretty irrelevant to the problem at hand.

In my opinion it is better to also give the reason so he can solve similar problems on his own next time! And he will have to deal with hunks, relocations and all that stuff sooner or later anyway.

Originally Posted by nandius_c

Now I'm able to assemble without errors and (after removing LOAD and ORG) generate the executable. BUT there must be something else because if I leave LOAD and ORG screen gets drawn and everything works perfect, but if I remove them I just get an empty screen (though I can still exit with keys and mouse). I'm trying to figure out the problem but any suggestion would be welcome.

This is probably because the code assumes that the screen is located at a fixed address (often done to speed up some effects since if the screen is aligned only the low word needs to be modified). Can you upload your source somewhere? Would make it easier to check.

[nandius_c]

Originally Posted by Photon

What you're doing is adapting a whole source in the middle of its development. The reason it's doesn't work to write an object file from it is because it isn't made for that yet. I've briefly shown the SECTION statements to warm viewers up for the change. Likely you just need to add SECTION mydemo,CODE_C at the start and it will work. If you still get problems, you need to link or attach your source.

Thanks again, Photon! It worked! Though I guess that having CODE_C at the beginning of the code is not the best idea for the final version. But it's OK for me at this moment as the only thing I needed was generating the executable so that I can send it to the person who is doing the graphics for the game. Later on I hope I will be able to find the right solution, with some help, probably...