Re: [cc65] __fastcall__

From: Bill Buckels <>
Date: 2015-01-15 01:18:14
As far as the uberlay routines go, having used overlays extensively and effectively, both on the c64 and Apple IIe in Aztec C65, and providing the same in several commercial products years ago, I obviously have full intention of exploring the cc65 notion of overlays.

As you know I am quite adaptive at working around cc65's limitations as opposed to Aztec C65's full-featured framework, becauyse obvuiusly cc65 is quite quick. 

I'll be fair and impartial about what I discover, which is more than I can say about this lot here... but at the end of the day, I won't be hitting a moving target, so don't change anything that is fundamental to what has been done, or I can guarantee a terrible review to say the least. I can't of course gurantee a good review until we see what you got fellah!

You work has been significant Oliver and is much appreciated. But this flavour of the month mentality needs to be curbed with some common sense if you want someone to actually use this tool. I mean someone.


  ----- Original Message ----- 
  From: Oliver Schmidt 
  To: Lists 
  Sent: Wednesday, January 14, 2015 3:37 PM
  Subject: Re: [cc65] __fastcall__


    The linker does actually seem to have a lot of the framework in place
    - I can declare ROM0, ROM and ROM2 to have the same addresses already
    and put different code in each, and I think (need to test it for real)
    that with the output file options I can also make it write them to
    different files.

  There's no need for investigation in that area as there's already a "multiple-output-files-for-same-addr" linker config at (and a demo using it at

    It does mean you can't easily bank data or even rodata (because you
    take pointers to it and pass it out elsewhere eg in pritnf()) but for
    pure code it's historically worked OK in the tools I've used.

  The comments in the demo above follow the very same reasoning.

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Thu Jan 15 01:18:21 2015

This archive was generated by hypermail 2.1.8 : 2015-01-15 01:18:23 CET