search

llvm-mos / llvm-mos-sdk

SDK for developing with the llvm-mos compiler
https://www.llvm-mos.org
Other
266 stars 53 forks source link

Provide linker-configured PAL_BUF for neslib/nesdoug #215

Closed mysterymath closed 11 months ago

mysterymath commented 11 months ago

Currently, the palette buffer used by neslib/nesdoug is hard-coded to the low portion of the hardware stack. This should be made a weak symbol instead to allow for the user to place it elsewhere. Stack is particularly valuable on the NES, since it enables techniques like pop-slide.

cogwheel commented 11 months ago

Would the same hold for VRAM_BUF and OAM_BUF? E.g. to be able to keep them all in RAM instead of PRG-RAM

mysterymath commented 11 months ago

Yep, that makes sense too.

cogwheel commented 11 months ago

Would it make sense to change the default (weak) PPU_BUF to be a normal array that doesn't share address space with anything else? This way overriding it to overlap the stack would be an opt-inmization. (#217 helps since you only pay for the space if you use the feature)

mysterymath commented 11 months ago

Hmm, I think yes to this one too. As always, it's this way because that's what I copied over during the nesdoug tutorial port, but using the hard stack for something should really be opt-in, even if there's e.g. a C macro to configure this. That's also a roughly backwards-compatible change; you shouldn't depend on the precise placement of library internal symbols.