Homebrew WIP melonDS for Switch

ShadowOne333

QVID PRO QVO
Developer
Joined
Jan 17, 2013
Messages
10,956
Trophies
1
XP
13,582
Country
Mexico
DraStic is going to be opensource next year, will this drastically (pun intended) improve or change the DS emulation abilities of the Switch ? Will MelonDS benefit from that ?
It is an insane emulator running very fine even on old hardware, so I hope this will accelerate the development of DS emulators on Switch :)

Source : https://drastic-ds.com/viewtopic.php?f=5&t=5680
Fucking finally.
Guess they couldn't comply with Google's new policies then? (can't open the link btw but it's on my end)

If at all, this would only help to maybe port Drastic to other devices, and perhaps even make it a core on RetroArch.
Out of that, I doubt it could be of much help outside of looking at it's dynarec and some very specific code.
Each emu is drastically different code-wise to just take other code and rebase the already existing code to match it.
 

Rahkeesh

Well-Known Member
Member
Joined
Apr 3, 2018
Messages
2,109
Trophies
1
Age
41
XP
2,723
Country
United States
They are complying actually. They have an arm64 dynarec now, just need to optimize a few more elements for 64-bit. Claim that it may run a bit slower than 32-bit but it's basically there.

Open source is pending them finishing their stated dev goals, less a sign of giving up than moving on once their task is done.
 

catlover007

Developer
Developer
Joined
Oct 23, 2015
Messages
693
Trophies
1
XP
3,249
Country
Germany
I am sorry that I have to say this, but this is still the thread for a melonDS on switch, not about Drastic on switch or nds emulation on the switch in general. Maybe it's time to move the more concrete questions out into it's own one, esp. with android on switch coming at some point?

Anyways to give this post atleast some substance, during the last weeks, the x64 JIT progressed well and though it still needs testing, it's mostly done. In the meanwhile I took a break from the CPU and tried optimising the 2d rendering of melonDS. Some progress was made, though I'm not sure if it's worth continuing the effort, with drastic around the corner.
 

ShadowOne333

QVID PRO QVO
Developer
Joined
Jan 17, 2013
Messages
10,956
Trophies
1
XP
13,582
Country
Mexico
I am sorry that I have to say this, but this is still the thread for a melonDS on switch, not about Drastic on switch or nds emulation on the switch in general. Maybe it's time to move the more concrete questions out into it's own one, esp. with android on switch coming at some point?

Anyways to give this post atleast some substance, during the last weeks, the x64 JIT progressed well and though it still needs testing, it's mostly done. In the meanwhile I took a break from the CPU and tried optimising the 2d rendering of melonDS. Some progress was made, though I'm not sure if it's worth continuing the effort, with drastic around the corner.
Don't feel discouraged by Drastic.
If at all it's always nice to see the development of a dynarec and more so for the complex system that the DS is.
Besides, it's always nice to have options, and for sure having melon around for multiple platforms would be neat too :P
 
  • Like
Reactions: lutyj

Arisotura

rise of melonism
Member
Joined
Dec 5, 2009
Messages
839
Trophies
1
Age
28
Location
center of the Sun
Website
kuribo64.net
XP
2,452
Country
France
can't tell how shit will go on the Switch, but as far as desktop is concerned, melonDS will remain a serious option, y'know

if we get DraStic as an option for lower-end hardware, or just for people who want speed in general, that's good

but melonDS is the only one implementing melonism with class :P

more seriously, tho:

https://drastic-ds.com/viewtopic.php?f=5&t=4391&p=18970&hilit=hacks#p18962

DraStic relies on several game-specific hacks. this approach is good for lower-end hardware where the extra accuracy needed would be too costly. but, as history has shown multiple times, any emulation solution that isn't accurate will keep running into issues. which is why melonDS's approach is to avoid game-specific hacks at all costs. the extra accuracy needs higher-end hardware, but also means that you're less likely to run into issues when playing obscure games.

as an example, several of the games listed in that post, run in melonDS without requiring any game-specific hack.

some others don't. what I want to know is how far we can get, without requiring absurd hardware of course. (I sure as hell hope we don't have to emulate the ARM9 caches)

for all I know, CPU timing is still vastly wrong in melonDS.

one common problem is that of badly-programmed games that have a race condition or whatever. on an environment like PC, those would quickly be caught and fixed due to the nondeterministic timing of those platforms. but, on the DS, games run on the bare metal, and all consoles have the same timing characteristics. so, basically, such bugs tend to go unnoticed, because it works out of sheer luck. but when you run it on an emulator with different timings, it explodes.

we had the same issue with GX timings and Spellbound for example. the game sends GX display lists via DMA, but here's the catch:
* it transfers a certain amount of words, then sets up an IRQ handler to continue the transfer once the GX FIFO is less-than-half-full, and so on until everything is transferred
* after setting up the first transfer, it immediately sends a SWAP_BUFFERS command, without waiting for the transfer to be actually finished

so how that works is that every time a DMA is finished, the GX FIFO must be less-than-half-full already, or nearly. otherwise, the time interval will cause the game to send a SWAP_BUFFERS command in the middle of the display list, which you guess doesn't go well.

while working out GX timings, we found out a lot of fun things. did you know that the GX is capable of parallel execution, to some extent? furthermore the timings are different if polygons pass or fail culling/clipping/etc. and so on. melonDS attempts to emulate all that, but it's still not perfect.

you can see from code comments that DeSmuME ran into similar issues in the past, and they took the easy route of making their GX commands artificially fast. measurements show that NO$GBA adopted a similar approach.

and yet, the GX is lame compared to a full-fledged CPU (hi, ARM9).
 

MK73DS

Non-commutative algebra
Member
Joined
Feb 23, 2015
Messages
575
Trophies
0
Age
23
Location
France
Website
www.youtube.com
XP
1,494
Country
France
DraStic relies on several game-specific hacks. this approach is good for lower-end hardware where the extra accuracy needed would be too costly. but, as history has shown multiple times, any emulation solution that isn't accurate will keep running into issues. which is why melonDS's approach is to avoid game-specific hacks at all costs. the extra accuracy needs higher-end hardware, but also means that you're less likely to run into issues when playing obscure games.

It uses only 13 game-specific hacks though. Which means that 99% of the games will run fine on low-end devices even without any hacks. I hope melonDS will be able to reach this level of performance in the future !
 

doctorgoat

Well-Known Member
Member
Joined
Jun 3, 2015
Messages
685
Trophies
0
Age
33
XP
527
Country
United States
Are there non-harmful speedhacks? I remember at least one emulator for PSP that had detection for certain loop types as a feature, but someone had to actually find said loops on a PC emulator before they could be added as patches. Wait loops? I don't remember.

I booted up SaGa 2 hoping it wouldn't be too rough, and it looks to be visually as complex as FFIV. There didn't seem to be any difference at all between OpenGL and software, except OpenGL was constantly artifacting.
 

Billy Acuña

Well-Known Member
Member
Joined
Oct 10, 2015
Messages
3,124
Trophies
1
Age
29
XP
3,628
Country
Mexico
speedhacks don't serve a lot of purpose in a DS emulator, except for the occasional game that has a stupid-ass idle loop pegging the CPU, but 99% of the DS games out there use proper IRQ waits
That's good to know, so melonDS may eventually be almost on pair to DraStic in terms of performance with only a few of exceptions of games, right?

Enviado desde mi SM-G950F mediante Tapatalk
 
  • Like
Reactions: ShadowOne333

Rahkeesh

Well-Known Member
Member
Joined
Apr 3, 2018
Messages
2,109
Trophies
1
Age
41
XP
2,723
Country
United States
Well Drastic tells me its locked at 60 FPS but I can see what feels like missed frames in Portrait of Ruin, so yeah corners are being cut. Still it was targeted at devices with far less power than the Switch so.
 
  • Like
Reactions: ShadowOne333

MK73DS

Non-commutative algebra
Member
Joined
Feb 23, 2015
Messages
575
Trophies
0
Age
23
Location
France
Website
www.youtube.com
XP
1,494
Country
France
Well Drastic tells me its locked at 60 FPS but I can see what feels like missed frames in Portrait of Ruin, so yeah corners are being cut. Still it was targeted at devices with far less power than the Switch so.

You can disable frameskip, I never experienced any kind of missed frames in any game
 

catlover007

Developer
Developer
Joined
Oct 23, 2015
Messages
693
Trophies
1
XP
3,249
Country
Germany
progress!

Green Joy-Con D-Pad Shells for Nintendo Switch

like the x64 JIT (which has been merged btw!) the ARM64 JIT is now in a state where it's roughly complete, with still (hopefully very few or no:D) bugs to be found and optimisations to be made.

Unfortunately the speed gained by the dynarec wasn't enough, it ran almost full speed. In most situations the 2D GPU was the bottleneck now (3-4ms spent emulating the CPU while 9ms per frame spent emulating the 2D GPU). Fortunately I had already experimented with some optimisations in the past and here we are. It's running barely at full speed, but there's also still enough optimisation potential there.

EDIT: this is of course without overclocking
 
Last edited by catlover007,

tabnk

Well-Known Member
Member
Joined
Jan 20, 2016
Messages
290
Trophies
0
Age
40
XP
1,611
Country
United States
Nice. Looking forward to this.

progress!

Green Joy-Con D-Pad Shells for Nintendo Switch

like the x64 JIT (which has been merged btw!) the ARM64 JIT is now in a state where it's roughly complete, with still (hopefully very few or no:D) bugs to be found and optimisations to be made.

Unfortunately the speed gained by the dynarec wasn't enough, it ran almost full speed. In most situations the 2D GPU was the bottleneck now (3-4ms spent emulating the CPU while 9ms per frame spent emulating the 2D GPU). Fortunately I had already experimented with some optimisations in the past and here we are. It's running barely at full speed, but there's also still enough optimisation potential there.

EDIT: this is of course without overclocking
 
General chit-chat
Help Users
  • No one is chatting at the moment.
    Veho @ Veho: Sup.