Re: much enhanced z-80 assembler now available
449 views
Skip to first unread message
tbur...@gmail.com
Sep 5, 2013, 8:14:03 AM9/5/13
to
On Wednesday, September 4, 2013 5:51:25 PM UTC-7, Steven Hirsch wrote:
> On 09/04/2013 11:01 AM, tbur...@gmail.com wrote:
>
>
>
>
>
> > 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 <ki...@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
> On 09/04/2013 11:01 AM, tbur...@gmail.com wrote:
>
>
>
>
>
> > 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 <ki...@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
Sep 5, 2013, 12:55:35 PM9/5/13
to
-uso.
Steven Hirsch
Sep 5, 2013, 6:12:46 PM9/5/13
to
On 09/05/2013 08:14 AM, tbur...@gmail.com wrote:
>> BSD or MIT would be the easiest and most string-free licenses.
>
> Does this work OK? ;-)
>
(snip...)
>> BSD or MIT would be the easiest and most string-free licenses.
>
> Does this work OK? ;-)
>
IANAL, but that looks fine. Any statement of licensing beats "public domain".
Bill Gunshannon
Sep 6, 2013, 6:32:31 AM9/6/13
to
In article <Z9CdnY0eHfJDnLTP...@giganews.com>,
Why?
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Steven Hirsch
Sep 6, 2013, 7:50:44 AM9/6/13
to
On 09/06/2013 06:32 AM, Bill Gunshannon wrote:
> In article <Z9CdnY0eHfJDnLTP...@giganews.com>,
> Steven Hirsch <snhi...@gmail.com> writes:
>> On 09/05/2013 08:14 AM, tbur...@gmail.com wrote:
>>
>>>> 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
> In article <Z9CdnY0eHfJDnLTP...@giganews.com>,
> Steven Hirsch <snhi...@gmail.com> writes:
>> On 09/05/2013 08:14 AM, tbur...@gmail.com wrote:
>>
>>>> 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".
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
Sep 6, 2013, 8:21:26 AM9/6/13
to
In article <79adnQkB3s0IXLTP...@giganews.com>,
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.
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.
dott.Piergiorgio
Sep 6, 2013, 12:18:37 PM9/6/13
to
Il 06/09/2013 14:21, Bill Gunshannon ha scritto:
>> 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,
>> 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.
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
Sep 6, 2013, 6:10:23 PM9/6/13
to
On 09/06/2013 08:21 AM, Bill Gunshannon wrote:
>> 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
>> 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.
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".
Torfinn Ingolfsen
Sep 7, 2013, 4:43:36 PM9/7/13
to
On 09/04/2013 10:09 PM, tbur...@gmail.com wrote:
> On Wednesday, September 4, 2013 9:53:22 AM UTC-7, Dennis Boone wrote:
>
> 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)
tingo@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:
tingo@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
ro...@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64
--
Torfinn Ingolfsen,
Norway
> On Wednesday, September 4, 2013 9:53:22 AM UTC-7, Dennis Boone wrote:
>
> 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)
tingo@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:
tingo@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
ro...@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64
--
Torfinn Ingolfsen,
Norway
gp2...@gmail.com
Sep 8, 2013, 12:15:56 AM9/8/13
to
On Saturday, September 7, 2013 1:43:36 PM UTC-7, Torfinn Ingolfsen wrote:
>
> 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)
>
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:
>
> 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)
>
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
Sep 8, 2013, 5:53:13 AM9/8/13
to
On 09/08/2013 06:15, gp2...@gmail.com wrote:
> On Saturday, September 7, 2013 1:43:36 PM UTC-7, Torfinn Ingolfsen
> wrote:
>>
>> 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)
>>
>
> 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:
with the Makefile you provided:
> On Saturday, September 7, 2013 1:43:36 PM UTC-7, Torfinn Ingolfsen
> wrote:
>>
>> 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)
>>
>
> 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:
tingo@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:
Stop in /zs/tingo/work/zmac/trs80/sdk/src/zmac.
tingo@kg-core1$ ls *.o
doc.o mio.o zi80dis.o zmac.o
Manually doing
tingo@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,
Norway
Torfinn Ingolfsen
Sep 8, 2013, 6:31:23 AM9/8/13
to
tingo@kg-core1$ g++ -o zmac zmac.o mio.o doc.o zi80dis.o
I get a zmac which appears to work:
tingo@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.
--
Torfinn Ingolfsen,
Norway
tbur...@gmail.com
Sep 8, 2013, 6:57:46 AM9/8/13
to
I'm curious if that works, but I'll have to install FreeBSD under Vmware to test it.
Tom
Torfinn Ingolfsen
Sep 8, 2013, 10:21:46 AM9/8/13
to
tingo@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):
tingo@kg-core1$ pinfo libc++
Port: libc++-185324
Path: /usr/ports/devel/libc++
Info: Llvm's C++ standard library with c++11 support
Maint: k...@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
--
Torfinn Ingolfsen,
Norway
tbur...@gmail.com
Sep 8, 2013, 10:46:02 AM9/8/13
to
Tom
gp2...@gmail.com
Sep 18, 2013, 12:59:30 PM9/18/13
to
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
The link again, for easy reference:
http://members.shaw.ca/gp2000/zmac.html
tbur...@gmail.com
Sep 3, 2013, 11:49:22 AM9/3/13
to
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
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
rzh_...@yahoo.com
Sep 3, 2013, 3:02:44 PM9/3/13
to
On Tuesday, September 3, 2013 8:49:22 AM UTC-7, tbur...@gmail.com wrote:
<snip>
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
<snip>
>
> 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:
> 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: 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
tbur...@gmail.com
Sep 3, 2013, 3:17:44 PM9/3/13
to
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
tbur...@gmail.com
Sep 3, 2013, 8:20:52 PM9/3/13
to
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
Steven Hirsch
Sep 3, 2013, 9:27:49 PM9/3/13
to
On 09/03/2013 11:49 AM, tbur...@gmail.com wrote:
> 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
> 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.
you know of any work in that direction? Most of the stuff I wrote for CP/M
required linker mojo.
tbur...@gmail.com
Sep 3, 2013, 9:50:27 PM9/3/13
to
On Tuesday, September 3, 2013 6:27:49 PM UTC-7, Steven Hirsch wrote:
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
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
tbur...@gmail.com
Sep 3, 2013, 10:01:10 PM9/3/13
to
On Tuesday, September 3, 2013 12:02:44 PM UTC-7, rzh_...@yahoo.com wrote:
So first rule when moving to Linux - All filenames are lower case.
Tom
rzh_...@yahoo.com
Sep 4, 2013, 12:05:20 AM9/4/13
to
>> 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
>> ./doc >nul
>> bison --output=./zmac.c ./zmac.y
<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
dott.Piergiorgio
Sep 4, 2013, 12:11:38 AM9/4/13
to
Il 04/09/2013 02:20, tbur...@gmail.com ha scritto:
> 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
> 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...
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.
Tesseract
Sep 4, 2013, 5:10:10 AM9/4/13
to
# 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$@ $<
#
# 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$@ $<
Steve Nickolas
Sep 4, 2013, 5:22:57 AM9/4/13
to
On Tue, 3 Sep 2013, tbur...@gmail.com wrote:
> 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
> 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.
roll for MSX.
-uso.
Steve Nickolas
Sep 4, 2013, 5:28:01 AM9/4/13
to
> 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
> 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.
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.
Peter Dassow
Sep 4, 2013, 5:29:39 AM9/4/13
to
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
Sep 4, 2013, 9:05:39 AM9/4/13
to
On 09/03/2013 09:50 PM, tbur...@gmail.com wrote:
>> 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/
>> 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/
> 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
> 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.
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
tbur...@gmail.com
Sep 4, 2013, 11:01:59 AM9/4/13
to
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
Dennis Boone
Sep 4, 2013, 12:53:22 PM9/4/13
to
> # 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.
> # 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.
De
tbur...@gmail.com
Sep 4, 2013, 4:09:00 PM9/4/13
to
On Wednesday, September 4, 2013 9:53:22 AM UTC-7, Dennis Boone wrote:
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:
Filenames are lower case.
Simple Makefile for *nix (written by him on OSX, tested on Linux)
2 warnings in doc.c fixed.
@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
Steven Hirsch
Sep 4, 2013, 8:51:25 PM9/4/13
to
On 09/04/2013 11:01 AM, tbur...@gmail.com wrote:
> 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.
> 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.
Tesseract
Sep 4, 2013, 10:28:04 PM9/4/13
to
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.