Problems building with ca65/ld65 ...

[James Keim]

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

[Michael Pohoreski]

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

[James Keim]

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

[James Keim]

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.

[MG]

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

[James Keim]

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

[Michael Pohoreski]

> 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

[Oliver Schmidt]

On Thu, 22 Mar 2018 10:38:07 -0700 (PDT), Michael Pohoreski
<michael....@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

[Antoine Vignau]

Relax, Oliver!

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

[Steve Nickolas]

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.

[Michael Pohoreski]

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!

[Michael Pohoreski]

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

I converted the source over to Merlin32 this morning. My repro has a Makefile which:

* builds the ca65 version
* buildl the merlin32 version
* does a byte-for-byte comparison to make sure they are identical

https://github.com/Michaelangel007/apple2_dclock

I also cleanup the hard-coded magic PRODOS commands in the merlin32 version.

Fire up your favorite visual diff tool and compare/contrast dclock.system.ca65.s and dclock.system.merlin32.s -- this will help you learn about the pitfalls when writing assembler source when some yahoo like me uses a DIFFERENT assembler. :-)

Cheers

[MG]

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

[Michael Pohoreski]

MG, here is a diff where I cleaned up your hard-coded ProDOS magic numbers in the original ca65 version:

$ diff dclock.system.ca65.s dclock.cleanup.s
85a86,93
> ; PRODOS Command
> PRODOS_QUIT := $65
> PRODOS_READ_BLOCK := $80
> PRODOS_OPEN := $C8
> PRODOS_READ := $CA
> PRODOS_CLOSE := $CC
> PRODOS_GET_EOF := $D1
>
328c336
< .byte $80 ; READ_BLOCK
---
> .byte PRODOS_READ_BLOCK ; READ_BLOCK
523c531
< .byte $C8 ; OPEN
---
> .byte PRODOS_OPEN ; OPEN
531c539
< .byte $D1 ; GET_EOF
---
> .byte PRODOS_GET_EOF ; GET_EOF
541c549
< .byte $CA ; READ
---
> .byte PRODOS_READ ; READ
545c553
< .byte $CC ; CLOSE
---
> .byte PRODOS_CLOSE ; CLOSE
611c619
< .byte $65
---
> .byte PRODOS_QUIT

[Antoine Vignau]

On the other hand, you can use Merlin32 for your NES or SNES projects ;-)
av

[Oliver Schmidt]

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

[Oliver Schmidt]

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

[Steve Nickolas]

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.

[Antoine Vignau]

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

[Oliver Schmidt]

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

[Oliver Schmidt]

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

[Bill Buckels]

"Oliver Schmidt" <ol...@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

[Bill Buckels]

"Michael Pohoreski" <michael....@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