|Home | Downloads | Screenshots | Forums | Source code | RSS|
melonDS aims at providing fast and accurate Nintendo DS emulation. While it is still a work in progress, it has a pretty solid set of features:
• Nearly complete core (CPU, video, audio, ...)
• OpenGL renderer, 3D upscaling
• RTC, microphone, lid close/open
• Joystick support
• Various display position/sizing/rotation modes
• (WIP) Wifi: local multiplayer, online connectivity
• and more are planned!
If you're running into trouble: Howto/FAQ
If you're feeling generous: melonDS Patreon
Some brighter news tho
Jan 3rd 2019, by Arisotura
Too many ideas.
Regarding the Colour Cross issue, I have an idea. It seems to stem from the GXSTAT busy flag, like, sometimes it's still set when it should be cleared because we aren't syncing the GX often enough.
I could go back to the old way (syncing it per-opcode), but I'm afraid this is going to be suboptimal. The better solution I have will require a bit of reworking how melonDS handles timing. As a bonus it would be more straightforward, easier to maintain and less error-prone.
I still have no idea about Spellbound though. I found that DMA timings can differ depending on how source/destination addresses are updated, but that doesn't apply in the Spellbound case. So, still no idea there.
I guess we can try releasing 0.7.3 after fixing Colour Cross, though.
I also have a few ideas for improving this site. A nice one to have would be an intro blurb before the blog posts, showing off melonDS and why it's awesome and you should totally download it, like the lolSNES site has.
Might also change the download page a bit, namely, to add downloadable extras like the latest romlist.bin or the dsbf_dump.nds copy that's been squatting the Kuribo64 uploader since forever.
Maybe even later, some form of compatibility list. Which will need some dedicated testers to fill it and keep it up to date.
If you have ideas how to improve the site, visually or technically, I'm open to all suggestions!
... read more
|5 comments (last by NinTester) | Post a comment|
Happy new year from melonDS
Jan 1st 2019, by Arisotura
This year is not starting too well. I implemented an instruction cache in melonDS, and what are the results? Absolutely none whatsoever (other than being a bit slower). It achieved as much as farting in the wind. The problem games I previously mentioned are still giving me the finger.
My motivation is utterly sapped.
We hope this year will be better for you.
|1 comment (by SC) | Post a comment|
Dec 31st 2018, by Arisotura
The database was rebuilt, this time from a mishmash of the Advanscene and Wood databases. It should be a lot better.
In the near future, the database will be changed to identify ROMs by game code rather than CRC, so it will also work with hacked ROMs and whatnot. But for melonDS 0.7.2 or 0.7.1, you can get this updated database.
-> Download here <-
Just overwrite your existing romlist.bin with this and you're good to go!
Remember, if your game is still failing to save, you may need to delete the savefile.
|3 comments (last by T3st3r) | Post a comment|
World of shit
Dec 30th 2018, by Arisotura
I've been looking at another 'timing renovation victim' issue: dual-screen 3D shitting itself in Colour Cross.
The game draws all its animated background tiles/etc separately, giving each its own transforms. It sends unpacked GXFIFO commands and doesn't use DMA. All in all, not very efficient, but probably not a bad way to do it given what they're doing.
Anyway, the game expects to take a certain time to draw each screen (for the bottom screen, it spans two frames). If the code runs too slow or too fast, it shits itself. Given how geometry is sent, GX timings don't affect this.
It doesn't have to be precise, but there's a window within which this has to fall, so we can't make it absurdly fast or absurdly slow and hope to fix it.
On the other hand, we have the Spellbound issue which I mentioned in the previous post. There, the code has to be running slow enough, I can't see any other way out. Both DMA and GX timings are correct there. I could always try dumping the display list and running it on hardware within the same conditions to see how it goes, but I'm sure the issue is with code timings.
So I guess this is it. No amount of hodgepodging timings will get us out of this, as I feared. And I really want to avoid 'solutions' like game-specific hacks or 'toggle this timing setting and see if it fixes your game'.
So, we have to emulate the ARM9 instruction cache.
On the plus side, since code fetches are mostly sequential, this shouldn't be a big performance penalty. The cache can be checked only upon branches and on cache line boundaries (on the DS, that is every 32 bytes). The ARM9 caches have 4-way associativity, which means a measly 4 cache lines to check before we know whether the current address is cached. So I believe we can afford to emulate it without killing performance.
The data cache would be the one killing performance; because data accesses are far less predictable, the cache would have to be checked upon every memory access. For now, it appears we can get away with not emulating it, so let's pray.
... read more
|3 comments (last by Ammako) | Post a comment|
Dec 24th 2018, by Arisotura
Much needed to avoid burnout these days.
Especially when it seems that all you're throwing at the wall is pointless. That sure deals a blow to motivation.
I picked one of the available Advanscene databases for savemem type detection, not knowing what all the available ones mean and what the differences are. Well, this one seems to be a Swiss cheese, full of errors and missing games.
If you have any ideas for a better database (like, what the fuck are the differences between all the Advanscene ones), I'd love to hear about it. Among the suggestions are that of using AKAIO's database, so I might look into that.
Also, a possibility to consider: detecting ROMs by game code rather than by CRC.
We're getting more timing renovation victims, and this time they're goddamn real. They all seem to be the same thing, missing/corrupted geometry. I don't know about all the games, but I looked into one of them (Spellbound), and it looks, well, not very good. The developers coded their own software version of GXFIFO DMA (the base idea is to transfer a fixed-size chunk of display list data every time the GXFIFO is less than half-full), which works by relying on the GXFIFO IRQ set to trigger when it's less than half-full.
However, the way this is coded expects that by the time a DMA transfer is finished, the GXFIFO will already be less than half-full, so the next chunk will be started immediately. Of course, there's a point in melonDS where that doesn't happen, causing the game to think the transfer has completed, and send a SWAP_BUFFERS command in the middle of the display list, which works as well as you'd expect.
Something's up with our timings. I hope we don't need to emulate the ARM9 caches.
And the goddamn input config dialog under Linux. I have no fucking idea why that would crash. I can't reproduce the crash. It's working just fine under my setup (Ubuntu 16.04). I can't even tell if we're just hitting some obscure GTK bug.
... read more
|7 comments (last by JamesBond@ge) | Post a comment|
Dec 16th 2018, by Arisotura
It appeared that, due to an oversight, melonDS 0.7.2 would crash when loading a ROM if the physical microphone init failed.
This has since been fixed, and a hotfix has been pushed. If you downloaded melonDS 0.7.2 before this post, just redownload it to get the fixed version.
|9 comments (last by Arisotura) | Post a comment|
Dec 16th 2018, by Arisotura
The melonDS company celebrates Christmas! Albeit one week early. But this new release of melonDS is a neat little pile of presents.
You have already gotten a glimpse of it, but let's go over all the changes since 0.7.1, because it's been a fast week.
So first of all, the issues we have seen pop up in NSMB, Pokémon, or Etrian Odyssey after the timing renovation, have been fixed. Nicely, the new timings uncovered some stealth GX bugs that would surely have bitten us another day under other circumstances.
So the claim that was made for 0.7.1 ("now your games run better than ever") is finally more than a phony advert :P
Second big thing is, as you probably guessed by now, microphone support. If your machine has a microphone connected and if you are using SDL 2.0.5 or more recent, you can blow or blare bullshit into it and it just works! If that is not the case, you can also opt to feed a WAV file or white noise as microphone input.
Note that this feature is still experimental. Quality of microphone input may not be optimal, especially when using a physical microphone. WAV input works better.
WAV and white noise modes send input when pressing a microphone hotkey (default is the key right next to right Shift, '?' on QWERTY keyboards). WAV mode can take any reasonably small file, encoded as 8-bit or 16-bit PCM, signed or unsigned, any number of channels (it will read the first channel).
All this can be configured in the new audio settings dialog, where you can also set the volume for audio output.
Which brings us to the new hotkey system. For now, aside from the aforementioned mic hotkey, there is only another one: 'Close/open lid', which simulates closing/opening the DS. Default key is Backspace.
... read more
|15 comments (last by Mauricio) | Post a comment|
I am fucking relieved
Dec 15th 2018, by Arisotura
You might already know that 0.7.1 sports all new timings and that it also causes a few issues that were not present in 0.7. Ranging from NSMB's cannons putting on some weight to Pokémon characters getting magical growth to, less amusingly, dual-screen 3D shitting itself in Etrian Odyssey.
The NSMB and Etrian Odyssey issues also had the fun aspect that they didn't occur in the USA ROMs, for some reason.
Well, that's a thing of the past now.
I knew the issues appeared after the timing renovation, but that was about it. I figured that instead of blindly hodgepodging timings until the issues disappeared, and potentially getting into some whack-a-mole game, I would take the time to understand the issues.
So the first one was the NSMB cannon.
Technically, the cannon body is a billboard (3D sprite that always faces the camera). The 'big' version is just the same but with the cannon body scaled too big.
So I investigate how the cannon body is rendered. For that, we can use NO$GBA's debugger version, atleast until melonDS gets similar tools :P
Conveniently, the cannon body is the first polygon in the display list. Before it gets rendered, there are some transforms set up so it will face the camera. In this case, the second-to-last scale transform sometimes got wrong values that caused the billboard to appear too big, hence the bug.
So I look into the game's code to find out where and how that scale transform is calculated. Noting that debugging NSMB is made way easy by the awesome folks at the NSMB Hacking Domain who have a complete IDA database of the game.
... read more
|5 comments (last by extherian) | Post a comment|
Dec 14th 2018, by Arisotura
New feature of melonDS 0.7.2, among a nice little pile of other features and fixes:
I'll let you guess ;)
|7 comments (last by Arisotura) | Post a comment|
melonDS on the Nintendo Switch
Dec 13th 2018, by Hydr8gon
In case you didn't know, melonDS has a port for the Switch. And it's made by me!
It's actually been around for a while now, but just today I put out an update with a major UI overhaul. As in, it actually has a UI now.
For the longest time the port was just text-based, with few options and it ran like crap. I just did it for fun, and because melonDS was surprisingly easy to port. A couple weeks ago we gained the ability to overclock the Switch, and this let melonDS actually reach playable framerates for a few games!
Normally overclocking is scary, but not so much on the Switch. The Switch rocks an Nvidia Tegra X1, the same processor used in the Nvidia Shield TV. Maybe to save battery life, or maybe to prevent overheating, the Switch runs at about half the clock speed of the Shield by default. Since melonDS isn't GPU intensive at all, the cooling of the Switch is plenty good enough to handle the higher clock speed on its own for emulation.
So now that that's a thing, melonDS on Switch seems to be more than just a novelty. It seems like it could actually become a usable NDS emulator! Unfortunately the UI is still shit. So I built a UI with OpenGL that resembles the UI of the Switch itself.
It's not much, but it gets the job done. On top of that I added all of the screen layouts available in desktop melonDS for some extra fun. Aside from a few minor things, melonDS for Switch is now at feature-parity with core melonDS, and it doesn't look terrible, either.
So what's in store for this project?
Well, since the UI is more or less finished, the plan from here on is to keep the Switch version up-to-date with core melonDS. Once the hardware renderer comes along in 0.8, it'll likely be able to run most, if not all, games at full speed. I'd also love to help StapleButter out with the core project, although my expertise in writing actual emulation code is extremely limited.
... read more
|9 comments (last by poudink) | Post a comment|