Views: 84,113 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 09-25-17 03:48 AM
Guest:

Main - Posts by StapleButter

Pages: 1 2 3 4 5 6
StapleButter
Posted on 03-29-17 05:46 PM, in Welcome to the melonDS board! Link | #1
This board will serve to post release announcements for melonDS, but also discuss all sorts of matters related to melonDS development, reverse-engineering of the obscure DS features, and so on. melonDS will be a fun adventure, and you can be part of it too!


So, welcome aboard!

StapleButter
Posted on 03-29-17 10:24 PM, in melonDS 0.1 (rev. 2 of 03-29-17 10:44 PM) Link | #2
There's a new DS emulator in the town, and it's finally seeing its first public release!


melonDS is part of a second wave of DS emulators. There are a few other emulator projects that are part of it, which you might have already heard of. Either way, check them out!

Why start this project? Mostly for the sake of the challenge, but also because I believe the DS emulation scene needs some fresh air. The NO$GBA author is working hard to reverse-engineer, document and emulate the DSi, but aside from that, there isn't a lot of progress regarding the DS, and I feel that there are still things to be done.

So, without further ado, let's relive 2007! :P


melonDS 0.1

[image] [image] [image]


Features

* almost-complete 2D graphics
* 3D graphics (software renderer) with texturing, alphablending, lighting
* input: keyboard and joystick, touchscreen
* backup memory
* booting from the BIOS
* resizable video output window, preserving aspect ratio of individual screens

How to use

melonDS requires BIOS/firmware dumps from a DS. You can dump them with the following dumper.

The files must be placed in the same directory as the melonDS executable, as follows:

* bios7.bin -- ARM7 BIOS, 16KB
* bios9.bin -- ARM9 BIOS, 4KB
* firmware.bin -- firmware, 256KB or 512KB

Note: the DS-mode firmware in the 3DS isn't bootable. It only contains the bare minimum required to run DS games. Be sure to enable direct game boot when using a firmware dump from a 3DS.

Settings

Emulation: settings related to emulation. For now it lets you enable direct game boot (directly runs the game instead of going through the firmware).

Input: allows you to configure keyboard and joystick input. You can change a mapping by clicking the corresponding entry, then pressing a keyboard key or joystick button. For now, joystick input uses the first joystick available if multiple joysticks are plugged.


Downloads

* Windows 64-bit
* Linux 64-bit


Have fun! :D

StapleButter
Posted on 03-29-17 10:25 PM, in melonDS IRC channel Link | #3
The IRC channel for melonDS-related matters is there:

Server: irc.nolimitzone.com port 6667
Channel: #melonds

StapleButter
Posted on 03-29-17 11:00 PM, in melonDS build system Link | #4
I used the following command to build melonDS under Linux:

g++ -O2 `wx-config --cppflags --static` -I/usr/include/gtk-2.0 $(find ./src -name "*.cpp") `wx-config --libs --static` -lSDL2 -o melonDS

Command may vary depending on your setup.


It appears that CodeBlocks is flaky under Ubuntu.


Ideally I want to setup CMake instead of relying on CodeBlocks. I'll have to look into that though.


For any builds that are going to be distributed, I recommend linking wxWidgets statically.

StapleButter
Posted on 03-29-17 11:12 PM, in Cross-platform UI toolkits (rev. 2 of 03-29-17 11:13 PM) Link | #6
melonDS currently uses wxWidgets, but this is by no means set in stone. I have heard things about wxWidgets that are... less than good.


Ideally, I want something lightweight and straightforward. melonDS should stay fairly simple.

Coding a different UI per platform is a no-no. Directly using the native toolkits would be as straightforward as it can get, but we know how that turned out in DeSmuME.


wxWidgets

:UP: not too heavy
:UP: well-featured
~ people keep saying it's bad
:DOWN: ties the program to a specific library version
:DOWN: requires a billion extra DLLs under Windows (or 6MB executable size when linking statically)


Full-SDL UI

:UP: lightweight, no extra toolkit required (minus file picker dialogs)
:UP: no dealing with interop between two toolkits
~ has its own style instead of using that of the system
:DOWN: more work required


libui

:UP: really lightweight
:UP: small enough that I could hack around its limitations and expand it
~ I couldn't get it to build under Windows. feh



whatever else

StapleButter
Posted on 03-29-17 11:13 PM, in melonDS 0.1 Link | #7
Any feedback is welcome! Just test whatever you like and let me know.

StapleButter
Posted on 03-30-17 07:34 AM, in ROMs that require precise timing Link | #15
I'm keeping a list here so we know what may break when altering timings, and can test extensively.


* Aging cart (test ROM)

The ARM9 clears memory at the same time as the ARM7 relocates its binary. Get the timing wrong and the ARM7 binary is erased before having been relocated, resulting in the ROM not booting.


* FF3 intro FMV

Cause unknown, but it is timing-sensitive.

StapleButter
Posted on 03-30-17 07:46 AM, in melonDS 0.1 Link | #16
Posted by Dawn
On (a very heavily hacked-up) Ubuntu 14.04, I got the following error when running the binary:

./melonDS: relocation error: ./melonDS: symbol _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_createERmm, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference

This sort of thing is easily solved if I were to just build the program from source myself, but I'm not going to bother with CodeBlocks today at least (I think something about potentially adopting CMake was mentioned? That would be very nice...)

At any rate, congrats on the first release! Looking forward to further development.

Actually, you don't use CodeBlocks under Linux. See this thread.

I tried setting up the CodeBlocks project to also work under Linux, but didn't finish. CodeBlocks is flaky as hell under Ubuntu. Toolbars fail to redraw after a while, the build options dialog just completely freezes if there's an option it doesn't like...


Regardless, thank you guys for the feedback!

StapleButter
Posted on 04-02-17 01:30 PM, in Cross-platform UI toolkits Link | #29
1. it's a behemoth
2. why reinvent everything instead of using the native UI
3. it's... corporate

StapleButter
Posted on 04-03-17 04:51 AM, in The Compatibility Thread Link | #32
The world of Android doesn't aim at properly emulating the DS, or properly doing anything for that matter. It only aims at extracting money from users.

Regardless, it's better to have accurate compatibility/playtesting information. Screenshots are ideal, but having them in one big post is going to be a pain. We should set up a real compatibility list thing.

StapleButter
Posted on 04-03-17 04:53 AM, in Metroid Prime Pinball Link | #33
Posted by MyNameIsDefault
Something odd I ran into with the bios/firmware though. I had settings set on my DS to auto boot carts if inserted, so I turned that off and redumped the stuff. Using that new dump, if autoboot isn't set in melonDS, results in the top screen staying white.

It's odd to say the least. Maybe some GPU configuration not properly changed/reset.

StapleButter
Posted on 04-03-17 06:42 PM, in melonDS 0.1 Link | #35
from what I read, the DRM simply checks the save RAM size. if melonDS detects the size properly (or is given an existing save file with the right size), it will properly redirect out-of-bounds accesses to the save memory.

most of those anti-piracy measures are aimed at bootleg carts, copiers or flashcarts that try to accomodate for most games by having SRAM as large as possible. an emulator that properly detects and enforces the SRAM size will not be affected by those measures.

there have been games that used tricks explicitly meant to break emulators. often features that emulators choose to ignore because they're too much effort and processing power for very little gain. a prime example would be those Wii games that basically overwrite critical memory with garbage, then invalidate the data cache: on the console, the data stays entirely in the cache and doesn't make it to memory before the cache is invalidated. a sane emulator will ignore the cache, resulting in memory getting trashed.

StapleButter
Posted on 04-03-17 06:52 PM, in The Compatibility Thread (rev. 2 of 04-03-17 06:52 PM) Link | #37
yeah, that's a good idea, don't swap melonDS and real hardware tho :P


(also, no need to put the images in spoilers)

StapleButter
Posted on 04-03-17 07:41 PM, in The Compatibility Thread Link | #39
I guess the glitches are because melonDS doesn't support decal texture blending. and shit like edge marking and antialiasing.

StapleButter
Posted on 04-04-17 05:03 AM, in Cross-platform UI toolkits Link | #41
It's something I may well consider. Lack of documentation shouldn't be an issue with a codebase that is small enough, as long as it is sane.

I'm not really into the modern C++11 stuff (I prefer keeping things low-level, I know better what's going on behind the scenes), but hey, there's a start to everything.


It's also cool if it's something small, that I can easily expand and build upon. Something I thought about, since melonDS ended up getting two separate windows, is a list of games with things like their icon, title, etc, maybe whether the ROM hash is known to be good...

StapleButter
Posted on 04-05-17 03:18 AM, in The Compatibility Thread Link | #45
you can take a screenshot of the active window only, by pressing Alt+PrintScreen ;)

StapleButter
Posted on 04-06-17 03:13 AM, in The melonDS Ideas Thread Link | #52
Why did you go through the trouble of making that banner if you think this thread is useless? :P


Regardless, this can be interesting, we'll see what comes out of it. Reminds me I want to put up a FAQ somewhere, so I don't constantly get people asking "will you implement <feature>?" and other common questions.

StapleButter
Posted on 04-06-17 10:45 AM, in The melonDS Ideas Thread Link | #54
I'm moving it to a more appropriate place.


Also, displaying low self-esteem doesn't help sell it, just saying.

StapleButter
Posted on 04-06-17 04:06 PM, in The melonDS Ideas Thread Link | #56
Hey, that's pretty cool! I'm implementing audio and I was wondering how to sync it, right now it's underflowing every now and then :P

StapleButter
Posted on 04-06-17 07:27 PM, in melonDS 0.5 TODO list (rev. 16 of 07-23-17 12:44 PM) Link | #58
This list is by no means exhaustive, but gives you an idea of what is planned.



melonDS 0.5 TODO


* sound: figure out why it's desyncing/crapping up occasionally when surround is used
-> capture buffer size may not be a multiple of 16 (sound is processed every 16 samples right now) nope
-> the capture and the corresponding output channel use the same address
-> figure out the sound FIFO thing, how it works
-> the game just starts channels 1 and 3 and the associated captures, and never touches it again. the surround effect is applied by the ARM9 (way to go Nintendo, not like you have an ARM7 that is mostly idle). TODO: find out when the ARM9 is told to do surround processing.
-> there's clearly an effect when booting from firmware, so this needs investigation. Seems firmware does some setup we're missing.

* wifi:
-> make it more stable, client->host occasionally shits itself
-> handle errors, report them via the various possible ways
-> RXSTAT (not crucial)
-> figure out port244 and port228
-> maybe find how wifi DMA works? (it probably just doesn't work)
-> rate for MP ack and MP empty reply, where is it pulled from? hardwired? (MP ack probably uses the same rate as MP command)
----> rate/preamble might affect the reply-wait time (it likely includes the ack preamble)

* also, figure out how the hell writing to VCOUNT works -- done, except for how it interacts with 3D
-> doesn't offset 3D scanlines but causes a weird scanline effect
-> capture shows that the scanline effect only affects the LCD. 3D is unaffected by VCOUNT writes.
-> still needs to be checked: the various DMA/IRQ/things that interact with VCOUNT
--> vmatch
--> windows
--> DMA types 1 (vbl), 2 (hbl), 3 (disp start), 4 (FIFO)
--> vblank IRQ, flag
--> capture!
--> also check if repeating scanline 214 or 215 fucks up 3D

* fix timing problem (apparent in the Sims 2 intro video, it plays too slow)

* 3D:
-> depth limit for 1-dot polygons
-> check whether vertical/diagonal lines and dots render right (and to a lesser extent, horizontal lines)
-> antialiasing (figure out the GPU division quirks so that the output is the same as hardware)
-> fix interpolation accuracy (see above)
-> eventually check clipping and culling

* 2D:
-> mosaic
-> mostly checking sprite mosaic and TODO/checkme things for correctness

* UI
Pages: 1 2 3 4 5 6

Main - Posts by StapleButter

Page rendered in 0.046 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 107/107, time: 0.021 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2015-10-07)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.