Latest Win32 VASM Build?
 

Hi,

Does anyone have or know where I can get a Win32/mot build of the latest VASM 1.6a+? I have a feeling that my version is quite old and I would like to use STRUCTURE definitions, which I think is only available in recent versions (?)

(yes, I attempted my own compile, and failed)

I could send you my compiled version. Its So, if you want drop me a letter with your email-address.

If you or anyone else wish to build the tools on Windows, you can use the Visual C++ command line tools:
You can use my attached makefile for vbcc, and when building for cross-compiling you need to specify signed and unsigned __int64 for the 64-bit integer data types. It will auto-detect all other types correctly.

Leffmann: Great. Your makefile builds VBCC nicely. And (after a reboot) VASM and VLINK are also compiling. I was messing around with PATH VAR, so that might be why those two were not compiling for me earlier.

One question: The VBCC website doesn't appear to have a direct link to the VBCC sources. The sources I'm using are from this link: http://www.ibaug.de/vbcc/vbcc.tar.gz which I found on some other guy's site. Does anyone know if this is the actual latest source archive for VBCC?

Apollo: thanks also for the offer of help, much appreciated!

That "other guy" is actually the main developer of vbcc :laughing

I've attached my source archive, it's the one you linked to, but I think I may have applied a patch or two from Frank Wille. Make sure you do a diff on the sources to see what's changed.

I've heard there's an update for vbcc on the way as well, so you may want to check the other guy's website for when that arrives.

Volker updates the source on his website only rarely. When anybody has a real problem and needs an update to the latest source, then just drop me an email.

For the upcoming 0.9c release there have been some severe modifications in the core and I'm not really convinced that everything is already stable enough again. So at this moment the current source can not really be recommend (Leffmann's archive is ok though - it is old).

Besides numerous bug fixes the new release will improve ColdFire and Atari support.

When I try to build v1.7 for win32 using visual c++ 2010 command prompt I get the following error in the link stage:

m68k_mot_expr.o : error LNK2019: unresolved external symbol _strtold referenced
in function _primary_expr

Any ideas?

Sorry, I didn't test that as I have no Windows system available.

Visual C++ never implemented C99 correctly (not even after 15 years?), so I guess that support for "long double" and strtold() is missing?

Vbcc has the same problem, as it only implements a part of C99. You may want to modify tfloat.h, which looks like this:
For a test you can use the same defines as for vbcc. A final fix might look like this:
But I'm not sure how to correctly identify VC++. Maybe somebody tells me. :)

strtold() (and lot of other still missing C99 features) were added to MSVC 2013.

long double is alias of double in MSVC. Probably some historic reason as usual..

MinGW always compiles this first time every time without errors or warnings. Typical of phx code, just type the commands and sit back and roll a cigarette. :cool

Ah, that's interesting (so it's only 14 years)! ;)

Any idea how I check for a version before MSVC 2013? Which value has _MSC_VER with MSVC 2013?

_MSC_VER is 1800

Thanks. Next nightly snapshot (pre 1.7a) will have that fixed.

It works when I use the define for VBCC, thanks! I should probably install version 2013 though.

I got another missing symbol when compiling with CPU=z80

z80_oldstyle_cpu.o : error LNK2019: unresolved external symbol _snprintf referen
ced in function _eval_instruction

Probably also a function left out of VC++ 2010.

That's ridiculous. According to the following bug report such an important function is even missing in 2013. Only 2014 implements it correctly.
https://connect.microsoft.com/Visual...al-studio-2013
Maybe you should consider using a real C compiler. :)

A workaround could be to use the MS-specific _snprintf() instead of snprintf(), i.e. try adding a preceding underscore.

Any suggestions for a clean workaround are welcome.

I used to build things for Windows in Cygwin, and lift out the executable and the required DLLs from Cygwin and dropping them all in the directory I kept all other command line tools. It worked fine for all those times VC++ refused to cooperate.

A small bug report:

I just built 1.7 and noticed that it can't always parse asterisk comments correctly. It fails when you have an instruction with one or more operands, followed by a comment at the end of the line. In all other cases it works fine.

I use semicolon for comments myself, but asterisk comments are everywhere in f.ex. the NDK 3.9, so it could be a problem.

Yup, but it is a Microsoft product. I started using VBA last year and stopped this year, because of the bugs in VBA kept annoying me. :guru

Recent errors in XP revealed to me (and I'm sure some of you know this already) that it was made using Visual C++. It's not surprising that Microsoft products have so many bugs when the software they use to make new software is already buggy.

Regarding the issues on the thread, I'm no C programmer (of any variety right now) so I'll leave it to the experts ;)

It is not a bug. MSVC is (or has been) officially C89 C-compiler for some reason, probably they think everyone should just use C++ or something.. At least until recently.

You're probably running the Motorola syntax module with -spaces option to allow blanks in the operands? Otherwise I couldn't see any problem.

When you want operands with blanks, then comments introduced by an asterisk are not supported. There is no way to differentiate it from a multiplication operator. For example:
Is the address 4 or 8?

Yeah you're right. I always use -spaces so I'll just fix the include files instead. Thanks.