Something I’ve been coming across a lot of late with Yabause is people integrating 3rd party open source code. Which by itself is good and fine, so long as the license is GPL compatible. For those who aren’t familiar with Yabause, we’ve released it under the GPL v2  license. Which basically means you’re free to download and modify the source code, so long as when you release your own binaries you include the source code, etc.(I recommend reading up the full license at GNU’s website).

Usually you can mix other licensed code like FreeBSD or Public Domain code as they are known to be compatible with the GPL. That being said, some open source licenses have goofy clauses or the like that restricts certain freedoms or requires you to do stuff like “advertise” the original creators or the like. Like for instance, the MAME license has a non-commercial clause that restricts you from selling the source code or binary. This conflicts with the GPL so therefore it isn’t compatible. Ironically enough, even though the wording is different, the Snes9x license is pretty much the same as the MAME license. So guess what? It isn’t compatible either.  Yet I’ve seen a few instances where people have added Snes9x licensed code to GPL code. Don’t. Thanks.

Why should you care? I mean we’re all doing this for free, right? Well, the problem ends up being that some of us may not be doing this for free. Then it potentially becomes a lawsuit. And lawsuits are expensive. Or even if we are doing it for free, some people don’t take kindly to mixing code from incompatible licenses. I remember an instance some years back with either the Sarien or FreeSCI project where they used code from MAME and the original owner of the code came down hard on them and rightfully so. I mean let’s face it, would you want people to respect the terms you released your source code under?

So yeah, it snowed again – like 40cm(or more) worth of it! Plus the wind dumped more of it in the driveway. Fortunately from all the exercise I’ve been getting all winter, this amount wasn’t too daunting, but still, it’s getting a bit hard to find spots to put it. Anyways, enjoy the pictures.

There was once garbage cans here

I’m at house number… Nevermind

I guess my neighbour’s getting mail today after all

So you’ve just written yourself a fancy new emulator with multiple cpu’s support and things are looking up. The only problem is, it’s slow. Not only is it slow, it’s just too darn slow. So you go back and optimize, optimize, optimize. And still, it’s just not very fast. So what do you do?

Well, there’s been all sorts of radical tricks people have used in the past. From dynamic and static recompilation(which I may get into another time, though I’m sure it’s been talked to death already) to high-level emulation. There’s one technique though you don’t hear too much about, but can yield some truly awesome results on cpu’s that end up waiting around a lot: idle detection.

The concept is that programs tend to wait on events to happen before they continue on with what they were doing. Like v-sync, dma transfers, a second cpu, etc. And most times the code looks something like this:

while (SomeVariable == SomeValue)
{
// Do nothing
}

So essentially the cpu is just spinning its tires while doing nothing productive. So how can we cut down on the waste? Well, first of all you’ll need to add a mechanism in your cpu emulation code that checks to see if we’re in such a state. You can either have your code check for certain instruction patterns, or use tables to speed things up. Once you’ve done that, then stop executing cpu instructions until you hit your next instruction executing phase.

At the next phase, see if the variable or register has changed, if it hasn’t once again stop executing cpu instructions. Keep repeating until there’s a change, then resume normal operation. It’s a pretty simple process.

People who know me know I generally hate it when people port my code over to [insert console or hand-held device here]. It’s not because I don’t like people using my code, but most times those people don’t properly evaluate whether or not the code will even run remotely well. Then, regardless of the results, they decide to release it for fortune and glory with no intention of ever making it useable.

And then I get random people asking for support on the project. Seriously folks, stop it. I don’t care how cool it would be to run Yabause, DeSmuME or anything on PSP, PS2, or god-forbid the NES. If the system obviously can’t handle it then don’t port it.

So I live in Canada. Ontario to be more exact. Normally we have light amounts of snow, you shovel your driveway for like 30 minutes and you’re done. Well, let’s just say I spent a large chunk of the day shoveling, and I’m just beat. Take a look at how much snow we got:

I think the accumulation over 24 hours was something like 40 cm. And then the worst part was we had north-east winds which blew all sorts of extra snow right in our driveway. Anyways it was nuts. Enjoy your balmy temperatures you darn Americans(and europeans)!

A few months ago I bought a wireless wii sensor bar made by a company called Asid. I was originally was planning doing some modifications to it, but after taking it apart, I changed my mind.

See for yourself:

For the visually impaired, instead of doing the standard clean mounting with screws you usually expect from electronics makers, they decided to hot glue everything. What’s worse, they even recycled some pcb from what appears to be an mp3 player(it says on the pcb stuff like “prev”, “next”, “play” “vol -”, “vol +”). All in all it screams quality engineering. What gets my goat is that people act all shocked and surprised when there’s lead in children’s toys from china, and yet that’s the usual for these guys. It’s all about doing it cheaply, even if it means cutting corners.

In the first part I talked about frame-limiting and some ideas as to how you can limit speed in a fairly accurate manner. It’s only fair to talk about the other part of keeping frame rates constant: frame-skipping.

Obviously with emulation there’s no guarantee you’ll have everything you want done for one frame in 1/60 of a second. Especially with the newer, more complex hardware it’s tough to do it all. You can’t really slow down cpu emulation since it’s vital for accurate emulation and you probably can’t live without sound support. About the best solution then is to just not draw anything to the screen for a frame or more until emulation catches up. If done right the users won’t notice any differences(unless you’re dropping a lot frames) and it’s something that everyone can live with. The only potential issue is that if the cpu emulation is taking signifcantly more processing than the video rendering, you’re screwed(since skipping frames won’t make that much difference).
Now then, here’s some basic pointers for implementing frame-skipping:

1. Don’t skip any more than I’d say 9 frames in succession. Heck, even that may be too much.

2. Just like with frame-limiting, you should be keeping track of timing every frame to see if a frame skip is needed.

3. Have some flexibility in your skiping code. So in case your frame is slow by like 1 ms, you don’t frameskip right away, but if the speed gets delayed by more than that, you skip a frame. You could also use this for frame-limiting as well.

So long as you keep those basic ideas in mind your implementation should work pretty well.

So anyways, normally I end up having nothing to write here, so I usually don’t. But once in a while I get a good question from someone which gives me a good idea for a post. This time I was asked about frame-limiting/frame-skipping in the context of an emulator.

For people new to the concept, I guarantee their first attempt(for at least frame-limiting) probably looks like this:

DrawFrame();
framecount++;
if (framecount > 60)
{
WaitUntilSecondIsUp();
framecount = 0;
}

For those of us that have already implemented a good frame-limiting scheme, you’ll know already what’s wrong with it You see, what you want is to have a steady frame rate regardless of how fast your emulator’s progressing. The problem is, say your system is capable of emulating at a speed like 100 FPS(a bit of stretch, but hey, some older emulated systems can run that fast and then some), if you render only the first 60 FPS and wait till the end of the second before you resume rendering, you’ll have around 4/10′s of a second where you’re doing nothing. Visibly, you’ll see gameplay going at a really jittery, disconnected pace.

A better solution is to calculate the time of each rendered frame and compare after each frame rendered to see how much you need to delay emulation by. There’s obviously a little more overhead, but the results are much, much better.

Well, it’s been a while since I’ve posted on here. Basically that job I had in spring finished before the fall and I’ve been looking for more work since then. Also during that time I was also trying to go back to university to eventually get my degree.

As I’m sure you can guess, what you plan and what inevitably happens is never one and the same. So basically I ended up contracting mononucleosis(also known as mono, the kissing disease, etc.) in August. I still don’t know how or where I got it from, but that’s pretty irrelevant. I also ended up resigning from DeSmuME(some of which was related to my illness, but not all).

So for about a month I suffered trying to get back to feeling normal again, and I did to some degree. I managed to get a whole lot more physical activity in, and yabause provided the mental stimulation I needed. Then about a month and a half ago, I ended up hiting some kind of physical relapse or something. I just had no energy. I’d wake up after sleeping for like 8 hours or so, be horribly groggy for 2-3 hours, then I’d be awake for about 2 hours and all the sudden I’d feel horribly tired again. Of course I tried fighting it and go to sleep earlier or whatever. But that didn’t seem to work well either.

So anyways, that’s where I’m at now. I’ll be seeing my doctor hopefully sometime during the next week or so(of course, it would help if I could actually make an appointment over the phone). And then we’ll see how it goes.

As far as Yabause goes, I’ve been working on various things here and there. Most of it went into the last release(v0.9.1), but there’s a few things I haven’t included or finished yet. The problem usually ends up being that some of the features Yabause’s needs are at times a project in itself, so I end up getting like half it done, and then I end putting it down because I’m tired of working on it.

Oh yeah, I picked up a Saturn USB datalink. Not too shabby actually. I’ll probably end up using it as a replacement for my commlink, but before I can do that I’m going to need a software replacement. It’s not that the software sucks, but seriously, I need more than -just- a utility that dumps the bios, exchanges saves, and allows you to upload a binary to 0×06004000.

Well, for those of you following DeSmuME and Yabause, not much has been done lately, I managed to get a new job as a software engineer(thanks to my pal Ben) so I haven’t had as much time to work on other things. That being said, I’ve got some things that I will be adding to Yabause in the near future and then hopefully we’ll see a release. As for DeSmuME, right now that’s going to have to be Guill’s and shash’s show. shash himself has been doing some awesome work on the GPU emulation and I think a lot of people will be impressed by the next release.