Assemblers
![]3ob's profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUNpP9prYUQuhp0JotmtGGziFeVOfo6IlPLl-ekNL1hLOK_wQ=s40-c)
]3ob
wondering about the different flavors of assemblers that are available
(for pre-IIgs hardware).
I don't want to start a war, but which one is considered the best (and
why)? I haven't started coding for the A2 yet but will hit it pretty
hard in about a month or so so I'd like to be prepared. I guess
coupled with this is which debugger to people like the best? Is there
any kind of 'remote' debugging solution available? By that I mean
controlling the A2 remotely so the debugger doesn't clobber the native
A2 screen, etc. Is there a way to switch between the debugger
(whichever one allows this) and the app's screen?
Thanks for all your feedback.
]3ob
Sheppy
> With all of the talk recently in c.s.a2 about assemblers, I got to
> wondering about the different flavors of assemblers that are available
> (for pre-IIgs hardware).
>
> I don't want to start a war, but which one is considered the best (and
> why)?
IMHO this depends on your needs. Merlin is fast and has an easier to
use macro syntax, but ORCA's macro system is more powerful (although
it has a very steep learning curve). ORCA assembles more slowly, but
you can combine ORCA/M assembly projects with C, Pascal, Modula-2,
Integer BASIC, and so forth, which makes it really convenient for
multi-language projects. It also has an arguably more powerful
development environment, although this depends largely on how you use
the software.
For projects where I'm certain I'm only doing assembly, I typically
prefer Merlin. If I think there's even a possibility I might need to
do some C code (which is these days most of my projects), I use ORCA/
M.
Sheppy
]3ob
> For projects where I'm certain I'm only doing assembly, I typically
> prefer Merlin. If I think there's even a possibility I might need to
> do some C code (which is these days most of my projects), I use ORCA/
> M.
If I'm not mistaken, ORCA is only for IIgs? (You only ship it on 3.5".
:) I was specifically asking about _pre_IIgs assemblers/debuggers.
Sheppy
There's ORCA/M 2.1 for Apple IIgs and ORCA/M 4.1 for 8-bit Apple II
systems. The latter is shipped on two 5.25" disks and one 3.5" disk,
and works on the Apple ][+ and later.
Sheppy
]3ob
> There's ORCA/M 2.1 for Apple IIgs and ORCA/M 4.1 for 8-bit Apple II
> systems. The latter is shipped on two 5.25" disks and one 3.5" disk,
> and works on the Apple ][+ and later.
Oh, nice! Thanks for the info!
Bill Buckels
>Oh, nice! Thanks for the info!
Aztec C comes with assemblers and there are native mode and MS-DOS (Windows)
cross-development environments for DOS 3.3 and ProDOS 8 for the Apple II and
Apple //e.
Look here:
http://www.aztecmuseum.ca/index.htm
http://www.aztecmuseum.ca/compilers.htm#applenative
http://www.aztecmuseum.ca/compilers.htm#applecross
I prefer to work in Windows and with the Applewin emulator when developing.
http://download.berlios.de/applewin/
Some discussion on Full Screen Debugger - in comp.emulators.apple2 and Tom
says to be out of Beta soon.
The Manx Native Mode Assembler AS is documented in the C65A Manual beginning
on page 98:
http://www.aztecmuseum.ca/docs/MANXC65A.PDF
Other Docs:
http://www.aztecmuseum.ca/docs/
Bill
mmphosis
it's retro: it was built into the ROM of the original Apple II. And
I like it because it's simple: it assembles 6502 mnemonics.
I would run this in an emulator with a debugger process running
outside the emulated machine with debugging information displayed/
piped to any manner of devices.
Sheppy
> I like the Sweet 16 mini-assembler the best. I like it best because
> it's retro: it was built into the ROM of the original Apple II. And
> I like it because it's simple: it assembles 6502 mnemonics.
I used the mini-assembler for a long while, although before that I
actually assembled my code myself on paper so I could key in the
hexadecimal values by hand (this was before I was using a machine
capable of loading the mini-assembler). I didn't much care for either
approach, and certainly wouldn't want to do either for anything of
substance nowadays, although to this day I occasionally key in small
bits of code by hand like that.
Sheppy
Bill Buckels
>Aztec C comes with assemblers and there are native mode and MS-DOS
>(Windows) cross-development environments for DOS 3.3 and ProDOS 8 for the
>Apple II and Apple //e.
Aztec C for the Apple II also comes with complete library source code which
includes the assembly language core, and is from the days when the compiler
output to assembly language. (All the aztec C compilers on the aztec C
website come with source including the CP/M 80 compilers which also run on
the Softcard and of course the Applicard even if it's not your Father's)
Another feature is the inline assembly capabilities. For example here's a
function scope DOS 3.3 catalog call which works in an Aztec C program:
catalog()
{
#asm
clc
jsr $a56e
#endasm
}
The following global scope mixed C and assembler mouse routines are taken
from my metoo children's program for ProDOS 8:
http://www.appleoldies.ca/MeToo.pdf
http://www.appleoldies.ca/metoo.zip
which is bundled with the Aztec C AppleX ProDOS cross-compiler distribution
for Windows XP:
http://www.aztecmuseum.ca/compilers.htm#applecross
Note that the mouse coordinates are set to correspond with the coordinates
used in Applewin. I checked with Oliver on this. In the old days I used a
coarser resolution.
Note also that the Aztec C65 compiler and assembler documentation is really
complete and lots of samples and libraries by me and others are on the
website.
x--- snip ---x
/* mouse routines */
/* turn the mouse on */
mouseon()
{
setmouseon();
homemouse();
readmouse();
}
/* read the mouse */
/* update the globals */
cmouse()
{
unsigned char *ptr;
readmouse();
/* mouse status register */
ptr=(unsigned char *)1916;
mousebutton=0;
mousebutton+=ptr[0];
/* x coordinate - units = 0-1023 */
mousex=0;
ptr=(unsigned char *)1404; /* MSB */
mousex +=ptr[0];
mousex <<= 8;
ptr=(unsigned char *)1148; /* LSB */
mousex +=ptr[0];
if(mousex>MXMAX)mousex=MXMAX;
/* use 0-1023 horizontal units */
/* y coordinate - units = 0-1023 */
mousey=0;
ptr=(unsigned char *)1532; /* MSB */
mousey +=ptr[0];
mousey <<= 8;
ptr=(unsigned char *)1276; /* LSB */
mousey +=ptr[0];
if(mousey>MYMAX)mousey=MYMAX;
/* use 0-1023 vertical units */
}
/* 6502 assembly language mouse core functions */
#asm
*
* use the second line of the second page of the text screen
* as a dynamic dispatch vector set pointing to the mouse routines
*
SETMOUSE EQU $880
SERVEMOUSE EQU SETMOUSE+3
READMOUSE EQU SETMOUSE+6
CLEARMOUSE EQU SETMOUSE+9
POSMOUSE EQU SETMOUSE+12
CLAMPMOUSE EQU SETMOUSE+15
HOMEMOUSE EQU SETMOUSE+18
INITMOUSE EQU SETMOUSE+21
public setmouseon_
setmouseon_
lda #$01
ldx #$C4
ldy #$40
cli
jsr SETMOUSE
rts
public homemouse_
homemouse_
ldx #$C4
ldy #$40
jsr HOMEMOUSE
rts
public readmouse_
readmouse_
ldx #$C4
ldy #$40
php
sei
jsr READMOUSE
cli
plp
rts
public mouseoff_
mouseoff_
lda #$00
ldx #$C4
ldy #$40
cli
jsr SETMOUSE
rts
#endasm
/* as above noted:
* use text screen page two line two as an intermediate jump area
* for access to the 8-mouse firmware subroutines.
* we use a jsr to get there from our code.
* our jmp vector instruction is placed there based on the rom
* configuration of the current platform.
* because we jsr'd from our code, we will return safely to our
* code. this is why we use a jmp to loop from our vector
* to the firmware.
*/
mouseinit()
{
unsigned char *vptr,*tptr;
unsigned char temp,i;
vptr=(unsigned char *)0xc40b; /* firmware card signature */
temp=vptr[0];
if(temp!=1)return; /* this must be set to 1 */
temp=vptr[1]; /* X Y pointing device signature */
if(temp!=32)return; /* this must be set to $20 */
vptr=(unsigned char *)0xc411; /* start of mouse vectors */
mouseflag=vptr[0]; /* this must be set to 0 */
if(mouseflag)return;
tptr=(unsigned char *)0x880; /* base address - page 2 line 2 */
for(i=0;i<8;i++)
{
*vptr++;
temp=*vptr;
*tptr= '\x4c'; /* raw jmp instruction */
*tptr++;
*tptr= temp ; /* mouse subroutine offset */
*tptr++;
*tptr= '\xc4'; /* base of mouse routines */
*tptr++;
}
}
Bill Buckels
"Bill Buckels" <bbuc...@mts.net> wrote:
>Aztec C comes with assemblers and there are native mode and MS-DOS
>(Windows) cross-development environments for DOS 3.3 and ProDOS 8 for the
>Apple II and Apple //e.
For using the aztec C MS-DOS cross-compilers and cross-assemblers for the
Apple II and other targets like CP/M 80 and even the Commodore 64 in
unix-like systems (linux etc), an MS-DOS emulator is required. This works
quite well in Ubuntu and I have the installation documentation on the Aztec
C website for anyone who is so inclined.
http://www.aztecmuseum.ca/docs/notes.htm
Here is the specific document:
Using Aztec C in Linux:
http://www.aztecmuseum.ca/docs/linux.txt
Bill
]3ob
> For using the aztec C MS-DOS cross-compilers and cross-assemblers for the
> Apple II and other targets like CP/M 80 and even the Commodore 64 in
> unix-like systems (linux etc), an MS-DOS emulator is required. This works
> quite well in Ubuntu and I have the installation documentation on the Aztec
> C website for anyone who is so inclined.
>
> http://www.aztecmuseum.ca/docs/notes.htm
>
> Here is the specific document:
>
> Using Aztec C in Linux:
>
> http://www.aztecmuseum.ca/docs/linux.txt
Thanks for all the good info.
]3ob
Bill Buckels
"]3ob" <jo...@doe.com> wrote:
>Thanks for all the good info.
My pleasure.
It's nice to have lots of alternatives. I have a GS that I am starting to
restore and I have an ORCA C Compiler that I want to work with at some
point. I didn't give the GS a chance back in the '80's and abandoned Apple
altogether around the time I had my
http://en.wikipedia.org/wiki/Macintosh_IIci
Or perhaps it was a little later. I used Think C on the IIci somewhat but
Windows 3.1 had overtaken me by that time. I remember mucking a little with
Filemaker Pro from year to year after that.
Now it's time to get back to the garden.
Bill
Jeff Blakeney
On Mon, 6 Apr 2009 17:44:15 -0700, Sheppy wrote:
> There's ORCA/M 2.1 for Apple IIgs and ORCA/M 4.1 for 8-bit Apple II
> systems. The latter is shipped on two 5.25" disks and one 3.5" disk,
> and works on the Apple ][+ and later.
Yes, ORCA/M started as an 8 bit assembler but your statement of:
> ORCA assembles more slowly, but you can combine ORCA/M assembly
> projects with C, Pascal, Modula-2, Integer BASIC, and so forth, which
> makes it really convenient for multi-language projects.
only applies to the Orca suite for the IIgs as far as I know.
Bill Buckels
"Jeff Blakeney" <jeff.b...@a2central.com.remove-9z2-this> wrote:
>> ORCA assembles more slowly, but you can combine ORCA/M assembly
>> projects with C, Pascal, Modula-2, Integer BASIC, and so forth, which
>> makes it really convenient for multi-language projects.
>only applies to the Orca suite for the IIgs as far as I know.
Using the Aztec C Assembler one does not have this limitation but is
confined to C and Assembly mixed language programming. As far as Pascal and
BASIC etc... well... a C programmer really has no need of those.
I do want to say however that Mike Westerfield's C Compiler has a really
nice user interface and really is of the next generation of C compiler. It's
a nicer user experience for a mouse-master... that's for sure. It is ANSI.
and has an IDE... but I do find the documentation is not as complete as
Aztec C's documentation. Or maybe I should say that it is not quite as
detailed. The aztec C65 manual is 100 pages longer and has much less about
windows and frames of course.
Two different animals anyway:) I couldn't be bothered to compile ProDOS or
DOS 3.3 programs in native mode anyway which is why I bought the IBM-PC
cross-compilers and cross-assemblers in the first place back in the '80's so
Aztec C's assembler wins in the speed of assembly area on this comparison.
No contest. You blink your eye slower under XP on a DX/2 3000 or whatever.
I prefer to work in the comfort of my usual text editor etc.
Bill
Sheppy
<jeff.blake...@a2central.com.remove-9z2-this> wrote:
> Yes, ORCA/M started as an 8 bit assembler but your statement of:
>
> > ORCA assembles more slowly, but you can combine ORCA/M assembly
> > projects with C, Pascal, Modula-2, Integer BASIC, and so forth, which
> > makes it really convenient for multi-language projects.
>
> only applies to the Orca suite for the IIgs as far as I know.
You're right. I was thinking about the IIgs version at the time I
wrote that.
Sheppy
lyricalnanoha
On Wed, 8 Apr 2009, Bill Buckels wrote:
> Two different animals anyway:) I couldn't be bothered to compile ProDOS or
> DOS 3.3 programs in native mode anyway which is why I bought the IBM-PC
> cross-compilers and cross-assemblers in the first place back in the '80's so
> Aztec C's assembler wins in the speed of assembly area on this comparison.
> No contest. You blink your eye slower under XP on a DX/2 3000 or whatever.
>
> I prefer to work in the comfort of my usual text editor etc.
Same. I do most of my coding in "gedit" these days.
-uso.
Oliver Schmidt
>With all of the talk recently in c.s.a2 about assemblers, I got to
>wondering about the different flavors of assemblers that are available
>(for pre-IIgs hardware).
If "for pre-IIgs hardware" includes cross assemblers then the cc65
toolchain (www.cc65.org) may interest you as well. It contains a
powerful macro-assembler, which is btw nicely integrated with a C
compiler. The focus of the package lies on standard compliance with C
and POSIX specs. It is available for free both as source and binaries
running natively on many platforms - incl. Windows.
Best, Oliver
mdj
> With all of the talk recently in c.s.a2 about assemblers, I got to
> wondering about the different flavors of assemblers that are available
> (for pre-IIgs hardware).
Merlin 8/16 is the only popular assembler for which we have access to
the source, and as far as I know, public domain rights.
I've tended to prefer EDASM (mentioned in another thread) primarily
because it's disk based and has command line driven interface. The
usefulness of Merlins in-memory approach is questionable for larger
than average projects.
Now that the source is available, I'm hoping someone will put a sane
CLI on Merlin, or at least integrate it with one of the existing ones.
Matt
Michael J. Mahon
> On Apr 7, 6:13 am, ]3ob <j...@doe.com> wrote:
>> With all of the talk recently in c.s.a2 about assemblers, I got to
>> wondering about the different flavors of assemblers that are available
>> (for pre-IIgs hardware).
>
> Merlin 8/16 is the only popular assembler for which we have access to
> the source, and as far as I know, public domain rights.
>
> I've tended to prefer EDASM (mentioned in another thread) primarily
> because it's disk based and has command line driven interface. The
> usefulness of Merlins in-memory approach is questionable for larger
> than average projects.
I thought that Merlin could assemble to disk, as well as "chain"
source into memory using "put". Then there's always separate
assembly and linking...
-michael
******** Note new website URL ********
NadaNet and AppleCrate II for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
mdj
> mdj wrote:
> > On Apr 7, 6:13 am, ]3ob <j...@doe.com> wrote:
> >> With all of the talk recently in c.s.a2 about assemblers, I got to
> >> wondering about the different flavors of assemblers that are available
> >> (for pre-IIgs hardware).
>
> > Merlin 8/16 is the only popular assembler for which we have access to
> > the source, and as far as I know, public domain rights.
>
> > I've tended to prefer EDASM (mentioned in another thread) primarily
> > because it's disk based and has command line driven interface. The
> > usefulness of Merlins in-memory approach is questionable for larger
> > than average projects.
>
> I thought that Merlin could assemble to disk, as well as "chain"
> source into memory using "put". Then there's always separate
> assembly and linking...
Indeed it can. I've just always found it somewhat tedious for multi-
file projects since you need to load the linker spec file into the
editor then 'assemble' it to get the desired output. EDASM's CLI
functionality makes it dead simple to create an EXEC file that builds
your project.
I tend to find my Merlin source files get a lot larger before I
consider segmenting them simply because of the overly 'interactive'
interface. But it's probably just too many years of Unix (vi, emacs
and cli tools) talking :-)
Matt
PZ
extremely fast. The older version is DOS 3.3 based, while the latest
version is ProDOS based. A GS version was released as well.
http://en.wikipedia.org/wiki/Lisa_assembler
has info and has links to downloads, source and documentation.
- Paul
Bill Buckels
> http://en.wikipedia.org/wiki/Lisa_assembler
Thanks Paul,
I am more interested in Randy ANIX Shell:) I didn't know about this!
Bill
PZ
No problem!
Skimming through the documentation, Randy mentioned that v3.2 should
be used by experienced assembly programmers while those who are newer
to programming assembly should use v2.6 of his interactive assembler.
Anyone have any insight on this and the differences? I'm not even sure
if v2.6 was DOS 3.3 based, or if it had a ProDOS version. Did he
strip out some of the more user friendly features in order to improve
performance? Let me know what you find out.
- Paul <-----not an assembly level programmer
Michael J. Mahon
I'd guess he stripped out helpful error messages to get space
for more features/speed.
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon
Lane
8 bit DOS: Turbo Assembler. No other offering compares to features,
editor or speed.
8 bit ProDOS: Merlin Pro - unfortunately Turbo Assembler never made it
over to ProDOS (at least as far as I know).
16 bit GS/OS: QuickASM - ok, so I am a bit biased here since I helped
develop it. :) Realistically, Merlin 8/16 is your best bet, as I can't
seem to find a single download of QuickASM online - guess I will have
to get time to correct that at some point. If you have a version of
Merlin that shipped somewhat later, it should have my project
management extensions included which make working with multiple
projects, and/or with very large projects with lots of files, some of
which were very large (Dark Castle //gs for instance) a LOT easier.
The Lisa assembler was also not a bad choice for any of these targets.
Apple's pre-APW assembler was also decent. I could never appreciate
the Orca offerings, by the time it finished loading and assembling one
pass I was able to complete my work in any of the others.
There was a mention that the source code to Merlin 8/16 was available,
but I didn't see a link and couldn't figure out the correct search
term for google. Where can I get the source?
Lane Roathe, CEO
Ideas From the Deep, llc.
apple
> but I didn't see a link and couldn't figure out the correct search
> term for google. Where can I get the source?
Never mind, after a bit of reading (some very interesting posts) on
the lists I found it. :)
-lane
Michael J. Mahon
Congrats, Lane!
And where did you find the DOS Turbo Assembler on line...? (You've
made me curious.)