Views: 6,696,212 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 03-28-24 12:05 PM
Guest:

Main - Posts by Arisotura

Pages: 1 2 3 4 5 ... 40 41 42 43 44
Arisotura
Posted on 03-29-17 09: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!

____________________
Kuribo64

Arisotura
Posted on 03-30-17 02:24 AM, in melonDS 0.1 (rev. 2 of 03-30-17 02:44 AM) 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

____________________
Kuribo64

Arisotura
Posted on 03-30-17 02:25 AM, in melonDS Discord/IRC channels (rev. 5 of 07-22-21 12:16 PM) Link | #3
The Discord/IRC channels for melonDS-related matters are there:


Discord

https://discord.gg/NdfMUGWDPJ


IRC

Server: irc.badnik.net port 6667
Channel: #melonds

Web client


The two channels are linked together by a IRC/Discord bridge.

____________________
Kuribo64

Arisotura
Posted on 03-30-17 03:00 AM, 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.

____________________
Kuribo64

Arisotura
Posted on 03-30-17 03:12 AM, in Cross-platform UI toolkits (rev. 2 of 03-30-17 03:13 AM) 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

____________________
Kuribo64

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

____________________
Kuribo64

Arisotura
Posted on 03-30-17 11:34 AM, in Timing test cases (rev. 9 of 01-20-19 12:23 AM) 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.

actually seems to just require some form of cart read delay


* Golden Sun: Dark Dawn

bad memory timings result in distorted characters?? the bug disappeared in 0.7 before we touched any timings, tho


* Rayman DS

bad memory timings result in all sorts of weird effects (esp kDataCacheFetch or whatever it was)


* Super Mario 64 DS

very bad timings cause the character to be randomly teleported
also, something is up with the Nintendo screen at the start (takes a lot of CPU, but messing with memory timings changes that)


* Who wants to be a millionaire

FMVs flicker if the FMV decoder and/or DMA take too long


* Burnout Legends

weird slowdown-compensation thing. seems to be based on GX timings.


* Spellbound

The ?'s on the menu. It sends display lists via DMA but doesn't wait for them to complete before doing other things with the GX. GX must be fast enough that the FIFO is always less than empty by the time a DMA transfer ends.


* Colour Cross

dual-screen 3D shits itself when not running the GX often enough.


* Mario & Sonic at the Olympic Games

dual-screen 3D render shits itself big time if it's running way too fast. running too fast causes some 3D sprites to flicker. old GX bugs.


* Over the Hedge - Hammy Goes Nuts!

bad timings (running too fast) causes intro sounds to be garbage. fixed in melonDS by setting kDataCacheTiming to 4 or more.

except kDataCacheTiming needs to be 3 or less for Millionaire's FMVs.

cause unknown. also affects NO$GBA.




affected by 0.7.1 timing renovation:

* NSMB world map cannons (non-USA ROMs)
* Pokémon Platinum sprites
those issues were unrelated to timings and uncovered a bug in how we handled the GXSTAT busy flag

* Etrian Odyssey
game waits ~400 cycles after VBlank (subs/bcs loop that runs 200 times)
then checks GXSTAT to see if it's still busy. if it is, it gives up
otherwise it does all the handling to swap screens etc

____________________
Kuribo64

Arisotura
Posted on 03-30-17 11: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!

____________________
Kuribo64

Arisotura
Posted on 04-02-17 05: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

____________________
Kuribo64

Arisotura
Posted on 04-03-17 08: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.

____________________
Kuribo64

Arisotura
Posted on 04-03-17 08: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.

____________________
Kuribo64

Arisotura
Posted on 04-03-17 10: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.

____________________
Kuribo64

Arisotura
Posted on 04-03-17 10:52 PM, in The Compatibility Thread (rev. 2 of 04-03-17 10: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)

____________________
Kuribo64

Arisotura
Posted on 04-03-17 11: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.

____________________
Kuribo64

Arisotura
Posted on 04-04-17 09: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...

____________________
Kuribo64

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

____________________
Kuribo64

Arisotura
Posted on 04-06-17 07: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.

____________________
Kuribo64

Arisotura
Posted on 04-06-17 02:45 PM, 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.

____________________
Kuribo64

Arisotura
Posted on 04-06-17 08: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

____________________
Kuribo64

Arisotura
Posted on 04-06-17 11:27 PM, in melonDS 0.6 TODO list (rev. 20 of 11-13-17 10:55 PM) Link | #58
This list is by no means exhaustive, but gives you an idea of what is planned.



melonDS 0.6 TODO


* fix bugs in the Sims

* 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 done but do more of it

____________________
Kuribo64
Pages: 1 2 3 4 5 ... 40 41 42 43 44

Main - Posts by Arisotura

Page rendered in 0.131 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 109/109, time: 0.016 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.