Issues with ORG directive (vasm + FS-UAE)

Hi!
I am trying to learn the basics of Amiga programming by following along with ScoopexUs' video tutorial on Yotutube.
https://www.youtube.com/playlist?lis...hTKJnjdTHz0_bW

I am using vasm and running the program in FS-UAE, which has been working great until part 7 where the ORG/LOAD/JUMPPTR directives are included.
This causes warnings when assembling with vasm and does not work at all in FS-UAE (only a blank screen is displayed when running the program).

This is the source code in question (i had to make the Copper: label lowercase since vasm appears to be case sensitive)
http://coppershade.org/asmskool/Tut7.S

Assembling:

$ vasmm68k_mot -Fhunkexe -kick1hunks -o hd0/tutorial Tut7.S 
vasm 1.8d (c) in 2002-2018 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.3c (c) 2002-2018 Frank Wille
vasm motorola syntax module 3.11d (c) 2002-2018 Frank Wille
vasm hunk format output module 2.9b (c) 2002-2017 Frank Wille

warning 1012 in line 2 of "Tut7.S": directive has no effect
>	LOAD $20000

warning 1012 in line 3 of "Tut7.S": directive has no effect
>	JUMPPTR init

seg20000(acrwx2):	         266 bytes

I then run it with the following command:

/usr/bin/fs-uae --amiga_model=A500 --hard_drive_0=hd0 --joystick_port_1=none --chip_memory=512 --slow_memory=512

If i remove the ORG/LOAD/JUMPPTR directives and add a SECTION tutdata,DATA_C above the copperlist it works correctly, this does however not work later in the tutorial.

Could anybody help me understand why this is not working?
Apologies if this is in the wrong forum since i'm not sure exactly where the problem is.

[phx]

Originally Posted by Maggot

working great until part 7 where the ORG/LOAD/JUMPPTR directives are included.

LOAD and JUMPPTR only make sense when running an assembler natively on the Amiga. But vasm is a portable cross-assembler, so they are disabled. The effect of the LOAD directive would be to write the assembled code directly into memory at $20000.

(i had to make the Copper: label lowercase since vasm appears to be case sensitive)

Option -nocase makes vasm case-insensitive.

Assembling:

$ vasmm68k_mot -Fhunkexe -kick1hunks -o hd0/tutorial Tut7.S

What you could do as a workaround, to have the same effect: Write a binary file with "-Fbin". Then load this binary file with a monitor program into your Amiga at $20000 and start it at $20000.

i remove the ORG/LOAD/JUMPPTR directives and add a SECTION tutdata,DATA_C above the copperlist it works correctly,

Right, you only have to make sure that the copper list is in Chip RAM (although it should be CODE_C when the section contains executable code).

It would also be sufficient to write this SECTION directive one line above the Copper: label. The code also works in Fast RAM.

this does however not work later in the tutorial.

Perhaps later tutorials additionally expect that data (graphics or copper lists) at a fixed address in Chip RAM (like $20000).

Thank you for your reply.

Perhaps later tutorials additionally expect that data (graphics or copper lists) at a fixed address in Chip RAM (like $20000).

The next issue appears in part 9:
http://coppershade.org/asmskool/Tut9.S

Assembling this causes the the above mentioned errors, removing ORG/LOAD/JUMPPTR instead causes the following errors:

$ vasmm68k_mot -Fhunkexe -kick1hunks -nocase -o hd0/tutorial Tut9.S 
vasm 1.8d (c) in 2002-2018 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.3c (c) 2002-2018 Frank Wille
vasm motorola syntax module 3.11d (c) 2002-2018 Frank Wille
vasm hunk format output module 2.9b (c) 2002-2017 Frank Wille

error 39 in line 149 of "Tut9.S": illegal relocation
>	dc.w $120,(Spr>>16)&$ffff

error 39 in line 150 of "Tut9.S": illegal relocation
>	dc.w $122,(Spr)&$ffff

error 39 in line 152 of "Tut9.S": illegal relocation
>	dc.w $124,(NullSpr>>16)&$ffff

error 39 in line 153 of "Tut9.S": illegal relocation
>	dc.w $126,(NullSpr)&$ffff

error 39 in line 154 of "Tut9.S": illegal relocation
>	dc.w $128,(NullSpr>>16)&$ffff
***maximum number of errors reached!***

I tried putting section directives above the init: and Spr: labels with CODE_C and/or DATA_C but it doesn't seem to make a difference.

Originally Posted by Maggot

I am using vasm and running the program in FS-UAE, which has been working great until part 7 where the ORG/LOAD/JUMPPTR directives are included.
This causes warnings when assembling with vasm and does not work at all in FS-UAE (only a blank screen is displayed when running the program).

Hi, I did have the same problem. Did you check if the memory adres $20000 is available in your current configuration. Maybe you have some applications running in your emulator that uses the same address space. Scoopex mentions a utility in this tutorial that you can use for that (chipmap: http://scoopex1988.org/utilities.html). When I used chipmap I discovered that memory space $20000 was occupied in my situation, so I use $30000 instead and then everything is working fine.
I must say that I don't use vasm, but I use ASM-ONE (editing my code on my Mac in Atom, which I think is a nice workflow).

[phx]

Originally Posted by Maggot

error 39 in line 149 of "Tut9.S": illegal relocation
>    dc.w $120,(Spr>>16)&$ffff

The problem here is what the error message says: When you don't use ORG for absolute code and let vasm create a relocatable AmigaDOS executable instead, you have to make sure that all label-references can be represented by legal relocation types in the AmigaOS hunk format.

"Spr" is such a reference, which would have to be relocated by the OS loader (dos.library LoadSeg()) when running the executable. Legal relocations are usually something like Label+Addend, but here we have (Label>>16)&$ffff!

This can only work in absolute code, while loaded and executed at a fixed address.

I tried putting section directives above the init: and Spr: labels with CODE_C and/or DATA_C but it doesn't seem to make a difference.

No. See above.

There are several workarounds. Either rewrite the code, so that you insert these addresses like Spr into the copper list during runtime. Or prepend a startup routine to the code, which copies everything to $20000, when the program is started (you probably also want to AllocAbs() this region, while being at it). Example:

        section code,code

        lea     start(pc),a0
        lea     $20000,a1
        move.w  #(end-start)/2-1,d0
.copy:  move.w  (a0)+,(a1)+
        dbf     d0,.copy
        jmp     $20000

start:
        ORG $20000
;       LOAD $20000
;       JUMPPTR init

w       =320
h       =256
bplsize =w*h/8

screen  =$60000

init:
        move.l 4.w,a6            ;execbase
        ...
        section code,code
end:

ORG inside a section is allowed (not all assemblers do that), and creates an absolute code block inside a relocatable section.

creativecoder: i tried chipmap a while back, but it didn't return any output when i ran it directly in AmigaDos (A500/KS 1.3). I didn't investigate it any further.
Do you save the source file from Atom and assemble it on the Amiga using ASM-ONE?
I use vscode with the "Amiga Assembly" extension which has quite a few nice features like assembling on save and being able to launch FS-UAE directly from the editor.

phx: thank you for the explanation and examples! I will play around with it and see if i can make it work.

Originally Posted by Maggot

Do you save the source file from Atom and assemble it on the Amiga using ASM-ONE?.

Yes, I use Atom with the 'language-m68k' package and the source code is saved in a folder that is an attached harddisk in the emulator. So I assemble the same source file in ASM-ONE.

Originally Posted by Maggot

I use vscode with the "Amiga Assembly" extension which has quite a few nice features like assembling on save and being able to launch FS-UAE directly from the editor.

Sounds nice! Working on a Mac or PC?

[leissler]

Originally Posted by phx

There are several workarounds. Either rewrite the code, so that you insert these addresses like Spr into the copper list during runtime. Or prepend a startup routine to the code, which copies everything to $20000, when the program is started (you probably also want to AllocAbs() this region, while being at it). Example:

        section code,code

        lea     start(pc),a0
        lea     $20000,a1
        move.w  #(end-start)/2-1,d0
.copy:  move.w  (a0)+,(a1)+
        dbf     d0,.copy
        jmp     $20000

start:
        ORG $20000
;       LOAD $20000
;       JUMPPTR init

w       =320
h       =256
bplsize =w*h/8

screen  =$60000

init:
        move.l 4.w,a6            ;execbase
        ...
        section code,code
end:

ORG inside a section is allowed (not all assemblers do that), and creates an absolute code block inside a relocatable section.

Wouldn't the workaround with the startup code copying everything to $20000 be dangerous, as you don't know if the startup code itself is somewhere in that area?

[phx]

Originally Posted by leissler

Wouldn't the workaround with the startup code copying everything to $20000 be dangerous, as you don't know if the startup code itself is somewhere in that area?

Yes, absolutely! That's why I wrote that you should better try to allocate this memory region with

AllocAbs()

first.

IMHO absolute RAM addresses should only be used if you take over the system completely, and the only way to return to the OS is by reboot.

[leissler]

Originally Posted by phx

Yes, absolutely! That's why I wrote that you should better try to allocate this memory region with

AllocAbs()

first.

IMHO absolute RAM addresses should only be used if you take over the system completely, and the only way to return to the OS is by reboot.

What workflow would be your recommendation if you'd want to completely take over (demoscene style) and then reboot, while having fixed addresses?

[phx]

You can find many example sources on the net, for cleanly taking over the system.

At first I would use the OS to gather all useful information, like PAL/NTSC, CPU type, available memory and memory locations.

Then take over the system by loading a default View (

LoadView(NULL)

, 2x

WaitTOF()

), get the Blitter (

OwnBlitter(), WaitBlit()

), disable all DMA channels and interrupts, reset the chipset into default state (

FMODE=0

, set

BPLCONx

, etc). You may also have to disable the MMU (or set to transparent translation for 040/060).

After that you can completely use all system resources. Copy your code to absolute memory addresses, set exception vectors, use the custom chipset directly, etc. But this is the point of no return (to the OS).

The steps required will vary a little bit, when you need to load data. A single file with all data included could also be launched from Workbench, but otherwise I would recommend to write a trackloader for the boot block and do you own disk routines. The boot block approach also has the advantage that the system is in a more defined state, without any unknown hardware causing interrupts (like network cards, hard disk controllers, etc.).

[leissler]

Originally Posted by phx

You can find many example sources on the net, for cleanly taking over the system.

At first I would use the OS to gather all useful information, like PAL/NTSC, CPU type, available memory and memory locations.

Then take over the system by loading a default View (

LoadView(NULL)

, 2x

WaitTOF()

), get the Blitter (

OwnBlitter(), WaitBlit()

), disable all DMA channels and interrupts, reset the chipset into default state (

FMODE=0

, set

BPLCONx

, etc). You may also have to disable the MMU (or set to transparent translation for 040/060).

After that you can completely use all system resources. Copy your code to absolute memory addresses, set exception vectors, use the custom chipset directly, etc. But this is the point of no return (to the OS).

The steps required will vary a little bit, when you need to load data. A single file with all data included could also be launched from Workbench, but otherwise I would recommend to write a trackloader for the boot block and do you own disk routines. The boot block approach also has the advantage that the system is in a more defined state, without any unknown hardware causing interrupts (like network cards, hard disk controllers, etc.).

Yes, of course, I agree. The "taking over the system" is not the problem. That's been shown in several demos on GitHub.
It's more the "copy your code to absolute memory addresses" that's still a problem with a cross compiler like vasm.
With a trackloader that is under complete control, but for just quick testing of single parts of your code, the missing LOAD directive is still a problem. The OS loads your executable to an unknown position in memory. Copying it from there to a fixed address still has the problem of potentially dangerous overlap.

When I stopped working with Amiga games, we had 2-Amiga development systems, where one Amiga had a very small listener program that could receive code and data via cable and then execute it. So other than the small listener, we had complete memory available.

[phx]

Originally Posted by leissler

It's more the "copy your code to absolute memory addresses" that's still a problem with a cross compiler like vasm.

When is that not a problem?

for just quick testing of single parts of your code, the missing LOAD directive is still a problem.

If you cannot or do not want to test parts of absolute code together with the whole project, then I would write a small loader for that part.

The OS loads your executable to an unknown position in memory. Copying it from there to a fixed address still has the problem of potentially dangerous overlap.

I wouldn't call that a problem. Attach a "loader" at the beginning of your test code, which copies itself to a safe region, then copies your test code to the absolute destination address. To avoid the rare case that your test code overlaps you could just copy backwards, whenever the destination address is higher than the source.

When I stopped working with Amiga games, we had 2-Amiga development systems, where one Amiga had a very small listener program that could receive code and data via cable and then execute it. So other than the small listener, we had complete memory available.

Today you would probably cross-assemble and use an emulator for testing. You can have a Makefile or a script which builds the complete ADF, ready to run.

As an example, have a look at the full source of our last game project:
https://server.owl.de/~frank/BlkStberries.lha

[Photon]

The tutorials start with absolute addressing, to dispel some of the magic and empower coders: Your code, as well as your resources end up at specific addresses in memory.

Like Phx says, LOAD doesn't make much sense when cross-assembling, unless it's connected to an emulator which does have "Amiga memory".

For learning, this offers the benefits of showing what you did, examining variables, interpreting hex numbers to check values, etc.

This is only possible with a native Assembler which has a monitor, or running a Monitor program separately. You can also do it if the emulator has a debugger and monitor, but that would be very confusing, I think. The Amiga is a real computer and this is how your program is converted to real words in memory.

Native tools are more direct, and this directness offers further benefits, such as not having to reassemble all of your program, find the part of your program that crashed to the Assembler prompt with a message + crash address, and so on.

Since anyone who has a 1MB Amiga (preferably with an extra floppy drive) can code Assembler for the same spec, I wanted to show this. In this environment, using ORG, LOAD, and EXTERN will still let you reassemble in seconds on a 7MHz 68000. The tutorials are coded live on such a config.

So, LOAD doesn't make sense for a cross-assembler, but ORG can. The simplest example where fixed addresses are very helpful is for track-loaded programs and resources. In this environment, normally the OS is shut down completely and overwritten to use maximum memory.

In the tutorials leading up to the introduction of SECTION statements, you can replace ORG and LOAD at the top with a SECTION MyCode,C

[leissler]

Originally Posted by phx

When is that not a problem?

If you cannot or do not want to test parts of absolute code together with the whole project, then I would write a small loader for that part.

I wouldn't call that a problem. Attach a "loader" at the beginning of your test code, which copies itself to a safe region, then copies your test code to the absolute destination address. To avoid the rare case that your test code overlaps you could just copy backwards, whenever the destination address is higher than the source.

Today you would probably cross-assemble and use an emulator for testing. You can have a Makefile or a script which builds the complete ADF, ready to run.

As an example, have a look at the full source of our last game project:
https://server.owl.de/~frank/BlkStberries.lha

Wow, thanks! That looks like a nice coding framework you put together over the last couple of years. It will take me some time to digest on how you do things, but this looks super clean using a lot of XDEF and XREF with includes, making for some pretty tidy code. I even spotted an entity system for gameobjects/bobs in a linked list! Awesome stuff there.

[phx]

Originally Posted by leissler

It will take me some time to digest on how you do things

It's always hard to dig through somebody else's code, even if I tried to comment most of it. Feel free to ask, if you have any questions (preferably by email, if the question is not of common interest).

I even spotted an entity system for gameobjects/bobs in a linked list! Awesome stuff there.

Yes, much of it is reused in all of our games. Modules like ptplayer.asm or trackdisk.asm should easily fit into any other project.

I'm currently adapting this engine to 8-way scrolling again. I had it already running ten years ago (with the game "Solid Gold"), but with an inferior technique.