ghost banks

[yenatch]

portions of bss can be repurposed between program states. this generally involves overlapping sets of labels. this occurs in commercial software

wram banks can act as ghost banks for address space 0xd000-0xdfff, but 0xc000-0xcfff is mapped to one bank only. an example workaround is to define constants in place of would-be ghost labels. however, the start point must be set manually, since constants must be evaluated before linking

there is potential for a lot of unneeded complexity, so this would be a good place to hash out how it could work

section wram0
wSomething:
    ds 100
wGhostArea:
    ds 5
wGhostAreaSubset:
    ds 5

section wram0 [wGhostArea], ghost
wGhostedArea:
    ds 10

section wram0 [wGhostArea], ghost [1] ; multiple ghost banks
wAnotherGhostedArea:
    ds 20

section wram0 [wAnotherGhostedArea] ; a ghost of a ghost
    ds 30

• there should be some way to keep track of multiple ghost banks. ghost [x] is probably not ideal
• being able to start a section at a relocatable address is a given, but the expected behavior would be to group ghost sections based on their starting point, which runs counter to current behavior (where sections are each forced to a starting point if one is given)

what if starting from a relocatable was interpreted as a ghost section in the first place? is that too implicit? how would the linker know which ghost bank to put it in?

section wram0 [wGhostArea]

other section features to consider in the context of ghosting:

• optional directives (i.e. start from the end of a bank, especially in rom sections)
• nameless sections
• custom bank definitions (maybe rom can be mapped to $8000-$bfff, like on the game gear)
• dmg (where ghosting is actually useful, because bss is bankless)

[yenatch]

wGhostedArea:
    ...
    ds wGhostedArea - @

wAnotherGhostedArea:
    ...
    ds wAnotherGhostedArea - @

wContinue:
    ...

; wGhostedArea == wAnotherGhostedArea == wContinue