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

Hi,

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
format.

> 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 
automatically.

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

Regards,
Fatih.


      
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.