Homebrew CitrAGB - 3DS GBA Emulator (WIP)

[sj33]

A .cia version of Homebrew Loader would certainly save a lot of hassle. I don't particularly want to clutter my system menu with loads of .cia homebrews, but it's better than having to boot up Cubic Ninja every time. It would be much nicer to be able to just install Homebrew Loader as a .cia.

 

[piratesephiroth]

A .cia version of Homebrew Loader would certainly save a lot of hassle. I don't particularly want to clutter my system menu with loads of .cia homebrews, but it's better than having to boot up Cubic Ninja every time. It would be much nicer to be able to just install Homebrew Loader as a .cia.

I think a homebrew loader is a pretty dumb idea. If someone doesn't want to clutter the home menu, just use folders.

 

[sj33]

It's not just that, it's also about avoiding the need to have multiple compiles of the same build/release of a homebrew. .3dsx, .cia, .3ds, .elf among others. We've been able to reduce that down to just .3dsx and .cia (people who can use Devmenu and people who cannot), but a Homebrew Launcer in .cia format would mean the scene can settle on .3dsx.

Not to mention how much homebrew releases in just one format or another, meaning people have to complile themselves. More standardisation is needed.

 

[piratesephiroth]

It's not just that, it's also about avoiding the need to have multiple compiles of the same build/release of a homebrew. .3dsx, .cia, .3ds, .elf among others. We've been able to reduce that down to just .3dsx and .cia (people who can use Devmenu and people who cannot), but a Homebrew Launcer in .cia format would mean the scene can settle on .3dsx.

Not to mention how much homebrew releases in just one format or another, meaning people have to complile themselves. More standardisation is needed.

Yeah, it should be standardized according to the most used method, and that's Gateway/MT Card.
Not only there are fewer Ninjhax users than flashcart users but also Ninjhax won't be updated for newer firmwares.
Gateway can keep going forward with its emunand.

Pretty much everyone on 9.2 will drop Ninjhax and buy a Gateway.

 

[NCDyson]

Yeah, it should be standardized according to the most used method, and that's Gateway/MT Card.
Not only there are fewer Ninjhax users than flashcart users but also Ninjhax won't be updated for newer firmwares.
Gateway can keep going forward with its emunand.

Pretty much everyone on 9.2 will drop Ninjhax and buy a Gateway.

I don't even see why anyone bothers to distribute .cia versions of homebrew to begin with, since if you can use .cia you can run CubicNinja, and then use ninjhax with it. But hey, let's alienate an entire group of users based on speculation about what gateway may and may not be able to do, including lower the price of their cart to around the same(still elevated) price of a copy of CubicNinja.

 

[sj33]

That's possible, of course. But looking around compiles of existing homebrew, .3dsx seems to be dominant right now - especially for builds compiled from git. It seems to be the preferred format for the developers themselves.

 

[william341]

And some people (like me) don't like flash cards, and like NCDyson said CN is like 1/3 of the price of a gateway.

Edit: Updated price fraction

 

[shinyquagsire23]

I'm actually kinda curious myself if you could hack the Cubic Ninja binary to load straight into the QR code reader and thus straight to the Homebrew Launcher. Might do that once GW updates for 9.4 since ROM Hacking is more my thing than programming emulators.

On a slight sidenote, I've got the hang of setting up executable RAM pages and I can execute from them just fine. Main issue now is getting the dynrec core to work properly with the 3DS. Since the core I'm using is optimised for ARM Linux rather than just ARM it's a tiny bit weird in how it does a few things, so I'm still working on getting that part to not crash. I'm hoping I'll get it settled soon, but who knows how long it will take. Also, I've added a way to check if ninjhax is currently running or not. If ninjhax is detected, it will set up the dynrec caches and run them through the hb service's methods to set them as executable, and also run a tiny piece of code through them as well to verify that they are working (if it crashes on startup, chances are that the test failed). It will also display which CPU mode it will be using in the lower left corner. This pic was taken from 3dmoo, and since it doesn't implement the hb service as of yet, it will boot into interpreter mode:

Although the interesting thing is that 3dmoo actually doesn't give a crap if memory is executable or not (apparently), so you could run the dynrec core in it at the moment if you disabled the checks. The same isn't the case on a real 3ds though, so don't try it. The good thing is though that this will be an easy tool to make sure people who happen to convert this to .cia or .3ds know that they are running in interpreter mode vs dynrec, so they won't be completely shut out from using CitrAGB, it's just better through ninjhax at the moment.

 

[kraan]

Good luck mate, I didn't catch any of that but I'm praying for a speedy and simple code <3

 

[piratesephiroth]

I don't even see why anyone bothers to distribute .cia versions of homebrew to begin with, since if you can use .cia you can run CubicNinja, and then use ninjhax with it. But hey, let's alienate an entire group of users based on speculation about what gateway may and may not be able to do, including lower the price of their cart to around the same(still elevated) price of a copy of CubicNinja.

Yeah, and since Ninjhax doesn't work on the latest firmware it's very nice to force Gateway users to use old emunands too, right? Why would they be able to use the eshop when Ninjhax users can't?

3DSX should be an OPTIONAL container. The Homebrew Launcher is and will always be a SECONDARY way to run homebrew.
DevkitPro makes standard elf files that can be built into 3DS, CIA and 3DSX all the same.

If everyone is being honest there's absolutely no reason for not distributing the homebrew in all formats.
All it takes is creating an RSF and adding more lines to their makefile. (Or a batch file, if it's a user compiling source code)

Anyone saying something works only as 3DSX is a liar.

 

[shinyquagsire23]

Anyone saying something works only as 3DSX is a liar.

Dynamic recompilation only works as a .3dsx

Spoiler

Just kidding it could technically run in other package formats if .cias and .3ds files had access to the hb service with the additional methods which allow me to remap memory but it doesn't and there's not much I can do about it at the moment. Maybe go bug smea about it? Also pls don't kill me thx

 

[piratesephiroth]

Dynamic recompilation only works as a .3dsx

Spoiler

Just kidding it could technically run in other package formats if .cias and .3ds files had access to the hb service with the additional methods which allow me to remap memory but it doesn't and there's not much I can do about it at the moment. Maybe go bug smea about it? Also pls don't kill me thx

<profi200> As said to get the same working for .cia versions you need access to svc 0x70 (ControlProcessMemory). Then you can set mem to rwx like with Ninjhax.
(...)
<profi200> svc 0x70 is not implemented in ctrulib unfortunately.

 

[shinyquagsire23]

<profi200> As said to get the same working for .cia versions you need access to svc 0x70 (ControlProcessMemory). Then you can set mem to rwx like with Ninjhax.
(...)
<profi200> svc 0x70 is not implemented in ctrulib unfortunately.

Eh, pointeroni. I might look into it if it means .cia compatability though, although I know zero about .cia at the moment so not much I could do in terms of testing.

 

[shinyquagsire23]

It's... ALLLIIIIVVVEEE!

At the moment though it's only in 3dmoo. I still have a few things to fix before it starts working on real hardware.

 

[davhuit]

Yeah, and since Ninjhax doesn't work on the latest firmware it's very nice to force Gateway users to use old emunands too, right? Why would they be able to use the eshop when Ninjhax users can't?

Well, that is only true for now. Once the gateway 9.2 exploit will be released, Ninjhax will work as you will be able to have a 9.2 (or lower, like 8.x, which I think Ninjhax also work? I think it work) sysnand.

It won't work on emunand but it'll work on sysnand.

(and if the new exploit still have emunand, even 4.x users would be able to update to 8.x at least with a cart, except if they want to keep using the blue card for NDS roms. In that case, they probably won't have any other choice than staying on 4.x).

Edit : I just checked the official ninjhax website and it seems the exploit even work on 4.x firmware as it let you choose 4.x in the firmware choice, so it might already be usable on 4.x sysnand.

Though, in those both examples, you would need the real cart, as sysnand can't play roms (don't know yet about gateway 9.x exploit but 4.x one can't for sure).

 

[sj33]

It's why I did actually buy a retail Cubic Ninja cart. If I ever want to update from 9.2 EmuNAND in the future, I can still boot Ninjhax from SysNAND.

Hopefully Gateway are working on their own native .3dsx support.

 

[shinyquagsire23]

Back.

Spoiler

Thanks to the help of yellows8, Normmatt, smea, and plutooo I finally managed to get it working. Basically the first issue was getting the cache invalidation to work properly every time a new block of code was pushed to the recompilation caches, and once that was done I got stuck on another issue which I initially thought was some weird cache issue, but ended up being a stack overflow (thanks to yellows8 for finding that one, I probably would never have guessed it would be a stack overflow...). Long story short, I relocated the stack with some more space and it's alive and breathing.

There is one slight downfall, and it's the cache invalidation. Currently due to the nature of how gpsp does it's stuff, the blocks are generated pretty much JIT, so after each block another block is generated. The problem is that every time I write to the recompilation cache, I have to invalidate the entire instruction cache (which is a lot). And with games that are rather large, this is a bit of an issue invalidating the cache takes a bit of time, and since large games often branch and go around quite a bit, this can equate to a metric crapton of lag.

The other issue now is rendering, rendering is becoming a bottleneck in some situations due to the use of the CPU rendering in order to flip the frame buffer the right way up. So I'll probably be implementing GPU rendering soon as well in order to minimize the lag generated here.

So basically at this point, some games run extremely well, some run absolutely horrible (worse than the interpreter), and a lot of optimizations are needed both on my end as well as maybe on ninjhax's end to allow the invalidation of specific blocks of the cache vs the entire thing. The good thing though is that we have the dynrec going fairly well at this point, which is good.

EDIT: Updated .3dsx is in the main post for those who want to try it. Don't get your hopes up too high for speed though, it's a big WIP at the moment even with the dynrec in place. Also, exiting with the X button isn't in place yet.

EDIT 2: Holy crap, just fixed a thing and now Fire Red is running much faster than the interpreter (still not 100%, probably closer to 60% or 70%, it's hard to tell without sound). Apparently I was invalidating the cache even when I didn't write anything new to the translation cache. Huge performance increases, although video is still lagging it down.

 

[kraan]

This post is what I've been waiting for since my copy arrived. Downloading as we speak.

 

[kane159]

Back.

Spoiler

Thanks to the help of yellows8, Normmatt, smea, and plutooo I finally managed to get it working. Basically the first issue was getting the cache invalidation to work properly every time a new block of code was pushed to the recompilation caches, and once that was done I got stuck on another issue which I initially thought was some weird cache issue, but ended up being a stack overflow (thanks to yellows8 for finding that one, I probably would never have guessed it would be a stack overflow...). Long story short, I relocated the stack with some more space and it's alive and breathing.

There is one slight downfall, and it's the cache invalidation. Currently due to the nature of how gpsp does it's stuff, the blocks are generated pretty much JIT, so after each block another block is generated. The problem is that every time I write to the recompilation cache, I have to invalidate the entire instruction cache (which is a lot). And with games that are rather large, this is a bit of an issue invalidating the cache takes a bit of time, and since large games often branch and go around quite a bit, this can equate to a metric crapton of lag.

The other issue now is rendering, rendering is becoming a bottleneck in some situations due to the use of the CPU rendering in order to flip the frame buffer the right way up. So I'll probably be implementing GPU rendering soon as well in order to minimize the lag generated here.

So basically at this point, some games run extremely well, some run absolutely horrible (worse than the interpreter), and a lot of optimizations are needed both on my end as well as maybe on ninjhax's end to allow the invalidation of specific blocks of the cache vs the entire thing. The good thing though is that we have the dynrec going fairly well at this point, which is good.

EDIT: Updated .3dsx is in the main post for those who want to try it. Don't get your hopes up too high for speed though, it's a big WIP at the moment even with the dynrec in place. Also, exiting with the X button isn't in place yet.

EDIT 2: Holy crap, just fixed a thing and now Fire Red is running much faster than the interpreter (still not 100%, probably closer to 60% or 70%, it's hard to tell without sound). Apparently I was invalidating the cache even when I didn't write anything new to the translation cache. Huge performance increases, although video is still lagging it down.

hey bro i tried the build from git, it's really smoother but still somewhere have weird color and the new build that X buttom to go back to HB doesent work

 

[shinyquagsire23]

hey bro i tried the build from git, it's really smoother but still somewhere have weird color and the new build that X buttom to go back to HB doesent work

Alpha transparency has strange coloration at the moment, not sure why, but that's probably it. And the X button I already said doesn't work (for now). Just eject the cart to exit while I get that figured out.