GBA support

[GValiente]

Would it be too difficult to allow the Game Boy Advance to play hUGETracker music?

GBT Player already allows it, so it should be possible at least.

[SuperDisk]

It would require a reimplementation of the driver in C, which means maintaining two separate drivers and ensuring that they are consistent with one another. Personally I don't have the resources to do this, sadly.

Additionally, most people expect GBA-quality sound in GBA games, so it seems like hUGE alone isn't a very good fit.

[GValiente]

I don't care about what most people expect.

Still, hUGETracker could be used for PSG channels while other solutions like Maxmod could be used for Direct Sound channels (what I guess most people expect from the GBA).

GBT Player already supports that use case: https://github.com/AntonioND/gbt-player/tree/master/gba/examples/combined_maxmod

People tend to use the CPU of the GBA for taxing tasks like 3D software rendering, so having a solution for playing music that doesn't steal too much CPU cycles is worthwhile IMO.

However, I agree that maintaining two separate drivers could be a lot of work, even if the GBA one could be coded in C without a big impact in CPU usage (again, what GBT Player does).

A nice example of both PSG and Direct Sound channels used at the same time (Mother 3, thanks to copetti.org for the video): https://www.copetti.org/videos/consoles/gba/crackers/8bit.2eef0679323ed59d5809ddcd17c891d2605f7f127a4a26b334ddc4fd60d407ac.mp4.

[SuperDisk]

True, it's an interesting use case, but I just don't have the time or interest in porting the driver to C right now. I'll leave the issue open in case somebody else wants to try, maybe.

The only thing I can think that might allow for only one codebase is maybe statically compiling the assembly mnemonics to C since there's no self modifying code, and "simulating" the registers with variables called a, b, c, etc. Supposedly this is how some classic games have been ported (chrono trigger to PS1 I think?)

[GValiente]

Thanks for leaving the issue open.

[SuperDisk]

@asiekierka

[SuperDisk]

Sorry. Fat-fingered the iOS keyboard. Meant to tag Asie since he contacted me a while back about this-- not sure if you're interested in taking on the porting process but maybe you could weigh in a little.

[asiekierka]

Sorry, didn't catch the ping in notifications for whatever reason.

In general, the porting process is simple: you need to rewrite the driver code in either ARM assembly or C, and you'll find that most of the hardware registers map nearly 1:1, so it's a matter of reproducing the logic.

Not sure when/if I'll have time to get around to this, however :(

[SuperDisk]

@GValiente I appreciate the interest, but I unfortunately don't have the ability to maintain 2 separate implementations and keep them at parity. Anybody else is welcome to try their hand at a port though.