mic

to be continued..

I put up sources for parts of the emulator every once in a while (eg the source of the latest MMU plugin was released last night). The reason I don't release the source for the entire emulator with each version is mainly because it's such a boring task to package the sources and I'm too lazy to do it.

The swi 255 method was added because people wanted to be able to output strings to the debug window and it's the same method that some GBA emulators use. Noone has suggested a method that is known to work on a real DS.

It's not a deliberate limitation, it simply doesn't run any commercial titles yet. And even when/if it would, its focus still will be on developer features.

If you have a test rom that shows this error I can take a look at it.

I'd say this is the key point for me. But we do share information among the authors - we just have different ways of implementing things.

There's no company, we're just hobbyists. Anyway, Dualis only runs homebrew roms at this point, due to some key aspects of the machines that aren't emulated yet. iDeaS is currently the emulator closest to have commercial games playable. But I haven't used it so I wouldn't know how.

A is X and S is Y. What doublec said sounds familiar, having looked at the source of an early tetris version, but I'm not sure.

I had the division software interrupt mapped to the wrong number. Both demos now work.

Well i extracted the modulo code from libgcc (which is also the one i found in your ROM) and ran it in Dualis - worked properly, so that doesn't seem to be the problem. So the bug most be occuring at a later point..

If you have a.bin/.nds that does this, i can check it out.

You *can* access the debug console. Use SWI 0xFF (255) and put a pointer to the (null-terminated) string you want to print in register r0.

It's a bug in the emulator's 3D emulation, so there isn't anything you can do about it in the current versions.

elektroplankton, meteos, submarine_tech_demo and zelda_gallery are no longer crashing. They're not working either though, since they require both processors to be emulated to function properly. But it's a step in the right direction.

There's a set of nine registers you can read at 0x4000680-0x40006A0 to get the current vector matrix (3x3). Just make sure the geometry unit isn't busy first, or you'll get bogus data.

Both screens are controlled by the ARM9. The ARM7 handles sounds, the touchscreen and some other things.

Yes, what you call CX and CY are the rotation/scaling position registers. The real scrolling registers are BG*HOFS, BG*VOFS (which only apply to text BGs).

You're talking about the rotation/scaling position registers now, right?

It's being developed on a Win2k box, and it runs on XP as well so there's no problem there. The GPU requires MMX and Conditional MOVes. SSE2 will be used if available, but isn't a requirement. Other reasons for the GPU failing could be that it failed to allocate sufficient memory (not so likely) or that neither OpenGL or Direct3D could be set up properly.

The reason some demos resulted in dualis just shutting down was due to a bug introduced in r10. It occurs in demos that enable one or more BG layers before having set up the VRAM banks (it is perfectly legal to do so, but it triggered the bug in r10). I've fixed this now, so those demos should work again in the next release.

Yeah, old graphics drivers are a likely problem source. It seems especially so with nVidia cards.

Gorilla and Nibbles both work fine in the new version that I just released, but there's a trick to it: Go to the memory tab in dualis and select "v2" in the "IPC format" list - et voila!

Touchscreen doesn't work in a lot of newer demos in dualis because they've changed the structure of the touchscreen data (again)

The reason for the screens being white is that the scanline renderer is searching for an appropriately mapped VRAM bank for each active BG. If no suitable bank was found for any of the active BGs I should draw just the backdrop (which I'm not at this point).

That'd be swell.