Homebrew [3DS] mGBA Alpha 1v Released

[AtlasFontaine]

And that will only happen on CIAs when it's fully supported by ctrulib.

Or when we get ARM11 in >9.2 (never lol)

 

[Xulin]

Except none of the emulators (or even any homebrew) being used so far are designed for multiprocessing

mGBA is, that's why you see the performance boost.

Has it really been confirmed there were 4 cores running? It would seem more logical that they kept the 2x core architecture (one for kernel loaded from firmware + one for application code) since it does not require devs writing applications designed for multi-processing, and simply doubled the clock speed of each core.

Yes, it has 4 cores. Same speed. Why wouldn't devs want to write multi-processed code? It's the standard. They already write multi-threaded code for every other platform - vita, smartphones, ps4, xbone, pc, etc. You're talking as if multi-threaded code is something devs want to avoid.

 

[Jacobeian]

And that will only happen on CIAs when it's fully supported by ctrulib.

You keep saying that but I don't think that's true.
Ctrulib is only a library of services usable in user mode, the difference you got between CIA and 3DSX are much likely related to the loader and the running application permission.

 

[Sr. G]

can this run Kingdom Hearts Chains of Memories?

 

[piratesephiroth]

You keep saying that but I don't think that's true.
Ctrulib is only a library of services usable in user mode, the difference you got between CIA and 3DSX are much likely related to the loader and the running application permission.

Of course it's possible. Ninjhax has very nice control over the memory (remember CitraAGB has dynarec on it, but not as a native 3DS executable). Only some of these functions have still not been been fully implemented on ctrulib.

 

[Jacobeian]

mGBA is, that's why you see the performance boost.

I didn't knew about mGBA
But see the retroarch thread: all the cores used are single-threaded but still run 2x faster on n3ds.
How do you explain that?

Yes, it has 4 cores. Same speed.

May I ask how it was verified / confirmed ?

Why wouldn't devs want to write multi-processed code? It's the standard. They already write multi-threaded code for every other platform - vita, smartphones, ps4, xbone, pc, etc. You're talking as if multi-threaded code is something devs want to avoid.

You can have multiple threads on a single processor core. My point was that having to choose which processor to use for each thread (which also could introduce some limitations since threads are generally supposed to run in a single process, with shared context area) was more complicated than having one core running the kernel / scheduler and another running application (with eventually its threads).

 

[NuikopeaDemon]

can this run Kingdom Hearts Chains of Memories?

Just tested it out and.... Well

I believe it's playable

 

[xdarkmario]

i refuse devolve and use the 3dsx ver.
so until its fixed ill be siting here patiently like the patient spy. lol

 

[Xulin]

Once again, none of the ported emulators use multi-threading: they are all designed to run in a single-threaded application and none of them were modified to use 3DS threading services. The fact they are running faster on n3ds seems to indicate cores were actually overclocked, not duplicated.

Have you looked at the code to determine what it is designed for? How would you even be able to recognize threaded code if you're not a coder?

Just because an app happens to run on single-threaded hardware doesn't mean it was designed for it. You can write some random dummy java file in 2 minutes that would run much quicker on a dual core cpu over a single core, but it would still run on the single core, just slower. That's whats happening with mGBA.

 

[Jwiz33]

Or when we get ARM11 in >9.2 (never lol)

*arm 11 kernel
We already have arm11 (userland, though)

 

[Jacobeian]

Have you looked at the code to determine what it is designed for? How would you even be able to recognize threaded code if you're not a coder?

Just because an app happens to run on single-threaded hardware doesn't mean it was designed for it. You can write some random dummy java file in 2 minutes that would run much quicker on a dual core cpu over a single core, but it would still run on the single core, just slower. That's whats happening with mGBA.

I actually can read the code of those emus and do not see them making use of threads while mGBA indeed uses POSIX threads and has some layer in the 3ds port to translate them into 3DS threading services.
https://github.com/mgba-emu/mgba/blob/master/src/platform/3ds/threading.h

 

[Xulin]

I'm not sure what you're arguing anymore. You just said 1 page ago that none of these emus were designed for multi-threading and that the fact that they run faster must be due to faster clockspeeds. We know the clockspeeds on N3DS aren't faster, and we know n3DS has 2 extra cores. So in this case the only option for something being faster on one system over the other is multi-threading. There literally isn't any other possibility.

 

[doctorgoat]

Does mGBA use any of the features NinjHAX 2/OoTHax/Ironhax don't have? That'd account for it.

I haven't see any definite data with framerates on games at all though between systems, which is why the speedup thing bugs me so much.

 

[Jim_e]

I'm not sure what you're arguing anymore. You just said 1 page ago that none of these emus were designed for multi-threading and that the fact that they run faster must be due to faster clockspeeds. We know the clockspeeds on N3DS aren't faster, and we know n3DS has 2 extra cores. So in this case the only option for something being faster on one system over the other is multi-threading. There literally isn't any other possibility.

That's not entirely true.
We had a similar conversation somewhere in the Gameyob thread. I have both a n3ds and o3ds, I wrote and tested single threaded code(brute math, each iteration dependent on the previous iteration). My findings were that the n3ds ran the code something like 2.3x faster than the o3ds. I also wrote code that checked the cpu ticks in relation to the system clock. Both the n3ds and o3ds returned the same value.

So that was odd in my opinion. Someone suggested that system services have been moved to another core, thus freeing up more CPU time on the main core. Plausible but that suggests that the OS uses more than 50% of the cpu time for it's own purpose, even though it has a dedicated core.

No matter the case, the n3ds effectively has double the CPU time for single threaded code, even if the cpu clock appears to be the same.

 

[doctorgoat]

There was something that made it so only <=9.2 could use dynarec. Was that active on both the O3DS/N3DS in those tests?

 

[Sr. G]

Just tested it out and.... Well

I believe it's playable

ok, thanks, i will see by my own now
is that or play the PS2 version on PC with 3DS as controller x'D

Ty anyway for the answered

 

[Jim_e]

Why wouldn't devs want to write multi-processed code?

Just noticed this post. It adds complexity, significantly. I've seen poorly implemented mutexes in my time. Online tutorials by people that don't know how IPCs work nor when it's safe to access data in a lock. It's a shame that it's easy to get miss informed.

Fact is, threaded code is hard. It's hard to catch corner cases, it's hard to debug, and there's always some bit of code(or worse a lib) that doesn't like threads. But most of the time, solutions to problems are simply more obvious in a single thread mindset.

More over, emulators are not so easily threadable. Basically it breaks down to an emulation thread and a render thread. This is impossible for older systems where cpu clock is tightly tied to the ppu and single instructions timing means the difference between correctly render or not. It's even harder on the 3DS since we lack render hardware capable of rendering from palate requiring CPU intervention.

There was something that made it so only <=9.2 could use dynarec. Was that active on both the O3DS/N3DS in those tests?

Are you asking me? Dynarec only applies to emulation. It doesn't apply to these test.

 

[doctorgoat]

Are you asking me? Dynarec only applies to emulation. It doesn't apply to these test.

... 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.

 

[Jim_e]

... 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.

No, the issue lies with user code not being allowed to set memory execution privileges. Only the kernal can do that, or an exploit that grant that privileges. Lacking that privilege should have no impact on performance.

 

[doctorgoat]

I appreciate you taking the time to explain that.