Friday, 17 September 2010

GBA emulator progress

Progress with my GBA emulator is going relatively slow, as this is a much bigger project than I realised. Emulating the CPU is probably the hardest task and is taking ages, but I'm getting there, one opcode at a time.

As of next week, I am going to be studying 5 days a week, and also on the weekends, so I probably won't be working on my emulator, or updating my blog as much, so I apologise in advanced for any long absenses from me. I have to do well this year in my college so I can get into university, so I will obviously proritise that over my hobbies and and such.

Anyway, thanks everyone for reading, more to come soon.


Monday, 13 September 2010

Emulation - what's the point?

Alot of people ask the question, "why bother writing emulators? why emulate a system when you can own the original?" etc... The motivation behind it is obviously going to be different for everyone, but I'll try to convey my reasons for (attempting) to write emulators, successfully or usuccessfully. Be aware that these are my personal opinions and motivation, there are obvious real advantages to emulators, such as using them to test games that are being written for a system that requires some sort of media, such as CD/DVD's or cartridges to be written to. There are many other reasons though, such as virtualization of operating systems, you know, Virtual PC, VMware etc...

First of all, let me just state that in my opinion, writing emulators is not the most rewarding hobby if you want to see immediate results and get immediate satisfaction, it takes alot of work to get any tangable output from an emulator. For me, this in itself is good motivation, as when you do get something working in an emulator, it feels much more rewarding, like you've really achieved something.

The other reasons why I try to write emulators are simple, I enjoy programming, I enjoy games, and I enjoy learning exactly what makes computers "tick", put all those together, and emulation seems the perfect hobby for me, which it is. Sometimes it is maddening, sometimes it makes your brain hurt, but these are all things which are necessary sacrifices.

The final reason is that I find the emulation scene very attractive, and one day, i hope to write (or atleast contribute to) an emulator that will actually be useful to someone, and not just a learning project for me. I look up to the authors of all emulators, but especially ones like the PCSX2, and Dolphin. One day, maybe I'll be knowledgable enough to do something to help out... *bwwwww*

At the end of the day, i do it because i personally find it fun, i would imagine that all emulator authors feel the same way, or else we wouldn't seen such an amazing amount of them out there today. I remember seeing a thread on the PCSX2 site, stating reasons why the authors chose to write the PCSX2, they said that they wanted to prove that PS2 emulation was possible, and they succeeded in that i think we all agree, but i digress.


Friday, 10 September 2010


I have a question for all you readers, as this is something that I seem to be struggling with recently. What keeps you motivated and focused?

It seems that i am not alone in this problem, I think it's fairly common amongst programmers for their mind to wonder every now and then. What keeps you motivated?

Of course I'm talking about anyone here, not just programmers.

Wednesday, 8 September 2010

Another blog

I just added a new blog page, which will be for posting (C++) code snippets, but I may post some tutorials too. The link is at the top of the page in the top menu bar, below the title. Hope it's useful to someone, enjoy :)

Code Snippets

Monday, 6 September 2010

Playstation 3 emulation?

Ok, so this I'm just about sick of videos like this, and this. Your average coder can tell you straight off the bat that these are obviously fakes, but is PS3 emulation really feasable at the moment, or even possible? The short answer is NO. Xbox 360 emulation and PS3 emulation is just not going to happen yet, for various reason which I will now go over briefly. (Note that these are my just my opinions, if you want better answers, then google the subject.)
  1. These threads on the PCSX2 site. here, here and here
  2. Any software emulator automatically takes on alot of overhead compared to the original console or system. This is simply the limitations of software.
  3. The PS3 has many different chips, which will all have to be emulated in sequence, unlike the PS3 which of course runs all the chips at the same time. For example, an emulator might run a scanlines worth of clock cycles, then emulate the graphics, then the sound... you see?
  4. The PS3 uses a Cell Processor with a PowerPC-base Core @3.2GHzper core. This CPU also have 7 cores. In an emulator, I can't even begin to think what kinda of techincal difficulties this would entail. Generally speaking, you will require a 10x faster CPU to emulate the CPU in question, but I think this is an extremely generous figure, the reality if probably FAR worse emulating the PS3.
  5. Lack of documentation, people have only just started to hack the memory of the PS3.
  6. Many more reasons which i do not know yet.

The people that make fake videos on PS3 and xbox 360 emulation are more often than not just attention seeking, sometimes, you get a person who genuinely thinks they have a PS3 emulator, and for some reason, it won't work... hmmm.. can't imagine why. Here for example

Here is an "interesting" blog I found that claims that he has a working PS3 emulator... i am disappoint if anyone believes him. I dunno, i guess some people will believe anything.

I just want to add that the fake ps3 emulators that arn't viruses may seem harmless, but in my opinion, it is quite insulting to the people that spend alot of time writing real emulators like the PCSX2 and Dolphin, and giving all their hard work away for free. It detracts from the emulation scene and makes a mockery of it... maybe I'm over reacting, i dunno, but either way, it's pretty insulting to the effort made by emu authors.

Here is a short, not very good video I made a while back exposing a forged PS3 emulator, it's pretty over the top but I hope it gives the message I wanted it to, PS3 emulation is not happening yet!

Sunday, 5 September 2010

Decoding the ARM instruction set

I haven't got far myself in decoding the ARM instruction set, but I have the basic idea, so I'll share it with anyone who's remotely interested. In writing this, I'm assuming you have a base knowledge about the ARM processor and you have studied the instruction sets. This will only just scratch the surface of the ARM instruction set, basically, it will give you a logical pattern to follow that can be used to decode the entire instruction set.

Unlike THUMB instructions, each ARM instruction is a full 32 bits, so decoding each instruction is a bit more complex, but not that much. First of all, take a look at the binary opcode format for an ARM instruction.

This reference isn't completely accurate though, it does miss some important details which we will need to decode the first instruction and which I'll go over soon.

So, to start off with, when we decoded the THUMB instruction set, we were simply using the upper 8 bits of the instruction, which allowed us to unambiguously decode the instruction. This time however, things are a little harder... let's say we took bits 27-20, and tried to figure out which instruction it is, this would be ambiguous, as more than one type of instruction can easilly have all of bits 27-20 unset (0). So, what we are going to do is take the high 8 bits (bits 27-20) and the base 4 bits (bits 7-4), and add them end to end. Here's a picture that should demonstrate the principle a little better.

In C/C++, to actually retrieve this value, you just need to to a bit of bitwise finicking. For example.

u32 instruction = fetch();
u16 _12Bits = (((instruction >> 16) & 0xFF0) | ((instruction >> 4) & 0x0F));

So now we have a 12 bit number that we are going to use to decode the instruction. Let's start from the beginning.

What if this 12 bit number was 0, ie every bit was unset. By looking at the opcode format, you can see that there is only 1 instruction format that allows this, the "Data processing / PSR" instructions. Now, already we know what type of instruction this is, but we need more info to see exactly what instruction it is. In the "Data processing / PSR" format, you see an "Operand 2" field. This field has a format that is not shown in the binary opcode format above, here is the specifications for the operand 2 field.

In our circumstance, the "immediate" bit (bit 25) is not set (all bits are zero, remember), so that means that we are using a shifted register. (I wont go into barrel shifts at the moment, this is beyond the scope of this.... you know the drill...). Here is a more formal way of putting it, straight from the manual.
"When the second operand is specified to be a shifted register, the operation of the
barrel shifter is controlled by the Shift field in the instruction."
  The shift field format is as follows...

I know this is all very complicated, but it is best that you read the manual to get a better grasp of what the hell I'm going on about.

Anyway, stay with me now! Let's go through what we have gathered about this instruction so far... assuming that all our 12 bits are 0 that is...
  1. This is a Data Processing instruction.
  2. It uses a shifted register barrel shift operation.
  3. It is an AND instruction (opcode is bits 24-21).
  4. Bit 4 is 0, so this must be a shift operation that shifts the shifted register by an immediate value, hence, uses the first shift field format (format to the right of the above picture).
  5. The entire shifted register field is 0, so this shift operation must be a 
  6. This does your head in if you think about it too much... 
So, by process of elimination, this instruction must be... *drumroll*

AND Rd, Rn, Rm, LSL #imm5

This instruction does the following.
  • Logically shift Rm left (LSL) by an immediate 5 bit value.
  • Logically AND Rn with Rm
  • Store the result in Rd
Anyway, to conclude, I hope this was informative in some way, even if you didn't know what I was rambling on about. Next time you look at a GBA or GBA emulator, think about what's going on inside, it's like "Whoaaa"... imo

EDIT: Forgot to mention the condition codes... 
Every ARM instruction can be executed conditionally, and bits 28 to 31 specify the condition that this instruction executes under. For more info, check out the manual, no point in me making is even harder to understand than it already is.


Saturday, 4 September 2010

Check this video out

This isn't necessarily about coding, but I thought this was the best TAS video I have ever seen, I had to post it. I found it on someone elses blog so excuse me if you feel I've ripped the idea from you, it's just so awesome.


Friday, 3 September 2010

Keeping this updated

Sorry about not posting for a couple of days, but I've been trying to figure out something decent to post, rather than just some random brain fart that comes into my mind. I have however updated my emulator review blogs, check them out, I'll keep em' coming.

When I get further along in the development of my GBA emulator, I'll be sure to post the progress. As of yet though, there is little to report, as I've been a little busy with some other stuff recently. Sometimes soon, I will make a small post of how I decode the ARM instruction set, hopefully this will be of use to someone, but it might not be much of an interest to people not interested in GBA emulator development.

Anyway, this was just an update to show my dedication. Keep checking up on me for more if you're interested. If anyone has any specific things that they think I should blog about relating to emulators and coding, I'll be happy to take them into consideration. I was thinking maybe a specific tutorial on how to write an emulator, a small emulator like the Chip8 maybe. Not sure.

In the mean time, here's the start of a great computer science course on youtube that you might want to check out, if you're into computer science that is.

Wednesday, 1 September 2010

A new blog

I just started another blog which will be dedicated to reviewing emulators. If you're feeling nostalgic about the old games you used to play, you should check it out from time to time. You can find it here.

"Emulation and Coding" will remain my main blog, but I'll keep both updated regularly.
Hope you like it.