Re: [cc65] Disabling the Upper Bank for use with DLGR, DHGR, and SHR

From: Bill Buckels <>
Date: 2014-05-16 15:41:20
Oliver Schmidt wrote:
>But as you are talking about graphics modes requiring AUXMEM I presume you 
>refer to that.

Hi Oliver,

This English Language comprehension problem extends to the documentation as 
well as to communciating with you. I will work with this on my own then 
unless you have some additional insight into what changes need to be made to 
the linker config to accomodate the double res modes or can provide a linker 
cfg to free the upper memory bank for application use outside of cc65's 
runtime.  You can refer to some of my documentation if you want to know more 
about a communication style that is english. My recent case study on 
HackBytes is probably a good place to start.

>I don't know your loaders so I can't comment on that.

If you know the apple II then you know that the page switches are used to 
access auxialiary memory when in some modes of DLGR and DHGR as in my Aztec 
C65 examples that have been around for years. In other modes of DHGR in a 
SYS program and the SHR modes on the Apple IIgs MainToAux and AuxToMain are 
used as well as in storing artifacts in the upper bank AKA Auxiliary Memory.

>You haven't given any specifics of what you are trying to archive, what 
>behavior you expect from the cc65 toolchain and in what aspect it differs 
>from your expectation. So I can't comment on that either.

Understood. I simply thought that there might have been some additional work 
done by someone else besides you and I. I wanted to take a look. I will work 
at deciphering this documentation in conjunction with the cc65 source code. 
I have no expectation of anything at all besides the work that you have 
done. I am doing a gap analysis. I have no problem doing code. I have a 
problem when documentation is light and incomplete. But I have no problem 
adding to documentation on my own either.

If someone wants to participate in my process they are welcome. I suspect 
however that nobody besides you has the knowledge and you likely don't have 
the time, so don't trouble yourself further trying to understand. 
Marshalling my code into your compiler will likely create a fork simply 
because it is more expedient for me.

We can talk about the possibility of merging this later when the fork is 
finished. My process is to provide working examples and clear documentation 
for those examples, and library routines for those examples, and to fill any 
gaps with library functions. But rest assured that I will constatly consult 
POSIX references and refer to existing functioniality to avoid duplication 
where possible.


To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri May 16 15:41:43 2014

This archive was generated by hypermail 2.1.8 : 2014-05-16 15:41:45 CEST