I keep the dsemu Darcs repository updated between releases for those who want to try out features between releases or to hack on the code. Details are here:

http://www.double.co.nz/nintendo_ds/dsemu.html#source

Recently I pushed a partial implementation of the IPCSYNC register. This is used by the Nintendo Downloadable E3 demos to synchronise actions between the ARM7 and ARM9. I'll post on this thread as I add things to the darcs repository.

Currently working on:

- Finishing IPCSYNC. Raising interrupts when the register changes is all that needs to be done.
- Fixing implementation of coprocessor 15 memory regions. The memory access routines do not take into account the fact that the regions can be changed. This affects ARM9 memory access.
- Implement FIFO registers.
- Try to get dslinux further along its boot process.

Still looking into what is lacking in the DS graphics support.

Any requests for features? I can shuffle the order of things around if there is interest.

I don't know anything much on the technical side, here's my list:

* Get X and Y keys working

* Get graphics working better to whatever level you are able to do

* At one stage dsemu could play GBA demos, this hasn't worked for a while. Although not important (there are other GBA emus around), the real DS can play them, so any DS emu should be able to as well.

* Is it possible to read a rom's header info to determine if it's a GBA or DS (wifi) or DS (passme), or whatever else? Rather than manually loading GBA or DS?

* Be able to support passthrough (PME / DS.GBA / NDS.GBA) demos

* Sound

* Is it possible to somehow automatically determine what kind of touchscreen support is needed (different ndslibs) and work accordingly?



I'll post more if I think of something.
Hope it's not too much.

Thanks for that. The GBA emulation is broken because I don't build the gba DLL file. I'll be including that in the next release or two. Hopefully I haven't broken anything in that area.

I can determine if things are a gba or ds file I think, I'll have a play with it.

The touchscreen support should work whether ndslib1 or 2 is being used. I've implemented the lower level touchscreen support (the serial access to the touch screen controller) which all touchscreen access goes through eventually. My initial stab at this should work for ndslib as I specifically implement the access protocol they are using to talk to the touchscreen controller. Other libraries will probably work. Some do things slightly differently and I'll be more completely implementing the touchscreen controller soon. I recently downloaded the docs for it so hope to be able to fully emulate it.

On the good news front, I got DSLinux partially booting yesterday. It runs up to the point of mounting the root partition and then fails there. This required lots of fixes to the ARM9 instruction emulations. The code is in the darcs repository. DSLinux does lots of stuff with interrupts and cpsr manipulations that most homebrew demos don't so it's a good test. There are still a few problems in the emulation of some arm instructions so I may need to write some test cases of all the instructions to iron things out. It'll be good for regression testing changes to the emulator too.

So I'm pretty much working in the following order:

1. Fix ARM instruction emulation bugs.
2. Get X/Y working
3. Finish touchscreen implementation
4. Put GBA back in the emulator.

5. Fix up graphics issues.
6. Improve debugger
7. Sound, and other stuff.

I'm pretty fluid though, so the list may change. Number 1 will take a while so it'll be a bit longer for the next release. I need to write some short ARM snippets that execute every emulated instruction to test they all work right.

That's a nice list of things to do . Keep up the great work .

I've released 0.4.5 with some fixes before I start the things mentioned above. It contains a speed improvement, various bug fixes, and partial mode 5 support. Finally Space Invaders 0.2 runs! But quite slowly unfortunately. Something to work on.

I'll have a look when I get back home, in about 9 hours.

I'm hoping someone will make a news item in the meantime.

cool, i like playing Space Invaders. Nice work doublec

I've added to the darcs repository for dsemu code that more correctly implements the vram bank mappings. This change allows the latest WinS to work correctly, including both screens and keyboard.

Unfortunately some demo's that didn't work before but partially ran now crash so I'm tracking that down before I release a new version.

I've also got submitted patches that will go in the next version for x/y key support and a logging window for the GUI.

nice progress although looking through the debugger i noticed the opcode MCR outputs pF instead of p15 which it should output they are the same but still just looks wrong

Nice work Chris keep up the good work.

Submitted patches? People sending you code? That sounds good.

Whoa! Accepting patchs from other coders?! That is an awesome idea! Just make sure to let people know what you are tackling and what you would want others to fix. That way you and us coders don't both do the same thing at the same time.

Thanks Normmatt, I also noticed the pF, p15 thing. It does indeed look odd.

Darcs makes the processing of applying patches from other people very easy so I'm keen to get any input from any other developers. I'm hoping this 'work in progress' thread will give others ideas of what I'm working on or a chance to say 'hey, I can do that'.

Or if, in using DSEmu, you see something not quite right, feel free to hack the source and send a patch.

I keep the darcs repository updated quite often on what I'm working on so doing a 'darcs pull' regularly will show what I've submitted.

On the 'bad news' side, my PC died last night. Hopefully it's just the power supply and I can pick up a new one in a few days and get back into it. So no DSemu updates for at least a few days.

Hmm, DSEmu development seems to be bad for the PC

It's an omen! You should cease development immediately!

Then again, it could also mean that you leave your computer on too much and you got a crappy power supply. I'm hoping mine will hold up running 24/7 for at least 4 more years.

So DoubleC when can we expect a new release?

Next weekend if not earlier.

I've updated the darcs repository with some new patches. These include X/Y key support contributed by Normmatt, partial FIFO support, some key handling fixes and GBA support re-enabled. Although the latter probably does not work, it's re-enabled for others to work on. When FIFO support is completed I'll release 0.4.7, including any other patches for other contributers.

FIFO support is completed and added to the darcs repository. There are a few bugs I want to try and stamp out and then 0.4.7 will be released. Some of the E3 demos run further now, but it looks like the hardware divide and squareroot registers may need to be implemented to get them further along. I tested a couple of GBA demo's with the recently re-added GBA support and they worked fine.

Sounds like good news. I have quite a few GBA demos and I'll be interested to see how they perform.

If you're interested in, I caan look at the square root and divider accelerator
I've already had a look at it, I just need to figure somthing out, and I think it'll be complete

Well what do you need to figure out?

The integer square root do not exist in C or C++ library. My first idea was to convert it to double, do the square root ad convert it back. but the conversion of a int64 to double can cause loss of data.

For now, i'm using this solution, knowing that it's both inaccurate and slow to execute.

I've made small test apps with libnds that just display the result of some division and square root. I'm just waiting my flash linker to validate the result of the emulator.

//EDIT : I've send a patch to doublec

Great, thanks! I'll take a look at it tonight.

I've looked at sprite code.

It seems that VRAMmap is never initialized, so when the program writes data int othe vmemory, as the vram pointer is null, the write is just skipped.

It seems that video memory remapping register is never written. Nobody knows any default value of it?? It maybe explained why some demo works (in fact, if they remap VRAM, it should work)

I will have a look at this tonight.

Crazyjul

VRAMmap is initialized in MMUMaininit in dsmmumain.c. It is initialized to nulls and then modified by writes to the VRAM registers. This is a recent change to get memory mapping working correctly (from 0.4.6). If you look at the MMUMainremapVRAM_BANK_A, etc functions you'll see where the initialization is done. Not all of it is implemented as I'm unsure how things like extended palletes, image textures, etc work.

I have noticed some demos don't map the VRAM by writing to the registers. I wrote a simple test of this and when writing to the memory area (VRAM_A for example), the write appears to work but when you read the value back you get 0x00, not what you wrote. So I assumed that there is no default mapping.

This may not be the case for sprites, or may not be the general case and only happened to be the case for the one that I tested of course.

Prior to me doing the VRAM mapping code sprites did not work correctly either so there may be something more fundamental wrong.

There is a problem with Thumb code emulation. GPFerror noticed that some of his demos don't run on dsemu if compiled with '-mthumb' but do if recompiled with '-mthumb-interwork'. For the former all that would happen is a black screen. This may be the reason why some of the demos give only a black screen.

I'm currently looking into this, to hopefully fix it for the 0.4.7 release.

So I'll try to make a lot of test. I'll start from scratch. From what I've understood, there are default value in vram mapping register, when I'll get my flasher, I'll try to read them. I will also do some test.

For the demo that does not work when not intializing the vram, they seem to write sprite at 0x06004000. On DsTekWiki, this is shown as Sprte memory, maybe when no memory is map to this address space.

Crazyjul

The darcs repository has been emptied and fill with tutorial

Where all the code had gone??
Where can I found the source??

Thanks

Crazyjul

Oops, my fault. Copied stuff into the wrong area. I've fixed it now and the repository is back online.

From what I've seen, it seems that DS graphic mode is close to GBA graphic mode when nothing is initialized.

Does somebody can approve this??

Crazyjul