Re: [cc65] Splitting crt0.s files in two?

From: Fatih AygŁn <>
Date: 2009-11-05 19:05:56

Uz wrote:
> If this were a real advantage, why has no one before used this approach? It is

> up to you, to write a small module that contains the header in a special
> segment, write a matching linker config and use this as a base for your
> assembler programs.

I do that all the time :) I'll try to explain the real advantage for me. It's a little
long, sorry...

Before discovering cc65 years ago, I was using Atari specific assemblers to write
assembly programs. But I wasn't happy with them and I even wrote my own crappy
assembler (I woder who didn't? :)) to add support for my needs. Then I met with cc65.
After a glipse at the tutorial, it took me two seconds to compile a "hello world" C program 
like this:

cl65 --target atari hello.c

And I started my emulator and loaded the output file and everything was fine. I was very
impressed :) But what I was really looking for was ca65, which was (and still is) the best
6502 assembler I have ever used. But it took me hours to be able to assemble and link
a simple assembly program. I had to dive deep into the ld65 docs and even to download
the library sources to see how it was done.

If the library contained a simple binary header, forced to be linked in by the default config,
which in turn looks for a start label, forcing the c initialization to be linked in, unless the
label is already defined, it would be much easier:

cl65 --target atari test.s

Where test.s defines the start label, and voila, I've got my Atari binary :) Ofcourse I could
do it even now with the test.s defining _main, but assembly programmers are picky, I would
wonder why my simple program generates such a big binary :)

> In addition, you
> will have to tell the linker to add the header from the library. All this
> together is probably too much for any casual ca65 user.

No. The default config file will tell that. And changing the binary format will be a simple matter of 
using an alternative linker config. 

In short, I think the feature I request is more user friendly, especially for a new comer wanting to 
do some assembly coding since most target specific assemblers just output the target's binary

> Again, I cannot see that a real advantage here. A disk image is usually
> created by other tools than ld65. A cartridge needs a new startup code anyway,
> because initialization differs. So you have to change the startup code. And
> when doing so, it's just 5 seconds to replace the SYS header by a "CBM80"
> string or whatever.

I was referring to a bootable disk image, a disk image without any file system in it.
It's a bit Atari specific, sorry. It's basically a header followed by an actual program, 
just like most other binary formats. And it's more or less the same with the bootable 
cassette binary format, and I think, is quiet popular for non-dos software. (cc65 
currently outputs an Atari DOS executable). You boot your computer with the diskette 
attached (or the cassette attached and the "start" key down) and the program loads 

I can see that memory initialization would be different for cartridges. So a new startup file
is the only option I guess. But they can still share most of the code with includes or conditional
compilation, and even by splitting them further to more files :P


To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Thu Nov 5 19:06:01 2009

This archive was generated by hypermail 2.1.8 : 2009-11-05 19:06:03 CET