So I used libui and botched it to fit my needs...


Functions that return strings

As they are, they allocate the string on heap and return a pointer. You get to do cool one-liners, but you need to remember to free the string, and it's not so efficient.

Should change those to use stack-allocated string buffers where possible.


uiArea handler

(why does this use a handler struct instead of hooking individual event handlers?)

The handler struct must remain accessible to libui throughout the uiArea's lifetime. Allocating it on stack can be a bad idea, esp. for secondary windows.

(solutions: copy the struct to an internal buffer, for example in the uiArea struct. or use individual handlers.)



Sizing

Under GTK, it is impossible to resize a window smaller than its original size.



List of changes

that were made to adapt it for melonDS.

(and tags showing where it's finished for now)

* [Win/GTK] file dialogs: added filter support, added extra parameter for setting starting dir (not supported yet)
* [Win/GTK] uiArea: added small API for creating and drawing bitmaps
* [Win/GTK] uiArea: botched keyboard input. only getting raw scancodes
* [GTK] uiWindow/GTK: fix window sizing to take the menubar into account. kind of a hack tho.
* [Win/GTK] uiWindow: add handlers for getting/losing focus and file dragdrop (limited to one file)
* [Win/GTK] uiControl: add uiControlSetFocus()
* [GTK] uiArea/GTK: make uiAreaQueueRedrawAll() thread-safe
* [Win] uiButton: cache ideal size
* wip


TODO

optimize uiBox sizing under Windows. and/or add grid container (would be better for the input dialog as the sheer amount of boxes lags it) there is already uiGrid but it needs optimization too

____________________
Kuribo64

I can change your name there so you have the same one everywhere, but please decide on a name and don't change constantly.

____________________
Kuribo64

This board mostly serves for support wrt melonDS, so... yeah

____________________
Kuribo64

As the IRC network that hosted our IRC channel is unmaintained and crumbling, we are moving the channel to a network that is in a better state.


irc.badnik.net / irc.rustedlogic.net
#melonds


Thank you.

____________________
Kuribo64

melonDS 0.5 is out!

This release finally brings a UI that doesn't suck. Oh and antialiasing.

There hasn't been a lot of changes due to real life issues (and being oh so efficient with UI coding).

The full changelog is below.


• new UI, more stable, less windows all over the place
• wxWidgets ditched, lost some weight
• 2D: allow reading BLDALPHA
• GPU: fix potential issues with VCount write
• implement 8bit accesses to some registers
• 2D: mosaic (not quite right for rotscaled sprites)
• 3D: fix culling
• allow 128KB firmwares from DSi/3DS
• 3D: more accurate fog
• 3D: more accurate polygon edges (but not perfect)
• 3D: antialiasing
• 3D: misc optimizations


pile of copypasta



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, 128KB, 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) and the threaded 3D renderer.

There's also a wifi-related setting (which only ended up there because I'm lazy and I need to redo the UI). You should try toggling it if you have trouble getting multiplayer working.

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.

If your game fails to save

Check the size of the savefile. melonDS can, in some circumstances, misdetect the save memory type.

Save memory type detection is done only when no existing savefile is present.

If you provide an existing savefile with the correct size, melonDS will use the correct save memory type and saving should work properly.


Downloads

* Windows 64-bit
* Linux 64-bit


If you feel generous

melonDS Patreon


Have fun!

____________________
Kuribo64

Accuracy isn't something you can measure as a general number. For example, melonDS may have the most accurate 3D renderer, but its timings are still pretty gross (and DeSmuME can be better in that regard).

____________________
Kuribo64

Posted by andlabs

On Windows I need to take out a UTF-16 string and convert it to UTF-8, so allocation is going to happen anyway.

mh, good point.

Posted by andlabs

In the event of having multiple Areas that share the same set of events. Think of it as a way of creating your own controls without extending libui.

mh, I see.

Posted by andlabs

Your initial window size is not big enough in this case, because it's GTK+ that limits the size on libui's behalf. Of note is that GTK+ tabs ("notebooks") request enough space for the largest tab page at all times, even if that page isn't the active one. You'll have to talk to the GTK+ team about that. Also note that the minimum size of controls is also theme-dependent.

actually, that issue was due to me using gtk_widget_set_size_request(), that sets a minimum size. (see below)

Posted by andlabs

I've wanted to do the filtering, but in one of the OSs if you specify an extension filter in a save dialog, you can't override it. I forget if there were other issues.

As for the starting directory, I forget if the OSs take care of that themselves, and if so, which OSs do (or what I would need to do to enable it if not).

It works well under Windows and GTK, not sure about Mac.

Windows remembers the last visited directory. GTK doesn't. I didn't end up coding support for it because I wasn't sure how to approach it. Apparently under Windows trying to force the starting directory is deprecated.

Posted by andlabs

This is in the works as part of the uiTable API. Not sure how it will suit melonDS though...

I'd have to know more about this, but the name uiTable implies that it wouldn't really fit melonDS's goals.

Posted by andlabs

This is deliberate; I wanted uiArea key events to be keyboard layout-independent. This decision is showing its flaws, but I'm not sure yet what I'll do about it. Also note that OS X uses its own scancode list for all keyboards.

Nah, I meant that libui comes with a whole system for detecting 'good' keys and modifiers and all that. Which is nice if you want to implement text entry I guess.

In the case of melonDS, I only need to know when a given key is pressed, and to tell that key apart from other keys, regardless of what it is. (think Left Ctrl vs Right Ctrl)

Posted by andlabs

I thought I took care of this already, but it's probably a TODO. What hack did you do?

The issue under GTK is that the menubar is part of the client area, which is inconsistent with Windows.

The original hack was calling gtk_widget_set_size_request() on the window's childHolderWidget. While it sized the client area properly, it also set that as a minimum size.

The final hack kicks in after the window is shown: the final menubar height is retrieved and the window height is adjusted accordingly.

Posted by andlabs

What do you mean by getting or losing focus? And for file drag and drop, I've wanted to put that in both uiArea and uiTable as an extra option and as an API, but that was a distant goal. Not sure about doing it to uiWindow...

What does this do?

Under Windows, I need to explicitly give focus to my uiArea or it won't receive key events until it's clicked. I need to do so when creating the window, and when it gets focus (is brought to foreground) after having lost it.

So I added event hooks to detect that. uiControlSetFocus() gives keyboard focus to a particular control.

Posted by andlabs

All libui functions except uiQueueMain() are not thread-safe (in fact, that's the whole point of uiQueueMain()). What did you do for this function? I wonder if it's the right thing to do in the first place...

It is called in a g_idle_add() callback if the calling thread isn't the GUI thread.

In melonDS, the emulator loop runs in a separate thread, and that thread needs a way to signal the UI to refresh itself. With GTK, doing it directly caused random freezes.

Posted by andlabs

Try disabling the WM_CTLCOLOR stuff in windows/parent.cpp or windows/container.cpp (I forget now where it is at present) and seeing if that is the real problem. Other people say it is, but a correct fix that still looks good (as removing that code would make tabs look bad) would require a(nother) major rearchitecture of libui's control hierarchy structure...

If it turns out the containers are indeed slow, I can try switching back to the DeferSetWindowPos() system, but I forget if I'm already using that...

Will look into it.

____________________
Kuribo64

I realized after releasing it that I forgot to add the FPS counter back.


Will be fixed for 0.6.


I want to work on wifi, or fancy addon devices.

____________________
Kuribo64

Local wifi already works but it can use improvement. Online isn't done yet.

Sound is also a todo.

____________________
Kuribo64

Comes with game "Pokémon Typing Adventure" or whatever the name is.


I'll post reverse-engineering notes in this thread.



Init

Game sends the following data via the aux SPI bus:

FF 01 00 00 04 01 03 0C 00

It doesn't read the response. A test on the cart returned all zeros.

There has to be something else the game is expecting but not getting.


The cart sends an IRQ (IREQ_MC) when receiving data over SPI. Regular carts don't do that (and respond all FF instead of 00 when sent the command above).

The IRQ is sent after the first SPI command byte is sent. No idea if there are specific values that don't trigger the IRQ, or if it has a "write zero to get to the backup memory" thing like other Pokémon carts (attempt at sending a RDID command read zeros).

Emulating it doesn't do shit, though.

Also: IREQ_MC triggers on both CPUs, regardless of EXMEMCNT. In the case of Pokémon, though, it's only enabled on the ARM9.


Cart ID

The cart returns an ID of 0x80007FC2.

Bit 31 there causes the BIOS to load the secure area differently: for each block, the command is repeated 9 times, first time with a zero length, next 8 times with 0x200.

It's not too clear how this should work, and melonDS doesn't emulate it, so such an ID causes firmware boot to fail (secure area is loaded wrong, which doesn't bode well).

The game itself seems sensitive to the cart ID. It behaves differently when bit31 is set, but... it doesn't try to do anything...? Nope.

____________________
Kuribo64

I got a report that it fails to load a ROM if the path contains special characters, so check for that.

____________________
Kuribo64

yup

____________________
Kuribo64

Function at 0x0206DEC4 refers to the following strings:

Sending to unknown dest
Send - buffer linked


Similar strings are found, for example, here: https://android.googlesource.com/platform/external/libnfc-nci/+/jb-mr1-dev/halimpl/bcm2079x/gki/common/gki_buffer.c#681


So I guess our cart is using a Broadcom Bluetooth controller, and they've been using one of those open-source drivers. Interesting.


More on this.

https://github.com/mozilla-b2g/platform_external_bluetooth_bluedroid/blob/master/stack/btu/btu_task.c

Driver sitting between the game and the hardware seems to be a stripped-down version of this.

____________________
Kuribo64

Or create a folder in C:\ for example and put your ROMs there

____________________
Kuribo64

Triggering another IRQ after the first SPI command is finished causes the game to send another SPI command.

(and things go wrong, because the command starts with a 02 and melonDS mistakes it for a regular savemem command. I need to rework that code)


I need to acquire a cart slot, so I can hook the cart to a raspi and test it. Issue with testing on the DS is that, I guess, when swapping carts, the new cart doesn't get a reset signal. May not be a big deal for regular savemem, but this cart embeds what seems to be a Broadcom controller that can do several things.

____________________
Kuribo64

The one that comes with the DS browser.


First 16MB of the GBA ROM address range are all FF, except:

080000B2: 00 00 00 24 24 24 (signature?)
080000BF: 7F
0801FFFF: 7F
08240000: 32bit register; bit0: 1=enable RAM, 0=disable; other bits are always zero; initial value is 00000001

The register is the only thing that can be written to.


The 8MB at 0x09000000 are the RAM. Initially garbage-filled. When disabled, reads FF, but contents are retained (atleast for a certain time).


0x09800000 and up are open-bus.

____________________
Kuribo64

It's been fixed, the fix will be included in 0.6.

____________________
Kuribo64

could be, but max emulation speed will be capped by your system's power

____________________
Kuribo64

0.4 had a secret feature where pressing TAB toggled the framerate limiter.

I could readd it, but it'd be best with a proper hotkey system.

____________________
Kuribo64

MP retry mechanism

after each round: (after ack is sent)
txheader[2] is updated, bits are cleared when the corresponding client responded fine
if the packet needs to be resent, the clients that responded fine aren't polled again (client mask in the frame body isn't updated on the host side tho, but clients do receive the new mask)

seems the frame body client mask is copied to txheader[2] at the beginning, regardless of what the initial value is

SEQNO is incremented normally for retries, as if they were separate transmits

____________________
Kuribo64