melonDS RSS http://melonds.kuribo64.net The latest news on melonDS. 2D accuracy: it's a rabbit hole too -- by Arisotura http://melonds.kuribo64.net/comments.php?id=102 Sat, 14 Sep 2019 19:01:18 +0000
Anyway, mosaic is a typical feature of old consoles with 2D engines, including the DS. It basically applies a pixelation effect to graphics, as shown here:



The basic idea is that the screen is split in a grid, whose dimensions are variable (configured by register 0x0400x04C on the DS). For each 'cell' in the grid, all the pixels are colored the same as the first (top-left) pixel. In reality, it's a bit more complex, as on the DS the effect can be applied per-layer and per-sprite, and you can even specify different grid sizes for BG layers and sprites, but fundamentally it's more or less the same thing, it pixelates shit.

Sounds simple enough, right?

It's a bit tricky to implement when you're trying to write a performant renderer, though. Which is more or less why blargSNES never supported it.

As far as melonDS is concerned, mosaic was implemented in version 0.5, but (among other silly bugs) it never worked quite right as far as sprites were concerned, especially when those use rotation/scaling. But, at the time, I didn't do much past the original implementation, mostly because I don't know of a lot of games that use the mosaic effect. The lack of test cases meant it stayed supbar.

Until, well, now.

First thing to do is to write some test cases for sprite mosaic. BG mosaic seems quite simple, even though I would still have to probe it extensively for edge cases, but sprite mosaic is a bit more oddball, as seen here:






Those snapshots were taken from Grey, my capture-card DS. This isn't some weird buggy emulator, sprite mosaic really is that weird.

The sprite being mosaic'd is a simple ball sprite. The cyan sprite behind doesn't have mosaic applied to it, but both share the same size and rotscale parameters. The sprites on the left have double-size mode enabled, which merely doubles the bounding box of rotscaled sprites.

I have yet to work out all the oddities, but, from what I have observed, it seems that sprite mosaic doesn't work as we thought. If vertical mosaic is simply done by adjusting the source Y coordinate when rendering BG layers or sprites, horizontal mosaic is a different topic. As far as sprites are concerned:

* horizontal mosaic is restrained to the sprite's bounding box (vertical mosaic is too, but only in one direction)
* seeing how it is affected by the presence of neighbor sprites, horizontal mosaic seems to be applied after all the sprites are rendered
* it seems to keep track of which pixels belong to each sprite, even when said pixels are transparent


As of now, none of the existing DS emulators get sprite mosaic right. Probably, none of the GBA emulators get it right either, since the GBA uses a similar renderer, and it doesn't look like anybody has ever figured out the mystery of sprite mosaic.


I wanted to be able to check my mosaic implementation against hardware for correctness in many situations, to make sure I'd gotten the logic right. But constantly dumping frames from Grey and hand-comparing them against melonDS would be tedious. I wanted to have a better tool.

So, I set to work. I opened ds_capture.exe in IDA, opened up the Linux DS-capture code example and WinUSB documentation, and set to work. And, in one evening, MelonCap was born.



This is pretty simple. Left screen is the output from melonDS, middle is what is captured from Grey, right is a color-coded visualization of the differences.

The precision isn't exactly optimal though: melonDS outputs RGB666 color, like the DS does, but the capture card degrades it to RGB565 due to technical constraints. Well, this is atleast better than RGB555.

This is pretty much made for graphical testing in specific use cases, as there's no synchronization mechanism, one has to ensure that both melonDS and the DS are rendering the same things.

Anyway, the example in the screenshot above shows something interesting. There's been all that effort put towards pixel-perfect 3D, but our 2D engine isn't pixel-perfect (neither is the 3D one, but... yeah). We figured pixel perfection with the 2D engine would be a given, and, yet... here we are.

The bottom screen has BLDCNT configured so that all layers/sprites will be dimmed, with BLDY=1. This is hardly noticeable, and is likely an oversight. However, the colors generated by melonDS in this situation don't quite match hardware output.

The function for the brightness-down effect is described by GBAtek as:

out = in - ((in * EVY) / 16);

However, a quick hardware test tends to show that the actual function is:

out = in - (((in * EVY) + 7) / 16);

There's probably more of this shit everywhere, so the 2D engine will have to be heavily tested for accuracy. Fun shit ahead.]]>
http://melonds.kuribo64.net/comments.php?id=102
melonDS 0.8.3 -- by Arisotura http://melonds.kuribo64.net/comments.php?id=101 Wed, 04 Sep 2019 15:20:40 +0000

So what does this release bring? Well, we have been trying to address the issues present in previous 0.8.x releases (or sometimes even older releases, heh).


For example, I fixed the bug that was introduced with the new support for Ctrl+K type hotkeys. Basically, using Shift/Ctrl/etc as regular keys mapped to buttons was no longer possible. So, support for key mappings with modifiers was restricted to hotkeys. Meaning that using right Shift as R (as done by the default key mapping) should no longer cause input problems.


I have been trying to fix the issues we had with the framerate limiter and audio output, too, with moderate success. As I haven't been able to come up with a one-size-fits-all fix, there are now three different sync modes you can use, individually or together:

* Limit framerate: the oldschool framerate limiter. Although this is a revamped version that tries to average over several frames, reducing the likelihood of limiting too aggressively on certain games that internally run at 30FPS and are otherwise able to run fullspeed.

* Audio sync: synchronizes emulation to the audio output system. Seems to result in a bit more fluctuation in the framerate, but should prevent any audio stuttering.

* VSync (in the video settings dialog): synchronizes video output to your monitor's refresh rate. This only works with OpenGL, and currently only works under Windows (OpenGL support under Linux still needs more love). Also, DS games/programs may alter their framerate by messing with VCount, which VSync would be ill-equipped to deal with (unlike the two other sync methods).

I think most of the audio issues came from not properly syncing, which resulted in semi-regular overflows or underflows in the SPU FIFO, causing stuttering. The current audio output system cannot be precise enough to prevent those, as it works with small audio frames.

Speaking of which, I have also been revising it to use a more standard output frequency, in case some bad audio driver doesn't appreciate the previous frequency of 47340Hz. Now, it will attempt to run at 48000Hz, but it also allows SDL to specify another frequency if needed.


There are also a few other fixes that were long due (like OpenGL initialization failing under OpenGL <4.2), and some accuracy improvements, as usual.


As promised, beta builds of the JIT and DSi branches are coming soon, so stay tuned! Those will be based off older melonDS versions (0.8.2 and 0.8.1 respectively), though.


Enjoy!


melonDS 0.8.3, Windows 64-bit
melonDS 0.8.3, Linux 64-bit

If you're feeling generous: here's our Patreon]]>
http://melonds.kuribo64.net/comments.php?id=101
We're alive -- by Arisotura http://melonds.kuribo64.net/comments.php?id=100 Fri, 23 Aug 2019 13:21:03 +0000

Also, on the DSi front:

I'm also unsure what to do. there are BIOS dumps out there that have been filled as much as possible, by dumping the lower half and adding back the known parts of the upper half that can be sourced from elsewhere, as seen there: http://problemkaputt.de/gbatek.htm#biosdumping . NO$GBA expects these particular dumps. I might want to adopt that method too, but I'm afraid such dumps are less complete than dsikeys.bin/initmem7.bin/initmem9.bin.

Opinions on this are welcome. I'll need to check how much of the AES keys is sourced from the BIOS, vs how much is needed to run shit like the DSi firmware.

For reference: dsikeys.bin contains all the AES keys, as extracted from the AES engine after an unlaunch boot. initmem7.bin and initmem9.bin are chunks of ARM7 WRAM and ARM9 ITCM that contain keys (RSA, Blowfish) and other shit needed for initialization, those are mostly (but not entirely) sourced from the BIOS.


On other fronts, all sorts of exciting things are being developed for melonDS! Those who follow repo activity may have noted that DLDI support is being worked on. Stay tuned!


Edit- comments about how "I don't give a shit about DSi emulation!! Work on the features I want!!" or "nobody cares about DSi" or whatever, are getting on my nerves. There are very good reasons to work on DSi emulation, so I swear that if this shit continues I'll be deleting comments and handing out bans.]]>
http://melonds.kuribo64.net/comments.php?id=100
Progress on the DSi front -- by Arisotura http://melonds.kuribo64.net/comments.php?id=99 Sun, 04 Aug 2019 00:09:35 +0000
So instead, I did what I typically do in these situations: procrastinate and work on something else.

In this case, the DSi front.

If you remember, this was at a point where it needed wifi initialization to be able to launch titles. I was stuck at a particular point of the init procedure, where it waited for something and I had trouble figuring out what. But, regardless, I set to work.

In the meantime, googling some of the strings present in the firmware's wifi code brought me to this Atheros driver codebase which is very close to what the firmware uses. This helped me a lot in figuring out how things work and what the firmware was expecting.

And, well...

melonDSi config melonDSi flipnote

It's possible to boot shit from the firmware now!

Couple issues with this though.

* the system settings app boots, but it's impossible to get further due to the lack of touchscreen support
* Flipnote boots but freezes when starting a new flipnote
* pure DS-mode games seem to be bootable, DSi-enhanced games are not

Also, some DS-mode games suffer from audio issues for whatever reason. Well, it's worth noting that atm melonDSi does not support dynamic ARM9 clock adjustment, so DS games are basically running in forced DSi mode.

Well, we're getting there, I guess.]]>
http://melonds.kuribo64.net/comments.php?id=99
The JIT -- by Arisotura http://melonds.kuribo64.net/comments.php?id=98 Sun, 21 Jul 2019 15:11:00 +0000
I meant to fix a few of the issues we had lurking around, so we could release 0.8.3. I managed to fix some issues that caused random crashes on exit, then began trying to fix the framerate limiter. Thing is, it is directly related to the audio output code and the issues that has. So, yeah, I still haven't found a solution to that tricky problem.

I also need to struggle to keep some motivation at times. Looking at the patterns in how I work, it is likely that I have ADHD. I have yet to get diagnosed and all, but this wouldn't surprise me.

Anyway!

As you may have noticed, Github user RSDuck sent a pull request for the JIT recompiler. This is a bit of a tricky situation though. I don't want to have to deal with a situation where people make third-party JIT builds, but at the same time, the JIT isn't quite ready for general use, as we're still ironing out various issues with it.

However, the JIT is said to give a performance boost ranging from 30% to 100%, which is fairly nice, especially as there's room for improvement. RSDuck also said that porting the JIT to other architectures, like ARM, should be easy, so we might finally have Switch builds that run at acceptable speeds.

Or, also, Android builds. But, dunno. On one hand, this is a market I want to address, but on the other hand, history from Dolphin has shown that the Android userbase isn't exactly the nicest to deal with, so... yeah. And don't get me started on Android itself and the fun that coding for it is.


But first, let's focus on what we have in front of ourselves.


I'm going to try as hard as I can to fix the audio issues for 0.8.3 (and also add a vsync setting).

We will also be releasing beta builds of the JIT and the DSi branch, for those of you who want to mess around with things.]]>
http://melonds.kuribo64.net/comments.php?id=98
welp. -- by Arisotura http://melonds.kuribo64.net/comments.php?id=97 Sat, 06 Jul 2019 14:31:06 +0000
It will require some amount of wifi support to be able to launch titles. The amount required makes the 0.2 wifi stub look tiny in comparison. Basically the DSi menu tries to communicate with the wifi CPU thing and upload firmware to it.

We can either HLE it given sufficient documentation (and have to deal with ass-shitting high-level wifi concepts) or LLE the damn thing.

We'll see.]]>
http://melonds.kuribo64.net/comments.php?id=97
the heat -- by Arisotura http://melonds.kuribo64.net/comments.php?id=96 Mon, 01 Jul 2019 16:49:00 +0000
..

Let's just say it's a bit hard to be productive when your outside temperature is a scorching, capitalism-induced 43°C.

It's back to more reasonable temperatures now, but regardless, we don't do much besides bathing at the beach or at the nearby river.

I kind of need to take a break at this point though. Like, there are many things I want to do with melonDS, but I have too much ideas, and there's only so much I can do at once.

I will need to release a quick-fix 0.8.3 though. Atleast to fix the bug I introduced when adding support for 'Ctrl+M' type keys'. Basically you can't press any key while keeping R pressed if you keep the default mapping (right Shift).

I also want to try and fix the framerate limiter, which, askskfdksgsf.

On the DSi side, there will be some alpha builds of melonDSi once I finish the DSi dumper. Right now, the dumper is able to extract AES keys from the AES engine. The rest will be a breeze: dumping the BIOSes, the memory holding RSA/Blowfish keys, the NAND, the eMMC CID and console ID. It's mostly just matter of copying memory to a file, except the NAND is going to be a bit more involved, but nothing insurmontable.

I gave melonDSi a small pause, because I got stuck on AES-CCM (needs hardware tests) and also didn't want to let the master branch rot. Right now, it's not in a very interesting state -- all it does is boot the DSi menu, but it's still not getting further. And also because I keep fixating on the lack of full DSi bootroms. I'm even considering getting in touch with someone who is doing the hardware haxing required to dump them, or attempting to do it myself.

melonDSi will eventually be merged into regular melonDS when it's ready. You can think of it like medusa vs mgba.

I'm also trying to optimize melonDS. I have several targets in mind, but we'll see. The plan is to get it to run on less powerful platforms, like the Switch, or Android.

Speaking of this, user RSDuck is working on a JIT. The first iteration will be for x64, but he said it will be easy to port it to other architectures. If we can get this going without sacrificing too much accuracy, it will be a great help on the performance front.]]>
http://melonds.kuribo64.net/comments.php?id=96
melonDS 0.8.2 -- by Arisotura http://melonds.kuribo64.net/comments.php?id=95 Tue, 25 Jun 2019 18:17:40 +0000

Namely, there have been some fixes to the OpenGL renderer. If you were one of those for whom it did not work, we hope that now it will work. There are still issues with it, but we will eventually find them and fix them all.

I also undid a quick hack I did in 0.8.1 to try fixing texture alignment problems, that in the end caused more issues than it fixed. This problem will need a cleverer solution. It basically stems from the fact that the DS rasterizer works differently from OpenGL: it has no subpixel precision, and calculates color/texcoord for exact pixel positions, where OpenGL calculates them for a position that is +(0.5,0.5) inside the pixel.

I also hope to improve the GL renderer some more. In mind are: texture cache, texture upscaling/filtering, applying filtering to the 2D layer, doing something for dual-screen 3D...


We fixed a bug with the 'map joystick button and axis' feature of 0.8.1, where, if you mapped an axis control alone, it would also map 'button 1' alongside it.


melonDS now explicitly disables VSync when using OpenGL, atleast under Windows.


We also fixed a bunch of issues, potential crashes, etc...


... and changed kMaxIterationCycles from 16 to 64. That constant controls how many maximum cycles the ARM9 can run before control is given to the ARM7 and other system components. This change might affect accuracy negatively (it is worth noting that melonDS has several provisions for on-demand sync, bypassing kMaxIterationCycles) but has been found to give a small speed boost.


We're also using Github releases now. I'll add the builds to the Github page (and to the downloads page on this site) soon :)


Enjoy!


melonDS 0.8.2, Windows 64-bit
melonDS 0.8.2, Linux 64-bit

If you're feeling generous, if you want to help us take this OpenGL renderer further: here's our Patreon]]>
http://melonds.kuribo64.net/comments.php?id=95
melonDSi??? -- by Arisotura http://melonds.kuribo64.net/comments.php?id=94 Thu, 20 Jun 2019 01:59:33 +0000
[DSi shito]

It doesn't get further than this though, but, considering the amount of work this required, between implementing the newfangled DSi hardware and fixing stupid bugs, this isn't a bad start. We can also thank Martin Korth and all the other comrades who have been paving the way and making this possible at all.

This is nowhere near ready for a release tho. It's an experimental branch in which I felt like playing around with things, attempting to boot a DSi firmware, and, well, this happened.

This also requires a bunch of data that have to be dumped from a DSi:

* NAND dump
* eMMC CID
* console ID
* RSA/Blowfish/AES keys

Those can be dumped from a DSi with unlaunch, but we will need a user-friendly way to do so.

--

There is also the issue that, well, this isn't completely clean and perfect.

When booting the DS firmware, we just load the ARM9 and ARM7 BIOSes, point the emulated CPUs to the reset vectors, and let it do all the work, just like how an actual DS would do. That way, we avoid any issues caused by incomplete memory/register setup when running a game, because the original boot ROM and firmware are taking care of everything. We also have a good reference for perfecting our direct boot implementation.

However, with the DSi, there's an issue: so far, we have only been able to dump the lower 32K of the 64K BIOSes. This is problematic as the first thing the reset vector does is jump to the upper half of the ROM. Then, said upper half is permanently locked right before jumping to the next bootloader stage (boot2), meaning that even if you somehow ran a completely custom boot2, you couldn't dump the upper halves of the BIOSes by software. The only way would be via hardware glitching attacks, or maybe by haxing a 3DS if it happens to have the full DSi BIOSes (noting that, ironically, the 3DS BIOSes were able to be dumped by software).

This means we run into issues like "decryption of X failed because the key is missing". We can work around them, but it's not as clean as starting from square one.

Oh well.]]>
http://melonds.kuribo64.net/comments.php?id=94
melonDS 0.8.1 -- by Arisotura http://melonds.kuribo64.net/comments.php?id=93 Wed, 12 Jun 2019 13:06:03 +0000
Edit- If fast forward doesn't work for you, it means one of two things: you're using OpenGL and your video driver is forcing vsync, or melonDS is just not running fast enough for fast-forward.




Input upgrade

The input code has been reworked to be more pleasant to deal with, especially with regards to adding hotkeys. In less nerdy terms, what does this mean?

It is now possible to map keys with modifiers, like Ctrl+Z or Shift+R or even combinations like Ctrl+Alt+Q. It is worth noting that during mapping, you should use left-hand Ctrl/Alt/Shift keys for these mappings. However, ingame, both sets of keys should work. This feature may not be too useful for DS input, but it should be more handy for hotkeys. It is also possible to delete a key mapping by pressing the Backspace key during the mapping process.

I have also been upgrading joystick support. You can now choose which joystick to use, and can map axes to buttons/hotkeys.

The twist to this is that I liked the old "axis maps to DS dpad" feature, and how it could be used alongside regular button/hat controls. I didn't want to lose the ability to use both, but I also wanted to make it, well, not a hardcoded mapping. So instead, you can map both a button/hat direction and an axis to each control. When mapping a joystick control, pressing a button/hat direction keeps the axis mapping intact, and vice-versa. You can delete both mappings by pressing Backspace during the mapping process.

The aforementioned axis support should also be able to support analog triggers, which are typically exposed as axis controls.

I also added support for multiple hat controls.


OSD

This new, optional feature shows some short, temporary status messages onscreen. For example, when loading or saving savestates, pausing, resuming...

The idea is to give some visual feedback about these operations, rather than, say, have savestate loads just appear to do nothing because the slot is empty.

You can disable the OSD if you find it to get in the way.


New hotkeys

You might remember that some early melonDS versions had a secret hardcoded fast-forward hotkey. This seems to have appeared in version 0.3, but eventually disappeared with the UI revamp in version 0.5.

Well, now, with Ace4896's contribution, this feature is back with a proper hotkey mapping. There is also a 'toggle' hotkey that enables or disables the framerate limiter.

I also added hotkeys for pausing and resetting emulation.


OpenGL fixes

Several of the crashes and rendering errors that appeared in 0.8, stemming from the new OpenGL support, have been fixed in this version.

I also added a little hack to support line triangles in OpenGL, and a preliminary implementation of edge marking, which you can see demonstrated in one of the screenshots above.


There's also a bunch of little fixes and optimizations, as usual. Enjoy!


melonDS 0.8.1, Windows 64-bit
melonDS 0.8.1, Linux 64-bit

If you're feeling generous, if you want to help us take this OpenGL renderer further: here's our Patreon]]>
http://melonds.kuribo64.net/comments.php?id=93