Support a music bank about hugedriver HOT 7 CLOSED

What's the benefit of having a fixed set of addresses to call? I'm not sure what you mean by the two bullet points.

from hugedriver.

You can update and build the player separately, these addresses just have jumps to the real functions.

The point of the second bullet point is this:
The hUGEDriver bank could be built with rgbds and later concatenated to the rom.
sdasgb, asgb and other assemblers only need to know the bank number and the addresses within the bank to interface with the driver.
If the tracks are also placed at a predefined position, that would even allow to supply a prebuilt player and just patch in the music. Or to update the player without touching the music and the rest of the rom.

from hugedriver.

But why would you want to do that? You can convert hUGEDriver to sdas's native format with rgb2sdas and then not have to deal with concatenation or anything.

from hugedriver.

It does not work with SDCC 4.2.0

?ASlink-Warning-Conflicting sdcc options:
   "-mgbz80" in module "hUGEDriver_obj" and
   "-msm83" in module "sdcc_player_example".
?ASlink-Warning-Conflicting sdcc options:
   "-mgbz80" in module "hUGEDriver_obj" and
   "-msm83" in module "sample_song".

from hugedriver.

Yeah, it looks like SDCC has renamed gbz80 to sm83. I ran into this exact issue actually while compiling the GBDK toolchain the other day. The current release of GBDK doesn't support SDCC 4.2.0, so I'll update the tool once it switches over.

from hugedriver.

I’m writing wrappers for the new calling convention and an example for pure SDCC (no interaction, display, interrupts, just music).
It looks like you can just drop the O line. But I’m not 100% sure if this could affect banking behavior or if it just depends on the name of sdld(gb).

from hugedriver.

I think with the updated rgb2sdas this shouldn't be an issue now. Please let me know and reopen if that's not the case.

from hugedriver.