doublec

Most reports of 'broken SWI' are the result of not notifying the BIOS that the interrupt was handled and the SWI appears to hang. See here for details: http://www.double.co.nz/nintendo_ds/nds_develop8.html In a nutshell, with libnds, you need to set VBLANK_INTR_WAIT_FLAGS to indicate that you've handled the interrupt. If you don't do this, the wait for interrupt SWI will appear to hang as it is never notified that the interrupt occurred. So in your interrupt routine, when handling the vblank do: VBLANK_INTR_WAIT_FLAGS |= IRQ_VBLANK;

Thanks for the testing. Space invaders is scrambled because of it being built with a devkitpro prior to r15. This version of dsemu works best with devkitpro r15 compiled apps, whereas 0.4.6 is better for prior devkitpro built apps. The next version of dsemu will resolve these issues hopefully. 0.4.7 will also hopefully re-introduce gba support since Normmatt has voluntered to look after that side of things. For BIN files I think I'll probably provide a default ARM7. Currently nothing runs on the ARM7 for BIN files so the touchscreen won't work. The problem becomes, what ARM7 to use for default. IPC v1 or IPC v2. Maybe both. Any of the Neoflash competition apps would probably make good demo tests btw.

DSEmu 0.4.6 is now out: http://www.double.co.nz/nintendo_ds/dsemu.html Thanks to all those who contributed patches!

Thanks for the fixes. I've not yet received the patch though. If you are on Windows the automatic sending of the patch sometimes doesn't work. I recommend using the '-o' option to darcs send: darcs send -o file.patch http://www.double.co.nz/nintendo_ds/dsemu Then zip up the file.patch (so the emailer doesn't corrupt it on sending by inserting line breaks) and email me the zip file. I've not yet looked at the bios implementations for the math functions so i'll take a look when I receive you patch. Thanks again!

That would be great, thanks! The sram patch was a contribution I received and I applied the patch, but after I tested it I forgot to save and record the project.

I'll take a look tonight and see if I can find the problem. In the meantime you could try unpulling the latest patch: darcs unpull from within your darcs repository. Then try to rebuild.

Are you using the Darcs repository? Are you using the VC6 project files? Don't use the Makefile, it's out of date.

Next weekend if not earlier.

Sory Robbbert, I was referring to the original poster, pointing them to 0.4.5. There's no new version yet from the one you tested last time. I've done a few fixes but nothing stable enough to release a version yet.

The latest version of dsemu is available from: http://www.double.co.nz/nintendo_ds/dsemu.html It runs most of my DS demos. It doesn't run any GBA demos as I've disabled that functionality for the time being. I'd prefer spending my time getting the DS side of things working since there are plenty of GBA emulators around. The source is available if you'd prefer to add the missing functionality yourself of course.

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

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.

BIOSHACK9 is the ARM9 bios and BIOSHACK is the ARM7 bios. They're not actually the real bios but just the interrupt handler and some swi code. Source for these files are in the source download.

I still haven't been able to solve the crash on open/close thing. I thought I had but it was still there so I temporarily disabled the close and open gba menu items. I'm on the case though and trying to track it down.

I'm not sure the touchscreen will work in any 'bin' files as they don't include the ARM7 code. As I now emulate the touchscreen using the SPI interface, it needs ARM7 code to read it and populate it into the IPC structure that ndslib uses. So pretty much only nds files will have touchscreen support. I could probably code around it with a default ARM7 but then it wouldn't be possible to know what the bin expects. Is it IPC v1, IPC v2 or something else for example.

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.

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.

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.

The ds.dll file should be bigger by about 4KB plus the contents should be different. The changes in this version mainly add features that I don't think many demo's use too much though. Nice to hear some demo's work fully! I tracked down the cloes bug and it'll be fixed in the next version. I've implemented the DS IPCSYNC register which will be in the next version too. I'd like to try and get some of the graphics issues corrected too so time to learn a bit about DS graphics.

New version up, DSEmu 0.4.4 http://www.double.co.nz/nintendo_ds/dsemu.html This adds support for keyboard interrupts and implements timers on the ARM7 and ARM9. I also did a pile of fixes to the way interrupts are handled again, enabling my code for tutorial 8 to work on DSEmu. Currently it's the only emulator that seems to successfully run that tutorial.

Thanks makes sense, thanks. I've always used the 'X'. I'll fix the 'Close' bug in the next release.

Does it happen if you close DSemu while the demo is still running? Or if you pause the demo first then close? I'm not getting this crash so may be doing something slightly different in the way I close. Do you use the 'X' in the top right to close, or are you using ALT+F4, or the file menu? Does any of this make a difference?

0.4.3 is up. I've fixed the sub screen issue and added touchscreen support. I tested it on my demo's and they all worked except for the latest space invader version. I think DSEmu doesn't do mode 5 correctly - I haven't looked into the graphics part much yet. I ran a number of the demo's at ndshb.com and quite a few at least ran. Tic Tac Toe from ndshb.com ran and I was able to play a game which was a good feeling The biggest issue now is the lack of reasonable graphics support so the next update is likely to be a while away (assuming no glaring problem like last time) while I learn a bit about how DS graphics work.

Yes, I very cleverly broke the sub screen in my last update, sorry about that! The fix is in the darcs source code repository but I haven't built a new version yet. I'm working on finishing touchscreen support and fixing a tile bug first. Hopefuily I'll have it up in a couple of days. I've also fixed the problem of the LCD screens sometimes being swapped. For the touchscreen support I'm implementing the Serial Periperal interface for reading the touchscreen so it won't have to have the ndslib IPC structure hard-coded in. This will allow non-ndslib based programs to work.

Thanks for that, I appreciate the kind words. I've put up a new version ,0.4.2: http://www.double.co.nz/nintendo_ds/dsemu.html There are quite a few important fixes in there and it runs all of my own demo's to some degree. That is, they at least start and display correctly. The page above shows the list of fixes. There is an issue with tile display and I've somehow broken something that was working in 0.4.1. I changed code to get text to dispay correctly (so my demo's display text displayed using ndslib's console output routines) but it has caused some demo's to display their graphics incorrectly. I'll be working on this next. I also fixed a couple of memory errors, where memory was being free'd twice causing a crash/corruption. I use Linux about 90% myself. I've recently used Windows more just to do DS development. My flash linker and the wireless multiboot stuff is all windows based unfortunately. My day job is 100% linux development though. So I'm keen to get things working, firstly under Wine, and secondly natively. I welcome any help from anyone who provide code porting to any OS. I notice under Wine 20050111, which I'm running, that as you can start DSEmu, but as soon as you run a.NDS file it crashes. I'll try and find out why this happens and work around it. For a full port two things would be required: 1) Compiling under GCC. Some of the code uses inline assembler so this would need to be moved to GCC's syntax. Apart from that it seems quite portable. 2) The UI. I think SDL would probably be the best choice there? Neither of these are priority for me though since I'm keen to get it running better first. But hopefully in the not too distant future.