Two9A

There's only one developer here. If Nukefall throws me what he's done with the config, there'll be an official contribution, but I'll still be the dev I started with emulating the GBA, but the code is (most)all my own work; you could say I started on this from scratch. If you grab old versions of DSemu, you'll note they can only open GBA demos. Even now, I have more screenshots of GBA stuff running than I do for DS, and this situation will remain for a while. Try converting from hexadecimal to decimal.

Someone understands my code? This isn't right. Well, work backwards from the child window. Take the debugger window. It has its buffer blitted in emuRefresh (one of a few places). Where does the buffer get filled? ARM7status, which has a reference to dbuf. Where does dbuf get passed into the ARM core? emuInit, with ARM7init after it's been allocated. It all ties together. If that made sense, you're a better man than me.

You seem to be getting stressed. There is a reason for the CPU hogging; it's doing work all the damn time. As for the 0.01fps, I dunno what the issue is there; I get about 10fps on a P3-600. If you take particular issue with the slowdown and the buggy output, I'd suggest that you fix it. The emulator is opensource, after all.

Indeed so. The GBA has an ARM7 core now, whereas the DS has an ARM9. Note that these aren't FAILs, just messages. Most of the time, you can safely ignore log messages until they are preceded by FAIL. I happen to like using the logfile to write out pertinent messages for debugging purposes; it's not all bad.

Thanks for the tests. The ARM v5 tests are bad because the GBA CPU is no longer an ARM v5. It's what it should be, an ARMv4. This extends to Fill1, since it employed an ARMv5 opcode to stop the CPU, which no longer gets executed. As for fontdisp, it's more a stop-working than an error-out (here, anyway); and it's my skills at SWI handling that're letting me down, I think.

I can't duplicate this behaviour in 0.0.3a, I'm afraid. That either means I managed to fix a bug I didn't know about in my huge hack session, or it's a problem with my end. Try it, and see if you still have the issue there. You people expect too much I'm on that, should be ok by the next release.

As Nukefall's stated, the DS is based heavily on GBA technology, so there'd be a GBA core in the emulator anyway. It only makes sense to expose it, and let it run stuff. Sure, the author can tell ya. Everywhere. Just do an all-file search for GetPrivateProfileString, and you'll turn up results from all over the source. The results should be mainly from glds/glgba, though.

I'm thinking about starting up a tutorial series about DSemu and what it's made of; it seems there's a little demand for it. Of course, it could be a while before I do make a start.

If you've got the hour to spare, please go ahead. It will have to be plain API though; I don't feel like spending weeks trying to integrate MFC. You should feel the pain I go through when I code GUI, it's good for you

Perfectly valid, since you wouldn't expect a DS emulator to run GBA software of any kind. I've never tried anything commercial either, so I haven't a clue how it fares on that stuff. People seem to be getting good results from some demos, though.

I did now. There's an armwrestler in the DS section as of 2 minutes ago.

Mm, and I haven't the faintest clue why. Unless mic changed the code between versions; because the CPU is the same ## After checking with mic, it is indeed the case that Wrestler's code has changed; the last GBA version assumed that saturation occurs on SMLA, but it doesn't really.

Why does no-one tell me these things? And it makes no sense for Dualis to display while DSemu doesn't, if the CPU cores are equal on functionality and the GPU parts that are used exist too.

Dang, boy, you work too quick for me. *left flailing in the wake*

Just in case, would it be asking too much to shove a GDI output in the GPU plugin? You can probably guarantee output on all host computers with the three options combined.

Bleh. Even on a GBA rom? I might have to put in a manual selection for GDI instead of just a fallback.

Dunno how exactly you manage to do it, but you seem always to grab a zip that's in the middle of being compressed, or something similar. I did a full rebuild and recompressed the zip, all works fine

Looks fantastic. I sincerely hope that source code is available, because DSemu direly needs a configuration dialog. If not, I'm gonna have to start debugging that app, and I don't wanna do that.

Just as an aside. You realise that JPEG was probably the worst possible format for those screenshots, if you wanted to retain any kind of quality? The graining on the menu bar is simply unacceptable, in my personal opinion I always use PNG.

I'd expect cube, ship, texture and tri to blackscreen, since they're 3D. davr should work fine, though. Haven't seen the rest, so can't comment thereon.

I refuse to believe that DSemu can do anything better than Dualis. Got a copy of that ROM?

Fantastic; great testing work, sir. The credit really should go to other people, since I didn't write most of the new GPU; all I have is the mosaic code hacks.

Ah come on, the debugger isn't that bad Great work, sir. I suspected it was to do with the new Thumb core, but I couldn't be sure. This is ample evidence. I'll see what I can do

And it's exactly how we've all been doing things for weeks, sir. Of course, none of the relevant demos actually run here, so I can't show anything.

X and Y are the two new buttons on the DS, in addition to A/B/L/R/dpad. DM is DesktopMan, who wrote the Tetris demo; I dunno if he checks the status of X and Y, see. And very appreciated it is, sir. It's good to know the current status of other projects in the field. PDroms.de is starting up a DS section; there should be a fair few demos on there by now.