GBA DS Style — A Nintendo DS-Inspired Custom Kernel for EZ-Flash Omega & Omega DE

[JackKiyTheGamerGuy]

Do you think it would be possible to have the 120x80 boxart work with 80x80 so that we can have the full art for Japanese games

 

[FrankieT19]

Do you think it would be possible to have the 120x80 boxart work with 80x80 so that we can have the full art for Japanese games

That may not be possible due to the limitations of the GBA, but I will consider it for when I add some new features as that would be cool to have. Nice idea, thank you!

 

[JackKiyTheGamerGuy]

Whenever I try to use the 120x80 with the 80x80, it doesn't show the full art. Do you think it would be possible to have them at the same time

Post automatically merged: Jun 8, 2026

Whenever I use the Japanese box art, it crops it to 80x80. Do you think it would be possible to have them both at the same time, so we can have the full box art for Japanese games

 

[FrankieT19]

Version 6.9 is now released

List-view scrolling has been refined to remove flickering, menu stability has been improved, and the occasional navigation crashes should now be resolved. This release also includes several smaller menu optimisations and UI refinements.

 

[JohngPR]

Love the work you've been doing!

I am having an issue however with version 1.3 of the scraper.

I'm trying to make custom images for my folders and the way it's formatted I can't actually see the "Build artwork" button at the bottom of the app. It seems like the app is too tall and it wont let me either scroll down to the button or resize the window vertically to make it shorter.

It actually took me a while to realize that there was a build artwork button since you can't see it. You can se it though if you drag the app to the top, but the moment you let go, the app is made full screen since you have it pulled to the top of the screen.

I can see the button if I scale down my screen's 3840x2160 below the recommended 300% down to 250%, but I'd rather have it at the default size. If there's something that you can do to fix that, I would be grateful! Thanks for making this program...for someone like me that likes to customize things to my liking, it's very cool.

 

[FrankieT19]

Love the work you've been doing!

I am having an issue however with version 1.3 of the scraper.

I'm trying to make custom images for my folders and the way it's formatted I can't actually see the "Build artwork" button at the bottom of the app. It seems like the app is too tall and it wont let me either scroll down to the button or resize the window vertically to make it shorter.

It actually took me a while to realize that there was a build artwork button since you can't see it. You can se it though if you drag the app to the top, but the moment you let go, the app is made full screen since you have it pulled to the top of the screen.

I can see the button if I scale down my screen's 3840x2160 below the recommended 300% down to 250%, but I'd rather have it at the default size. If there's something that you can do to fix that, I would be grateful! Thanks for making this program...for someone like me that likes to customize things to my liking, it's very cool.

Hi! Thanks for reporting this. Should be fixed now in the latest version. I overlooked how it would scale on larger resolutions, sorry!

 

[JohngPR]

That was incredibly fast...thank you!

 

[Merle]

Thanks a lot for the bugfix update! It's really appreciated.

There's still some extra bit of polish I believe we could have, like:
- Hiding systems files at the root of the SD card, like ezkernelnew.bin and SYSTEM, as well as common system metadata files like .Trash, .Trash-1000, .DS_Store and whatever is put on SD cards by Windows.
- Bringing the adjacent thumnails closer to the focused one in Box mode, as there is plenty of empty space.
- Not shrinking adjacent thumbnails as they are hard to read, especially in Box mode as there is plenty of room to display them.

Minimal and possibly controversial but what about renaming Title and Box to Wide and Square? Boxes aren't square in Japan, but that's not the reason why I suggest that: I don't like using title screens or box fronts and I'm building a set of square thumbnails like we find on modern consoles, with an illustration and a title logo but no other logo whatsoever around.

If we keep the names then I agree with @JackKiyTheGamerGuy it'd be nice to have Box be able to handle box sizes, though as a UI dev I believe it's not the way to go and sizes should be consistent, especially if we want to implement my previously mentioned spacing refinement suggestions. I mean, it would likely be manageable as we only show 3 thumbnails at a time so it's not like the possibilities matrix would explode, especially if each adjacent thumbnail is handled individually, but that would still increase the complexity of a critical piece of code.

Post automatically merged: Today at 11:25 AM

I played a bit with the sources and noticed that there is a mix of or LF and CR+LF for new lines, all within the same file. That makes my IDEs and text editors trip up and add tons of changes to files by making automatically making it consistent. What about standardizing on a single one, whatever it is? Something like an .editorconfig file would help. I'm happy to submit such a fix, but whoever does that will show up everywhere in git blame.

 

[FrankieT19]

Thanks a lot for the bugfix update! It's really appreciated.

There's still some extra bit of polish I believe we could have, like:
- Hiding systems files at the root of the SD card, like ezkernelnew.bin and SYSTEM, as well as common system metadata files like .Trash, .Trash-1000, .DS_Store and whatever is put on SD cards by Windows.
- Bringing the adjacent thumnails closer to the focused one in Box mode, as there is plenty of empty space.
- Not shrinking adjacent thumbnails as they are hard to read, especially in Box mode as there is plenty of room to display them.

Minimal and possibly controversial but what about renaming Title and Box to Wide and Square? Boxes aren't square in Japan, but that's not the reason why I suggest that: I don't like using title screens or box fronts and I'm building a set of square thumbnails like we find on modern consoles, with an illustration and a title logo but no other logo whatsoever around.

If we keep the names then I agree with @JackKiyTheGamerGuy it'd be nice to have Box be able to handle box sizes, though as a UI dev I believe it's not the way to go and sizes should be consistent, especially if we want to implement my previously mentioned spacing refinement suggestions. I mean, it would likely be manageable as we only show 3 thumbnails at a time so it's not like the possibilities matrix would explode, especially if each adjacent thumbnail is handled individually, but that would still increase the complexity of a critical piece of code.

Post automatically merged: Today at 11:25 AM

I played a bit with the sources and noticed that there is a mix of or LF and CR+LF for new lines, all within the same file. That makes my IDEs and text editors trip up and add tons of changes to files by making automatically making it consistent. What about standardizing on a single one, whatever it is? Something like an .editorconfig file would help. I'm happy to submit such a fix, but whoever does that will show up everywhere in git blame.

These are all great suggestions, thank you! I’ll have a look at what’s practical.

For hiding system files, I think the best approach may be to add an option in the settings menu to hide common system/kernel files from the file browser. Since it can still be useful for users to access those files directly on the device if they need to delete anything.

On the thumbnail layout, I’m a little cautious about changing how the two modes behave individually, as that would add quite a bit of complexity, especially with how it integrates into the customiser program. The smaller adjacent thumbnails were originally a deliberate design choice to help convey movement, particularly when browsing icons. That said, I’m not against revisiting it in future. I did test larger adjacent thumbnails before, but at the time I felt it made the UI feel more crowded and a bit more static.

For the artwork mode names, I chose the current labels because they’re clear for people using the default setup, which is my main priority. That said, I can see the argument for names like ‘Wide’ and ‘Square’, and I’m not opposed to reconsidering them if that ends up being clearer overall.

Looping back to thumbnail dimensions, I may look into allowing different dimensions with different packs, but I’d need to be cautious because it’s a delicate part of the kernel. It had to go through a lot of optimisation to get it running at the current speed.

As for the mixed line endings, yes, there’s still a fair bit of mess in the kernel source. Some of that is due to it being inherited from multiple authors over time. I do plan to clean it up!

I’m away from my computer for a few weeks now so there won’t be any more work done until July. But please keep the suggestions coming in the meantime.

 

[iateyourcheesebro]

Thanks a lot for the bugfix update! It's really appreciated.

There's still some extra bit of polish I believe we could have, like:
- Hiding systems files at the root of the SD card, like ezkernelnew.bin and SYSTEM, as well as common system metadata files like .Trash, .Trash-1000, .DS_Store and whatever is put on SD cards by Windows.
- Bringing the adjacent thumnails closer to the focused one in Box mode, as there is plenty of empty space.
- Not shrinking adjacent thumbnails as they are hard to read, especially in Box mode as there is plenty of room to display them.

Minimal and possibly controversial but what about renaming Title and Box to Wide and Square? Boxes aren't square in Japan, but that's not the reason why I suggest that: I don't like using title screens or box fronts and I'm building a set of square thumbnails like we find on modern consoles, with an illustration and a title logo but no other logo whatsoever around.

If we keep the names then I agree with @JackKiyTheGamerGuy it'd be nice to have Box be able to handle box sizes, though as a UI dev I believe it's not the way to go and sizes should be consistent, especially if we want to implement my previously mentioned spacing refinement suggestions. I mean, it would likely be manageable as we only show 3 thumbnails at a time so it's not like the possibilities matrix would explode, especially if each adjacent thumbnail is handled individually, but that would still increase the complexity of a critical piece of code.

Post automatically merged: Today at 11:25 AM

I played a bit with the sources and noticed that there is a mix of or LF and CR+LF for new lines, all within the same file. That makes my IDEs and text editors trip up and add tons of changes to files by making automatically making it consistent. What about standardizing on a single one, whatever it is? Something like an .editorconfig file would help. I'm happy to submit such a fix, but whoever does that will show up everywhere in git blame.

Hey Merle, at least on Windows I’m able to add “hide” to the property of files/folder on the SD card (right click, properties, check “hide”) and they are then hidden on GBA

 

[Merle]

Hey Merle, at least on Windows I’m able to add “hide” to the property of files/folder on the SD card (right click, properties, check “hide”) and they are then hidden on GBA

Oh neat, I didn't know that feature of FAT32, thanks for letting me know! While there are ways, it sadly it's not so simple on my system, and it's a nice individual workaround, but I'd say it should be handled by the kernel at least for files specific to it.