Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!bionet!ames!ucsd!nosc!crash!pnet01!pro-sol.cts.com!edwatkeys
From: edwatkeys@pro-sol.cts.com (Ed Watkeys)
Newsgroups: comp.sys.apple2
Subject: Re: which assembler to get
Message-ID: <1991May25.051608.11359@crash.cts.com>
Date: 25 May 91 05:16:08 GMT
Organization: Crash TimeSharing, El Cajon, CA
Lines: 53

In-Reply-To: message from MQUINN@UTCVM.BITNET

It was said that ORCA/M locals aren't as "good" as Merlin ones, and I think
that's dead wrong.  While ORCA/M is slower (by far) than Merlin, if you
turn off the display and don't use the libraries, things speed up
considerably.  And, if you have 128K, you can put your source and macro
files in /RAM.  This makes things about even (not strictly, but it's good
enough that it isn't way way too slow).

Before I say what I'm about to say, just let me say that I started with
Merlin in '84 or something, got a DOS 3.3 version of ORCA/M for $10 at a
compuuter show and then bought 4.1 through Bytes Works (along with Small-C
and the source code to the libraries).  Just recently, I switched back to
Merlin, mostly because I had the money to buy it and I wanted to write some
Davex external commands (Dave provides Merlin PUT files, but no ORCA
ones...).  The following is my feelings about using two generations of both
ORCA/M and Merlin...

For quick and dirty stuff, Merlin is by far easier to use.  The way it is
implemented (the menu, etc...) leaves a lot to be desired, I think.  I
prefer commands lines to menus, and Ilike being able to use the delete key
on my IIc (nitpicking, yes...)  Also, testing programs from withing Merlin
is a pain, since everything is in memory, and ProDOS acts strange. 
Overall, it seems to be a port of a DOS 3.3 program (which is what it is).

ORCA/M is better for large jobs in my estimation.  There are a huge number
of pseudo-ops which can do almost anything that you'd want to do.  Also, it
includes a large macro and subroutine library which can be invaluable.  The
START...END and DATA...END are superior to Merlin's local variables, which
seem like a hack to me.  ORCA/M can produce LINKED files limited only by
disk space, allows integration of other languages, and provides a command
shell that does far more than Merlin's disk commands.

One thing in Merlin's favor is that you can have multiple DSKs in a file. 
This means that you can reference program modules external to the current
one, which makes overlays far easier.   What I mean to say above is that
you have access to ALL global variables in a source file, regardless of
where those labels end up in terms of BIN files.  The only way this can be
done in ORCA/M is through jump tables or some other workaround.  This
strength is a plus for big application development, but I still think
ORCA/M is better for the huge things...

For me, it comes down to this: If I'm going to have to know what I writing
means in six months, I'll use ORCA/M; but if I'm working on it for three
days straight and will never have to look at it again, I'll use Merlin.

Ed

Ed Watkeys III

Internet: edwatkeys@pro-sol.cts.com  ProLine:  edwatkeys@pro-sol
UUCP:     crash!pro-sol!edwatkeys    ARPA:     crash!pro-sol!edwatkeys@nosc.mil
BitNET:   edwatkeys%pro-sol.cts.com@nosc.mil