Two9A

Sorry for the delay, first of all. I don't pop by here much any more. To your opcode. E is simple, condition "always". 12 is definitely MSR_cpsr/reg, and the 1 after that means it's a "control-field" transfer, with r0 defined down the bottom there. I've inserted another couple of spaces in your bitfield above, which should allow you to highlight that. As far as ddi0100e (the opcode reference) says, this is unambiguously "MSR cpsr_c, r0".

Note that Stephen says the HTTP client is easy. And of course, it is; all you have to do is connect to port 80 and grab a HTML. Then what? You have to parse it. That's the point made further up the thread: parsing isn't easy. And then you have to render the tree you've parsed out, and that's an order of magnitude harder again. So go ahead, write a HTTP client. It'd just be a telnet connection with a fixed destination port of 80

Alright, lemme chip in here. At present, Moonshell can barely play MPEG1 at a framerate more than a slideshow. I think that's due, at base, to the fact that the IDCT and Huffman algorithms haven't been ported to optimised ARM9 at this time. Because the MPEG library used in Moonshell is portable C (afaik), your problem lies there. We'll ignore the fact that the use of wifi and packaging a stream for use over the network takes up significant processor time, and we'll ignore audio too for now: the root issue is that JPEGs (being MPEG I-frames) simply can't be decoded fast enough. Fortunately, there is something in the works on that. I've been interested in MPEG for a while, so I'm probably gonna make a start on a JPEG decoder written (at least the optimal bits) in ARM9 asm. No guarantees, since y'all know how I am with difficult projects (Sinking ship, anyone?), but we'll see how we go.

As far as I understand things, Chris isn't going for compatibility here primarily, although it's an honourable goal in itself. It's the step-debugging of the CPU cores that he wishes most to leverage, hence features like the gdb interface. (How's that coming, anyway?) Please remember that DSemu is still an opensource project, and now it even has a code repository (ask Chris for details on that), so if you feel you can improve the codebase, dive in and contribute.

Of course, then your problem becomes how to service interrupts that happen every two clocks. Not sure you can do a great deal in that amount of time.

I'd do that, sure, if I was in the country. If you remember, I've been in Turkey for about 9 months now, and the hard drive's back in England. I may attempt a recovery when I get back, but I dunno what will be possible to salvage by then (if the hard drive's even still around).

As you've probably worked out by now, Tuesday saw my webserver's hard drive fail. I lost the database of progress reports for DSemu (which I've never backed up, being a clever sod), although my source codebase is safe on another drive. So, I've called an end to the DSemu-ng project, and am throwing the source out for people to use. Essentially, it'd be great if the plugin architecture could be integrated into something. This iteration of DSemu has a plugin architecture at least, unlike the original, and it's relatively complete. The schema can probably do with a couple of re-jigs, but overall it works. If you want documentation on how it works, let me know and I'll throw some to you. Have fun.

Oh, hell yes. The current distribution (20060103) has dynarec tables defined for compilation, but I believe I've only added compilation instructions in the Makefile for Unix (that being what I test it on). If you want to compile it with mingw, have fun editing the Makefile. Apologies for the delay, by the way; I don't drop by so often

And to you, sir. Hopefully, 2006 will be a productive year for all of us; personally, I'm hoping I can do some work this year.

I just thought of something. If your lecturer/professor keeps abreast of the latest developments in DS (including wifi), it's quite probable that he reads this forum. Keep that in mind, since he'll probably ask you to put this place down as a reference for your initial research/feasibility report

As far as I know, Java's a totally open specification. It'd be quite possible for someone to write a JVM for the DS. It wouldn't be the easiest thing, however

Sure, it'd be nice, but it's not exactly vital functionality for the application. Personally, I'd much prefer a working application before the tacking-on of various bells and whistles. (Ignoring the fact that I don't have a DS with which I could use the wardriver anyway )

It's quite possible to write a JVM to run on the DS. With some assembly-level optimisation, it might even run at a usable speed. And then you can run whatever Java apps you like. Could be quite a fun project, in fact. (Not that I'd take it up, having never coded for the DS.)

It may be that MKDS appears in the shops before sgIP is complete and polished. The two do entirely different things, however. MK connects over WiFi to let you play MK. sgIP allows you (the developer) to connect over WiFi to do anything you like. It's not just the simple fact of WiFi that's being provided here (I know 802.11b's anything but simple, but skipping over that); it's a homebrewn IP stack as well. Perhaps MKDS will be the first WiFi app, but sgIP means there'll be hundreds of others. And Stair-san will polish the stack when he's able, don't push Just my two English sterling pence on the issue.

Sure, sounds good; I'll take it. Good to hear that it's all BSDd, since that's the licence for DSemu-ng; can't go around distributing lgpl code under bsd, now can we. Just throw a link or the file in my direction, it'll be much appreciated.

Erm. I didn't actually do any setting up, having a superripped commandline version of MSC++; all I did was dump the FL includes in INCLUDE, get someone else to compile the libs, and dump those in LIB. I haven't the first clue how to go about building Fltk

No, no it's not ok DSemu-ng links against Fltk 1.1.x (1.1.4 in particular is what I dev with). I have no idea if 2.0 will work. Also, you won't be needing SDL any more; I finally got around to removing the references to SDL for the 1101 release.

I've noticed something through all your posts, JaJa. Transmission Control Protocol/Internet Protocol. tcP/ip. </pedantic>

Ok, as promised, a new fileset for DSemu-ng. I've simplified the Windows compile a little, and added an OSX makefile based on recommendations provided to me. Please try them out, and let me know how things go. http://ng.dsemu.org/dsemu-ng-20051101.tar.bz2

Now now, let's not get all bitchy up in this 'ere joint. We are, after all, peace-loving and friendly people who happen to like murdering newbies with axes every now and again. But Not Every Day.

As of the version sitting on my hard drive right now (which I'll probably put up in the morning), you need: A compiler. This can be gcc for Linux/OSX, MinGW for Win32, or MSVC++. The Fltk libraries and includes for your compiler. If getting them for MSVC is a pain (it was for me), I can upload a copy of the libraries I use in compilation. (The current version on the website needs SDL and SDL_mixer libraries, even though they're not used any more. That dependency has been removed since.) So that's it. Once you've got those, grab the package I'll put up later, and give it a trial run. I've got verified compiles on Linux and MSVC (from me) and MinGW and OSX (from others), so you should be fine.

Catching doublec is gonna take a bit of work; it'll probably be a while. The major problem with releasing builds is that I only have a Linux box; I can compile for Windows through Wine, but I can't guarantee that anything'll work, because I can't test it. Eventually, I do want to have all 6 channels of GBA sound, so I'd have to write a mixer. I did take a short look at PortAudio, and it seems to be on about the same level of simplicity as the SDL standard sound. If the mixer turns out not to be too much of a hassle, then perhaps I'll check it out.

Why, to our esteemed sgstair, of course. Well done, sir. As of now, this is merely the bounty for documentation of the registers (no mean feat in itself), which is half of the bounty: $1400. The other milestones aren't far away. I've put a post into Slashdot, as have a couple of other people. Spread the word.

DS functionality's a long way off yet. I'm gonna try to attack sound first. If I can add one channel of sound, that'll be a lot more than DSemu's ever had before.

That's very kind of you to point out, but the feature's already there. The problem is that I found a bug in the MMU yesterday, where the bytes are being swapped twice for MMIO memory. So I've prised that out, and you might have more luck with the next release, when I get the time to put a tarball together.