Re: [cc65] ld65 Config Question

Date view Thread view Subject view

From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-02-19 11:41:08


> It looks like it's either a simple modification to config.c or very
> difficult to do.  It may well be simple but I just can't see so at
> this time of the day...  :)

With just LOAD= given, the RUN memory area will be made identical to LOAD.
Allowing RUN and LOAD to point both to the same area should not be too
difficult, but I will have to check that twice, because this setup is the
default today but means something else.

I will have a look at it and send you a patch as usual:-)

> Maybe the easiest way to do it is to trick the linker into secretly
> creating an extra segment, say "DATASAVED", that just happens to be
> the same size as DATA?

The only solution that will work without changing the linker is to create a
separate memory area that just holds the original copy of the data segment.
Unfortunately, you have to make the size of this area fixed.

> [Yes, I do have valid reasons for wanting separate load and run
>  segments on the same ram chip :) ...if the ram chip is loaded through a
>  serial port which is then disconnected, with no permanantly writeable
>  memory areas available, then one would want two copies of the DATA.]

This is weird. Some people complain about the complexity of the linker
configuration and others find new problems every week that cannot be solved
because the linker config is too simple:-)

Regards


	Uz



P.S.:
I found yesterday that the .ELSEIF directive in the assembler is broken. It is
not completely broken, so it works in the most common situations, but not in
others. If anyone has problems, please use .ELSE/.IF instead.

--
Ullrich von Bassewitz                                  uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.


Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:35 CET