Technical details

[Bart]

Is the aforementioned API manual the same as this pdf?
http://web.archive.org/web/199806100621 ... guide4.pdf

That's the one!

[Arbee]

At the moment, I am quite content in learning about addressing systems, endians etc. It's fun.

The good news? If you really think that's fun, you have precisely the right kind of what I half-jokingly call "brain miswiring" to write emulators

In terms of my IDE I am using CodeBlocks, which I find to be perfect for my needs, though I find the debugging tool to be very vague. Throwing up an error when compiling and giving a nonsensical statement telling me what is wrong isn't particularly helpful.

For the record, compiler errors are a separate matter from debugging. You may already know that; I just interpreted the quoted part as being a link.

I post here and try and help users regarding specs and stuff, but bothering some of you emulation big boys with - what you would consider to be fairly trivial - questions, I feel a bit, I dunno, cheeky/daft/like an annoyance! Perhaps setting up a separate forum folder for general programming assistance may be worth considering if you weren't averse to proletariat scum like me asking daft questions?!

One thing I've learned in my professional programming career is that there are two kinds of questions: things you can punch into Google and figure out pretty quickly (many of GCC's more unusual compiler errors fit that category), and things where doing that would waste a lot more time than if you simply asked someone who knew the answer. Contrary to what a lot of users think, guys who write emulators aren't especially "elite" and none of us are likely to solve cold fusion. Thus, it's not at all imposing as long as you're genuinely curious about something and trying to actually learn. (There are people on MAMEWorld who've asked the same question and gotten the same answer 5 or 6 times; that's obviously not learning).

This is going to sound like insincere toadying, but I'll say it anyway, I genuinely don't think that emulation authors appreciate how influential they are to aspiring coders - and while you get plenty of OMG Y IZ SEGA RALLY 2 NT WURKING FIX IT NAO! comments, which must be a little disheartening to say the least; the vast majority of people who use your emulator appreciate the time; effort and complexity of such a project.

Everyone has some hook that gets them into programming. For me, it was the realization that video games were programming just like the crappy BASIC I'd figured out on my TI99-4A. Nowadays it's both likely and reasonable that emulation can be that hook.

Oh, and while I'm a much older fogie than Bart, I love the new web technologies. Especially in the hands of the demoscene. Tools like GLSL Sandbox are fantastic: live, online editing of OpenGL shaders with color syntax highlighting and you see the changes take effect as you type. That's barely possible offline half the time

[Bart]

Oh, and while I'm a much older fogie than Bart, I love the new web technologies. Especially in the hands of the demoscene. Tools like GLSL Sandbox are fantastic: live, online editing of OpenGL shaders with color syntax highlighting and you see the changes take effect as you type. That's barely possible offline half the time

That's pretty cool. My primary objection to the web stuff is how horrifically slow and bloated it is. I think Google's NaCl is a better approach, although tying it to X86 is a sure-fire way to limit its adoption. A more flexible, VM-based approach (like Java or .NET) would be much nicer than JavaScript. AFAIK, most implementations of JavaScript are still interpreted and do not use JITs. Things like HTML5 and WebGL are a step in the right direction but they're hampered on the front end by JS. Despite all the pretty stuff that can be done nowadays (albeit tediously), I think there is a tremendous amount of room for improvement on the front end/UX side. Even the best web apps feel constrained, as if the underlying idea is begging to break out.

[Arbee]

NaCl as it's currently deployed in Chrome 13+ (and MAME for NaCl) *is* VM-based; the "executable" distributed is LLVM bytecode, which then can be JITed on any processor LLVM supports (which is a rapidly growing list) and run in a sandbox (no direct host file I/O, among other things). Definitely a much more clever solution than their original plan with X86, and MAME performs pretty well on it with fairly minimal changes. The downside is nothing supports it except Chrome.

JavaScript is JITted in all major browsers, by the way. Chrome 12+ optimizes the most aggressively, followed by Safari/generic WebKit, IE 9+, and then Firefox 6+. (Opera JITs too, but I don't know how their performance is). On mobile devices, iOS, Android, and Windows Phone all inherit JIT from their desktop parents so they have it too.