melonDS 0.7 -- Granting popular wishes
Or atleast starting to do so. There isn't a lot in this release, but hey, we have to start somewhere.

Atleast, The Spark is back, somewhat. So I guess we can take melonDS somewhere.


Not a lot of novelty visually speaking, so there will only be one screenshot:



Nothing changed! :D

Except, if you look closely, the bottom border of the blue platform thing.

Couldn't resist.

Fixed a small bug regarding shadows and antialiasing, that caused that.


What else? Miscellaneous fixes. melonDS shouldn't crash randomly when closing it anymore. And other things.


Oh, and savestates. Which were one of the popular demands, and which are finally brought to you.

Here is the outline of our implementation:

• 8 savestate slots, which are per-game. Savestate files are stored in the same place as save files.
• 'Undo state load' will revert to the state from right before loading a savestate. For example, if you loaded it accidentally.
• In savestate settings: 'Separate savefiles' allows saving to a separate save file after loading a savestate. The separate save file is bound to that savestate slot.
• Shift-Fx to save state, Fx to load state. x = 1 to 8 for regular slots, 9 for using an arbitrary file. F12 to undo the latest state load.


Have fun!


Windows 64-bit
Linux 64-bit

melonDS Patreon
Coming soooooooon!
The savestates feature is finished! Not saying much more though, the details are a surprise ;)

Other than there were other bugs like mentioned in the previous post that bit me, but eh, that's all over now.

There are a few issues to iron out regarding menus under GTK, though, so it'll take a little while.

But it's coming soon!
When your innocuous little code goes kaboom
So until we get something amazing to release, we're going to post some technical shito again.


As said in the previous post, I've been coding savestates. The base idea seems simple enough, just throw all the emulator's state into a file (or read it from that file if you were loading a state), make extra sure that you're not missing anything important, regenerating things that need it when loading, etc...


So I first designed the bases of the implementation:

• A savestate file is divided in several sections. Those can be ordered arbitrarily. The file format itself is very simple.

• To reduce complexity, we only handle loading/saving between frames.

• Some questions are still not clear, and I still need a way to avoid loading a savestate over the wrong ROM. (or I could allow it as a fun Easter egg, even if it generally results in a crash)


Then, the gruelling work, storing all the emulator state.


Including, you guess, the event scheduler, which is an array of event structures with an entry per possible event source. Just write that to the savestate file, right?

Think again.

typedef struct
{
   void (*Func)(u32 param);
   s32 WaitCycles;
   u32 Param;

} SchedEvent;


This is the event structure. We have a handler for when the event fires, how many cycles remain before it fires, and a parameter that is passed to the handler. The idea is that we can use different handlers for one event source, acting sort of like a state machine, which is what is done in display emulation for example (HBlank, next scanline, frame end).

The handler is a function pointer. Which means that storing it as-is in a file is a bad idea. For various reasons, there is absolutely no guarantee that the functions those pointers refer to will be at the same addresses between two runs. In fact, it even seems completely impossible, because modern-day OSes will randomize the address at which the melonDS process is loaded. Then you have things like using savestates across different versions or even different builds...


Well, good thing I thought about that before trying to run that code.


(now I also realized that there are several other instances of dumping structure arrays straight to the file, namely in the 3D pipeline, which might cause compatibility issues between builds as compilers might decide to order the structures differently; that will have to be dealt with too)


So, what do we do now?


As I originally wanted to keep the evnt system fairly flexible, an idea I had was to store relative function pointers, ie basing them off of main()'s address or something like that. While this would work for making savestates reusable between runs, it wouldn't fix any of the other issues. For example, run a different melonDS build and the event functions may be at different places, meaning the relative pointers wouldn't point to them anymore.


So instead, the way I went with was to store the handlers as indexes.

The idea is to keep a table of event handlers. When saving, we lookup the table to convert each event entry's handler to an index. When loading, we do the conversion backwards. Et voila, no problem. There are a couple safety checks around it, for example, to prevent haxing via a bogus savestate file containing an event handler ID that is out of range.

The main disadvantage of this method is that any function that is to be used as an event handler needs to be added to the event handler table.

But atleast our savestates are portable. I guess we win.


That being said, if any of you folks has a better idea for this problem, I'd like to hear about it.
gettin' there
Apologies for not keeping this up to date lately.

Anyway, savestates are being coded, and we need your help to test them out. More about this in this reddit post.

Other than that, I tried some hax on my new green DSi. Was able to install unlaunch. I'm not yet able to run DSi homebrew though-- ndstool builds oldschool DS ROM headers, which causes unlaunch to load these ROMs in DS mode. I have yet to figure out how to make ndstool build DSi ROM headers.

On the real life side... I'm getting there. Depression is a bitch tho. And capitalism too. I would feel a lot better if that didn't exist.
the plaaaaaans: getting staaaaaarted
this is spaaaaaarta





Meet Green.

It's a big DSi. Pretty cool, eh?

Quick inspection reveals that everything is alright. It was factory-reset, tho, so it might not have Flipnote on it. But whatever, we'll find a way. actually it does still have Flipnote. All good!


Still no news of the other order. If you happen to remember, it was returned to sender, and the sender notified me about it and asked me what they should do. I gave them another address to ship to, and even offered to pay for the reship, but since then, silence.

I guess I'll have to give the seller a reminder. Or ask for a refund.


Regardless, I think we can get started with the interesting things... once I'm a bit more settled.
The 'timing' branch
In the meantime, I figured I'd give this a try.

Basic idea is that emulating timings with reasonable accuracy will require emulating the ARM9 caches.

I want to see if I can emulate those without completely killing performance. If I pull it off, there'll be several benefits:

* much more accurate timings, fixing games that do weird things
* homebrew developers using melonDS wouldn't fall into the typical 'forgot to flush/invalidate cache' pitfall that reveals itself when testing on hardware
* if we take it even further, we can emulate the MPU (memory protection unit), which means emulating crashes

I guess that if I manage to get it going, there will be a sorta beta release so I can get feedback about this, whether it's killing performance, etc...
Updates on the plaaaaaaans
The package was, surprise, returned to sender, because some idiot can't find a mailbox that is street-facing and not hidden or anything fancy. Hell, it's right next to the building's front gate.

Whatever.

I'm trying to see if I can have it shipped at another address which I know should work.

I ordered another one, too (that was before the seller for the first one contacted me about the package), but it won't be shipped until a week.


I guess it can't be a bad idea to get two consoles either way. Like, if one turns out to be less/not haxable, or if I need to do hardmods...
oh well
The plan was to receive the package and post a picture of the contents as a reveal, but obviously this is not going as planned. So I guess a shitty reveal is better than teasing people and letting them hang in the void forever.

So here it is.


The next direction for this is DSi emulation.


In the meantime, depending on how things go, I might do some work on GPU accuracy again, but for now I'm taking a few days of vacation.

Upscaling is also something I might try someday. I have some ideas for it, but we'll see.


See ya!
blarg.
Did the package arrive since then?

Of couuuuurse not.

I guess I'm in for another round of fighting the incompetent postal services. Yay.

The sender also didn't provide a tracking number so I have no idea what's going on. This is so fucking amazing.
Thank you all! :)
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 :)