[feature request] allow for multiple ORG directives

[mvdhoning]

Like other modern c64 ide (e.g. c64 studio) it would be nice if a future version of p65pas allowed for multiple origins for code and data.

When dealing with small amounts of data (like sprites) the current way is nice but as soon as you want to use larger data sets like charsets or even image things become not nice to work with having to move large amounts of data instead of having them already at the right spot (also think of sid music). And yes that would make very large prg files with a lot of emty space inside of them (c64 studio just fills that with 00's).

And yes one could make horror large prg files with that with part of the code at $0801 and another part at $c000 ;-) But it would be very usesfull for making a c64 application at once with a custom charset or/and a koala image.

To maybe limit implementation difficulties only allow one ORG directive per file.

[Squall-FF8]

Although the idea might seems good at first glance, it is a very, very bad practice for reasons well explained in the question,.

A good practice will be including a custom loader that can load different fragments in memory from external files. Such loaders usually simply call few kernel functions and have very little footprint. It is also possible to copy these chunks from within the main program but that is harder to implement, require good organization of the data and might not be even possible if data is too large and overlaps.

[t-edson]

In fact you can write code at several RAM location in P65Pas without using multiple ORG directives.

Firstly, is good to remember we have the {$SET_DATA_ADDR ... } directive to set the location where variables will be allocated, commonly used to set the zero page space. Of course this is for Data not for Code.

However, although we know {$ORG .. } directive defines the start location in RAM where the code will be compiled and we can only use one $ORG directive, there is the directive ORG in assembler blocks.

Using ORG in assembler blocks we can change the current location where the code is compiled (should be bigger than the location defined with $ORG directive ) and there is not limit in using several ORG in ASM blocks.

In the picture I show a code that have one part in $0800 address and other part in $1000 address, using ORG in assembler blocks. The remains RAM locations are filled with 00's values.

It's clear that playing with ORG in assembler blocks is something delicate and not recommended.