-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide linker-configured PAL_BUF for neslib/nesdoug #215
Comments
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 |
Yep, that makes sense too. |
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) |
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. |
- Use weak symbols so they can be customized by users (fixes llvm-mos#215) - Place them in `.ram` instead of `.noinit` (fixes llvm-mos#219)
- Use weak symbols to allow customization (fixes llvm-mos#215) - Place in `.ram` instead of `.noinit` (fixes llvm-mos#219)
Fixes llvm-mos#215: - Use weak symbols - Move PAL_BUF out of hardware stack Fixes llvm-mos#219: - Place in `.ram` instead of `.noinit`
Fixes llvm-mos#215: - Use weak symbols - Move PAL_BUF out of hardware stack Fixes llvm-mos#219: - Place in `.ram` instead of `.noinit`
Fixes llvm-mos#215: - Use weak symbols - Move PAL_BUF out of hardware stack Fixes llvm-mos#219: - Place in `.ram` instead of `.noinit`
Fixes llvm-mos#215: - Use weak symbols - Move PAL_BUF out of hardware stack Fixes llvm-mos#219: - Place in `.ram` instead of `.noinit`
Fixes llvm-mos#215: - Use weak symbols - Move PAL_BUF out of hardware stack - Split multi_vram* ops from the definition of the buffer
Fixes llvm-mos#215: - Use weak symbols - Move PAL_BUF out of hardware stack - Split multi_vram* ops from the definition of the buffer
* Improve allocation of VRAM/PAL/OAM buffers Fixes #215: - Use weak symbols - Move PAL_BUF out of hardware stack - Split multi_vram* ops from the definition of the buffer * Fix weakness of VRAM_BUF
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.
The text was updated successfully, but these errors were encountered: