much enhanced z-80 assembler now available

[t***@gmail.com]

George Phillips has released a new version of his zmac z-80/8080 assembler that might be of interest to people in this group.

It is now (mostly) backwards compatible with several existing assemblers including Misosys' MRAS as well as Microsoft's Macro-80 including those assemblers *.rel output. In addition (if linking is not needed) zmac will directly output TRS-80 CMD files, CP/M binaries and several other output formats.

It accepts 0x1234h as well as $1234 hex formats, an optional '.' before any pseudo-op (e.g. .ascii or ascii means the same thing) and other flexible input variations so as to be as accommodating as possible to existing z-80/8080 source code.

It comes with full documentation built-in (i.e. zmac --doc) and complete source code. I have successfully compiled it under Ubuntu Linux while doing some testing for him during zmac's latest development effort.

For anyone interested, here is where to get both the Windows binary and the source code:

http://members.shaw.ca/gp2000/zmac-update2.html

Tom

[r***@yahoo.com]

On Tuesday, September 3, 2013 8:49:22 AM UTC-7, ***@gmail.com wrote:

<snip>

Post by t***@gmail.com
It comes with full documentation built-in (i.e. zmac --doc) and complete source code. I have successfully compiled it under Ubuntu Linux while doing some testing for him during zmac's latest development effort.

Mind sharing your makefile (for Ubuntu) with us? I tried building it on Slackware, and the "doc" compile seemed to work, but the "zmac" compile just generates a lot of errors:

bash-3.1# gcc -s -o zmac -DUNIX zmac.c MIO.C doc.c /home/ftp/zmac/lib/zi80/zi80dis.cpp
MIO.C:20: error: 'filename' was not declared in this scope
MIO.C:20: error: 'mode' was not declared in this scope
MIO.C:20: error: initializer expression list treated as compound expression
MIO.C:21: error: expected ',' or ';' before 'char'
MIO.C:22: error: expected unqualified-id before '{' token
doc.c:27:19: error: doc.inl: No such file or directory
doc.c: In function 'doc':
doc.c:52: error: 'documentation' undeclared (first use in this function)
doc.c:52: error: (Each undeclared identifier is reported only once
doc.c:52: error: for each function it appears in.)

Looks like a nice assembler .... if only I could get it to work.

Roger

[t***@gmail.com]

Post by r***@yahoo.com
<snip>

Post by t***@gmail.com
It comes with full documentation built-in (i.e. zmac --doc) and complete source code. I have successfully compiled it under Ubuntu Linux while doing some testing for him during zmac's latest development effort.

bash-3.1# gcc -s -o zmac -DUNIX zmac.c MIO.C doc.c /home/ftp/zmac/lib/zi80/zi80dis.cpp
MIO.C:20: error: 'filename' was not declared in this scope
MIO.C:20: error: 'mode' was not declared in this scope
MIO.C:20: error: initializer expression list treated as compound expression
MIO.C:21: error: expected ',' or ';' before 'char'
MIO.C:22: error: expected unqualified-id before '{' token
doc.c:27:19: error: doc.inl: No such file or directory
doc.c:52: error: 'documentation' undeclared (first use in this function)
doc.c:52: error: (Each undeclared identifier is reported only once
doc.c:52: error: for each function it appears in.)
Looks like a nice assembler .... if only I could get it to work.
Roger

I don't mind a bit, but no Makefile (just sheer laziness on my part). As I remember, I modified George's mk.bat file into a bash script to compile it under 64 bit Ubuntu. I'll have to dig it out of my backups as it was done earlier this summer and so I'll post the compile script later this afternoon as I'm literally on my way out the door right now.

Again, as I remember there were 2 or 3 warnings in 64 bit mode that George quickly fixed. It really is the best, most flexible z-80/8080 assembler I know.

Tom

[t***@gmail.com]

Post by t***@gmail.com

Post by r***@yahoo.com
<snip>

Post by t***@gmail.com
It comes with full documentation built-in (i.e. zmac --doc) and complete source code. I have successfully compiled it under Ubuntu Linux while doing some testing for him during zmac's latest development effort.

bash-3.1# gcc -s -o zmac -DUNIX zmac.c MIO.C doc.c /home/ftp/zmac/lib/zi80/zi80dis.cpp
MIO.C:20: error: 'filename' was not declared in this scope
MIO.C:20: error: 'mode' was not declared in this scope
MIO.C:20: error: initializer expression list treated as compound expression
MIO.C:21: error: expected ',' or ';' before 'char'
MIO.C:22: error: expected unqualified-id before '{' token
doc.c:27:19: error: doc.inl: No such file or directory
doc.c:52: error: 'documentation' undeclared (first use in this function)
doc.c:52: error: (Each undeclared identifier is reported only once
doc.c:52: error: for each function it appears in.)
Looks like a nice assembler .... if only I could get it to work.
Roger

I don't mind a bit, but no Makefile (just sheer laziness on my part). As I remember, I modified George's mk.bat file into a bash script to compile it under 64 bit Ubuntu. I'll have to dig it out of my backups as it was done earlier this summer and so I'll post the compile script later this afternoon as I'm literally on my way out the door right now.
Again, as I remember there were 2 or 3 warnings in 64 bit mode that George quickly fixed. It really is the best, most flexible z-80/8080 assembler I know.
Tom

George has tweaked it a bit since I last compiled it, but it still compiles with little trouble.
1. Rename all upper case files e.g. ZMAC.Y, MIO.C to lower case. Linux is happier that way.
2. Edit doc.d at line 159 and 161 and put an "%ld" where there is now just %d (warnings about int but type is long int - I'll mention it to George).
3. Ideally, remove the CR before LF of all files, but only mk.sh must have that done (or you get /bin/bash^M not valid interpreter or some such)
4. Run this script as mk.sh

#!/bin/bash
gcc -o doc -DMK_DOC doc.c
./doc >nul
bison --output=./zmac.c ./zmac.y
gcc -s -o zmac -DUNIX zmac.c mio.c doc.c ../../../../lib/zi80/zi80dis.cpp

AFAIK, this script should work on any version of Linux with gcc, g++ and bison installed. The version of zmac I compiled earlier did not have the doc.c file yet.


That's about it. I know it's not much, but for a quickie test, I assembled this:
ASEG
org 100h
loop:
nop
nop
nop
jp loop
end

Then a directory below the source code is automatically created called "zout"

In zout, the lst file looks like this:

1: ASEG
2: - 0100 org 100h
3: - 0100 loop:
4: 0+4 0100 00 nop
5: 4+4 0101 00 nop
6: 8+4 0102 00 nop
7: 12+10 0103 C30001 jp loop
8: - 0106 end



Statistics:

3 passes
0 jr promotions
1 symbols
6 bytes



Symbol Table:

loop 100

I think that should do it. If you have any further questions, please don't hesitate to ask. I used Werner Cersovius' disassembled source code to test it extensively in early summer. It will build Microsoft's Basic 5.21, Bascom, Macro-80, Link-80 and a bunch of other stuff to the bit after a link with L80/LD80. I have source for a C recreation of the Microsoft Linker I need to get running on Windows/Linux and then all cross development will be done on Linux/Windows with those nice, big table sizes instead of crammed into 64KB including the linker and the OS.

And OK, I'll build a proper Linux Makefile and send it to George...

Enjoy,
Tom

[dott.Piergiorgio]

Post by t***@gmail.com
I think that should do it. If you have any further questions, please
don't hesitate to ask. I used Werner Cersovius' disassembled source
code to test it extensively in early summer. It will build
Microsoft's Basic 5.21, Bascom, Macro-80, Link-80 and a bunch of
other stuff to the bit after a link with L80/LD80. I have source for
a C recreation of the Microsoft Linker I need to get running on
Windows/Linux and then all cross development will be done on
Linux/Windows with those nice, big table sizes instead of crammed
into 64KB including the linker and the OS.
And OK, I'll build a proper Linux Makefile and send it to George...

I have successfully compiled & tested it, and I confirm that rzh's issue
is caused by gcc taking .C as C++ source.

Only one issue, the output of an entire subdir with many unneded
binaries (CP/M people here needs only .cim, .hex and .rel binaries,
often not all of these) IMHO can be an annoyance and some selective
output switch will be really nice.

doing a mv <ufn>.cim <ufn>.com (or .bin) is a really minor issue, not
worth doing the effort of coding the testing if there's an ORG 0100 and
naming .com or .bin accordingly, but the annoyance of doing a mv *.<what
one actually needs> updir, followed by an rm *.<all unneded binaries>
and getting rid of the output sub-dir IS worth of implementing an output
format switch and/or outputting in the current dir instead of creating a
new sub-dir, IMHO.

Best regards from Italy,
dott. Piergiorgio.

[t***@gmail.com]

Post by r***@yahoo.com
<snip>

Post by t***@gmail.com
It comes with full documentation built-in (i.e. zmac --doc) and complete source code. I have successfully compiled it under Ubuntu Linux while doing some testing for him during zmac's latest development effort.

bash-3.1# gcc -s -o zmac -DUNIX zmac.c MIO.C doc.c /home/ftp/zmac/lib/zi80/zi80dis.cpp
MIO.C:20: error: 'filename' was not declared in this scope
MIO.C:20: error: 'mode' was not declared in this scope
MIO.C:20: error: initializer expression list treated as compound expression
MIO.C:21: error: expected ',' or ';' before 'char'
MIO.C:22: error: expected unqualified-id before '{' token
doc.c:27:19: error: doc.inl: No such file or directory
doc.c:52: error: 'documentation' undeclared (first use in this function)
doc.c:52: error: (Each undeclared identifier is reported only once
doc.c:52: error: for each function it appears in.)
Looks like a nice assembler .... if only I could get it to work.
Roger

Quickie followup I thought about after I got zmac running on Linux. I just do it without thinking from experience and it probably warrants an explanation. The problems with MIO.C were the default assumptions of the gnu compiler collection. Most other C++ compilers follow suit. If the extension is upper case (e.g. *.C) the compiler assumes C++ source code and, of course it isn't. Yeah, I know Windows doesn't differentiate between upper and lower case very well. This can cause all kinds of problems for compilation, but I didn't write it and it's just one of many pet peeves of mine with C++, but no one cares. ;-)

So first rule when moving to Linux - All filenames are lower case.

Tom

[Steve Nickolas]

Post by t***@gmail.com
Quickie followup I thought about after I got zmac running on Linux. I
just do it without thinking from experience and it probably warrants an
explanation. The problems with MIO.C were the default assumptions of
the gnu compiler collection. Most other C++ compilers follow suit. If
the extension is upper case (e.g. *.C) the compiler assumes C++ source
code and, of course it isn't. Yeah, I know Windows doesn't
differentiate between upper and lower case very well. This can cause
all kinds of problems for compilation, but I didn't write it and it's
just one of many pet peeves of mine with C++, but no one cares. ;-)
So first rule when moving to Linux - All filenames are lower case.

$ for x in *; do mv -vi "$x" "$(echo "$x"|tr A-Z a-z)"; done

Should work on just about any *x to force all filenames to lowercase, if
that helps any. (A *really* old Bourne shell might need backticks instead
of $(), but I believe at least ksh, ash and bash all support this syntax.
I *think* think syntax of tr is supported outside of GNU as well, but as
the only systems I have are GNU-based, I can't test that.)

-uso.

[Steven Hirsch]

Post by t***@gmail.com
George Phillips has released a new version of his zmac z-80/8080 assembler
that might be of interest to people in this group.
It is now (mostly) backwards compatible with several existing assemblers
including Misosys' MRAS as well as Microsoft's Macro-80 including those
assemblers *.rel output. In addition (if linking is not needed) zmac will
directly output TRS-80 CMD files, CP/M binaries and several other output
formats.

Nice! If a companion linker existed, I'd be in classic-computer heaven. Do
you know of any work in that direction? Most of the stuff I wrote for CP/M
required linker mojo.

[t***@gmail.com]

Post by Steven Hirsch

Post by t***@gmail.com
George Phillips has released a new version of his zmac z-80/8080 assembler
that might be of interest to people in this group.
It is now (mostly) backwards compatible with several existing assemblers
including Misosys' MRAS as well as Microsoft's Macro-80 including those
assemblers *.rel output. In addition (if linking is not needed) zmac will
directly output TRS-80 CMD files, CP/M binaries and several other output
formats.

Nice! If a companion linker existed, I'd be in classic-computer heaven. Do
you know of any work in that direction? Most of the stuff I wrote for CP/M
required linker mojo.

I do know of a great start. Most of what is needed is here:
ftp://gatling.ikk.sztaki.hu/pub/z80/

It compiles OK, but needs some work (e.g. current default address is 0000h as it's intended for embedded ROM use and not CP/M and the like. If this code can be made to work reliably with George's zmac, and I know of no reason why it can't, all cross development could be done for embedded boards, CP/M, TRSDOS and all its derivatives, and probably even MSX as both Macro-80 and Link-80 exist for that platform. Memory limitations for Z-80 development purposes would cease to be an issue as long as the resulting code used overlays or fit in 64KB.

I have exchanged emails with the original author and he hasn't looked at the code in many years and he basically said "you're on your own, modify it any way you want". However, it's known to be essentially functional correctly handling several hundred symbols, I think it just needs a bit of TLC to make it work for CP/M, TRSDOS or wherever by default. It will successfully search Microsoft high level language libraries, Aztec C libraries and anything else in *.rel format.

Free of the memory limitations of a Z-80 at both assembly and link time, I think that should be plenty of mojo for Z-80 or 8080 development. I've let it sit for a few months, but now that George has put zmac into the wild, I need to do the same for ld80 (lousy name - conflicts with Microsoft's ld80.com linker - maybe ld80x?).

Tom

[Steve Nickolas]

Post by t***@gmail.com
It compiles OK, but needs some work (e.g. current default address is
0000h as it's intended for embedded ROM use and not CP/M and the like.
If this code can be made to work reliably with George's zmac, and I know
of no reason why it can't, all cross development could be done for
embedded boards, CP/M, TRSDOS and all its derivatives, and probably even
MSX as both Macro-80 and Link-80 exist for that platform. Memory
limitations for Z-80 development purposes would cease to be an issue as
long as the resulting code used overlays or fit in 64KB.

MSX-DOS is API-compatible with CP/M 2.2, so if it can roll for CP/M it can
roll for MSX.

-uso.

[Peter Dassow]

Post by Steve Nickolas

Post by t***@gmail.com
It compiles OK, but needs some work (e.g. current default address is
0000h as it's intended for embedded ROM use and not CP/M and the like.
If this code can be made to work reliably with George's zmac, and I
know of no reason why it can't, all cross development could be done
for embedded boards, CP/M, TRSDOS and all its derivatives, and
probably even MSX as both Macro-80 and Link-80 exist for that
platform. Memory limitations for Z-80 development purposes would
cease to be an issue as long as the resulting code used overlays or
fit in 64KB.

MSX-DOS is API-compatible with CP/M 2.2, so if it can roll for CP/M it
can roll for MSX.

Except for FCBs, DPBs or similar file- and disk handling structures,
you're right with MSX-DOS compatibility, e.g. Turbo PASCAL will run on
MSX-DOS also without hassle.
If someone wants to have 100% CP/M compatibility, he might use CP/M 3.0
for at least MSX2 computers, see http://www.z80.eu/msx2.html also.

Regards
Peter

[Steven Hirsch]

Post by t***@gmail.com

Post by Steven Hirsch
Nice! If a companion linker existed, I'd be in classic-computer heaven.
Do you know of any work in that direction? Most of the stuff I wrote for
CP/M required linker mojo.

ftp://gatling.ikk.sztaki.hu/pub/z80/
I have exchanged emails with the original author and he hasn't looked at
the code in many years and he basically said "you're on your own, modify it
any way you want". However, it's known to be essentially functional
correctly handling several hundred symbols, I think it just needs a bit of
TLC to make it work for CP/M, TRSDOS or wherever by default. It will
successfully search Microsoft high level language libraries, Aztec C
libraries and anything else in *.rel format.

That looks promising. However, the license is going to be an issue in the
large. As tempting as it is, stating that a body of work is in the public
domain has zero legal meaning (in the US, at least). Unlike GPL or BSD, etc.,
that statement cannot be taken as a license grant to use or redistribute the
code.

Anyway, legalities aside, it seems like a good starting point.

Steve

[t***@gmail.com]

Post by Steven Hirsch

Post by t***@gmail.com

Post by Steven Hirsch
Nice! If a companion linker existed, I'd be in classic-computer heaven.
Do you know of any work in that direction? Most of the stuff I wrote for
CP/M required linker mojo.

ftp://gatling.ikk.sztaki.hu/pub/z80/
I have exchanged emails with the original author and he hasn't looked at
the code in many years and he basically said "you're on your own, modify it
any way you want". However, it's known to be essentially functional
correctly handling several hundred symbols, I think it just needs a bit of
TLC to make it work for CP/M, TRSDOS or wherever by default. It will
successfully search Microsoft high level language libraries, Aztec C
libraries and anything else in *.rel format.

That looks promising. However, the license is going to be an issue in the
large. As tempting as it is, stating that a body of work is in the public
domain has zero legal meaning (in the US, at least). Unlike GPL or BSD, etc.,
that statement cannot be taken as a license grant to use or redistribute the
code.
Anyway, legalities aside, it seems like a good starting point.
Steve

I don't believe licensing would be any problem.
Here is an email I received from the author of ld80 in late May:
----------
Dear Tom,

I wrote this program 13 years ago because I developed
embedded Z80 code on Linux. (I.e. it was burned into EEPROM.)
ld80 was never intended to produce CP/M executables.
I did not need this functionality for two reasons:
- Original CP/M linkers (as l80, pl80, link80) do this job better.
- I did not see working CP/M since 1987. :-)

So I'm afraid there is no solution better than dd in Makefile.
Don't worry about it. This is perfect.
Or if you wish please feel free to modify the linker to
fit your requirements. It is copylefted. :-)
I guess you know that source code is downloadable from here:
ftp://gatling.ikk.sztaki.hu/pub/z80/
------------

I think if I ask him to make the code GPL, BSD or whatever, he'll do it. My guess is the code is old enough I doubt those licenses had the "official" stamp of approval they do now, so he did the equivalent at the time.

The "dd in Makefile" comment comes from the fact that the linker always starts at 0000h even if it builds code at 0100h so 256 00h bytes are always at the beginning of the file. I was able to link simple CP/M programs with no problem. I had trouble linking the Q/C compiler with it, but that's an extreme test that to my knowledge only Plink II (that I do not have) will do. I need to get back to it and remove the leading 00h issues. Then if it had a command line option for cmd output, it would also be useful in the TRS-80 environment with a 5200h org. I don't think any of that should be (famous last words... ;-) ) overly difficult from C source. It just got put aside for other stuff in the intervening time frame.

Tom

[Steven Hirsch]

Post by t***@gmail.com
I think if I ask him to make the code GPL, BSD or whatever, he'll do it.
My guess is the code is old enough I doubt those licenses had the
"official" stamp of approval they do now, so he did the equivalent at the
time.

BSD or MIT would be the easiest and most string-free licenses.

[t***@gmail.com]

Post by Steven Hirsch

Post by t***@gmail.com
I think if I ask him to make the code GPL, BSD or whatever, he'll do it.
My guess is the code is old enough I doubt those licenses had the
"official" stamp of approval they do now, so he did the equivalent at the
time.

BSD or MIT would be the easiest and most string-free licenses.

Does this work OK? ;-)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

License of ld80 linker program written in 2000.



Copyright (c) 2013, Gabor Kiss <***@ssg.ki.iif.hu>
All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iEYEARECAAYFAlIocjUACgkQd2oiOrtquzgTEgCgq9Sp6tQDBoqIQYxQ8mxp+5Ef
SekAoKo6AnjHNXJFg9bMn14ldUZ3PrKV
=pKcN
-----END PGP SIGNATURE-----

I'll see what I can do about getting it on a site (sourceforge? github?) so it can be worked on for anyone who wishes to do so.

ld80x in combination with zmac can be a really useful combination for cross development.

Tom

[Steve Nickolas]

Post by t***@gmail.com
Does this work OK? ;-)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
License of ld80 linker program written in 2000.
All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

...that's the 2-clause BSD license, so prolly.

-uso.

[Steven Hirsch]

Post by t***@gmail.com

Post by Steven Hirsch
BSD or MIT would be the easiest and most string-free licenses.

Does this work OK? ;-)

(snip...)

IANAL, but that looks fine. Any statement of licensing beats "public domain".

[Bill Gunshannon]

Post by Steven Hirsch

Post by t***@gmail.com

Post by Steven Hirsch
BSD or MIT would be the easiest and most string-free licenses.

Does this work OK? ;-)

(snip...)
IANAL, but that looks fine. Any statement of licensing beats "public domain".

Why?

bill

[Steven Hirsch]

Post by Steven Hirsch

Post by t***@gmail.com

Post by Steven Hirsch
BSD or MIT would be the easiest and most string-free licenses.

Does this work OK? ;-)

(snip...)
IANAL, but that looks fine. Any statement of licensing beats "public domain".

Under US law, there are some landmine issues with statements of "this is
public domain". Again, IANAL, but recalling conversations with the IP legal
folks at work (where we are absolutely forbidden to use anything that carries
such a label) you cannot simply declare something as "public domain". Things
pass into this state naturally when copyright expires but I don't believe you
can place them there to start with. So the fear is that you might start using
or deriving something from a creative work, only to have the author (or worse,
a third party) pop up and make a claim against you. When/if that happens you
have absolutely no license, implied or otherwise, to fall back on as a defense.

Once more: IANAL and I may have mangled this explanation. All I know is that
some very highly-paid IP lawyers have placed an utter ban on using code so
labeled.

[Bill Gunshannon]

This post might be inappropriate. Click to display it.

[dott.Piergiorgio]

Post by Bill Gunshannon

Post by Steven Hirsch
Once more: IANAL and I may have mangled this explanation. All I know is that
some very highly-paid IP lawyers have placed an utter ban on using code so
labeled.

Actually, it is the exact opposite. Once you explicitly say something
is "In the Public Domain" that becomes the fact of law and it can not
be reversed. You relinquish all control over that particular piece of
IP. It was Stallman's lack of understanding of this that resulted in
his original rant and gave us the GNU Public Virus.

I disagree; as the (discussed elsewhere) history of Vulcan/dBase shows,
people can take a PD source, modify or port it, and label it as
propiertary software; the initial GPL (v.1) indeed act like a virus, but
the core of this license is that one shouldn't take it and pretend that
is their work and sell it.

Later GPL and LGPL removes the "public virus" thing (in particular, LGPL
allow static linking of GPL code into propiertary code mantaining the
propiertary nature of said code.

Side digression: As historian, after comparing the two sides of the "NDA
incident" whose led Stallman to his ways against closed-source software,
I suspect that perhaps the truth is that RMS was victim of a goliardic
joke (the professor involved was absent, and some postgraduates decided
to pull the classical pretending joke "yes, I'm professor X, what I can
do for you ?" to the visiting researcher (Stallman).

will be interesting showing separately contemporary photos to Stallman
and that professor to each other, albeit the 30 or so years will not
allow reaching a definite conclusion on this hypothesis.

Best regards from Italy,
dott. Piergiorgio.

[Steven Hirsch]

Post by Bill Gunshannon

Post by Steven Hirsch
Under US law, there are some landmine issues with statements of "this is
public domain". Again, IANAL, but recalling conversations with the IP legal
folks at work (where we are absolutely forbidden to use anything that carries
such a label) you cannot simply declare something as "public domain". Things
pass into this state naturally when copyright expires but I don't believe you
can place them there to start with. So the fear is that you might start using
or deriving something from a creative work, only to have the author (or worse,
a third party) pop up and make a claim against you. When/if that happens you
have absolutely no license, implied or otherwise, to fall back on as a defense.
Once more: IANAL and I may have mangled this explanation. All I know is that
some very highly-paid IP lawyers have placed an utter ban on using code so
labeled.

Actually, it is the exact opposite. Once you explicitly say something
is "In the Public Domain" that becomes the fact of law and it can not
be reversed. You relinquish all control over that particular piece of
IP. It was Stallman's lack of understanding of this that resulted in
his original rant and gave us the GNU Public Virus.

Well, I cannot argue the legal issues since that's not my background. I'm
only going by what some very sharp lawyers told me: "Don't download or use
anything without a license statement - and only some of those".

[Tesseract]

Post by t***@gmail.com

Post by Steven Hirsch

Post by t***@gmail.com
George Phillips has released a new version of his zmac z-80/8080 assembler
that might be of interest to people in this group.
It is now (mostly) backwards compatible with several existing assemblers
including Misosys' MRAS as well as Microsoft's Macro-80 including those
assemblers *.rel output. In addition (if linking is not needed) zmac will
directly output TRS-80 CMD files, CP/M binaries and several other output
formats.

Nice! If a companion linker existed, I'd be in classic-computer heaven. Do
you know of any work in that direction? Most of the stuff I wrote for CP/M
required linker mojo.

ftp://gatling.ikk.sztaki.hu/pub/z80/
It compiles OK, but needs some work (e.g. current default address is 0000h as it's intended for embedded ROM use and not CP/M and the like. If this code can be made to work reliably with George's zmac, and I know of no reason why it can't, all cross development could be done for embedded boards, CP/M, TRSDOS and all its derivatives, and probably even MSX as both Macro-80 and Link-80 exist for that platform. Memory limitations for Z-80 development purposes would cease to be an issue as long as the resulting code used overlays or fit in 64KB.
I have exchanged emails with the original author and he hasn't looked at the code in many years and he basically said "you're on your own, modify it any way you want". However, it's known to be essentially functional correctly handling several hundred symbols, I think it just needs a bit of TLC to make it work for CP/M, TRSDOS or wherever by default. It will successfully search Microsoft high level language libraries, Aztec C libraries and anything else in *.rel format.
Free of the memory limitations of a Z-80 at both assembly and link time, I think that should be plenty of mojo for Z-80 or 8080 development. I've let it sit for a few months, but now that George has put zmac into the wild, I need to do the same for ld80 (lousy name - conflicts with Microsoft's ld80.com linker - maybe ld80x?).
Tom

I've found a few issues with the assembler itself. Most of these seem to be related to conditionals.

1. Code which should be excluded is getting assembled and generating multiple definitions.

2. Code is being excluded/assembled differently on the various passes and is generating phase errors.

Simple programs which don't use conditional assembly seem to be OK.

The 'macro' pseudo-op is recognised but things like 'rept' are not.

I believe that all these issues are fairly easy to fix, then this will be a really useful tool, especially since it can generate .rel output.

I started working on a cross-assembler a few weeks ago. I suspect I don't need to pursue that activity any further as it would probably be easier to add the features I want to zmac.

[g***@gmail.com]

Post by Tesseract
I've found a few issues with the assembler itself. Most of these seem to be related to conditionals.
1. Code which should be excluded is getting assembled and generating multiple definitions.

The conditional assembly is reasonably robust, but it certainly doesn't support much beyond "if" (i.e., not the various different conditionals of macro-80). But I'd be happy to look into it if you have an example.

Post by Tesseract
2. Code is being excluded/assembled differently on the various passes and is generating phase errors.

Internally I added multiple passes to zmac (for JR promotion, in particular), but it is very particular about the conditionals always being the same on every pass. Might be something worth fixing. Though for the life of me I've having trouble constructing and example of that right this minute.

Post by Tesseract
The 'macro' pseudo-op is recognised but things like 'rept' are not.

Indeed, I thought about implementing that (and exitm), but ran out of steam (and zmac's macro handling is a little bit cumbersome). I sorta convinced myself that one can always hand translate repeats into things like:

rep macro n
if n>0
rep n-1
endif
nop ; repeated code here
endm
rep 5

Post by Tesseract
I believe that all these issues are fairly easy to fix, then this will be a really useful tool, especially since it can generate .rel output.

I'd be very happy to receive any changes you make.

Post by Tesseract
I started working on a cross-assembler a few weeks ago. I suspect I don't need to pursue that activity any further as it would probably be easier to add the features I want to zmac.

Quite likely. Drop me a line if any of zmac's weirdness gets in your way.

[r***@yahoo.com]

On Tuesday, September 3, 2013 8:49:22 AM UTC-7, ***@gmail.com wrote:

<snip>

Post by t***@gmail.com
gcc -o doc -DMK_DOC doc.c
./doc >nul
bison --output=./zmac.c ./zmac.y
gcc -s -o zmac -DUNIX zmac.c mio.c doc.c ../../../../lib/zi80/zi80dis.cpp

<snip>

Thanks Tom --- that worked like a charm (on Slackware!). I think the uppercase file names were causing the problem (for me). Can't wait to run some real code through it. I tried your nop/loop and got the same result.

Roger

[Tesseract]

# Generate zmac on *nix
#
# There is a bit of a problem with the files as distributed in that zmac.y
# and mio.c are stored in the .zip file with UPPER CASE names. That doesn't
# matter on Windows but it can be annoying on UNIX systems.
#
# This Makefile assumes the names are lower case.
#
# A refresher for those (like me) who can't remember all the intricacies:
#
# $@ represents the target of the current rule
# $< is the input file

# Names for the tools used herein. Probably redundant but the documentation
# for gmake recommends this practice.
BISON= bison
CC = /usr/bin/gcc

# Directories in the source tree. Note that $(Z80D) is the current directory
# when this Makefile is invoked.

LIBD = lib/zi80
Z80D = trs80/sdk/src/zmac
TOPD = ../../../..

# File extensions. .o is common on *NIX whereas .obj is more frequently
# used on Windows, MS-DOS and OS/2. The suffix for executable files should
# be empty on *nix but probably .exe on most other platforms.
O = o
E =

PIECES = doc.$O mio.$O zmac.$O \
$(TOPD)/$(LIBD)/zi80dis.cpp

# Primary targets

all : $(TOPD)/zmac$E

clean :
rm -f *.o doc$E doc.inl zmac.c

# Secondary targets

$(TOPD)/zmac$E : $(PIECES) $(TOPD)/$(LIBD)/zi80dis.h
$(CC) -o$@ $(PIECES)

# This is a bit strange. When doc.c compiled to an executable with MK_DOC
# defined then it can be run to generate doc.inl which is used when doc.c is
# recompiled without MK_DOC. The source for doc.c indicates that it expects
# to find the files doc.txt and doc.inl in the current directory.
#
# Putting generated files in the source directory is bad form but lots of
# Makefiles do it and it is too hard to change given the presence of hard-
# coded relative paths in some of the sources.

doc$E : doc.c
$(CC) -o$@ -DMK_DOC $<

doc.inl : doc$E doc.txt
./doc$E >/dev/nul

# Intermediates

# The generated code (by bison from zmac.y) has a hard-coded relative path
# to zi80dis.h. That is the ONLY reason we have to run from the lowest
# level directory in the source tree.

zmac.o : zmac.c
$(CC) -c -o$@ $<

zmac.c : zmac.y
$(BISON) --output=$@ $<

doc.$O : doc.c doc.inl
$(CC) -I. -c -o$@ $<

mio.$O : mio.c
$(CC) -c -o$@ $<

[Dennis Boone]

Post by Tesseract
# There is a bit of a problem with the files as distributed in that zmac.y
# and mio.c are stored in the .zip file with UPPER CASE names. That doesn't
# matter on Windows but it can be annoying on UNIX systems.

Fwiw, "unzip -L" should fix names as they come out of the zip file.

De

[t***@gmail.com]

Post by Dennis Boone

Post by Tesseract
# There is a bit of a problem with the files as distributed in that zmac.y
# and mio.c are stored in the .zip file with UPPER CASE names. That doesn't
# matter on Windows but it can be annoying on UNIX systems.

Fwiw, "unzip -L" should fix names as they come out of the zip file.
De

George has updated the zmac.zip file on his website.

Filenames are lower case.
Simple Makefile for *nix (written by him on OSX, tested on Linux)
2 warnings in doc.c fixed.

To get it to compile on Windows with a generic bison install from the gnuwin32 site (http://gnuwin32.sourceforge.net/) along with the MingW gcc/g++ compiler, I had to change the mk.bat file to this:
@echo off
@rem Generate doc.inl
gcc -o doc.exe -DMK_DOC doc.c
doc >nul
@rem convert grammar into C code
@rem cd bison\bin
bison --output=zmac.c zmac.y
@rem cd ..\..
@rem compile the rest
gcc -s -o zmac.exe -DMSDOS zmac.c mio.c doc.c ..\..\..\..\lib\zi80\zi80dis.cpp

Hopefully, these changes and the above .bat script should make it easier for anyone who wishes to build it to do so. The zmac.zip file already includes zmac.exe so this is just for those who wish to change/experiment with the source code under Windows. Linux people must compile it.

Tom

[Torfinn Ingolfsen]

Post by t***@gmail.com
George has updated the zmac.zip file on his website.
Filenames are lower case.
Simple Makefile for *nix (written by him on OSX, tested on Linux)
2 warnings in doc.c fixed.

For some reason it doesn't compile on FreeBSD:
(I added '-x c' to gcc command line in order for it to treat source as C)

***@kg-core1$ make
yacc -d zmac.y
mv y.tab.c zmac.c
gcc -DMK_DOC -o doc doc.c
./doc >/dev/null
gcc -x c -o zmac zmac.c mio.c doc.c ../../../../lib/zi80/zi80dis.cpp
../../../../lib/zi80/zi80dis.cpp:60: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'major'
../../../../lib/zi80/zi80dis.cpp:350: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'minor'
../../../../lib/zi80/zi80dis.cpp:1222: error: expected
specifier-qualifier-list before 'Opcode'
../../../../lib/zi80/zi80dis.cpp:1244: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
../../../../lib/zi80/zi80dis.cpp:1252: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
../../../../lib/zi80/zi80dis.cpp:1257: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
../../../../lib/zi80/zi80dis.cpp:1262: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
../../../../lib/zi80/zi80dis.cpp:1269: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
../../../../lib/zi80/zi80dis.cpp:1274: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'Zi80dis'
../../../../lib/zi80/zi80dis.cpp:1281: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
../../../../lib/zi80/zi80dis.cpp:1500: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
../../../../lib/zi80/zi80dis.cpp:1554: error: expected identifier or '('
before string constant
*** Error code 1

Stop in /zs/tingo/work/zmac/trs80/sdk/src/zmac.

This is on:
***@kg-core1$ uname -a
FreeBSD kg-core1.kg4.no 8.4-STABLE FreeBSD 8.4-STABLE #0 r253646: Thu
Jul 25 10:12:31 UTC 2013
***@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64

[g***@gmail.com]

Post by Torfinn Ingolfsen
(I added '-x c' to gcc command line in order for it to treat source as C)

If I add "-x c" under Linux it breaks the compile in a sort of similar way (namely zi80dis.cpp fails massively). Assuming you added '-x c' because it wasn't otherwise working, try this Makefile:

CC=gcc
CXX=g++
DEP=zmac.o mio.o doc.o ../../../../lib/zi80/zi80dis.o

zmac: doc.inl $(DEP)
$(CC) -o zmac $(DEP)

doc.inl: doc.c doc.txt
$(CC) -DMK_DOC -o doc doc.c
./doc >/dev/null

clean:
rm -f $(DEP)
rm -f zmac.c doc.inl

[Torfinn Ingolfsen]

Post by g***@gmail.com

Post by Torfinn Ingolfsen
(I added '-x c' to gcc command line in order for it to treat source as C)

If I add "-x c" under Linux it breaks the compile in a sort of
similar way (namely zi80dis.cpp fails massively). Assuming you added

with the Makefile you provided:
***@kg-core1$ make
gcc -DMK_DOC -o doc doc.c
./doc >/dev/null
yacc -d zmac.y
gcc -O2 -pipe -c y.tab.c -o zmac.o
rm -f y.tab.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c mio.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c doc.c
${CTFCONVERT_CMD} expands to empty string
g++ -O2 -pipe -c ../../../../lib/zi80/zi80dis.cpp
gcc -o zmac zmac.o mio.o doc.o ../../../../lib/zi80/zi80dis.o
gcc: ../../../../lib/zi80/zi80dis.o: No such file or directory
*** Error code 1

Stop in /zs/tingo/work/zmac/trs80/sdk/src/zmac.

For some reason all object files are in current directory:

***@kg-core1$ ls *.o
doc.o mio.o zi80dis.o zmac.o

Manually doing
***@kg-core1$ gcc -o zmac zmac.o mio.o doc.o zi80dis.o
zi80dis.o(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'

and I'm back to the error that made me add the '-x c' in the first place.

[Torfinn Ingolfsen]

Post by Torfinn Ingolfsen
gcc -DMK_DOC -o doc doc.c
./doc >/dev/null
yacc -d zmac.y
gcc -O2 -pipe -c y.tab.c -o zmac.o
rm -f y.tab.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c mio.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c doc.c
${CTFCONVERT_CMD} expands to empty string
g++ -O2 -pipe -c ../../../../lib/zi80/zi80dis.cpp
gcc -o zmac zmac.o mio.o doc.o ../../../../lib/zi80/zi80dis.o
gcc: ../../../../lib/zi80/zi80dis.o: No such file or directory
*** Error code 1
Stop in /zs/tingo/work/zmac/trs80/sdk/src/zmac.
doc.o mio.o zi80dis.o zmac.o
Manually doing
zi80dis.o(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
and I'm back to the error that made me add the '-x c' in the first place.

However, if I manually do

***@kg-core1$ g++ -o zmac zmac.o mio.o doc.o zi80dis.o

I get a zmac which appears to work:
***@kg-core1$ ./zmac
No source file
zmac version 10aug2013
usage: zmac [-8bcefghijJlLmnopstz] [-I dir] file[.z]
other opts: --rel --mras --zmac --dep --help --doc --version
zmac -h for more detail about options.

Nice.

[t***@gmail.com]

Post by Torfinn Ingolfsen

Post by Torfinn Ingolfsen
gcc -DMK_DOC -o doc doc.c
./doc >/dev/null
yacc -d zmac.y
gcc -O2 -pipe -c y.tab.c -o zmac.o
rm -f y.tab.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c mio.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c doc.c
${CTFCONVERT_CMD} expands to empty string
g++ -O2 -pipe -c ../../../../lib/zi80/zi80dis.cpp
gcc -o zmac zmac.o mio.o doc.o ../../../../lib/zi80/zi80dis.o
gcc: ../../../../lib/zi80/zi80dis.o: No such file or directory
*** Error code 1
Stop in /zs/tingo/work/zmac/trs80/sdk/src/zmac.
doc.o mio.o zi80dis.o zmac.o
Manually doing
zi80dis.o(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
and I'm back to the error that made me add the '-x c' in the first place.

However, if I manually do
No source file
zmac version 10aug2013
usage: zmac [-8bcefghijJlLmnopstz] [-I dir] file[.z]
other opts: --rel --mras --zmac --dep --help --doc --version
zmac -h for more detail about options.
Nice.
--
Torfinn Ingolfsen,
Norway

You got it. Googling the original missing symbol, it seems to be a fairly common problem when mixing C and C++ including when suffix issues (upper vs. lower case '.c') exist. The missing symbol is caused by the routine being in the library libc++ and needs gxx to find it automatically. As an alternative, it's suggested that using gcc with -llibc++ at the end of the command line might also work. That symbol refers to a function in libc++ used for exception handling.

I'm curious if that works, but I'll have to install FreeBSD under Vmware to test it.

Tom

[Torfinn Ingolfsen]

Post by t***@gmail.com

Post by Torfinn Ingolfsen

Post by Torfinn Ingolfsen
gcc -DMK_DOC -o doc doc.c
./doc >/dev/null
yacc -d zmac.y
gcc -O2 -pipe -c y.tab.c -o zmac.o
rm -f y.tab.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c mio.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c doc.c
${CTFCONVERT_CMD} expands to empty string
g++ -O2 -pipe -c ../../../../lib/zi80/zi80dis.cpp
gcc -o zmac zmac.o mio.o doc.o ../../../../lib/zi80/zi80dis.o
gcc: ../../../../lib/zi80/zi80dis.o: No such file or directory
*** Error code 1
Stop in /zs/tingo/work/zmac/trs80/sdk/src/zmac.
doc.o mio.o zi80dis.o zmac.o
Manually doing
zi80dis.o(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
and I'm back to the error that made me add the '-x c' in the first place.

However, if I manually do
No source file
zmac version 10aug2013
usage: zmac [-8bcefghijJlLmnopstz] [-I dir] file[.z]
other opts: --rel --mras --zmac --dep --help --doc --version
zmac -h for more detail about options.
Nice.
--
Torfinn Ingolfsen,
Norway

You got it. Googling the original missing symbol, it seems to be a fairly common problem when mixing C and C++ including when suffix issues (upper vs. lower case '.c') exist. The missing symbol is caused by the routine being in the library libc++ and needs gxx to find it automatically. As an alternative, it's suggested that using gcc with -llibc++ at the end of the command line might also work. That symbol refers to a function in libc++ used for exception handling.
I'm curious if that works, but I'll have to install FreeBSD under Vmware to test it.

libc++ isn't installed as standard on FreeBSD, so this errors out:
***@kg-core1$ gcc -o zmac zmac.o mio.o doc.o zi80dis.o -llibc++
/usr/bin/ld: cannot find -llibc++

It is available as a port for llvm (not sure if it will work with gcc):
***@kg-core1$ pinfo libc++
Port: libc++-185324
Path: /usr/ports/devel/libc++
Info: Llvm's C++ standard library with c++11 support
Maint: ***@FreeBSD.org
B-deps: clang-3.3_1 cmake-2.8.11.2 cmake-modules-2.8.11.2
libexecinfo-1.1_3 llvm-3.3_2 perl-5.14.4
R-deps:
WWW: http://libcxx.llvm.org/

HTH

[t***@gmail.com]

Post by Torfinn Ingolfsen

Post by t***@gmail.com

Post by Torfinn Ingolfsen

Post by Torfinn Ingolfsen
gcc -DMK_DOC -o doc doc.c
./doc >/dev/null
yacc -d zmac.y
gcc -O2 -pipe -c y.tab.c -o zmac.o
rm -f y.tab.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c mio.c
${CTFCONVERT_CMD} expands to empty string
gcc -O2 -pipe -c doc.c
${CTFCONVERT_CMD} expands to empty string
g++ -O2 -pipe -c ../../../../lib/zi80/zi80dis.cpp
gcc -o zmac zmac.o mio.o doc.o ../../../../lib/zi80/zi80dis.o
gcc: ../../../../lib/zi80/zi80dis.o: No such file or directory
*** Error code 1
Stop in /zs/tingo/work/zmac/trs80/sdk/src/zmac.
doc.o mio.o zi80dis.o zmac.o
Manually doing
zi80dis.o(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
and I'm back to the error that made me add the '-x c' in the first place.

However, if I manually do
No source file
zmac version 10aug2013
usage: zmac [-8bcefghijJlLmnopstz] [-I dir] file[.z]
other opts: --rel --mras --zmac --dep --help --doc --version
zmac -h for more detail about options.
Nice.
--
Torfinn Ingolfsen,
Norway

You got it. Googling the original missing symbol, it seems to be a fairly common problem when mixing C and C++ including when suffix issues (upper vs. lower case '.c') exist. The missing symbol is caused by the routine being in the library libc++ and needs gxx to find it automatically. As an alternative, it's suggested that using gcc with -llibc++ at the end of the command line might also work. That symbol refers to a function in libc++ used for exception handling.
I'm curious if that works, but I'll have to install FreeBSD under Vmware to test it.

/usr/bin/ld: cannot find -llibc++
Port: libc++-185324
Path: /usr/ports/devel/libc++
Info: Llvm's C++ standard library with c++11 support
B-deps: clang-3.3_1 cmake-2.8.11.2 cmake-modules-2.8.11.2
libexecinfo-1.1_3 llvm-3.3_2 perl-5.14.4
WWW: http://libcxx.llvm.org/
HTH
--
Torfinn Ingolfsen,
Norway

It does. Thanks for the info. There is always something new to be learned.

Tom

[g***@gmail.com]

I've made an update to zmac. The source code is now in a single directory, the Makefile is more portable and there are some minor fixes in the documentation.

The link again, for easy reference:

http://members.shaw.ca/gp2000/zmac.html

[Jonathan Harston]

Is there a way to use strings in expressions in ZMAC, so I can do
the following more efficiently:

VersDD equ 06
VersMM equ 11
VersYY equ 2000

DEFB '0'+(VersDD / 10)
DEFB '0'+(VersDD MOD 10)
DEFB "-"
if VersMM=1
DEFB 'Jan'
endif
if VersMM=2
DEFB 'Feb'
endif
if VersMM=3
DEFB 'Mar'
endif
if VersMM=4
DEFB 'Apr'
endif
etc....

In my PDP11 assembler I'd do:
VersDD: equ 06
VersMM$: equ "Nov"
VersYY: equ 2000
DEFM '0'+(VersDD/10),'0'+(VersDD MOD 10)
DEFM "-"+VersM$+"-"+STR$(VersYY)

[George Phillips]

Post by Jonathan Harston
Is there a way to use strings in expressions in ZMAC, so I can do

Maybe it would be enough to just do the month as a macro?

VersMM macro
defm 'Mar'
endm

DEFM '0'+(VersDD/10),'0'+(VersDD MOD 10),'-'
VersMM
DEFM '-'

Or use irp to do the month number to name lookup in a cleaner fashion:

VersMM equ 7
m1=0
irp s1,<Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec>
if VersMM == m1
defm '&s1'
endif
m1++
endm

For the year you can stringify it doing something like this:

VersYY equ 2000

str macro sx
defm '&sx'
endm

str %VersYY

Though I guess the answer to your question is that zmac doesn't have string variables and you need to use macros to get the same kind of manipulation.