Homebrew app Overlay programming NDS Homebrew

Cervi

Well-Known Member
OP
Newcomer
Joined
Aug 25, 2022
Messages
46
Trophies
0
Location
Catalonia
XP
383
Country
Spain
I'm aware lots of NDS games use overlays stored in NitroFS to reduce the memory it uses at a time. But how would you go about implementing overlay programming in a homebrew game?

Searching online, I found that it maybe could be achieved by using linker scripts. But how would you go about implementing that using devkitpro's toolchains? And where could I maybe find tutorials for this sort of things?
 

Foxi4

Endless Trash
Global Moderator
Joined
Sep 13, 2009
Messages
30,818
Trophies
3
Location
Gaming Grotto
XP
29,789
Country
Poland
NitroFS is a homebrew filesystem, it’s already implemented in DevkitPro. It effectively creates a “partition” appended to your binary where you can store data, as if it was an ordinary drive. Unlike FAT, NitroFS is read-only and used exclusively to store game assets which you can then load into a buffer in memory. libnds has an example of usage that comes with the default package:

https://github.com/devkitPro/nds-examples/tree/master/filesystem

What is it that you’re trying to achieve, exactly?

Many moons ago I wrote a tutorial for NDS programming beginners which leveraged NightFoxLib for the purposes of displaying sprites and backgrounds. The library uses NitroFS extensively, so if you want a shortcut, you can follow the link below:

https://gbatemp.net/threads/ds-programming-for-newbies.322106/

Otherwise all you need to do is throw files into the NitroFS folder and then read them as if they were files on a FAT drive, using standard I/O.

http://blea.ch/wiki/index.php/Nitrofs

Caution - here be dragons! A lot of this stuff is *very* old and may behave unexpectedly, so the libnds example is probably your most up-to-date resource.
 

Cervi

Well-Known Member
OP
Newcomer
Joined
Aug 25, 2022
Messages
46
Trophies
0
Location
Catalonia
XP
383
Country
Spain
NitroFS is a homebrew filesystem, it’s already implemented in DevkitPro. It effectively creates a “partition” inside your binary where you can store data, as if it was an ordinary drive. Unlike FAT, NitroFS is read-only and used exclusively to store game assets which you can then load into a buffer in memory. libnds has an example of usage that comes with the default package:

https://github.com/devkitPro/nds-examples/tree/master/filesystem

What is it that you’re trying to achieve, exactly?
What I meant is that original games had this thing called Overlay tables (GBATEK, at the end) which just meant memory could be reused for different pieces of code. It's the principle described here: GeeksForGeeks article.
I just wanted to know if there was any way to do this with devkitpro toolchains. This would be really useful to reduce the size of the game's binary. For example, the main menu code does not need to be kept in RAM while in game.
 

Foxi4

Endless Trash
Global Moderator
Joined
Sep 13, 2009
Messages
30,818
Trophies
3
Location
Gaming Grotto
XP
29,789
Country
Poland
What I meant is that original games had this thing called Overlay tables (GBATEK, at the end) which just meant memory could be reused for different pieces of code. It's the principle described here: GeeksForGeeks article.
I just wanted to know if there was any way to do this with devkitpro toolchains. This would be really useful to reduce the size of the game's binary. For example, the main menu code does not need to be kept in RAM while in game.
This is unnecessarily low-level in my opinion, but I’m sure you could achieve this if you sliced your code accordingly. Realistically, the NDS has ample RAM to store all of your code, it’s the assets that are “chunky” and require streaming or shuffling around. If you had access to Nintendo’s tools you could use NitroROM and NitroARC as described on GBATEK, DevkitPro has its own implementation of Nitro that doesn’t really work in the same way. In theory libnds provides you with 4 DMA channels and pointers to RAM, so if you knew exactly what you wanted to replace and with what, you could do that. I’ve never seen it done personally as I’ve never seen a project that required it. You’re not saving much, if anything, in file size by slicing code like this, it still has to be stored somewhere. You’re not even saving on memory because it’s sectioned, so freeing up space in main RAM won’t give you any additional wiggle room in other areas (see the breakdown of RAM on GBATEK or in my tut.

EDIT: This is what you’re working with, simplified.

0130524C-34FE-4E93-ABFE-5A2EBB103FBB.png

If I’m understanding you correctly, you’d want to flush a part of your main RAM and replace it with something else on the fly, yes?

EDIT2: Upon some searching and digging through the Wayback Machine I found some code relevant to your interest. Keep in mind that this likely *will not* work on the current devkit as it’s over a decade old, so you’ll have to do your own debugging. As it says in the thread, on the DS you don’t really have a main ROM, you only have RAM, and that’s where your code and assets are. You should be able to shuffle both as needed, and store them at the end of your binary.

https://web.archive.org/web/20160324225148/https://forum.gbadev.org/viewtopic.php?t=14707

If you actually *need* this and aren’t just optimising for the heck of it, you must be dealing with an ungodly amount of code.
 

Cervi

Well-Known Member
OP
Newcomer
Joined
Aug 25, 2022
Messages
46
Trophies
0
Location
Catalonia
XP
383
Country
Spain
Thanks! I'm not optimizing for the heck of it, it's just that I'm thinking of maybe starting a decompilation project of an NDS game. That game uses overlays, and if I'd want to recreate it accurately I'd have to be able to rebuild these overlays.
 

Foxi4

Endless Trash
Global Moderator
Joined
Sep 13, 2009
Messages
30,818
Trophies
3
Location
Gaming Grotto
XP
29,789
Country
Poland
Thanks! I'm not optimizing for the heck of it, it's just that I'm thinking of maybe starting a decompilation project of an NDS game. That game uses overlays, and if I'd want to recreate it accurately I'd have to be able to rebuild these overlays.
That makes sense. Unfortunately, if you’re aiming for a 1:1 recreation of a retail title, you’ll have to get your hands on a real Nitro devkit, you’re not going to get the same result on any other toolchain because the tech is proprietary. It appears that WinterMute, creator of DevkitPro, made some strides in getting overlays to work in libnds, but they were never added to the official release, which tells me that it may have been wonky. Realistically the only kind of software you’d need overlays for would be some kind of loader or on-the-fly patcher, and that’s not what you’re aiming for.
 
  • Like
Reactions: Cervi

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,284
Country
United Kingdom
I always viewed overlays as a clunky/crude way of having some kind of dynamic libraries or allowing those devs that went too far down the incbin path (which to be fair was the default for cartridge consoles up to and including the GBA) a chance at having it work without having to refactor everything (don't build it to work for the ideal case as much as having it work well enough and all that).

I believe the official toolchains did leak with the gigaleak a while back -- people were compiling the pokemon code leaked with it. Though equally you are restricted with the commercial stuff and it uses a lot of precompiled things so there might be a case for it.
Anything I know of homebrew options for it was expanded many times reading the posts leading up to this so I will skip that one for now.
 
  • Like
Reactions: Foxi4

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    SylverReZ @ SylverReZ: @salazarcosplay, Morning