bd452/desmumewii

Automatically exported from code.google.com/p/desmumewii

desmumewii's Issues

To or not to port glib?

On it's own, the DeSmuME svn compiles up to the GPU_osd.h and GPU_osd.cpp
files. These are source files of the utmost importance as they deal with
emulating the graphics processing unit of the DS. These files rather
trivially use GLib's GTimer to keep track of clock speed in order to make
sure to not overclock the emulation.

Since we dont have GLib, we get compilation errors at this point.

There are 3 things we can do:

1) Look at how other emulators handle overclocking and try to mimic their
implementation

2) Assume we shouldn't worry about overclocking on the Wii and remove the
implementation completely

3) Port GLib


Im personally leaning towards option 1 but I looked through glib and seems
it shouldn't be too bad to port as we have libogc equivalents to major
(maybe even all) win32 libraries it calls. I want to completely avoid
option 2 at all costs.

Looking for some feedback.

--Arikado

Original issue reported on code.google.com by [email protected] on 6 Mar 2010 at 5:41

Issue Potential

Awesome will try some roms out. Feed back to come

Original issue reported on code.google.com by [email protected] on 5 Nov 2009 at 6:16

GX game issues archive

There is a major graphical bug with NSMB in GX mode,the graphics do not show up 
at all.

In M&L3 Bowser's Inside Story,the top screen appears zoomed in too far.

and...

You probably already know that SM64DS has coloring and lighting issues.

Original issue reported on code.google.com by [email protected] on 6 Aug 2010 at 3:31

Wiimote

improve the wiimote ir sensor support. its hard to point with it in other 
screen modes

Original issue reported on code.google.com by [email protected] on 21 Jun 2010 at 9:41

Project check list

This is really for myself to help me keep the project on track (and myself
busy of course) as well as to let everyone working on the project or
interested in becoming involved with the project to know what most pressing
things need to be done. Listed here are everything from trivial programming
tasks to potentially major core changes.

1)Getting 3D working well
Right now, 3D renders some things but textures are for the most part
transparent. This is what I am personally working very hard on resolving.
It seems on the outside that we need to allocate more memory for the 3D
functions to use. However, it also seems that there is something going
wrong causing some textures not to show. I think it involves the palette
color conversions but I'm really not too sure at the moment. If you
couldn't tell, this is what I'm personally focusing my working around.

2)Getting homebrew and commercial ROMs to work properly
It seems we can only get homebrew ROMs to work correctly when we hardcode
in the GPU display mode as 2. But we can only get commercial ROMs to work
when we do not. At the very least, we need to setup an if() that hardocdes
the gpu display mode if "Homebrew" is detected as the ROM ID.

3)Visibly marking stylus position
We've got X and Y coordinates tracking the stylus. Now let's use GX to
render a small aquare or something to show where the stylus is positioned
at. At the moment, as you cant see where the stylus is at, it's almost
impossible to use it or tell if it even works at all.

4)Getting more ROMs to boot
It's no longer an issue of ROMs just crash the emulator because we can't
get 3D to work. While compatibility has been greatly improved, there are
many ROMs like the Castlevanias and Mario Kart that just freeze and don't
do anything. This is presumably something in the loader code. My guess
would be that there's a register we need to give memory that we stole back to.

5)Optimization
I'm noticing in the rasterizer and  3D effects that we could probably
directly use GX to get some things done more efficiently and quickly. There
are most certainly other places in the emulator where similar things can be
done to shorten code or make it more Wii friendly.

6)Removing unneeded code
We need every extra bit of memory we can get! We do not need things in
DeSmuME like code to record a video of gameplay. Or to interface with a
linux filesystem. We can also probably start getting rid of OGLRender files
now. Please, if you see code we can get rid of: Get rid of it. We need the
extra memory.

7)Using 32-Bit Variables
ekeeke suggested using 32 bit variables in lieu of smaller ones
(specifically 32 bit ints instead of the 8 bit ones we were using) in order
to speed up the emulator. I would love to look into this and see how
helpful this may be.

8)Adding frame skipping
We've got some code in main.cpp to monitor the fps rate. It shouldn't be
too hard to use it to give the user control over frame skipping to
artificially speed up emulation for themselves.

Original issue reported on code.google.com by [email protected] on 2 Apr 2010 at 2:20

Utilizing Starlet

There's a reason that I've been so quiet lately. 

These may just be the rantings of a madman, but I was thinking...

Since the esteemed Arikado worked on DOP-Mii, I figured that you would know
whether this was possible or not. At least, moreso than I. Is it possible
to get access to the starlet? Is it even doing anything when we're running
homebrew? The DS runs on an arm processor, so if we could utilize even a
fraction of Starlet's power, well... I think we all know what would happen.

I have read the crap out of the technical manuals, and I found some
striking similarities to Vanilla's Disassembler.cpp code and native
instructions for the ARM processor. I have some heavily commented files to
this effect. 

Since Vanilla was not built with an ARM processor in mind, it had to
emulate everything. Consider this piece from arm_instructions.cpp:

 armcp15_moveARM2CP((armcp15_t*)cpu->coproc[cpnum], ...);

//Which is defined as:

 armcp15_moveARM2CP(armcp15_t *armcp15, u32 val, u8 CRn, u8 CRm, u8
opcode1, u8 opcode2)

//Now, this code is to "move from the ARM to the Co-Processor", which is
defined on the ARM architecture as: 

 mcr p<cpnum>, <opcode1>, Rd, CRn, CRm, <opcode2>

Notice any similarities? 

So, if this is possible, we need to communicate with the Starlet. This, I'm
told is by the Hollywood's IPC engine
(http://wiibrew.org/wiki/Hardware/IPC). I don't know how to set up
communications in the first place, though.

This just scratches the surface of what I've found. I wanted to get some
feedback before I committed my commented versions of the files, seeing as
how they are even less organized than this. I have also created a header
file with ARM-specific assembly code, ready and raring to go, if I get a
green light.

Original issue reported on code.google.com by dancinninjac on 1 Apr 2010 at 3:01

Fowarder Channel Code Dumps

What steps will reproduce the problem?
1. Use A forwarder Channel
2.
3.

What is the expected output? What do you see instead?
Desmunewii                   Code Dump

What version of the product are you using? On what operating system?
Wii 3.2e cIOSX rev 19 (38 base) desmunewii r73 
Forwarder channel used customizemii and NAND Loader as waninkoko although
I'm pretty sure that wouldn't change anything 

Please provide any additional information below.

I do see the desmune wii screen for like 1 second then it code dumps
I know A forwarder channel is the most important thing right now but it
would be nice if it worked, Here's the one I made :
http://www.megaupload.com/?d=R50FX6Q4

Original issue reported on code.google.com by [email protected] on 31 Mar 2010 at 4:25

White screen for some games

Discussion of the white screen bug.

Games know to have this issue.

==============

Super Princess Peach
castlevania series
Zelda games
Advance Wars
Pokemon games Heartgold & Soulsilver.

============= 

After a few hours of debugging I'm seeing that the REG_AUXSPIDATA is never
reached and the MC commands are never processed. The problem is deeper than
just the MC commands the arm cores continue to run but it obvious they've
gone of track somewhere.  Not sure if there are similarities between these
games or a certain piece of hardware they use that the other games don't.

I'm asking for suggestions as I'm really not looking forward to debugging
arm instructions one by one on the Wii.

Original issue reported on code.google.com by [email protected] on 14 Apr 2010 at 4:35

[deleted issue]

[deleted issue]

Pokemon Diamond

Loads fine, but does go very slow in the start screen. Stays in black
screen and does not play the game afterwards.

Original issue reported on code.google.com by [email protected] on 11 May 2010 at 3:27

How to compile DeSmuME Wii

There is a compiling guide to WiiDS on its google.code page and I got it
successfully compiled, but was not able to compile desmume. So any further
instructions how to compile it would be much appreciated.

Original issue reported on code.google.com by [email protected] on 29 Mar 2010 at 6:37

Matrix review

Purpose of code changes on this branch:

I overhauled the way that we handle matrices in gfx3d.cpp. Right now everything 
comes out black, which means that the matrices are not scaling the coordinates 
right (I think).

The only changes from the trunk should be in gfx3d.cpp, GXRender.cpp, and the 
additional files (MtxStack and MtxMath).

When reviewing my code changes, please focus on:

- How the scaling/rotation/positioning is done for coordinates of textures and 
points. I believe this is where the problems lay.

- What needs to be "cut" in order to make this work. I suspect that since in 
order to get "Vanilla" to run on the Wii, we changed a few things and that is 
"undoing" what the matrix overhaul has done.  

Thank you very much!

Original issue reported on code.google.com by dancinninjac on 24 Aug 2010 at 6:06

Touch Screen usage with wiimote.

I'm hoping that eventually this emulator has touch support so that everyone 
can play super mario 64 ds because you have to touch the star first to get to 
the menu.

Original issue reported on code.google.com by [email protected] on 4 Apr 2010 at 9:43

Add folder for all save

please add a folder for all save files.
maybe :

SD:/desmumewii/save/

thx

Original issue reported on code.google.com by [email protected] on 3 Apr 2010 at 12:13

Emulator produces a frozen black screen

I added some basic text output to DeSmuME Wii. So when we start the
emulator, we should see text and then, based on the text, be able to
determine where and why a freeze occurs.

However, the first line of text, "Welcome to DeSmuME Wii!" is never displayed.

My speculation for the reason is that:

1)We have an error with SDL Wii not returning to main properly.

2)My environment sucks (I just reconstructed it) and is preventing the
program from being correctly built.

Could someone please compile and confirm or deny if #2 is the issue?

Original issue reported on code.google.com by [email protected] on 5 Nov 2009 at 10:06

[deleted issue]

[deleted issue]

I can´t compile r180

hello i can´t compile r180. bevor i have compile all versions. now there a 
lot of errors at compiling with defkit

Original issue reported on code.google.com by [email protected] on 2 May 2010 at 9:02

Still looking for GLib?

I'm unsure if you guys are still looking for Glib or not, but I figured I'd
post this just in case. GLib is a library from the GTK+ Project.

Here are the Win32 Binaries, followed by the Win32 src:
http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.22/glib_2.22.4-1_win32.zip
http://ftp.gnome.org/pub/gnome/sources/glib/2.22/glib-2.22.4.tar.bz2

Original issue reported on code.google.com by [email protected] on 3 Mar 2010 at 12:23

No console text

The expected output when you compile the project should be along the lines
of: "Welcome to Desmume Wii!" and so forth.

However, this is not the case. There is only a blank screen. What is
troubling is the fact that, in the previous version (before the reboot to
Desmume 0.95), the console worked. Any ideas as to what has changed would
be greatly appreciated, since I'm more than a tad stumped at this.

This also could be a sign of a bigger problem, such as ALL video. Let's
hope that it's not.

Original issue reported on code.google.com by dancinninjac on 18 Mar 2010 at 12:11

Get rid of SDL. (patch)

Based on r83.
Also changed type of xfb to solve compile-time error.

Original issue reported on code.google.com by AndreyLegchilin on 1 Apr 2010 at 5:01

Attachments:

• bye_sdl.patch

Graphic glitches and wrong colors.

I'm working to fix these problems and I need a feedback.

Please report only if something worked fine with X-revision, but Y-revision 
broke that.
It would be bad if I'll "fix" one game that I have and broke all another.

First rev. to test is r91, second r105.

Original issue reported on code.google.com by AndreyLegchilin on 6 Apr 2010 at 5:26

Option to switch d-pad and joystick's function (GC)

It would be very convenient for me if there was an option to use the 
Gamecube d-pad for movement. My classic controller broke and I've been using
a ps1/gc adapter as a substitute.

Original issue reported on code.google.com by [email protected] on 25 May 2010 at 3:51

MMU

Ah yes, the dreaded MMU. The bane of our existence. Here is what I have
gathered so far:

1) If you set DesmumeWii to exit right before calling MMU_Init (in NDS_Init
of NDSSystem.cpp), it will successfully exit to the loader. 

2) If you set it to exit INSIDE of MMU_Init, it will freeze forever, and no
text will display on the screen at all.

This leads to the deduction that MMU.cpp has code that is "optimized out"
by the compiler when we exit prior to using any of its code (before
MMU_Init). This means that the compiler doesn't actually include the code
within MMU.cpp. 

So something within the file MMU (or series of files) is causing the entire
program to self-destruct before it is even run.

Original issue reported on code.google.com by dancinninjac on 20 Mar 2010 at 7:33

Zoom

add zooming in and out

Original issue reported on code.google.com by [email protected] on 19 Jun 2010 at 10:06

Chrono Trigger Weirdness

What steps will reproduce the problem?
1. run chrono triger in rev 154 then run it in rev 184
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
184

Please provide any additional information below.
well i notice that on rev 154 when you load chrono trigger there a clock when 
it first starts that moves left to right. in rev 154 when the clock moves it 
seems to refresh and run properly. also the game runs normal speed. In rev 184 
the clock seem to keep multiplying and doesnt refresh. its like it stacking 
clocks on each other. when you play the actual game tho it seem like it's a tad 
slower running than it was in 154.

Original issue reported on code.google.com by [email protected] on 17 Jun 2010 at 6:36

Slow Games

Most if not all the game on Desmumewii run way too slow, i don't see the point 
of fixing graphical problems if you cant even play the game a full speed.

Who care if Mario looks like a blob, as long as the blob can finish and beat 
the game.

Original issue reported on code.google.com by [email protected] on 23 Nov 2010 at 10:17

Great Job!

Ide just like to say great job. This does look like you worked hard and I can 
see it, and I look forward to your progress! :D
and im here to help out with testing and will report when they arise!

Original issue reported on code.google.com by [email protected] on 27 Jun 2010 at 7:12

Channel

Hey i have maked a Channel for desmume wii is tihs ok? you can install the 
channel ( über den HBC ) it is a Boot.dol..#

It´s all Ok and its works Very Fine.

Can this the Official Forwader?

For user the have ios 249 base 38:

http://www.mediafire.com/?pvfj32hkaq3m5wa

For User the have  ios 36 Pathed:

http://www.mediafire.com/?2or95t3wf1fler0


And It is good?

Original issue reported on code.google.com by [email protected] on 23 Aug 2010 at 7:49

Team DpSp

We are work on a new ds emulator for psp please help :):)

http://code.google.com/p/dsonpsp/

Original issue reported on code.google.com by [email protected] on 8 May 2010 at 8:02

8bit backgrounds in homebrew

What steps will reproduce the problem?
1. Run any homebrew that uses 8bit backgrounds

What is the expected output? What do you see instead?
Expected output is of course normal background that was composed in 
homebrew, instead of that it's displayed like 8x8 pixels of background 
multipled like tiles, it looks sometimes really uggly, in other cases 
sometimes there is white background like in GIF loading, same happens in 
PC 0.9.5 version of Desmume.
However if 16bit backgrounds are used, problem doesn't occur, but it can't 
be said as resolve because 16bit backgrounds takes more memory if I recall 
correctly.

What version of the product are you using? On what operating system?
Recently compiled Desmume revision 169 and used once previous official 
release 154
Wii OS 4.0

Please provide any additional information below.
Well, outside of that problem things like keys, music, actions foreseen in 
homebrew code works pretty nice (tried with one homebrew so far)
I can make video of that broken backgrounds if that's necessary

Original issue reported on code.google.com by [email protected] on 26 Apr 2010 at 1:47

Debug Log Window

When I boot up the project I'm only able to see maybe 1/2 of the bottom
screen in the top right corner. Is this normal or is everyone else
disabling the window before testing? If so how would I go about doing this?
I'm guessing I would need to uncomment "//log_console_enable_log(true);"
and set it to false. Is this correct? If not, and there isn't anyway to
disable the log just yet, may I suggest switching the display to vertical
and aligning the screens to the right side of the screen. I say this
because I'm seeing some discoloration, or rather some color mix-ups, and I
wanted to make sure it wasn't just my TV before I submitted the issue...
But, it's hard to tell when I can only see as little as I mentioned above.

Original issue reported on code.google.com by [email protected] on 27 Mar 2010 at 7:07

BIOS

What steps will reproduce the problem?
1. Menu option
2.
3.

What is the expected output? What do you see instead?
No Option

What version of the product are you using? On what operating system?

R149
Please provide any additional information below.
The Ability to Use BIOS and Firmware.bin

Original issue reported on code.google.com by [email protected] on 15 Apr 2010 at 5:19

GPU Bug

In one of my rev's I added a hack in the GPU code. (basically so we'd see
the screen)

in ::: GUP.cpp, void GPU_setVideoProp(GPU * gpu, u32 p)
....
gpu->dispMode = 2; // NOT sure if this is an option or what ... Setting it
makes the screen WORK :)))) scanff

What this is actually doing is using the frame buffer to grab pixels from.
 So you're only seeing the main screen and not the sub screen.  I've
checked over all the code and can't figure out what's going on.  All I'm
seeing is a block of stretched pixels for both screens.  Almost like a
block of 16x16 pixels is being stretched to 256x192 pixels.

I'm looking into this but thought I'd log it in case anyone has any ideas??

Original issue reported on code.google.com by [email protected] on 28 Mar 2010 at 6:35

Remove OpenGL

Just a note to self. Remove OpenGL from project, it's not needed!

Original issue reported on code.google.com by [email protected] on 27 Mar 2010 at 5:11

BOOLs vs bools

Since we have a desperate need for space, I was thinking...

BOOL is defined as an unsigned int, or 4 bytes. 
bool (lowercase) is defined as only one byte. 

I was thinking it might be a hoot if we converted all of the BOOLs to bools
for space consideration.

If the "Vanilla" Desmume used BOOLs in the correct way, then it shouldn't
be a problem... Right?

I wanted to get some input before I start to dive in, however. 

Original issue reported on code.google.com by dancinninjac on 28 Mar 2010 at 6:26

Add game language support

Hi, an option to select the ingame language should be nice, cos all
european roms start only in english. 

Cheers :)

Original issue reported on code.google.com by [email protected] on 22 Apr 2010 at 11:16

Memory bug?

What steps will reproduce the problem?
1. Run DeSmuMe
2. Start Super Mario 64 DS (U)
3. Start the main adventure then walk around.

What is the expected output? What do you see instead?
Expected: Walk normally in a linear fashion.
Real: You warp around.  This may or may not be triggered by certain areas.

What version of the product are you using? On what operating system?
r154

Please provide any additional information below.
I have warped outside the map, and the camera could barely show me (it 
showed the edge of the lake, and I was a tiny speck in the background.)

Original issue reported on code.google.com by [email protected] on 27 Apr 2010 at 12:10

Gamecube "C stick Cursor" movement speed

What steps will reproduce the problem?
1.C Stick- cursor movement abit slow 
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

If possible could the speed of the cursor possibly be sped up to maybe slightly 
slower speed say for the speed used in the wii menu when using the classic 
controller's left analog stick,also something else i may suggest is what about 
using the right analog stick on the classic controller for the cursor and using 
one of the "Z" buttons as click/tap?just thought i would see what your mind set 
on some of these ideas are,i mean if there ok with you and the team and can be 
implemented into the emulator without any major hassles then i would love to 
see them implemented 

Original issue reported on code.google.com by [email protected] on 17 Jul 2010 at 7:59

Problem

I was trying to load Animal Crossing Wild World, and I pressed 1 on the wiimote 
to see the status and recieved this:

Inintialszing Virtual Nintendo DS...
Found external BIOS files. Will use!
Wooooot.... MMU is here !! (<--- I think it says MMU)
Microphone successfully inited. (Weird, I don't have a microphone?)
SoftRest Initialized
Initialization successful!
Setting up for sound...
Placing rOM into virtual NDS...
DEBUG_reset: 88902978 (I think it says that number ayways)
Using CFlash directory:
ARM7 BIOS is loaded.
ARM9 BIOS is loaded.

ROM crc: 00000000

ROM serial: ANIMAL CROSS_ADME10
yikes!!!!! please report!
yikes!!!!! please report!
yikes!!!!! please report! (this one showed up near the time I was finished 
typing the above^)

Also the whole screen flashes, the Virtual DS screen alternates with the 
status, really hard to read. Please reply if you know what's wrong, thanks :) 
p.s. What's the yikes please report all about?

Original issue reported on code.google.com by [email protected] on 8 Jun 2010 at 9:47

pokemon heartgold won't save.

What steps will reproduce the problem?
1.start game
2.try to save 
3.it will freeze when saving

What is the expected output? What do you see instead?
frozen screen

What version of the product are you using? On what operating system?

r183
Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 8 May 2010 at 9:22

my pokemon diamond wont work

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?
all i see is a black screen after the screen that says press start.

What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 6 Jun 2010 at 11:44

Doesn't run new super mario bros

What steps will reproduce the problem?
1. Run emulator
2. open new super mario bros


What is the expected output? What do you see instead?
The game runs very slow and crash

What version of the product are you using? On what operating system?
r122

Please provide any additional information below.
tested on HBC 1.06 wii 4.1U

Original issue reported on code.google.com by [email protected] on 10 Apr 2010 at 4:59

3D Crash/Bug

Ok, so I've tried a whole bunch of things.  Here's where I'm at.

Firstly to stop the crash in gfx3d.cpp put a return in the gfx3d_execute
function.  This will stop the crash and you you can play the game but there
will be NO 3D.

like :-

static void gfx3d_execute(u8 cmd, u32 param)
{
    return;
......
}

I'm still suspect of the stack as there's several functions calling other
functions.  It could also be the Wii does not like a certain task one of
these functions is doing, but without a gecko it will take time to identify
which.

baby.lueshi I checked lowering the VERTLIST_SIZE and POLYLIST_SIZE but
there are sanity checks in the vert functions that don't allow more than
the defined number to be added..  I'd image it would stop drawing 3D when
it reached the max.... But having said that. the count is stored as an
"int" and the SIZE's are defined as more than the max of an int (assuming
int's are 32767).  If this is a bug ... It should be reported to the main
desmume project.

i.e. You can see VERTLIST_SIZE is larger than the "count" variable as it's
an int.  I am allocating these the original desmume project puts them on
the stack.

#define VERTLIST_SIZE 400000
//#define VERTLIST_SIZE 10000
struct VERTLIST {
    VERTLIST()
    {
        list = new VERT[VERTLIST_SIZE];
    };
    ~VERTLIST()
    {
        delete [] list;
        list = 0;
    };

    VERT* list;
    int count;
};

Original issue reported on code.google.com by [email protected] on 31 Mar 2010 at 7:04

Cyan's Patch Missing and /DS/ROMS not default

1. Download and compile r157
2. Run and if you don't have a /DSROMS directory you will notice that it
goes into a folder browser thing.
3. Run a game and hit the 1 (2?) button a couple times and you will notice
that Cyan's in-between screens X amount of pixels isn't there.
4. You will also notice that it won't detect a /DS/SAVES directory, it
looks in the root.

Changes for rev 152 in the comments says that /DS/ROMS and /DS/SAVES and
/DS/BIOS was left in there from the bad previous version.

Changes for rev 153 says it adds Cyan's patch which adds space between the
screens.

I don't know why it's like this.

Original issue reported on code.google.com by [email protected] on 21 Apr 2010 at 10:22

Castlevania Dawn Of Sorrow white screen.

What steps will reproduce the problem?
1. Load the game.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
r185. Wii

Please provide any additional information below.

The game would start up and play on r184, even though painfully slow to the 
point of unplayable. Now when it is loaded it stays a white screen as soon as 
its loaded. I'm not sure if its changes that have been made or just from 
reworking the desmume 0.9.6 or whatver it was (the new one) into the wii. If 
this issue is irrelevant then sorry for posting it.

Original issue reported on code.google.com by [email protected] on 28 Jun 2010 at 2:21

Add usb support

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?
being able to move the DS folder which contains /roms/saves/bios that is in the 
root of the sd card to USB drive

What version of the product are you using? On what operating system?
184

Please provide any additional information below.
since there my sd is full of so many apps it be nice to be able to move that 
folder to the usb drive and load the roms and everything from there.

Original issue reported on code.google.com by [email protected] on 18 Jun 2010 at 6:19

The NDS_init() problem code

I have managed to trace the source of the current problem (where the screen
will freeze and do nothing) to a specific place.

The problem is actually in MMU_Init. This is the culprit:

for(i = 0x80; i<0xA0; ++i) {
    MMU_struct::MMU_MEM[0][i] = MMU.CART_ROM;
    MMU_struct::MMU_MEM[1][i] = MMU.CART_ROM;
}

After doing a lot more testing the problem was actually from the MMU_struct
access. I could get it to trace something to the screen up until that
point. A simple trace of "MMU_struct::MMU_MEM[0][0x80]" triggered the same
results.

I am still unsure as to WHY this is, though. Looking at the original
Desmume code, there is no difference. Of course, the original Desmume has
since updated the MMU code significantly. Trying to put in the new code
didn't work.

At least it's a bit more pinpointed, though. If that helps at all.

Original issue reported on code.google.com by dancinninjac on 13 Feb 2010 at 12:36

Code dump after select device

Please provide here info if you got this error.

1) Your SD card vendor, size, class.
2) Your region.
3) Last revision that worked.
4) Revision that not working.
5) You compile it yourself or download it. Where you download it.
6) Any additions from you.

Original issue reported on code.google.com by AndreyLegchilin on 5 Apr 2010 at 3:34

Controls.

Just throwing it out there... You guys are more than welcome to borrow
WiiDS's button maps. They should move over to this project simply with only
a few changes (removing/editing the libwiigui functions). They're located
inside input.cpp/.h and btnmaps.cpp/.h. You'll also need to add support for
wiiuse and wpad, if you haven't already.

Original issue reported on code.google.com by [email protected] on 29 Mar 2010 at 10:46

Memory corruption

What steps will reproduce the problem?
1. Run DeSMuMe r154
2. Load Super Mario 64 DS (U)
3. Walk around in the main story

What is the expected output? What do you see instead?
Expected: Walk around and have Yoshi go where I tell him to.
Real: Yoshi warps around, not paying attention to any boundaries.

What version of the product are you using? On what operating system?
r154, DeSMuMe Wii

Please provide any additional information below.
This should classify the game as "Unstable" since only the Minigames work 
right.

Original issue reported on code.google.com by [email protected] on 31 May 2010 at 10:23