Latest Win32 VASM Build?

[clenched]

Here is my little laundry list of stuff. V1.7 no longer assembles the Solid Gold game. V1.6c is OK

vasmm68k_mot -Fvobj -quiet -x -DCOPPERBACK -DBOOTLOGO -DKILLOS -DTDFORMAT -I /ND
K_3.9/Include/include_i -o font.o font.asm

error 2030 in line 251 of "font.asm": displacement out of range
>       lea     -MENUFONT16W>>3(a1,d0.w),a2
make: *** [font.o] Error 1

C:\wsg>

Also on the 6502 oldstyle module I couldn't INCBIN a file > 32K. Earlier versions are the same way so maybe not a bug. It would be nice if that limit was lifted.

[phx]

Originally Posted by clenched

error 2030 in line 251 of "font.asm": displacement out of range
>       lea     -MENUFONT16W>>3(a1,d0.w),a2

Right. I decided to make the shift-right operator unsigned, to increase DevPac compatibility, although most other assemblers shift signed. I fixed the SolidGold source...

But, I have to admit that I'm no longer convinced that this is an improvement. I am open to hear the opinion of other 68k coders.

Also on the 6502 oldstyle module I couldn't INCBIN a file > 32K. Earlier versions are the same way so maybe not a bug. It would be nice if that limit was lifted.

That's a bug, which I didn't notice yet!
The size of a data block atom in vasm in stored using the taddr (target address) type, which is only 16-bit signed for 6502. Maybe I should just use int or size_t for that. Will think about it.

[Thorham]

Originally Posted by phx

Right. I decided to make the shift-right operator unsigned, to increase DevPac compatibility, although most other assemblers shift signed. I fixed the SolidGold source...

But, I have to admit that I'm no longer convinced that this is an improvement. I am open to hear the opinion of other 68k coders.

Make it a command line switch.

[StingRay]

What Thorham said. I'd expect signed shift to be default behaviour though.

Slightly OT: Thanks for the vasm TOS module, works great and I put it to good use for my Enduro Racer conversion!

[phx]

Ok, I reverted the change of V1.7, so right-shifts are signed again.
They will be unsigned in only two cases:
- the new option -unsshift was specified
- full Devpac compatibility mode (-devpac option)

Originally Posted by StingRay

Slightly OT: Thanks for the vasm TOS module, works great and I put it to good use for my Enduro Racer conversion!

Always glad to help.
The Atari scene uses vasm frequently as a cross-assembler, so I implemented TOS-support many years ago.

[StingRay]

Originally Posted by phx

Ok, I reverted the change of V1.7, so right-shifts are signed again.

Good decision!

Originally Posted by phx

Always glad to help.
The Atari scene uses vasm frequently as a cross-assembler, so I implemented TOS-support many years ago.

Well, meanwhile I got sidetracked and coded 3 demo effects for the ST using vasm! Since there is no ASM-One for Ataris and I hate Devpac with a passion I really didn't have much motivation for ST demo coding the last years, however, now that I tried vasm I can say it is extremely useful and makes cross-development really easy. Thanks again!

[Cyprian]

Hi Phx, first of all thanks for TOS and Devpac support in VASM. I use it since 2011 I am happy with it.
Well, back to my subject. I faced an issue with relocation and I'd like to report it. Where can I do that? Maybe is there any mailing list or dedicated forum?

[phx]

Bug reports always directly to me, by email.
There is no mailing list. I rarely get more than one vasm-related mail per day, which I can easily handle.

[Cyprian]

ok, just sent to phoenixowl

[clenched]

phx, I hope you can help me. V1.7e is behaving differently from what I am used to. All I need is a dependable way to retrieve the program ORG value. This has worked going back some time. Red text is all that is touched. Of course the aout produced in all cases is fine.

output_bin.c

    }
    else
      pc = ULLTADDR(s->org);
      /*asm ("int $3");*/
	  printf ("%x",pc); 

When I assemble some trivial 68k program ORG $100 I don't get 100 printed anymore.
1.7c

c:\vasm>vasmm68k_mot -Fbin \100.asm
vasm 1.7c (c) in 2002-2015 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.0f (c) 2002-2015 Frank Wille
vasm motorola syntax module 3.8 (c) 2002-2015 Frank Wille
vasm binary output module 1.8 (c) 2002-2009,2013,2015 Volker Barthelmann

seg100(acrwx2):          278 byte
100

1.7e

c:\vasm>vasmm68k_mot -Fbin \100.asm
vasm 1.7e (c) in 2002-2016 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.1 (c) 2002-2015 Frank Wille
vasm motorola syntax module 3.9 (c) 2002-2016 Frank Wille
vasm binary output module 1.8 (c) 2002-2009,2013,2015 Volker Barthelmann

CODE(acrx2):             278 byte
0

I can still get ORG from 6502.

c:\vasm>vasm6502_oldstyle  -Fbin \nop.asm
vasm 1.7e (c) in 2002-2016 Volker Barthelmann
vasm 6502 cpu backend 0.7a (c) 2002,2006,2008-2012,2014-2015 Frank Wille
vasm oldstyle syntax module 0.12e (c) 2002-2016 Frank Wille
vasm binary output module 1.8 (c) 2002-2009,2013,2015 Volker Barthelmann

seg100(acrwx1):            2 byte
100

[jotd]

Can someone zone a working Windows binary version ? I'd like to try that

Being a developper myself, I really don't understand why everyone want to build their own version with such or such compiler really, except if you want to change things to the code (which is risky)

I suppose a lot of people use windows and cannot use stuff because of stupid recompilation. Vamos is another example, with cython, different versions of C for python compiler and I'm stuck with various error messages, whereas someone could successfully build it for windows...

(thanks for this and phxass!)

[phx]

Originally Posted by clenched

phx, I hope you can help me. V1.7e is behaving differently from what I am used to. All I need is a dependable way to retrieve the program ORG value.

I changed the way ORG works in V1.7e, with the intention to allow absolute, relocated ORG-blocks within a normal section (Devpac supports that too). Now I have to admit that I missed something. Using multiple ORG directives in a raw binary output will no longer work this way.

So, I'm doing the following now: Whenever ORG follows a SECTION directive (or CODE, or DATA, etc.), then it works like in V1.7e, and the absolute code is embedded in that section. Otherwise I'm switching to the absolute section mode like in V1.7d and before.

Try the following patch (or wait until tomorrow's snapshot):

--- syntax/mot/syntax.c    2 Jan 2016 16:57:07 -0000    1.156
+++ syntax/mot/syntax.c    28 Mar 2016 10:39:58 -0000
@@ -12,7 +12,7 @@
    be provided by the main module.
 */
 
-char *syntax_copyright="vasm motorola syntax module 3.9 (c) 2002-2016 Frank Wille";
+char *syntax_copyright="vasm motorola syntax module 3.9a (c) 2002-2016 Frank Wille";
 hashtable *dirhash;
 char commentchar = ';';
 
@@ -495,8 +495,12 @@
     else
       syntax_error(7);  /* syntax error */
   }
-  else
-    start_rorg(parse_constexpr(&s));
+  else {
+    if (current_section!=NULL && !(current_section->flags & ABSOLUTE))
+      start_rorg(parse_constexpr(&s));
+    else
+      set_section(new_org(parse_constexpr(&s)));
+  }
 }

Originally Posted by jotd

Can someone zone a working Windows binary version ? I'd like to try that

Being a developper myself, I really don't understand why everyone want to build their own version with such or such compiler really

It is impossible for me to provide working executables for any possible host platform (I don't even have MacOSX or Windows compilers), so I'm just releasing the source.

[jotd]

Source is great by all means. Well, someone should provide the windows port. I can try if other people have the same need. After all windows is a widely spread platform.

[Leffmann]

Here's the latest version of the whole VBCC tool chain, with the above patch, and GNU Make 3.82. The binaries should run on Windows XP and all later versions.

[phx]

Originally Posted by jotd

Well, someone should provide the windows port. I can try if other people have the same need. After all windows is a widely spread platform.

I can compile for AmigaOS/MorphOS and NetBSD only.

Originally Posted by Leffmann

Here's the latest version of the whole VBCC tool chain, with the above patch, and GNU Make 3.82. The binaries should run on Windows XP and all later versions.

Tack så mycket! Much appreciated.

[jotd]

That's just great!! If someone can compile VAMOS for windows too that would just be even greater

[kamelito]

I did that but had to reinstall so it's lost
I remember a weird issue with 64bit, in order to build it you needed another file not available in the tools provided.

Kamelito

[Leffmann]

Originally Posted by jotd

That's just great!! If someone can compile VAMOS for windows too that would just be even greater

Extract this into the amitools directory, and add amitools/ to your path. If it doesn't work then you will have to build the Musashi DLL on your own system.

[clenched]

Thank you phx. It's back to working just the way I like it.

[jotd]

Thanks leffman, but I really don't get the @py -2 "%~dp0\geotool" %* command line.
py is not a valid command, -2 is not a valid python option.
the rest I understand...