Re: [cc65] Hello, and a memory corruption (?) issue when optimizing

From: Maik Merten <maikmerten1googlemail.com>
Date: 2013-06-11 18:54:43
Am 11.06.2013 07:23, schrieb Greg King:
> When the optimizer gets to "base = 16384", it removes a "LDX #$40" from the
> output assembly code.  Therefore, the statement becomes "base = 0".  But,
> the optimizer remembers what "base" is supposed to hold!!  It converts the
> expression "(base + 8192)" into "(16384 + 8192)".  So, the first memcpy()
> puts the bitmap where it should go.  The optimizer doesn't remember "base"
> in the next memcpy() -- the variable is read; so, that function call puts
> the text-RAM palette into the normal screen area, instead of where the
> VIC-II will look for it.  The video chip sees garbage for that color
> palette.

Thank you very much for this detailed analysis! Sorry to hear this is an 
actual bug in the optimizer, but then again I hope that hitting such 
corner cases is interesting and useful.


> After that fix, the palette will be copied on top of another part of the
> program.  So, you need to add an option to the cl65 command line.
> "-m nuclear.map" will give you a text file that will show you where the
> program sits in RAM.  Look for the section of that file that is entitled
> "Segment list".  Then, you must change the destination of the memcpy().
> (A good place for the text-RAM palette is just below the bitmap.)

The memory map was most useful, as it became immediately clear that some 
segments were allocated in bank 1 of the VIC. I now copy the bitmap data 
to bank 3, which is far away from the allocated segments ;-)

To work around the optimizer bug I now #define the memory offsets for 
the various bank settings.

The complete commit: 
https://github.com/maikmerten/c64-nuclearreaction/commit/33c5d0209c90f011b02c27c35ac8eeb38c91e31c


Thank you very much!


Maik
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Tue Jun 11 18:55:00 2013

This archive was generated by hypermail 2.1.8 : 2013-06-15 17:37:38 CEST