I think we should ask
@ichichfly first. The current source code compiles in older devkitarm, but generates several .LUB files (which are really standalone, recompiled versions of the gbaemu4ds source code). Then you use hbmenu as launcher to boot these .LUB files. The hbmenu launcher chooses a file, which then is passed as a fullpath to each standalone version, so game boots.
The problem:
- the source code has several parts unused, some VBA ARM/THUMB cpu core is recompiled as arm assembly, really un maintainable and not required. Since the ARM/THUMB code is recompiled from sources (C/C++)
- the shared stacks: depending on the part gbaemu4ds runs from (say, a irq interrupt or data abort) the stack is shuffled. It is not linear: say, the usual way for an ARM program would be two interrupts to happen at the same time, the context is saved to stack then restored in full descending nature by default. In gbaemu4ds case, depending on code section, the stacks are mixed (interleaved)
- the gbaemu4ds code recompiles the SAME VBA ARM/THUMB cpu core at least twice. One for normal VBA CPU Core and another for half software emulation + MPU aborts (which just redirect to NDS map that is the same as GBA map), which is faster. Best case scenario (which I tried at some point years ago), was to have the first cpu core (full software), but either some games would stop working or the interrupts would have to be handled through software, because MPU layer would just redirect to actual NDS interrupts (for instance reading and writing IE/IF would be available from GBA mode only if that map was MPU protected)
- overall code was a bit messy, but nothing too terrible when you know already how everything goes together.
To be fair, I would rather update the code so it runs on devkitpro, THEN I would move it to ToolchainGenericDS. For now I just have the barebone stuff for building in TGDS. So homebrew would be equally maintained I guess.