Problem with VASM - file is not an object module on A500, ok on A1200???

[mcgeezer]

I have a really odd problem that I haven't been able to get fixed after a few hours banging my head and I'm hoping someone could give some insight.

I have a source file which compiles fine, if I run it on a WinUAE A1200 config it runs fine, if I run it with A500 config I get an error "file is not an object module from workbench".

I can only imagine it's something to do with Vasm flags.

vasm -Fhunkexe -I C:\Development\Scroller\Include -o C:\Emulators\Commodore\Amiga\HardDrive\A500_TestRig\ToolChain\test.exe C:\Development\Scroller\main.asm

Can anyone shed any light? I didn't seem to have this problem when I was compiling Bomb Jack... very odd.

Cheers,
Geezer

[roondar]

Originally Posted by mcgeezer

I have a really odd problem that I haven't been able to get fixed after a few hours banging my head and I'm hoping someone could give some insight.

I have a source file which compiles fine, if I run it on a WinUAE A1200 config it runs fine, if I run it with A500 config I get an error "file is not an object module from workbench".

I can only imagine it's something to do with Vasm flags.

vasm -Fhunkexe -I C:\Development\Scroller\Include -o C:\Emulators\Commodore\Amiga\HardDrive\A500_TestRig\ToolChain\test.exe C:\Development\Scroller\main.asm

Can anyone shed any light? I didn't seem to have this problem when I was compiling Bomb Jack... very odd.

Cheers,
Geezer

The first thing that springs to my mind is that some hunk types are not compatible with Kickstart 1.3. If you use BSS or similar sections this might cause trouble.


I usually use: vasm -kick1hunks -Fhunk
That should force Kickstart 1.3 compatible hunks.

Edit: -Fhunk is for further linking, so it should be -Fhunkexe in your case.

[mcgeezer]

Originally Posted by roondar

The first thing that springs to my mind is that some hunk types are not compatible with Kickstart 1.3. If you use BSS or similar sections this might cause trouble.


I usually use: vasm -kick1hunks -Fhunk
That should force Kickstart 1.3 compatible hunks.

Edit: -Fhunk is for further linking, so it should be -Fhunkexe in your case.

Buddy - that was totally the issue, THANKYOU!!!!

I have no idea why I did not run into that when making Bomb Jack... really really weird.

If I post the source would we be able to understand why?

[roondar]

Well, maybe - I'm not actually an expert on object files. Never looked into how that works t.b.h.

The VASM manual says that some types of relocation don't work under KS 1.3, but I don't know when these are created (as in, I do understand when relocations are created, just not why the linker would choose one type over another). Perhaps it'll shed some light on the matter?

Originally Posted by VASM Manual

‘-kick1hunks’

Use only those hunk types and external reference types which have been valid at the time of Kickstart 1.x for compatibility with old assembler sources and old linkers. For example: no longer differentiate between absolute and relative references. In executables it will prevent the assembler from using 16-bit relocation offsets in hunks and rejects 32-bit PC-relative relocations.

[hmn]

Originally Posted by mcgeezer

If I post the source would we be able to understand why?

Look at the binary, does it start with $03f3 ? That is the header block id for executables (load files), whereas $03e7 is the header block id for linkable files. I would be really surprised if the loader on KS 1.3 accepted anything but the former.

EDIT: disregard - I mis-read roondar's reply and thought the problem was with -Fhunkexe.

[phx]

When the program still assembles without error using -kick1hunks, then it cannot be an OS2+ specific relocation which was in use. So I am quite sure that the first executable just contained a HUNK_RELOC32SHORT hunk with 16-bit offsets for relocations, which is unknown to Kickstart 1.x, and which is the default without -kick1hunks (because it saves much space).


That the problem didn't appear with Bomb Jack might have several reasons. Maybe the sections offsets were too big for HUNK_RELOC32SHORT, or there were too many, or none at all? Or you linked the final executable from multiple object files with a different linker or different options?