By the way, the dumps should now be correct- there was a bug in the previous dumper, where some of augmented bits were read from wrong addresses, although these particular bits don't seem to be important. This dumper is also a tad smarter: it will warn you if the data required for proper augmented BIOS dumps has been altered. It is now able to dump all the files you need for DSi emulation: NAND, DS-mode firmware, BIOSes. I have been updating the DSi BIOS dumper, to hopefully make DSi mode more accessible. The other team members are also working on cool things, even if they might not be as talkative as me.ġ4 comments (last by ApacheMan) | Post a comment There will also be some additions, like proper HTTPS.įinally, happy birthday Generic! The melonDS HQ will bring you your melon-cake tonight.Įven if I'm not posting here, you can follow me on Twitter for smaller melonDS updates (but also a lot of other bullshit). I will keep you informed about this, as there will be a downtime whenever I get round to migrating everything to the new server. More modern, better specs, more secure, all you want. Next, I'm setting up a new server that will eventually replace the server Kuribo64 runs on.
I'm not going to go over these things in public. It's a mix of your typical winter depression and other things, family-related. I hoped to deliver a release around Christmas, but, seeing how things are going, it may not happen.įirst of all, I'm having a rough time these days. And as of now, melonDS has no provision for ejecting the current cart, nor for loading a new cart without resetting emulation.ġ0 comments (last by branchus) | Post a comment So it's something we need to take in account too. However, things are different with the DSi: for example, you can insert and eject carts while in the DSi menu and it detects that. On the DS, you can't hotswap cartridges, because there's no hardware support for it, so we didn't have to account for this possibility. A tad redundant.Īnother fun thing is DSi support. So this means a second NDSCart::LoadROM() function was added, that loads a ROM from a memory buffer. In this case, the ROM isn't accessible as a regular file, instead we get a memory buffer with the ROM's contents.
Of course, as melonDS evolved, other concerns arose.įor example, archive support was added. So the original NDSCart::LoadROM() function did just that. When I first built the melonDS core, it was pretty simple, and all it had to do was load a ROM from a given file, load the associated save file, and start emulating. I mean, it certainly could be worse, but some parts could definitely use a refactor. The state of the melonDS codebase doesn't help, either, sometimes. I had tried to make plans of what I wanted for the custom paths feature, but, surprise, the actual implementation is going to be different. This is also why it can be difficult for me to get things done: I will try to envision the scope of the task at hand, then begin seeing related things that need to be done, more or less drifting away from the original task, and at the end I have too many ideas and I don't know where to start.
As of now, melonDS takes the easy route and dumps these files alongside the current ROM, but not everybody wants that.Īnd, well, implementing this whole thing raises a bunch of issues. It's been a popular request for a while: customizable paths for things like save files, savestates. You might have seen that pic I posted on Twitter a while back: If you're running into trouble: Howto/FAQ (WIP) Wifi: local multiplayer, online connectivity.Various display position/sizing/rotation modes.Nearly complete core (CPU, video, audio.While it is still a work in progress, it has a pretty solid set of features: MelonDS aims at providing fast and accurate Nintendo DS emulation.