Re: [cc65] ca65 for stand-alone asm projects

From: Agent Friday <64subnet1gmail.com>
Date: 2010-11-05 21:59:27
On Fri, Nov 5, 2010 at 5:42 AM, Ullrich von Bassewitz wrote:
> . . . what people expect is not so much formed by what does make sense
> or what is possible on other platforms, but what they're used to . . .
> . . this is why people get so upset: They're used so much to having [the
> load address] supplied automatically, that they don't even think about
> it any more.  As a consequence, ca65 is bad - not because it really is,
> but because it doesn't live up to the expectations.

As I see it, providing the load address really is about making
sense as well.  The proper file format for a PRG type file on the
Commodores machines--a loadable, executable file-- *always* includes
a load address.  Without it, you can't really do anything with a
machine language program file.  BASIC probrams do not rely on this
address, but if at least _some_ addres in the first two bytes, even
tose files become unusable.

It would be really handy if compiled code were not tied to a
particular address and you could load and execute them at any
address on the C64, but that's a different file format altogether
(called o65 :).  Too bad there's no loader to let you take advantage
of it... but that's something I hope to change.

> So I do also expect that adding a BASIC header by default, so people
> could start asm programs with RUN, would make them upset. Not so much
> because it isn't useful, but because they aren't used to it.

Binding complete applications to a BASIC stub is quite useful.  But
for machine code utilities that work along with BASIC and other
loaded tools, it just isn't workable.

So, do we CBM types really come across all whiny and ungrateful?

// Agent Friday
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Nov 5 21:59:35 2010

This archive was generated by hypermail 2.1.8 : 2010-11-05 21:59:37 CET