Newbie query on assembling an intro on VASM

[RoC]

Hello,

Totally new to VASM assembly, so if my question is too simple or stupid please bear with me, because I am certainly doing something wonky

I have been testing the https://github.com/mnemo70/paranoimia-vector-logo on the latest VASM with the Amiga VSCode toolchain https://github.com/prb28/vscode-amiga-assembly

By the way, kudos to all the above people for the great work!

Since the code has been Re-Sourced for Asm-One, the PNO source assemble and runs just fine on Asm-One v1.20 on the WB 1.3. I am using the v1.20 only because the intro runs on KS 1.3, I guess the Asm-One v1.48/1.49 would work too.

Now the question. This is meant more to learn how this works on vasm rather than getting that specific intro working.

When compiling the source on vasm, I get several "unsupported on CPU". No probs, I have added the following and it assembles fine.
For simplicity, I list only one occurence per intruction. They all seem related to long-words.

    mc68020
     bne.l    .notzero
    mc68000
    
    mc68020
    bmi.l    lbc00037c
    mc68000
    
    mc68020
    beq.l    lbc0002d0
    mc68000
    
    mc68020
    bpl.l    lbc000468
    mc68000
    
    mc68020
    ble.l    reinit_starpos
    mc68000
    
    mc68020
    blt.l    reinit_starpos
    mc68000
    
    mc68020
    bgt.l    reinit_starpos
    mc68000

    mc68000
    cmpi.w    #255,d5
    mc68000

    mc68020
    bgt.l    reinit_starpos
     mc68000

Nevertheless, I keep getting the guru on the A500 emulated machine.

I know this is a bit newbie to ask, but any suggestions if it could be possible to get this linked fine?

Thank you in advance if someone could help a little

These are the VASM settings that I have tried. The VScode in ASM compatibility mode.

"-linedebug",
"-Fhunkexe",
"-m68000",
"-devpac

I tried to add the following but to success:

"-nosym",
"-kick1hunks"

The vlink settings are the following:

	
    "-bamigahunk",
    "-Bstatic"

Please find attached the "mc68020" amended version for your ease of reference that assembles on vasm but guru on the emulated A500 68000 KS 1.3 test with cycle-exact - i.e. a typical vanilla A500 of the good old days

[a/b]

32-bit relative branches (bcc.l, bsr.l, bra.l) require a 68020+ cpu. A500 is typically equipped with a 68000. Use jsr/jmp instead, or try to convert to 16-bit .w (destination must be within +/- 32KB).

[meynaf]

What does it say if instead of :

    mc68020
     bne.l    .notzero
    mc68000

You do :

     bne    .notzero

(and this for all cases, obviously)

As the "mc68020" directive says, long branches won't work on 68000 and so they crash on emulated A500.

EDIT:
a/b was faster

[RoC]

Hi a/b

Thanks, this is helpful

So the first advise would be converting to a 16-bit range, I will make it a try.

Hi Meynaf,

I will test that too

[StingRay]

Assemble the source with ASM-One using the "optimise" option (i.e. use AO instead of just A), it should fix the long branches. Then save the source and it should assemble fine with VASM too.

[phx]

Early 80s 68000 assemblers, like the infamous Seka, used

.s

for short branches and

.l

for long branches. With short and long they meant 8-bit and 16-bit distances, as nothing else was possible on the 68000.

Correct would be

.b

for 8-bit and

.w

for 16-bit branches, of course, as documented by Motorola. At least my 1989 edition of the M68k PRM doesn't know about short or long branches.

The

.s

can still be found in many sources, but

.l

has really become a problem since the introduction of the 68020, which was already quite a few years ago...

So I'm surprised that ReSource generates such output.
EDIT: And I'm equally surprised that AsmOne accepts that (like Seka!). Or does it automatically treat .l as .w in 68000 mode?

[StingRay]

Originally Posted by phx

So I'm surprised that ReSource generates such output.

I do not think this is the original ReSource output, the source has probably been modified.

Originally Posted by phx

EDIT: And I'm equally surprised that AsmOne accepts that (like Seka!). Or does it automatically treat .l as .w in 68000 mode?

Long branches will be silently "converted" to the correct .w version. When using AO (A.ssemble O.ptimise(d)), the branch will be converted to .w ("Branch forced to word size") and the source will be changed accordingly.

[Don_Adan]

Originally Posted by StingRay

I do not think this is the original ReSource output, the source has probably been modified.



Long branches will be silently "converted" to the correct .w version. When using AO (A.ssemble O.ptimise(d)), the branch will be converted to .w ("Branch forced to word size") and the source will be changed accordingly.

This is original ReSource 5/6 output. ReSource has 2 options. New Syntax (correct handling for size of branches) and Old Syntax (.s and .l handling for branches). I personally prefer .b than .s for handling 8 bits branches, this is much logical for me. But many sources/coders mixed size of branches.

[RoC]

Gents,

Many thanks for the many good ideas

I am going to explore all the different routes, because the scope is to learn.

Will let you know

[StingRay]

Originally Posted by Don_Adan

This is original ReSource 5/6 output.

The intro runs on 68000, thus I do not think it is original ReSource output.

I personally prefer .b than .s for handling 8 bits branches, this is much logical for me.

I also prefer the distance specifier with .b, it makes perfect sense, whereas .s leaves room for interpretation.

[Don_Adan]

When I was active, then i was used Asmone 1.20. Asmone 1.20 has no problem for assembling .l branches as .w branches. Devpac has no problems too, but many warnings was displayed. In general I prefer code in Old Syntax look (with New Syntax for branches) , because is shortest (less signs), fastest for assembling and its easiest to understand for me. Then later i dissasemble players with Resource 5 in Old Syntax mode, load resourced source in CED, and autoreplace .l branches with .b branches (Devpac warnings was used which branches must be replaced)