Re: [cc65] Customization of cc65 for new targets

Hi Bruce,

> Second, I probably misread what Oliver said in this thread (and apologies to
> Oliver if I did), but I got the impression that he recommended the RAM space
> start at $0 instead of $200.

Sorry for the confusion I've caused :-( I indeed did _not_ want to
propose to have RAM started at $0.

> I was under the
> impression that the .cfg file is used to describe the underlying hardware
> memory map, so bumping the ZEROPAGE segment to $100 in length does no harm,
> since that what it truly is.

> So again, I see the .cfg file as a description of the actual hardware memory
> map, which means that the program RAM space really does start at $200 since
> the first two pages are reserved for the 6502.

Looking at your two statements above I think I can now see our
misunderstanding: From my point of view the .cfg file does _not_
describe the underlying hardware memory map - although some aspects of
it might lead to this interpretation. Rather I see the .cfg file
describing the environment the cc65 program is intended to run in. I
see this perspective supported by the fact that there are several
examples in the cc65 distribution of a number of different .cfg files
for the same machine.

In your scenario the environment for the cc65 program is only
determined by the (virtual) hardware. Therefore you only have to take
care about the zeropage and stackpage and therefore moved the RAM
start from $0 to $200 - which is of course correct. Thus you can call
it the "underlying hardware memory map".

But in some/many/<you name it> other cc65 scenarios there are
additional entities determining the environment for the cc65 program -
both hardware (i.e. memory mapped i/o ports and video ram areas) and
software (i.e. the operating system). So in general it's the "map of
memory available to the cc65 program" what the .cfg files describes.

And in some some/many/<you name it> environments there are (typically
software, but sometimes hardware i.e. $00/$01 on the CBM 5/610 -
correct?) entities using parts of the zeropage in a way that even
saving and restoring those parts wouldn't help (i.e. because you want
to actually call into the operating system for certain services).
Therefore i.e. on the Apple2 the zeropage area doesn't start at $00
but at $80.

As a result the ZP memory area in a .cfg is by no means always $0 -
$100 just because you have 256 bytes of RAM there in the machine -
this is what I wanted to point out.

Best, Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.