mic

I haven't solved that yet, since I don't know of any demos that exhibit that behavior. Might have to write one myself.

Found the bug. Bank I was getting a 128kB size when mapped to the sub BG, when it's actually only 16kB -> crash. (This is what you get when creating large arrays by copy-pasting

The IRQ/timer issue is news to me. I'll look into it. For the VRAM problem, what mode are you using? I'm not familiar with the ndslib defines, only with the raw bitpatterns. If you posted a demo eventually that'd help, since that way I could figure out which line of code in the emulator is causing the crash which makes finding the reason behind it easier.

The touchscreen issues is likely because of changes made to the IPC structure in ndslib. If I changed dualis to handle these changes it would break all the demos compiled with older versions of ndslib... Once the second (ARM7) processor is emulated this shouldn't be a problem anymore.

The best solution would probably be to have the ARM7 code running from its own dedicated RAM. I don't know if this has been done by the people who are working on the linker scripts and C runtime (mainly WntrMute). As far as the SWI goes, I know it was broken in the past in NDSLIB. I haven't checked out the last couple of versions so I can't tell you if they've fixed it yet.

The nds format has been supported since release 6, and release 8 and later will warn you if you try to load a file with a bad header. The main reason for bad headers is that in some cases people have renamed.pme files to.nds, for reasons beyond my knowledge.

Yes, the nds format is supported. You load them exactly like you would load a bin file.

I have no idea about iDeaS, but dualis does not support windows atm. I don't think normal windows (as opposed to OBJ windows) would be that hard to add, but to my knowledge there are no demos available that use them, so I wouldn't be able to test for correctness.

I just had some real life things I needed to attend to, so I put dualis aside in the meantime, as well as the forums, irc etc. But I'm getting back on track with the emulator now.

From the README: Keys ---- D-Up Up arrow D-Down Down arrow D-Left Left arrow D-Right Right arrow B Z A X Start Return Select Space L L R R

He's not. The real answer is - I don't know.

Dualis and any DS SDK has nothing to do with eachother. If you want some free development tools you can get them here.

I took a look at my code and I think I've solved the problem (see the screenshot).

In that case I simply don't try to load anything, since it indicates that the user pressed the Cancel button on the open dialogue, or the dialogue failed. There is no debug build. Nor can I make one since I don't have all the relevant libraries.

GetOpenFileName is checked for a proper return value. It could have something to do with your japanese Windows. I'm running swedish Windows myself so I don't really have any way of testing it with Windows versions not using the latin alphabet.

The first thing that's done is to open the "Load ROM" dialog, which uses the standard win32 GetOpenFileName API call. Could it be that your system is very low on memory? Since the Windows file dialogs seem to consume a fair amount of memory when they're active.

The sprite bug was due to a mapping mode error, and has been fixed since the last release. As far as 64x64 backgrounds are concerned I need to do some more testing, so if you have a test to release that would be good.

There's no special limitation for either core. You're allowed to have 128 visible sprites on both cores, for a total of 256.

Hflip works for 16-color sprites already. But if the sprites goes partially off-screen it will crash since clipping isn't done properly for hflipped 16-color sprites.

Dualis doesn't emulate much of the 3D features atm, since I've focused mainly on the 2D hardware. The cube- and ship demos are the only ones that run kind-of properly. Seems to be the opposite story with iDeaS; good 3D, not-so-good 2D.

If you click on the menu in Darkstar (the asterisk) there should be a "DSPAINT" option. Once there, you draw on the bottom screen. Flip the screens with the blue arrows on the right-hand side to select drawing mode and color.

Here

Actually, 2 is red and 12 is dark blue. This is the color theme setting that you get to select on a real DS in your personal settings. The only demo I know of that uses it so far is Darkstar (a multi-application demo containing dsPaint and smo mini games). Darkstar supports on-the-fly theme changes, which will be in the next release of Dualis (ie changing the theme at runtime using the combobox on the "Memory" tab).

Dovoto's 2D_example uses 128 sprites and works fine. If you have your demo available somewhere I could try it.

I don't think Battleship even uses the calibration data. I know how I could fix this though, so in the next release it should work properly in both cases.