Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #4407 > unrolled thread

Problems building with ca65/ld65 ...

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Problems building with ca65/ld65 ... James Keim <email@jameskeim.com> - 2018-03-21 19:19 -0700
    Problems building with ca65/ld65 ... Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-03-21 21:49 -0700
      Re: Problems building with ca65/ld65 ... James Keim <email@jameskeim.com> - 2018-03-21 22:26 -0700
        Re: Problems building with ca65/ld65 ... James Keim <email@jameskeim.com> - 2018-03-21 23:14 -0700
          Re: Problems building with ca65/ld65 ... MG <*@guidero.us> - 2018-03-22 00:10 -0700
            Re: Problems building with ca65/ld65 ... James Keim <email@jameskeim.com> - 2018-03-22 06:33 -0700
            Re: Problems building with ca65/ld65 ... Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-03-22 10:38 -0700
              Re: Problems building with ca65/ld65 ... ol.sc@web.de (Oliver Schmidt) - 2018-03-22 23:08 +0000
                Re: Problems building with ca65/ld65 ... Antoine Vignau <antoine.vignau@laposte.net> - 2018-03-22 19:27 -0700
                  Re: Problems building with ca65/ld65 ... Steve Nickolas <usotsuki@buric.co> - 2018-03-22 22:55 -0400
                    Re: Problems building with ca65/ld65 ... ol.sc@web.de (Oliver Schmidt) - 2018-03-23 21:33 +0000
                      Re: Problems building with ca65/ld65 ... Steve Nickolas <usotsuki@buric.co> - 2018-03-23 18:51 -0400
                        Re: Problems building with ca65/ld65 ... ol.sc@web.de (Oliver Schmidt) - 2018-03-24 07:27 +0000
                  Re: Problems building with ca65/ld65 ... ol.sc@web.de (Oliver Schmidt) - 2018-03-23 21:33 +0000
                    Re: Problems building with ca65/ld65 ... Antoine Vignau <antoine.vignau@laposte.net> - 2018-03-23 16:16 -0700
                      Re: Problems building with ca65/ld65 ... ol.sc@web.de (Oliver Schmidt) - 2018-03-24 07:32 +0000
                        Re: Problems building with ca65/ld65 ... "Bill Buckels" <bbuckels@mts.net> - 2018-03-24 03:24 -0500
                Re: Problems building with ca65/ld65 ... Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-03-22 21:05 -0700
                  Re: Problems building with ca65/ld65 ... MG <guidero@gmail.com> - 2018-03-23 09:17 -0700
                  Re: Problems building with ca65/ld65 ... "Bill Buckels" <bbuckels@mts.net> - 2018-03-24 03:47 -0500
            Re: Problems building with ca65/ld65 ... Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-03-23 11:03 -0700
              Re: Problems building with ca65/ld65 ... Antoine Vignau <antoine.vignau@laposte.net> - 2018-03-23 14:10 -0700
        Re: Problems building with ca65/ld65 ... Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-03-23 07:57 -0700

Page 1 of 2  [1] 2  Next page →

#4407 — Problems building with ca65/ld65 ...

I really don't know what I'm doing but I'm interested in compiling the dclock.system to use with my new Ramexpress II+ card. I want to try the version located here: 

https://gist.github.com/mgcaret/7f0d7aeec169e90809c7cfaab9bf183b 

However, when I try to follow the instructions, I run into a problem at this command: 
     ld65 -t none -o dclock.system dclock.system.o 

I receive an error that says: 
     ld65: Error: Cannot find config file `none.cfg' 

I'm using Arch Linux updated last week. ca65/ld65 V2.16 - Git d54d46c. Googling a bit suggests that if I use "-t none" that I also have to "-C config.cfg" but I'm not sure what config.cfg should be. 

Anyone run into this before? What am I missing? 

Thanks, 
James 

[toc] | [next] | [standalone]

#4408

1. Try using an assembler that doesn't suck out-of-the-box, like Merlin32. That way you don't waste your time with bullshit linker / configuration problems.  Using Merlin32 also lets you use the _same_ assembler source on real / emulated hardware.

2. The cc65 configuration file reside in: cfg/
i.e. 
* cfg/none.cfg
* cfg/apple2.cfg
* cfg/apple2enh.cfg
* cfg/apple2enh-asm.cfg

3. You may want to try:

-t apple2enh -C apple2enh-asm.cfg

4. But I'm assuming that since cc65 isn't in your path you will run into the same issue. The contents of none.cfg are:

- - - 8< cfg/none.cfg - - - 
SYMBOLS {
    __STACKSIZE__: type = weak, value = $0800; # 2k stack
}
MEMORY {
    ZP:  file = "", define = yes, start = $0000, size = $0001F;
    RAM: file = %O,               start = %S,    size = $10000 - __STACKSIZE__;
}
SEGMENTS {
    LOWCODE:  load = RAM, type = ro,                optional = yes;
    INIT:     load = RAM, type = ro,  define = yes, optional = yes;
    CODE:     load = RAM, type = rw;
    RODATA:   load = RAM, type = rw;
    DATA:     load = RAM, type = rw;
    BSS:      load = RAM, type = bss, define = yes;
    ZEROPAGE: load = ZP,  type = zp;
}
FEATURES {
    CONDES: type    = constructor,
            label   = __CONSTRUCTOR_TABLE__,
            count   = __CONSTRUCTOR_COUNT__,
            segment = INIT;
    CONDES: type    = destructor,
            label   = __DESTRUCTOR_TABLE__,
            count   = __DESTRUCTOR_COUNT__,
            segment = RODATA;
    CONDES: type    = interruptor,
            label   = __INTERRUPTOR_TABLE__,
            count   = __INTERRUPTOR_COUNT__,
            segment = RODATA,
            import  = __CALLIRQ__;
}
- - - 8< - - -

[toc] | [prev] | [next] | [standalone]

#4409

On Wednesday, March 21, 2018 at 11:49:35 PM UTC-5, Michael Pohoreski wrote:
> 1. Try using an assembler that doesn't suck out-of-the-box, like Merlin32. That way you don't waste your time with bullshit linker / configuration problems.  Using Merlin32 also lets you use the _same_ assembler source on real / emulated hardware.

Michael,
Thanks for the suggestions. I'll give them a shot. I'm just teaching myself assembler and wondered if I could convert it to Merlin-16 as that is what I'm using. Sitting here with "Assembly Lines: The Complete Book" on my lap.

But I only know enough to get myself in over my head. Since the file itself included build instructions using ca65 I was just following it instructions but I do appreciate the recommendations. 

And, it does look like I have a path issue. I'll use the file locations and see what happens.

Thanks,
James

[toc] | [prev] | [next] | [standalone]

#4410

Thanks again. The path was the problem. I substituted "-C /usr/share/cc65/cfg/none.cfg" for "-t none" and that allowed it to finish building. Moved it over to my IIc+, used Appleworks to set the filetype (it really does do everything), and now have a less buggy DCLOCK.SYSTEM providing the ProDOS clock. 

Appreciate the nudge in the right direction.

[toc] | [prev] | [next] | [standalone]

#4411

On Wednesday, March 21, 2018 at 11:14:58 PM UTC-7, James Keim wrote:
> Thanks again. The path was the problem. I substituted "-C /usr/share/cc65/cfg/none.cfg" for "-t none" and that allowed it to finish building. Moved it over to my IIc+, used Appleworks to set the filetype (it really does do everything), and now have a less buggy DCLOCK.SYSTEM providing the ProDOS clock. 
> 
> Appreciate the nudge in the right direction.

Well, that disassembly and fix of the DClock driver would be my work.

-t foo is short for ..../cfg/foo.cfg, so specifying the full path to your desired config via -C gives the same results.

I'm curious as to the path of the ld65 binary and whether you installed it as pre-compiled package or by cloning/building yourself.  By default it looks for the aforementioned cfg directory in one of several places (see https://cc65.github.io/doc/ld65.html#ss3.3).  If that isn't at the default compiled-in location for the cfg dir, you will ned to tell it where it lives.

In your case, set CC65_HOME=/usr/share/cc65 and you'll be good to go with the instructions I provided in the file.

MG

[toc] | [prev] | [next] | [standalone]

#4412

Yes! Thanks, MG, for all your work! I’m learning a lot by following your Github repositories. My IIc+ has the 12/10/18 version of your ROM 5x and now I’m using the your patched DCLOCK.SYSTEM. 

I installed a CC65 package from the Arch User Repository. Arch is fairly hardcore about requiring the user to setup their own configurations but I guess I didn’t spend the time with this package. I need to go back and look at what was configured at compile time for these packages ... or clone and compile it myself. 

The link to the cc65 Github docs are helpful as is the explanation of the ld65 config file search path. Overall, I’m hearing you say “RTFM” but in a very kind way. ;-)

Thanks again for all your work on the Apple II. I’m finding it all very helpful. 

James

[toc] | [prev] | [next] | [standalone]

#4413

> In your case, set CC65_HOME=/usr/share/cc65 and you'll be good to go with the instructions I provided in the file. 

That is the proper solution.

One of the reasons cc65 sucks out-of-the-box is that there is no install script that sets this environment variable -- and you are forced to waste your time RTFM.  I corrected this oversight with install.sh file in my forked branch cc65upstream.

https://github.com/Michaelangel007/cc65/blob/cc65upstream/apple2/install.sh

[toc] | [prev] | [next] | [standalone]

#4414

On Thu, 22 Mar 2018 10:38:07 -0700 (PDT), Michael Pohoreski
<michael.pohoreski@gmail.com> wrote:

>> In your case, set CC65_HOME=/usr/share/cc65 and you'll be good to go with the instructions I provided in the file. 
>
>That is the proper solution.

Nope, not at all.

>One of the reasons cc65 sucks out-of-the-box is that there is no install script that sets this environment variable -- and you are forced to waste your time RTFM.

The environment variable isn't supposed to be used. Just stop ranting
about things you have not the slightest idea of.

Oliver

[toc] | [prev] | [next] | [standalone]

#4415

Relax, Oliver!

Could you explain why things present are not to be used?

[toc] | [prev] | [next] | [standalone]

#4416

On Thu, 22 Mar 2018, Antoine Vignau wrote:

> Relax, Oliver!
>
> Could you explain why things present are not to be used?
>

Well, it's really for MS-DOS and Windows users, isn't it?

-uso.

[toc] | [prev] | [next] | [standalone]

#4425

Hi Steve,

>Well, it's really for MS-DOS and Windows users, isn't it?

Actually not.

- The cc65 Windows binaries are 32-bit binaries which for sure don't
work on MS-DOS ;-)

- In fact Windows requires it even less than *IX.

On Windows you simply unzip the cc65 snapshot into any directory and
it'll just work. That's because cc65 can use GetModuleFileName() to
find the true absolute path to itself and deduct all necessary paths
from that:
https://github.com/cc65/cc65/blob/master/src/common/searchpath.c#L173

On *IX you have to make sure that cc65 ends up in the "correct"
directory as it has all necessary paths built into the binaries (like
e.g. GCC):
https://github.com/cc65/cc65/blob/master/src/Makefile#L67-L68

The latter is ensured by either building cc65 from the source (and not
moving it elsewhere afterwards) or by using the supported packages
from
https://software.opensuse.org/download.html?project=home%3Astrik&package=cc65

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#4427

On Fri, 23 Mar 2018, Oliver Schmidt wrote:

> Hi Steve,
>
>> Well, it's really for MS-DOS and Windows users, isn't it?
>
> Actually not.
>
> - The cc65 Windows binaries are 32-bit binaries which for sure don't
> work on MS-DOS ;-)

When I first used CC65, my main PC ran PC DOS 7, and I ran CC65 on it. 
The version that existed at that time required DOS4GW.EXE so was compiled 
with Watcom C.  Or am I misremembering?

-uso.

[toc] | [prev] | [next] | [standalone]

#4436

Hi Steve,

>> - The cc65 Windows binaries are 32-bit binaries which for sure don't
>> work on MS-DOS ;-)
>
>When I first used CC65, my main PC ran PC DOS 7, and I ran CC65 on it. 
>The version that existed at that time required DOS4GW.EXE so was compiled 
>with Watcom C.  Or am I misremembering?

Sorry, a misunderstanding. I was referring to the current cc65 as the
original question referred to the current cc65.

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#4426

Hi Antoine,

>Relax, Oliver!

Likely the best advice...

>Could you explain why things present are not to be used?

For sure. CC65_HOME is present for two reasons:

1. It was necessary in former times.

2. It is beneficial in special scenarios.

One example for the latter: A user wants to modify/extend a cc65 C
library but he doesn't want to build cc65 itself from the sources.
Maybe he doesn't even have GCC (or Visual C++) at hand.

The user installs the "binary cc65" as usual in directory A (and ueses
it as usual). Additionally he clones the cc65 sources in directory B.
Then he can set CC65_HOME to B. This makes the cc65 binaries in A work
with the headers/configs/<...> in B.

While I'm at explaining things. Here are some sensible command lines:

cl65 -t apple2 hello.c

... creates from the C source an AppleSingle file that can be imported
into a disk image with AppleCOmmander or Cadius.

cl65 -t none hello.s

... creates from the asm source (with .ORG directive) a bare binary
file.

cl65 -t apple2 -C apple2-asm.cfg -u __EXEHDR__ test.s

... creates from the asm source  (with .ORG directive) an AppleSingle
file that can be imported into a disk image with AppleCOmmander or
Cadius.

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#4428

Thank you, Oliver, for the detailed explanations.

I have another question, not "linked" to cc/ca65, but to AppleCommander. I see you typed AppleCOmmander, why? Was it branded like that for a reason?

Cheers,
Antoine

[toc] | [prev] | [next] | [standalone]

#4437

Hi Antoine,

>Thank you, Oliver, for the detailed explanations.

You're welcome :-)

>I have another question, not "linked" to cc/ca65, but to AppleCommander. I see you typed AppleCOmmander, why? Was it branded like that for a reason?

Nope, that was just a (C&Ped) typo - I'm not getting younger so my
eyes aren't getting better ;-)

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#4439

"Oliver Schmidt" <ol.sc@web.de> wrote:
>I'm not getting younger so my eyes aren't getting better ;-)

I can certainly agree with you on that... the glaucoma in my left eye has 
become so bad that it requires my right eye to see :)

As far as this discussion goes, I am grateful for your work on cc65 even if 
the assembler is not what some peoplekind want. I certainly had great fun 
writing in C with cc65! As a C cross-compiler goes, The performance of the 
code cc65 produces certainly exceeds my expectations especially when 
compared to classic MS-DOS based C cross-compilers for the Apple IIe like my 
old favourite Aztec C65.

One thing that I hope we can all agree on is that programs cobbled-together 
in unstructured AppleSoft BASUC suck when compared to the readability and 
performance of those written in the modern cc65 cross-compiled working 
environment, which is of course largely made possible by the ca65 assembler 
that comes with the cc65 toolchain which is not merely a replacement for 
some old native assembler.

As you also know I am also grateful for the inline assembly supported by 
cc65 as well. And then of course there is the support for overlays that you 
know I enjoy...

But anyway, both you and Michael Pohereski have contributed greatly to my 
enjoyment of the Apple II which of course includes the AppleWin emulator and 
I know that you are both passionate about your work so lively discussions 
like this are to be expected :)

Again thanks Oliver.

Thanks also to Michael for being focused as usual.

Bill 

[toc] | [prev] | [next] | [standalone]

#4417

Oliver if you would pull your head out of your ass for a minute and actually _look_ at the user experience you would see the out-of-the-box experience for ca65 is garbage compared to other assemblers.  Where is the native HEX directive support? Where are the native ASC ''  and ASC "" directives?  But since James isn't running into _those_ issues let's focus on the one issue he actually _is_ running into.

With Merlin32 I just type: merlin32 <file.s> and I get a raw binary file AND and a listing file. **DEAD SIMPLE.**

Now let's compare and contrast with ca65 shall we.

With `ca65 <file.s>` I get an .o file and I STILL have to fuck around with linker and configuration files to produce an executable.

Hell, even with gcc I can do: gcc <file.c> -o <file> and get an executable. I don't have to fart around with compiler/linker settings just to produce a bloody executable.  **You could actually _learn_ something the way gcc streamlines calling as/ld as a convenience for the user.**

Even calling `ca65 -v <file.s>` prints NOTHING extra.  In contradistinction `gcc -v <file.c>` prints off the FULL as/ld command line.

The fact that I even have to tell ld65 to use `-t none` is retarded. WHY doesn't it _default_ to none in the first place???

Since you will probably complain that I should be using cc65, fine.  If I run `cc65 -v <file.c>` I _still_ get no output for the command-lines used for ca65 & ld65.  *facepalm*

If **ca65 didn't suck** then one would be able to do: `cc65 <file.s> -o file` and have it automatically call the assembler and linker to produce a working binary.

The ONLY thing going for ca65 is that it has a pretty sweet macro system.

However, the fact that you are too fucking lazy to streamline the whole Apple 2 toolchain process, let alone support native pseudo-directives (listed above) that people have been using for the past, gee, 30+ YEARS, and provide an apple2/ directory with an src2dsk script, tells me you don't care in the least bit about about _understanding_ why ca65 is crap.

I don't give a fuck about your opinion -- I will *keep* ranting about how horribly broken ca65 out-of-the-box it is.

At least with Merlin32 I can actually assemble a source file out-of-the-box without needing to read any documentation. Go figure!

[toc] | [prev] | [next] | [standalone]

#4420

You keep trying to box ca65 into being an "Apple II assembler."

It isn't.

It's a 6502 assembler that includes some configurations that are suitable for a limited class of Apple II programs.

MG

[toc] | [prev] | [next] | [standalone]

#4440

"Michael Pohoreski" <michael.pohoreski@gmail.com> wrote:
>If **ca65 didn't suck** then one would be able to do: `cc65 <file.s> -o 
>file` and have it automatically call the assembler and linker to produce a 
>working binary.

I think you are a little overboard on that last remark. That's not the way a 
C cross-compiler for the Apple IIe works despite whether or not it's a user 
experience that suits all of peoplekind.

I can agree that it takes a special kind of moron to not be able to produce 
programs in cc65 for the Apple IIe. These rookie mistakes of not setting 
environments are no big reason to condemn cc65 to the scrap-heap.

>However, the fact that you are too fucking lazy to streamline the whole 
>Apple 2 toolchain process

<snip>

I'm lazier than both of you and I don't have a problem with cc65 for what it 
is.

>I don't give a fuck about your opinion

I extend the same courtesy to most of the Apple II community :) The IBM-PC 
(and clones) was a much better computer for what I needed in the '80's. But 
for old kid's toys, the 6502 machines are a hoot to play with... there isn't 
much challenge getting old MS-DOS programs to work... but it's still the 
wild west in here, cowboy!

Bill

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web