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

Sound channel 3 is referred to as Triangle channel, but it isn't #7

Open
hippydave opened this issue May 23, 2021 · 2 comments
Open

Comments

@hippydave
Copy link

hippydave commented May 23, 2021

Triangle Channel Control Register

Sound channel 3 is a programmable wave table, but is referred to in the header as a triangle channel.
Pinobatch says:
"It's because when I wrote the header that that header was based on, I had recent experience with the Nintendo Entertainment System and I started by using the wavetable channel to replicate the capability of the NES triangle channel until I realized that the GBA internal speaker's 800 Hz high pass characteristic wouldn't let the typical applications of the NES triangle wave through"

I don't know if this is being kept as a fun historical quirk, or if nobody's actually thought about it.

@WinterMute
Copy link
Member

Quite a few things in the libgba headers are entirely legacy defines because of the fragmented nature of gba homebrew at the time. Many GBA projects were built with hand rolled tools and headers which varied a great deal and encouraging people towards homogenising an enviromment to foster greater collaboration involved pulling in a whole bunch of things that make no particular sense almost 2 decades later.

Further up the file you'll find defines based on later documentation (https://github.com/devkitPro/libgba/blob/master/include/gba_sound.h#L116-L118) The bogus triangle stuff can probably just be removed. It remains only because nobody has given the matter any thought.

@hippydave
Copy link
Author

Thanks for the reply, so it was to provide compatibility, that makes sense.
I know the REG names at the top are the more standard ones, but the defines lower down provide useful named values that can be or'd and passed to the registers, which makes code more readable than just using numbers. If any updates are planned it could be nice to adapt and modernise some of those.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants