Homebrew [3DS] mGBA Alpha 1v Released

  • Thread starter Thread starter NCorp.
  • Start date Start date
  • Views Views 269,469
  • Replies Replies 842
  • Likes Likes 35

mGBA/CitrAGB/Reroarch gPSP, What do you like.


  • Total voters
    337
... I meant whatever it was that was allowing dynarec. I don't know what capabilities are removed from the user if they're using a usermode exploit instead of a kernelmode exploit in the context of homebrew.

Dynarec's the only major performance difference I know of, and I didn't know if the capabilities that were allowing it allowed anything else remotely relevant for brute force testing.
Yeah, dynarec makes a huge difference for the GBA emulators but unfortunateley that memory manipulation functionality is available exclusively under ninjhax and the homebrew channel.
It hasn't been implementend in ctrulib yet and since some developers are such anti-piracy white knights, that's definitely not a priority.
 
  • Like
Reactions: AtlasFontaine
I also wrote code that checked the cpu ticks in relation to the system clock. Both the n3ds and o3ds returned the same value.

It could still be that the timer is sill running at 268Mhz for compatibility reason but master clock was doubled. Measuring CPU clock speed using internal timer is not always reliable since there can be divider from input clock.

Or, more likely it could be that the multi-processing is entirely handled by hardware and transparent to software which sees it as a unified single-core processor, thus not requiring special care for multi-threading. I'm not familiar with ARm11-MP architecture but this seems to be indeed the case :
https://www.arm.com/products/processors/classic/arm11/arm11-mpcore.php

Looks like a uniprocessor
  • Simplified SoC integration
  • Common solution for a range of devices
  • Standardized software platform

So I guess this is why single-threaded application still performs better on n3DS :-)


Yeah, dynarec makes a huge difference for the GBA emulators but unfortunateley that memory manipulation functionality is available exclusively under ninjhax and the homebrew channel.
It hasn't been implementend in ctrulib yet and since some developers are such anti-piracy white knights, that's definitely not a priority.

The code of ninjhax and homebrew launcher is freely available: if it was so simple as just "adding it to ctrulib", this could have been copied to the emulator code. ctrulib is just a library providing easier access to kernel functions.

If you read JimE post on previous page, it explains that dynarec do not work because application running in user mode cannot execute code from writable memory area so an emulator running in this mode can not generate executable code (which is basic principle of dynamic recompilation).

To configure memory regions, you need to be running with kernel privileges or run an exploit, which is surely more complicated than just adding a few functions in a library, and for some reason, seems impossible to use once the loaded application is running.
 
Last edited by Jacobeian,
  • Like
Reactions: teampleb
The code of ninjhax and homebrew launcher is freely available: if it was so simple as just "adding it to ctrulib", this could have been copied to the emulator code. ctrulib is just a library providing easier access to kernel functions.

If you read JimE post on previous page, it explains that dynarec do not work because application running in user mode cannot execute code from writable memory area so an emulator running in this mode can not generate executable code (which is basic principle of dynamic recompilation).

To configure memory regions, you need to be running with kernel privileges or run an exploit, which is surely more complicated than just adding a few functions in a library, and for some reason, seems impossible to use once the loaded application is running.
To install applications we need the same privileges and we can do it perfectly fine from a CFW. Dynarec IS possible through regular 3DS executables running on a fully exploited device but of course ctrulib must support those services required to manipulate memory regions.
 
To install applications we need the same privileges and we can do it perfectly fine from a CFW. Dynarec IS possible through regular 3DS executables running on a fully exploited device but of course ctrulib must support those services required to manipulate memory regions.

Please correct me if I'm wrong but I think those services are actually supported, cf. svcControlProcessMemory in svc.h

https://github.com/smealum/ctrulib/blob/master/libctru/include/3ds/svc.h
 
Please correct me if I'm wrong but I think those services are actually supported, cf. svcControlProcessMemory in svc.h

https://github.com/smealum/ctrulib/blob/master/libctru/include/3ds/svc.h

I was told a long time ago which was the relevant service and I don't remember it anymore (I would have mentioned it)... Now if it was this one and it's already supported, why isn't dynarec working yet?
Would the emulator developers be using a method valid only for homebrew menu?

Maybe we should ask @shinyquagsire23
 
I was told a long time ago which was the relevant service and I don't remember it anymore (I would have mentioned it)... Now if it was this one and it's already supported, why isn't dynarec working yet?
Would the emulator developers be using a method valid only for homebrew menu?

Maybe we should ask @shinyquagsire23

According to 3dsbrew, there is an header (exheader) for installed executables that tells what it can and what it cannot do, in particular:
- if it can use core #2 (on n3ds only)
- what services and system calls it can use

http://3dbrew.org/wiki/NCCH/Extended_Header

The reason you can not get access to a second core for faster processing on n3ds or that you cannot declare executable memory area for dynarec despite having full kernel access might simply be because your installed CIA does not have proper executable header, while the homebrew channel likely has all needed permissions.

I don't believe anyone is "checking" if you used a CIA and deliberately limits what the code can do, it does not make much sense.
 
  • Like
Reactions: piratesephiroth
According to 3dsbrew, there is an header (exheader) for installed executables that tells what it can and what it cannot do, in particular:
- if it can use core #2 (on n3ds only)
- what services and system calls it can use

http://3dbrew.org/wiki/NCCH/Extended_Header

The reason you can not get access to a second core for faster processing on n3ds or that you cannot declare executable memory area for dynarec despite having full kernel access might simply be because your installed CIA does not have proper executable header, while the homebrew channel likely has all needed permissions.

I don't believe anyone is "checking" if you used a CIA and deliberately limits what the code can do, it does not make much sense.
Well, I added "ControlProcessMemory: 112" to the list of allowed system calls and it didn't change anything at all.

EDT: Added all the missing memory-related systemcalls to the exheader and still nothing.

If it's supported by ctrulib then mgba is built to use dynarec only under the homebrew menu (never actually uses ControlProcessMemory)
 
Last edited by piratesephiroth,
what Is a tgs file??? wheres the 3dsx file???

--------------------- MERGED ---------------------------

im on ironhax 2.1

--------------------- MERGED ---------------------------

Are you on Ninj/Iron/Tube-hax 2.1?

Isn't that same file? It's just the latest nightly.
I meant tgz... what the heck is a tgz????
 

Site & Scene News

Popular threads in this forum