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.