CA65 and ZP

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
CA65 and ZP
by on (#65304)
I'm porting code to CA65 and have hit a snag.

If I do this;

Code:
.segment "ZP"
vector:
  .res 2



then try to do this;

Code:
  lda (vector),y


I get a "range error" error.

However, doing this;

Code:
  lda <(vector),y

seems to compile OK. I'm guessing that using the "<" forces it into the correct addressing mode.

My question is, is there a way of defining this behaviour so that I don't have to prepend all my (ZP) addressing with "<"?


Oh, in my .CFG file I have (edited);

Code:
MEMORY
{
   ZP:     start =   $10, size =  $F0;
}


SEGMENTS
{
   ZEROPAGE:   load = ZP,      type = zp;
}

by on (#65305)
Damn, damn, damn!

As soon as I'd pressed "Submit" I noticed that I'd used "ZP" instead of the proper segment name of "ZEROPAGE" in the code.

Seems OK now.

:)

by on (#65306)
Actually, while I'm here, the .lobytes and .hibytes directives don't seem to work on my version of CA65 (2.12). Should they?

by on (#65307)
ca65 does seem to have .lobyte and .hibyte. The plural suggests they return more than one byte. :)

by on (#65308)
blargg wrote:
ca65 does seem to have .lobyte and .hibyte. The plural suggests they return more than one byte. :)


I can see you've got;

SARCASM = 1

set :)

I'm using it like;

tableOfLowBytes: .lobytes address1, address2, address3

but the error says;

".LOBYTES is not a CA65 recognized control command"

(or something like that)

by on (#65309)
.lobytes works for me. I'm using the latest snapshot version.

D:\Users\thefox>ca65 --version
ca65 V2.13.9 - (C) Copyright 1998-2005 Ullrich von Bassewitz

by on (#65310)
How odd....

by on (#65311)
Yes, .lobytes appears to be a new addition. I read through the ca65 manual all the way once, and then I read through it later after 2.13 came out, and a few new features were present.

by on (#65312)
Ah. Blargg sent me an OSX build of 2.13 a while ago and I thought I'd installed it, but obviously not :)

I have now though and .lobytes works.

Anyone know how to build the current version? For some reason, apt-get (fink) complains bitterly if I try to upgrade cc65 the "proper" way. Posting the error in case anyone knows what the issue could be.

Edited to add: cc65 is at version 2.10 too on my system and when I try to upgrade cA65 via apt-get, it says it's dependent on cC65 2.13, hence me trying to upgrade that first.

Code:
Setting up fink (0.27.16-41) ...
Checking system... i386-apple-darwin10.4.0
Use of uninitialized value $darwin_osx in numeric eq (==) at /sw/lib/perl5/Fink/Services.pm line 1404.
Use of uninitialized value $darwin_osx in concatenation (.) or string at /sw/lib/perl5/Fink/Services.pm line 1404.
Argument "10.6 does not match the expected value of . Please run `..." isn't numeric in exit at /sw/lib/perl5/Fink/Services.pm line 1404.
/sw/bin/dpkg: error processing fink (--configure):
 subprocess post-installation script returned error exit status 10
Errors were encountered while processing:
 fink
E: Sub-process /sw/bin/dpkg returned an error code (1)

by on (#65318)
cc65 is to GCC as the rest of the package is to GNU Binutils. So ideally, you should be able to install ca65 without cc65 in the same way that one can install GNU Binutils without GCC. If you can't uninstall the C compiler without uninstalling the rest, tell the Fink maintainer that the package is broken.

by on (#65320)
Oh wow, that's exactly the thing I wanted a few days ago, and was thinking of writing as a macro... glad I didn't try!

As for compiling the latest version, I much prefer to just do it manually for ca65 and ld65, and avoid all the other tools. This makes and copies them into your usr/bin/:

Code:
cd src/common
make -f make/gcc.mak all

cd ../ca65
make -f make/gcc.mak all
cp ca65 ~/usr/bin

cd ../ld65
make -f make/gcc.mak all
cp ld65 ~/usr/bin

by on (#65328)
Perfect. Command-line manual building I can cope with and prefer. I downloaded the source .tar but couldn't see a simple way to just build ca65 but I probably just didn't look hard enough.

Blargg - do all recent-ish releases of ca65 now have the immediate mode warning patch that you did?

by on (#65374)
No, my "warn on missing #" patch has been submitted to the maintainer, but it doesn't look like it'll be included, given that it's sort of an incomplete implementation. Here's the patch for ca65-2.13.2, in case anyone else is interested: ca65-2.13.2-addr-type.tgz