TIP: Click on subject to list as thread! ANSI
echo: apple
to: comp.sys.apple2
from: mdj
date: 2008-08-21 21:23:48
subject: Re: To cross develop or not - was Re: eBay WTH?

On Aug 22, 3:24 am, heuser.mar...{at}freenet.de wrote:

> > The biggest time saver for me ended up having an emulation
> > environment that could start up quickly and load the binary I had
> > just build with the cc65 toolchain.  Having the ability to break
> > into the emulator and check memory values and insert watchpoints/
> > breakpoints was crucial.  Since I use a Mac, Virtual ][ was not
> > just the obvious choice, it was a godsend.  No source code level
> > debugging here!  Full screen wasn't an issue as I generally needed
> > to have the source code windows up next to the emulator.
>
> ...but source and emu/debugger next to each other are great, of
> course. You don't know an assembler IDE by chance? ;-)

My workflow is probably pretty similar to Dave's. Although I'd prefer
to
code on the Apple II where possible (I like the "no distractions"
environment
if provides), I spend so much time developing on modern platforms I
find that
the somewhat manual process of application switching, etc. on the
Apple II to
be a distraction. Over time, I've come up with a relatively
streamlined setup
using a combination of Merlin, ProSEL and EXEC files which works well.
However,
I tend to write my code using lots of fairly small files and as such I
very
much miss my modern toolchain.

Rather than go completely cross-platform (although I do when I want
the
convenience of C) my approach is to use Emacs to edit my Merlin files,
and let
an Apple II emulator running 'flat out' assemble them. This way when I
feel
like sitting down at my IIe, I can, and I can also work on the same
sources
in a more powerful environment as either my mood or location demands.

I've recently finished migrating myself from Linux as my primary
workstation
to a Mac, and have stopped using Kegs in favour of Virtual ][. V2 has
two very
impressive features that make it (now that I have them) indispensible:

1. Ability to treat a directory on the Mac as a ProDOS volume
2. AppleScript

By combining the two with Emacs' extensibility and macros, I can have
two
keystrokes assigned to 'assemble' and 'run' that can transparently
invoke
the emulator to do the magic and voila! Apple II development is as
easy
as writing Ruby scripts :-)

> > Transferring everything over to real hardware once in a while is
> > important to ensure the feel and look is right.
>
> I really do agree on that. Especially when you do something
> graphically.
>
> > For content creation, I wrote tools in AppleSoft and ran the
> > emulator at full speed. It made for pretty quick development
> > inside the environment the content would be seen in.  My content
> > was pretty minimal though.
>
> I'll have a look at cc65 which, judging by your efforts, contains
> a good enough assembler and linker. I already had the link to their
> homepage but didn't evaluate it, yet.

If you don't have the 'requirement' of Apple II compatible source
code,
the cc65 assembler and linker is probably the best option out there.
For me,
I'm way too familiar with Merlin's macro facilities to be bothered
much with
learning anything else. If someone were to write a native assembler/
linker
that was cc65 compatible i'd switch to that without hesitation.

Matt
--- SBBSecho 2.12-Win32
* Origin: Derby City Gateway (1:2320/100.2008)
SEEN-BY: 10/1 3 34/999 106/1 120/228 123/500 140/1 222/2 226/0 236/150 249/303
SEEN-BY: 250/306 261/20 38 100 1404 1406 1410 1418 266/1413 280/1027 320/119
SEEN-BY: 393/11 396/45 633/260 267 712/848 800/432 801/161 189 2222/700
SEEN-BY: 2320/100 105 200 2905/0
@PATH: 2320/100 261/38 633/260 267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.