|Home | Downloads | Screenshots | Forums | Source code | RSS|
Full steam ahead!
Feb 21st 2019, by Arisotura
You might have noticed the beginning of another coding streak. Is an awesome feature being coded? You'd be right.
One of the main reasons why coding is going at this weird pace, besides the recent surge in local political activity and moving to a betterer apartment, is, well, how I achieve work. Whenever big-ish changes are required (designing something new, redesigning something...), I need time to think about it, and sometimes just do something else entirely for a long while. Until I go 'fuck it' and just code the damn thing.
So, I started coding the damn thing.
The "bind socket to any address" setting for local wifi has been moved to this spanking new wifi settings dialog.
There's also the new UI for setting up online mode, so you can, you know, pick a network adapter, etc.
That's why it took a while btw. It displays adapter information such as MAC, IP, DNS servers, which aren't provided by stock libpcap. So I had to use the Win32 API to retrieve those (and I have yet to code the Linux equivalent). We also get more meaningful adapter names this way, instead of having them all be named 'Microsoft'.
Then, there is the 'direct mode' thingablarg. What's that for?
Direct mode is basically the old way of forwarding network traffic: directly passing packets from/to libpcap. While this is the most straightforward and less likely to shit itself, it has the downside that it requires an ethernet connection. Reason is that under this mode, melonDS is seen as an entirely separate device on the network, with its own MAC address and all. On an ethernet connection, you can just use promiscuous mode to retrieve the packets sent to melonDS. But wifi is a different affair. Devices need to be associated to the access point. As that isn't the case for melonDS, its packets are just thrown away.
To work around this issue, not-direct mode is being developed. The idea is to do DHCP/NAT inside the emulator. melonDS would be in a little subnet along with its access point melonAP and its miniature DHCP server, and a bridge to the actual network. This way, packets sent to melonDS would bear the MAC address of your computer instead of that of melonDS, and wifi access points wouldn't throw a fit.
Hoping I can get this to work. But first, I have to finish fixing up the water heater.
|4 comments (last by SkalFate) | Post a comment|
Jan 26th 2019, by Arisotura
A little update on the plans for upcoming melonDS versions.
Things have slowed down a bit since 0.7.3. I wanted to address some of the newer timing issues, but there's bigger trouble arising from this, I'll get to it.
Also, attempting to get things done(tm) in real life, which is another reason why it's slowing down.
Regardless, we're still alive and kicking.
For melonDS 0.7.4, I want to fix some interface issues, and finally add some interface for setting up online-mode wifi. There might be other fixes, but that release will hardly be a revolution.
0.8 will be, as promised, the hardware renderer and upscaling. I don't want to delay this any further, so instead I'm going to delay what will come next.
For 0.9, or something like that. We're running into timing issues that can't be addressed by simply tweaking our timing values for cached memory. Not without breaking other games. I am reluctant to using per-game hacks.
So, the last line before the dreaded "per-game hacks or full ARM9 cache emulation" situation: perfecting CPU timings. The current CPU timings are imperfect, making things run faster than their hardware counterpart, especially on the ARM9 side. The ARM9 is complex so working out its complete timings will take a while.
Also, there's been some changes to this site, and we're not done :)
|20 comments (last by A dragon) | Post a comment|
Jan 5th 2019, by Arisotura
After another round of fixoring, we present you melonDS 0.7.3. So, what are the changes in this version? Mostly addressing the issues that popped up in 0.7.1/0.7.2, and improving the interface a bit.
Something that should have been done long ago, and has finally been done: the emulator's main loop was rewritten to use absolute timestamps to keep track of cycle counts. Overall, it's more reliable (far less chances of desyncs), more accurate, and also a bit faster, and the code is cleaner. So we win on all fronts.
This should fix the recent flickering issues, like that of Colour Cross.
The downside is that this breaks savestate compatibility with older melonDS versions.
In the same vein, there's another fix to GX timings. We knew that vertex timings were different when a vertex completed a polygon, but we just found out that timings also differ based on whether the polygon passes culling and clipping. This will help with games that need their display lists to be running fast enough.
To hopefully fix the saving issues, we built a new database, resulting of a mix between the Advanscene XML and savelist.bin from the R4 Wood firmware. For better detection, the new romlist.bin indexes games by their serial code rather than by the ROM's CRC32, which also means that it will work with hacked ROMs. This means you will need to make sure to replace romlist.bin with the newer one if you're extracting this melonDS release over an older one.
There's also a particular fix for Pokémon Mystery Dungeon - Explorers of Sky, which uses 128K EEPROM. It should now save properly.
However, note that the correct savefile size for this game is 128KB. If you have a savefile which is 256KB, the game will read it fine but fail to save to it (because that size is detected as FLASH memory and not EEPROM). You can fix this by opening your savefile in a hex editor and deleting the upper half of it. This is especially important if you use a savefile coming from DeSmuME as it will create a 256KB file.
We also have a neat little pile of UI improvements.
melonDS now supports hotplugging joysticks. That being said, it still defaults to the first joystick available on your system. I'm not quite sure how to go about handling multiple joysticks.
Under Linux, the crashes coming from the input config dialog should be fixed.
The main window is smarter about remembering its size: it also remembers whether it was maximized.
There's a tentative fix for hiDPI under Windows, which should atleast make the screens scale correctly.
There's a new menu for setting the window size to an integer scaling factor (1x to 4x).
The setting for savefile relocation when using savestates is now disabled by default. While the feature may be useful, having it enabled by default was confusing for unaware users.
And finally, the misc fixes:
* fix STRD_POST (fixes music in Just Sing - Vol 2)
* 2D: fix blending bugs
* add support for 8bit reads to DISPCNT/BGxCNT (fixes The Wild West)
* make nocashprint also work in ARM mode
melonDS 0.7.3, Windows 64-bit
melonDS 0.7.3, Linux 64-bit
melonDS Patreon if you're feeling generous
|16 comments (last by MelonMan) | Post a comment|
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!
I'm contemplating running a sorta-buildbot on blargcity (the server), like we had for lolSNES. Looking at MinGW and how we can use it to produce 64-bit Windows and Linux builds.
Might even produce 32-bit builds if it's any worth doing. Noting that it wouldn't run on Windows XP as it is, libui uses several APIs that were introduced in Vista.
One fear I have over that is that having a buildbot might kill incentive to do proper releases. Kind of what happened with lolSNES.
|4 comments (last by extherian) | 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.
For less performant devices, we could always have a 'performance' profile that uses the old timing model (2 cycles per code fetch in cached memory, always). It's less exact and more likely to break something else, but it seems to run most things reasonably well, so it's a good candidate for a performance/accuracy compromise.
I still have to look into Spellbound, because of course making code fetches taking 2c doesn't fix it. It needs to be atleast 5c to work correctly, but 5c breaks other things, no surprise there.
Quick testing confirms what I suspected there, it only ran correctly in older melonDS versions because the GXFIFO DMA was too slow, taking 3c per word. On hardware, transferring from main RAM to IO registers (GXFIFO or whatever else) takes 2c per word, which is also the case in melonDS after the timing renovation. So, well, we can't take it back.
(the difference looks puny, but when transferring hundreds of units, it quickly adds up)
In brighter news, well, 0.7.3 will come out soon-ish, once I come up with something for the ARM9 code cache.
There are also a few improvements making it more user-friendly. For example, I made savemem relocation when loading savestates disabled by default, as I figure that having it enabled by default can be confusing.
We're also trying to fix the input config dialog crashes under Linux. I wasn't able to reproduce them because I wasn't looking at the right place: they happen when mapping joystick buttons, and taking that into consideration, I reproduced it, and could fix it. It was quite silly, reason is that we use a SDL timer callback to sense joystick input, and were updating the UI directly from that timer callback. Forgetting that GTK is not thread-safe and the UI shouldn't be manipulated outside of the UI thread, even after I ran into similar issues with the main window. Using uiQueueMain() lets us get around this and fixes the crash.
I'm still not 100% sure there though, there was a crash under FreeBSD that appeared to be different.
There's also a little improvement to joystick input, it can detect if the joystick is disconnected/reconnected while melonDS is running.
It's still limited to one joystick though, I'm not quite sure how to go about handling multiple joysticks and whether we can trust the OS not to go and change their indexes.
I also want to work on network support, adding the interface selector and built-in DHCP/NAT, but maybe for 0.7.4. I already have enough on my plate here, and that's without getting into the 0.8 hardware renderer.
|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.
and merry Christmas to you reader.
|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.
Oh and the hotkey system is an extension of the regular input system, which means you can also assign joystick buttons to these hotkeys.
Speaking of the input system, Windows users may have noticed that the input config dialog was abysmally slow, taking several seconds to open and generally feeling quite laggy. With a quick little fix in libui, that is no more, and the dialog now feels a lot more normal.
Some attempt was made at fixing possible crashes with that dialog under Linux, but those crashes may need more investigation. In my current setup (Ubuntu 16.04), I am unable to reproduce them, or break the input config dialog in any way. I don't know which are caused by melonDS and which are obscure GTK bugs. While one of the stack traces that were reported showed something I could easily work around, the other pointed at some obscure bug where some function internal to GTK is getting a NULL value and crashing.
On a whim, I added support for nocash-style debug print, which enables homebrew to print to the emulator's console. Also, Windows users don't need to get a debug build to get console output -- running the release version of melonDS from cmd will dump the console output there.
We also have some welcome contributions from some fine Github comrades:
* FPS limiter toggle, courtesy abcdjdj
* flatpak manifest, by cpba
* Linux libpcap library names added to the libpcap loader by dogtopus
* and finally Aqueminivan renovating the readme, it looks cool now!
And, last but not least, a whole bunch of misc bugs were fixed:
* black screens in Puzzler World 2
* American Girl - Kit Mystery Challenge! screeching garbage audio in the house
* blending fail in Pokémon Mystery Dungeon - Explorers of Sky
* lack of background music in Club Penguin: Herbert's Revenge
* a few wrong entries in romlist.bin were corrected
* config dialogs could be opened multiple times
melonDS 0.7.2, Windows 64-bit
melonDS 0.7.2, Linux 64-bit
melonDS Patreon if you're feeling generous
|15 comments (last by Mauricio) | Post a comment|