Skip to content
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

Closed
mysterymath opened this issue Sep 21, 2023 · 4 comments · Fixed by #222
Closed

Provide linker-configured PAL_BUF for neslib/nesdoug #215

mysterymath opened this issue Sep 21, 2023 · 4 comments · Fixed by #222
Labels
enhancement New feature or request good first issue Good for newcomers p1

Comments

@mysterymath
Copy link
Member

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.

@mysterymath mysterymath added enhancement New feature or request good first issue Good for newcomers p1 labels Sep 21, 2023
@cogwheel
Copy link
Contributor

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
Copy link
Member Author

Yep, that makes sense too.

@cogwheel
Copy link
Contributor

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
Copy link
Member Author

mysterymath commented Sep 22, 2023

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.

cogwheel added a commit to cogwheel/llvm-mos-sdk that referenced this issue Sep 25, 2023
- 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)
cogwheel added a commit to cogwheel/llvm-mos-sdk that referenced this issue Sep 25, 2023
- Use weak symbols to allow customization (fixes llvm-mos#215)
- Place in `.ram` instead of `.noinit` (fixes llvm-mos#219)
cogwheel added a commit to cogwheel/llvm-mos-sdk that referenced this issue Sep 25, 2023
Fixes llvm-mos#215:
  - Use weak symbols
  - Move PAL_BUF out of hardware stack
Fixes llvm-mos#219:
  - Place in `.ram` instead of `.noinit`
cogwheel added a commit to cogwheel/llvm-mos-sdk that referenced this issue Sep 25, 2023
Fixes llvm-mos#215:
  - Use weak symbols
  - Move PAL_BUF out of hardware stack

Fixes llvm-mos#219:
  - Place in `.ram` instead of `.noinit`
cogwheel added a commit to cogwheel/llvm-mos-sdk that referenced this issue Sep 26, 2023
Fixes llvm-mos#215:
  - Use weak symbols
  - Move PAL_BUF out of hardware stack

Fixes llvm-mos#219:
  - Place in `.ram` instead of `.noinit`
cogwheel added a commit to cogwheel/llvm-mos-sdk that referenced this issue Sep 27, 2023
Fixes llvm-mos#215:
  - Use weak symbols
  - Move PAL_BUF out of hardware stack

Fixes llvm-mos#219:
  - Place in `.ram` instead of `.noinit`
cogwheel added a commit to cogwheel/llvm-mos-sdk that referenced this issue Sep 27, 2023
Fixes llvm-mos#215:
  - Use weak symbols
  - Move PAL_BUF out of hardware stack
  - Split multi_vram* ops from the definition of the buffer
cogwheel added a commit to cogwheel/llvm-mos-sdk that referenced this issue Sep 28, 2023
Fixes llvm-mos#215:
  - Use weak symbols
  - Move PAL_BUF out of hardware stack
  - Split multi_vram* ops from the definition of the buffer
mysterymath pushed a commit that referenced this issue Sep 30, 2023
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers p1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants