Freshly compiled Nitro Engine example gets recognized as retail game

[JustMeDaFaq]

Console Configuration: N3DS XL + latest Luma + Twillight Menu TWiLight Menu++ Version: v23.4.0 TWiLight Menu++ Theme: Nintendo DSI

Expected behaviour

Expected Twillight Menu to load the attached .nds homebrew file via nds-bootsrap-hb as usual

Actual behaviour

nds-bootsrap says an error has occured, it seems to me that Twillight menu doesnt launch it via nds-bootsrap-hb but the non -hb one (since it tries to get SDK-VER and NTR-### values and allows to press x for cheats)

Steps to reproduce

1. Download and extract the attached .nds homebrew file (which is an sample of Nitroengine 0.7) free_camera.zip
2. Add it to your roms folder as usual
3. Start Twillight Menu up and try to launch that said homebrew file

[lifehackerhansol]

The issue appears to be that Nitro Engine's templates has a makefile that compresses the ARM9 into a bin before loading it via ndstool.

When removing the $(TARGET).arm9 flags and using the elf directly to ndstool, this doesn't happen and correctly determines that it is homebrew. It seems to me that TWiLight does a different check for homebrew, instead of checking if the game code is #### / game title is HOMEBREW or 0xEA00002E, it does a deeper check on the arm9 binary itself, which in the case of Nitro Engine is compiled in a way unexpected in the modern build environment.

To make sure this wasn't specific to Nitro Engine, I grabbed some random source code which is compiled as according to a modern build environment and added the $(TARGET).arm9 flag to it: https://github.com/Garhoogin/Gravity, and this also fails the check.

While this is a bug on TWiLight's end it does bring the question to whether Nitro Engine actually needs to compress the arm9 to a binary before ndstool. Seems one will have to contact @AntonioND if this is intended or not.

[AntonioND]

Well, all I did was to copy a template from an old version of devkitPro for NDS, including the Makefile. I remember updating the makefiles when I pushed Nitro Engine to GitHub (that's when I released version 0.7), so that's when I got the current Makefile. Are they different than in devkitPro now?

I'd suggest you test with any random sample from libnds and see if the same issue appears.

[lifehackerhansol]

Well, all I did was to copy a template from an old version of devkitPro for NDS, including the Makefile. I remember updating the makefiles when I pushed Nitro Engine to GitHub (that's when I released version 0.7), so that's when I got the current Makefile. Are they different than in devkitPro now?

The "compress to binary" was removed from the source way back in 2010: https://github.com/devkitPro/nds-examples/commit/981a3f080327f3ee8182f34a77501c4946f71931

You can find the current templates here: https://github.com/devkitPro/nds-examples/blob/master/templates

FWIW I did test compilation of the free_camera example with the latest arm9 makefile and it seems to be working on DSi.

[lifehackerhansol]

I went ahead and decided to compile the standard libnds example here: https://github.com/devkitPro/nds-examples/tree/master/Graphics/gl2d/2Dplus3D

I made this change to the makefile, which then compiles exactly as nitro-engine does:

- $(OUTPUT).nds :   $(OUTPUT).elf
+ $(OUTPUT).nds :   $(OUTPUT).arm9
+ $(OUTPUT).arm9  : $(OUTPUT).elf

This produces the exact same result.

This is an issue with TWiLight, but it's also worth mentioning that this also goes against how devkitARM is designed to compile modern NDS homebrew. So it's kind of an issue that stems from all sorts of places.

Should probably update your examples, though :D

[AntonioND]

Ok, I'll update my Makefiles this evening. I guess I didn't update them after all.

[AntonioND]

Updated! Let me know if the problem is gone now.

[lifehackerhansol]

Updated! Let me know if the problem is gone now.

Works! Thanks.

I'll leave this issue up for now in case @RocketRobz wants to look into seeing if incorrectly compiled homebrew is something to fix.

[NightScript370]

Is it possible to detect compressed ROMs? Since I highly doubt retail ROMs would be in the same format as homebrew compressed, maybe we could check and see if it is compressed. If so, then assume 99% of the time its an old homebrew and run it under nds-bootstrap