|Home | Downloads | Screenshots | Forums | Source code | RSS|
Thank you all! :)
Jul 15th 2018, by StapleButter
I don't always take the time to respond to your comments on this site, I'm sorry about it.
But I read your comments. I always do.
And I want to say, thank you. Those comments are real nice.
It's nice to see that you are still following this blog, despite the lack of modern subcription/following features.
(it's also nice to note that the viagra spammer stopped posting spam comments on the blog's second entry. not that their attempts at making links ever worked)
I have been ordering something that should arrive next week, hopefully Monday :)
This is related to the surprise. You'll know soon :)
|6 comments (last by Asura) | Post a comment|
Jul 12th 2018, by StapleButter
I finally intend to keep going with melonDS, in one of the possible directions.
You will know more about this soon, but for now, it's a surprise ;)
|15 comments (last by Lolito) | Post a comment|
melonDS status, and plans for the future
Jun 2nd 2018, by StapleButter
I figured I would write this, to give you an idea of melonDS's current status, what has been done and what remains to do.
To reply to the comments on the previous post: melonDS is already open-source, and it has always been. You will find the source code on Github. You can do whatever you want with it, as long as you are respecting the GPL.
So, here's a quick list of how things are and what needs to be done, from the top of my head. Searching the codebase for TODO/FIXME/HACK will find all the items.
All the instructions supported by the ARM7 and ARM9 are implemented.
ARM9-only instructions are enforced, altough this may be incomplete. It's unclear how some of them behave on the ARM7: some throw undefined instruction exceptions, but some seem to do nothing or behave like another instruction.
Cycle counting is rather crude and likely to be wrong for the more complex ARM9. Speaking of, the MPU and cache still have to be implemented (hopefully without killing performance). The first would allow emulating some game/homebrew crashes that happen on hardware, the second would be a requirement for reasonably accurate timings.
All DMA types are implemented, with reasonably accurate timings and operation. Running DMA and ARM9 simultaneously (possible under specific conditions) isn't implemented.
Timers might need checking/rework?
Memory map is accurate, including things like overlapping VRAM banks.
ROM/SPI transfers are emulated with proper delays, and should function like their hardware counterparts, minus some uncovered details (see all-caps printf() calls).
ARM9-side div/sqrt are emulated with delays.
All features are implemented. Even the rarely used 'main memory display FIFO'.
OBJ mosaic may be wrong, especially with rotated/scaled sprites.
DISPCNT latching is missing. Other registers may be latched, that hasn't been researched much yet.
VRAM access timings aren't implemented.
Most features are implemented.
The geometry engine is emulated mostly accurately. Polygon/vertex limits are enforced. Culling and clipping haven't been researched closely and may produce results different from hardware.
GXFIFO overflow isn't implemented properly (should incur penalty for ARM9 and presumably ARM7).
Misc things like effects of invalid operations (incomplete polygons etc) may not be implemented.
The rendering engine is emulated with much more accuracy than needed for your average game. Much research went into figuring out how the rasterizer works. melonDS is not pixel-perfect but close. Pointless besides for passing aging cart tests.
Antialiasing over shadow pixels is glitched.
The scanline cache is not emulated (requires figuring out rasterizer timings, including VRAM access and all).
Capture addition and source selection are missing (have yet to find something that uses them).
Other than that, the mixer is complete and emulated with sample accuracy.
Memory access timing isn't emulated, however buffering mechanisms (FIFO) are implemented.
Much of wifi still has to be researched.
The current implementation allows some form of local multiplayer (and connecting to the internet with proper support), but communication errors aren't properly reported, which results in bad things. So far my attempts at fixing that only made things worse.
Wifi is subpar compared to the rest of the emulator :P
With that in mind, where do we go next?
I'm not sure about attempting to continue the JIT. Considering I went for accuracy, preserving it at a reasonable level with a JIT is going to prove tricky, even moreso when you're emulating two simultaneous CPUs and a bunch of extra hardware. Make it too accurate and the synchronization overhead negates any speed benefits from the JIT, but going too far in the other direction will inevitably break games.
DSi emulation is another of the possible avenues. There's not a lot of DSiware to play, and even less cartridge games, but regardless, there are things to be done there.
Or I might go and emulate something entirely new for me? N64? Dreamcast? Xbox?
|11 comments (last by Casgaro) | Post a comment|
May 13th 2018, by StapleButter
You probably have noticed it, things are going down.
It's been 5 months since the last release.
What do we have that would be worthy of a 0.7?
The JIT? I started working on it, and... lost motivation.
DLDI? Same story. I hackishly added some commands so it can access a FAT image, and lost motivation to take it any further. For example, accessing the actual host filesystem instead of having to use an image file.
I have pretty much lost motivation. The context I find myself in these days doesn't help, either. I'm mostly just... bouncing between places and having trouble getting really settled.
So for now, melonDS is on hiatus.
I feel bad for those who are still donating to the project. If you are, well... do whatever you want, but consider that melonDS isn't going to see progress for a good while, if not ever.
|20 comments (last by poudink) | Post a comment|
Long time no see
Apr 25th 2018, by StapleButter
Things have been pretty busy real life wise. Apologies for the lack of updates regarding melonDS.
You might know how things went lately. I started coding a JIT recompiler for melonDS, then... lost motivation. Oh well.
Instead, I figured I would work on other things. Like, y'know, homebrew. melonDS runs commercial games all neatly and all, but its homebrew support is still subpar.
For one, DLDI support is one of the things I intend to work on. And not just granting filesystem access to homebrew, but actually attempting to emulate one of those flashcarts. It'd be amusing if melonDS could run a flashcart firmware. Not very practical or useful when you can load your ROM directly, but it'd be a cool feat. Besides, it's something the DS can do, so melonDS should also be able to do it.
Even that aside, there are some technically challenging homebrew games. A prime example would be Dirbaio's Fireworlds which pushes the system to its limits (and is also a cool game, try it).
Dirbaio recently put together a NitroFS build of Fireworlds, so that it can run on emulators that don't support DLDI. To give you an idea:
• NO$GBA: crashes after intro
• DeSmuME: runs okay, but no music (console complains about zero-length channels, likely related)
• medusa: crashes when loading level select menu
• dasShiny: gets stuck on NitroFS init
A quick test revealed that it didn't run on melonDS, but it was a rather silly issue (it tried accessing IPCSYNC via 32-bit reads/writes, which melonDS didn't handle). Dirbaio fixed it in a PR, which means Fireworlds finally runs... but not perfectly, heh.
Fireworlds seems to do some weird partial rendering to reduce the 3D engine load (noting that the most extreme levels do cause lagging-3D-engine glitches on the DS), and using display capture to mix together all the parts, or something like that. But it doesn't work right on melonDS and results in some flickering.
So there's atleast that to fix. That aside, the game seems to run quite well. But hey, it's nice to have technically interesting homebrew like this.
Fun side fact: Fireworlds has code to detect emulators, and it doesn't detect melonDS or medusa :)
Soo... there we go!
|7 comments (last by its_notjack) | Post a comment|
Network support: in the works
Jan 24th 2018, by StapleButter
You might have seen this thread.
Network support was achieved, but it was roughly equivalent to that of DeSmuME.
Currently, the network interface used by libpcap is hardcoded, I haven't added a UI for this yet.
There is also a disadvantage to this: it only works if your computer is connected via ethernet. It also requires promiscuous mode, which might be a problem in some situations.
I am working on a workaround to this, that allows networking without promiscuous mode. It will have to be tested extensively, but so far I got promising results.
|18 comments (last by not_A_staple) | Post a comment|
Jan 16th 2018, by StapleButter
What an original title.
Regardless, it's the case again. Real life is... still a bitch.
I need to change my phone plan, because while it was fine when I mostly used home internet, it sucks big time for more nomad uses. It's one of those plans that completely block internet access once you reach the data cap. So I'm going to switch to a plan with more data and that throttles speed instead of outright blocking. But in the meantime, I'm having trouble getting internet access.
As far as melonDS is concerned, I'm not quite sure what to try.
I have been trying to address the wifi stability issues, without much success. I have been doing a bunch of research on the multiplay communication thing and how it handles errors, thinking that properly handling those would make for a more stable connection (as opposed to always reporting success even when some data didn't make it through).
But so far, it has largely been a failure. At best, my attempts fixed nothing, and they generally made things worse.
I don't understand what it's expecting, so for now I'm putting this on the back burner.
Upscaling is a possibility, but as explained in a previous post, it's not all easy and nice. It'll also require writing a hardware renderer first, which could be a fun challenge.
There are quite a few tricks we can pull with modern OpenGL to emulate the DS GPU as accurately as possible. Obviously it would never get perfect, but we can get close.
Savestates are another avenue. Nothing really interesting though, it's mostly matters of properly saving and restoring all the emulator state. But it'd be one of the 'popular request' items.
In the less 'popular request' zone, what do we have? Bluetooth keyboard support for that Pokémon typing game. It'd be a fun little RE project, but it would only end up benefitting one game. Kind of an emulation white whale.
|14 comments (last by hyarsan / Flooder) | Post a comment|
Dec 16th 2017, by StapleButter
As promised, the quick fix release is out. There are a few other goodies too.
|9 comments (last by BlookyDJ) | Post a comment|
Dec 8th 2017, by StapleButter
I just realized that there are some bugs with the menu options pertaining to screen layout/etc, esp with how the checkmarks are initially placed. There will be a quick fix release to address this.
|3 comments (last by Rin Tohsaka) | Post a comment|
Dec 7th 2017, by StapleButter
I'm lazy, and there are little visual changes, so I will reuse those screenshots.
So what's new in melonDS 0.6? Little emulation wise, a bit more UI wise.
First of all, I want to thank the artists who have been (and are still) drawing all sorts of rad icons for melonDS. For 0.7, I will pick the one I like the best (and it won't be easy, heh). Thing is, I want to put the icon in the melonDS windows, and I will need to add support to libui. Which also means embedding the icons in some portable format, because each OS does its own thing when it comes to window icons.
Emulation wise, the big thing is the sound fix I talked about in a previous blog post. I already went in detail over this, but, long story short, surround works now. And sound emulation is more accurate, that can only be good.
There. The rest is meaningless shenanigans.
UI wise, you get fancy display modes now. Those were also discussed in a previous blog post, so no big surprise there.
The only thing that was added is a toggle for linear filtering, for those who like pixels.
The rest is, well, little bug fixes. Under Windows, you can now load ROMs with non-ASCII characters in their paths. As a side note, under Linux and OSX, fopen() can take UTF8 paths, but Windows requires a separate codepath because herpderp. fopen() can only take ASCII, for anything outside of that you need to use the Windows-only _wfopen() which takes wide-char strings. In the end, the code is a bit ugly, but it works.
That's about it for this release. But stay tuned, 0.7 should bring in some Christmas fun.
|12 comments (last by yolo) | Post a comment|