[DRAFT] NES famitone5

[CharlesAverill]

I've started porting the NES target's famitone support from v2 to v5, which supports many more audio features.

To test the updates, I've started refactoring my project to use llvm-mos and its copies of neslib and famitone (I was previously using cc65 and a custom build pipeline). However, while the refactor will compile and run, I have not been able to get audio running. Perhaps this is just a build system issue, and the actual v2->v5 refactor is correct, but I thought I'd talk about it here before un-drafting the PR.

My porting work was a large amount of sed executions, so it's rough around the edges and might not meet the project's style guide. Not sure what the expectation is here though.

[mysterymath]

This comes with a massive increase in the code size, which means it's not a strict improvement over the smaller famitone2. But more broadly, we've talked about this back and forth, and including as many third party libraries as we did in the NES SDK was probably a mistake. We don't really have the ability to provide support for them, and they're outside what we've generally agreed to be the scope of the SDK. (Namely, linker and C/C++ runtime support, interfaces to expose as simply as possible functionality already present in the hardware of the underlying target, and interfaces to hook that functionality up to the C standard APIs whenever it's straightforward to do so.)

At some time, we may deprecate and move the existing neslib, nesdoug, and famitone2 stuff to separate repos. Accordingly, I don't think this is something that we should add to the SDK, but I do think it's an excellent thing to have hosted elsewhere on Github!

[CharlesAverill]

That all makes sense. Adding v5 to the SDK was actually my backup plan; when I first started refactoring my build system I didn't want to link against the SDK's copies of neslib and famitone (because of the lack of v5 support). But compiling my own copies of the two libraries with llvm-mos turned out to be infeasible without essentially duplicating my initial cc65 setup. I'm disappointed, as I'd really like to utilize clang's superior optimization, but maybe substituting in clang for specific object files is the solution there, rather than depending on it for the entire binary.

[mysterymath]

That all makes sense. Adding v5 to the SDK was actually my backup plan; when I first started refactoring my build system I didn't want to link against the SDK's copies of neslib and famitone (because of the lack of v5 support). But compiling my own copies of the two libraries with llvm-mos turned out to be infeasible without essentially duplicating my initial cc65 setup. I'm disappointed, as I'd really like to utilize clang's superior optimization, but maybe substituting in clang for specific object files is the solution there, rather than depending on it for the entire binary.

You can also link in object files assembled with cc65 into llvm-mos links; for example, I have a little demo repo doing this with pently, off the shelf: https://github.com/mysterymath/llvm-pently

[CharlesAverill]

I do that in a very hacky way with my asset files: https://github.com/CharlesAverill/RedShift/blob/llvm-mos-port/Makefile#L44