The art of emulation

Emulation resources

2010-10-12T13:50:00.000-07:00

I just noticed that my bookmarks are beginning to get pretty substantial, and most of them are resources related to emulation. I've been far and wide on the net looking for documentation so I'll post them here. I hope someone finds them useful, or even just interesting.

Nes
(Too many links to post here, i'll post the important ones, you can find Nes docs easy anyway)
NES nocash docs
6502 reference

Super Nintendo

Programming the 65816
Snes programming tutorial
Snes graphics documentation

GB/GBA/DS
GBA & DS NO$ Docs GBATEK
GBA_11.pdf (application/pdf Object)
Tonc: Whirlwind Tour of ARM Assembly
ARM ASSEMBLER PROGRAMMING; tutorial, resources, and examples
ARM7TDMI Tech manual
ARM7TDMI data sheet
CowBite Virtual Harware Spec
GBA Game development
GB/GBC Specs
Game dev
ARM Instruction Formats and Timings

Playstation 1
Everything you ever wanted.. (html)
Everything you ever wanted.. (pdf)

Playstation 2
Inside the Playstation 2: PS2 Architecture, Graphics Rendering and Programming
Procedural Rendering on Playstation
An Introduction to PS2DEV « Lukasz.dk
PlayStation 2 Architecture (pdf) (takes ages to load)
A Technical Overview of the Emotion Engine
PS2 Basics
PS2IOP
PS2BMP1.pdf (application/pdf Object)
Win32 PS2 Dev. Intro
Downloads - GSHI
MIPS Assembly
VPU Thesis (pdf)

Nintendo 64
RCP64, Nintendo 64 Machine
Nintendo 64 Specifications
http://infrid.com/rcp64/docfiles/n64maps.txt
Nintendo 64 Tech
Nintendo64 Technical Information...

Misc
Sanity Warning
HUGE emulator list and sources etc
NO$FUN (All NO$ docs)

Peace

Be careful what you click!

2010-10-10T07:25:00.000-07:00

This is not related to emulation, but I feel that it's something that needs to be said. I think that Microsoft should do something about this huge weakness I have found in their operating system!

I hate viruses, most of us do, which is why I thought I'd have a try at writing one... just to see how easy it was for people to write malicious software. Turns out, it is very easy with just some basic coding knowledge.

In my opinion, the most destructive malware would be malware that deletes information from your computer, and what better information to delete from your computer than the Master Boot Record. For those who don't know what the MBR is, it is a small peice of code (512 bytes) that lies at sector 0 of your boot disk. This is the sector that the BIOS loads into memory for immediate execution after the post screen. It essentially boots up your operating system and usually loads the kernel and jumps to it. Without a valid Master Boot Record, your entire operating system is useless, removing the MBR effectively renders your OS useless, and unbootable.

However, there are steps you can take to repair your MBR, infact, it's very easy in modern operating systems like Vista or Windows 7. You just insert the Windows 7 system disk, and repair your operating system, however, if you do not know how to do this, or you have an older OS like XP, you are pretty screwed.

Which brings me on to this software I wrote. The virus I wrote (which I will never be using maliciously of course), replaces your MBR with my own custom MBR, which prints a little message to the screen instead of loading your OS. Keep in mind that I have created a few safe guards to make sure that I didn't click it by accident, I created some "Are you sure" messageboxes just to be safe, but if I took these away, this software would be very dangerous.

The executable needs to be run as adminstrator, but this is hardly much of a safe guard, as most users would probably be logged on as admin anyway.

I won't release this software or source code for now, unless anyone specifically asks for it, because there is always the chance that it could be used maliciously. It is however a very small file, and the source is very small, so be careful what you click.. or you might just get your MBR deleted. The Windows 7 and Vista UAC doesn't seem like such a bad thing to me anymore...

PS2 Development

2010-10-09T05:28:00.000-07:00

For ages now, I've wanted to develop my own programs/games for the PS2, and up untill today, I've had no luck in finding a straight forward, up to date enough tutorial. For anyone interested in PS2 dev, I would highly recommened this guide, and the pre-compiled PS2SDK mentioned in the tutorial, from here.

You can use the PCSX2 to run the resulting ELF files, on the file menu, "Open ELF file".

Well, that's about all I have to say about that, I will be hopefully posting updates on my own emulators, although I have so much left to do.

Peace

GBA emulator progress

2010-09-17T12:12:00.000-07:00

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.

Peace

Emulation - what's the point?

2010-09-13T17:45:00.000-07:00

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.

Peace

Motivation

2010-09-10T17:03:00.000-07:00

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.

Another blog

2010-09-08T09:24:00.000-07:00

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

Playstation 3 emulation?

2010-09-06T13:24:00.000-07:00

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.)

These threads on the PCSX2 site. here, here and here.
Any software emulator automatically takes on alot of overhead compared to the original console or system. This is simply the limitations of software.
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?
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.
Lack of documentation, people have only just started to hack the memory of the PS3.
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!

Decoding the ARM instruction set

2010-09-05T23:17:00.000-07:00

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...

This is a Data Processing instruction.
It uses a shifted register barrel shift operation.
It is an AND instruction (opcode is bits 24-21).
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).
The entire shifted register field is 0, so this shift operation must be a
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.

Peace

Check this video out

2010-09-04T12:48:00.000-07:00

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.

Enjoy

Keeping this updated

2010-09-03T14:10:00.000-07:00

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.

A new blog

2010-09-01T22:47:00.000-07:00

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.

http://emulatorreviews.blogspot.com/

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

Peace

Setting up an OpenGL texture for emulation

2010-08-31T11:16:00.000-07:00

In this post, I will describe how I render graphics in my emulators using OpenGL, although, the idea of drawing to textures applies to any modern graphics library.

I interface the Windows API and OpenGL to create a GUI that I can render graphics to. To render the graphics, I create a texture in the following way.

// create a texture
glTexImage2D(GL_TEXTURE_2D, 0, 3, x_res, y_res, 0, GL_RGB, GL_UNSIGNED_BYTE, screenData);

// set up the texture
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);

and update the texture like this

// Update texture
glTexSubImage2D(GL_TEXTURE_2D, 0 ,0, 0, NTSC_WIDTH, NTSC_HEIGHT, GL_RGB, GL_UNSIGNED_BYTE, screenData);

The pixel buffer i use is a 3 dimensional array, which is layed out in the following way.

u8 screenData[y][x][3];

The last 3 being the RGB value for each pixel
So, lets say I wanted to draw a blue pixel at coords(X:10, Y:15), i would do something like this.

// Draw blue pixel
screenData[15][10][0] = 0;      // R
screenData[15][10][1] = 0; // G
screenData[15][10][2] = 255;    // B

I wont' explain too much more, instead, I'll provide the source to a small program I created to show you, which can be download from the following link. It can be compiled with Visual C++ 2010. This program creates a texture and draws some pixels to it, and also stretches the scene depending on the width and height of the window and creates a small menu, just for the sake of it.

Download here.

You will notice that in my DrawScene() function, I rotate and texture, this is because by default the bottom left is coord 0,0, when i want the top left to be 0,0.

If link goes down, make me aware please.
Peace

How emulators work

2010-08-31T08:20:00.000-07:00

In this post, I'll attempt to explain how emulators fundamentally work.

The legalities
In general, writing an emulator is considered legal, as long as it's is all your work and all the documentation has been gathered legally, but spreading copyrighted work such as ROMs is highly illegal and I will not provide download links, so please, don't ask.

Different methods of emulating a system
The CPU of any system is pretty much the most important part, it is essentially the brain of the system, assuming the system doesn't have two or more brains (co processors), so your emulator will be based around the CPU core you write. To write a CPU emulator, you need to first understand how a CPU works. A CPU works on the basis of fetch, decode, execute.

Fetch: Retrieve the instruction from memory.
Decode: Figure out what the instruction is, this may be simple in an older 8 bit CPU.
Execute: Execute the instruction and write back any resulting values etc...

To emulate this process, we can use a few different methods.

Interpreter
An interpreter is the most popular method of emulating chips such as CPU's inside systems. Here is the basic way that an interpreter works.

cyclesThisUpdate = 0;
while (cyclesThisUpdate < cyclesToExecute)
{
    opcode = readMem(PC++);     // fetch instruction
    executeOpcode(opcode);             // decode and execute instruction

    // do cyclic tasks
    doGraphics();
    doSound();
    checkInterupts();
}

Let me explain, "cyclesThisUpdate" is going to be the amount of cycles that the CPU has executed this update, usually we update the emulator one frame at a time then draw the screen. "cyclesThisUpdate" must be reset at the start of the loop. "cyclesToExecute" is simply the amount of cycles we want to execute for this update, for example, lets say we wanted to update about a frame, we would work out how many CPU cycles a frame takes to emulate. Be aware that "cyclesThisUpdate" will be incremented a certain amount by the instruction, certain instructions will take more cycles than others to execute, not including memory access times. You will need to keep track of these cycles.

As you can see, the first thing we do is fetch the instruction, we then decode and execute the instruction, after this, we do all the cyclic tasks that need to be emulated, such as video, sound and CPU interupts. Fetching the instruction involves memory I/O, which will need to be emulated. For example, your fetch step will probably be some kind of readMemory() function which takes an address as a parameter, and returns the data as that address. This will serve the purpose of figuring out where in memory you are trying to read, and acting appropriately. For example, in the Gameboy Classic, reading addresses 0x4000, to 0x7FFF is reading a memory bank, and you must perform ROM memory banking to return the correct bytes. The "PC" is the program counter, which keeps track of where we are in the program, instructions like branches and jumps will change this register and it is incremented past each instruction everytime one is executed. If this confuses you, don't worry, you will understand eventually.

TL:DR Emulator is updated until cycles per update (usually per frame) is achieved.

Benefits of interpretation
1. Easy to debug
2. Simple to implement
3. Portable
4. Easy to synchronise your system
Drawbacks of interpretation
1. Very slow compared to other methods
Dynamic Recompilation
Recompilation or Dynarec for short, is a complex subject that I'm not really fully qualified to explain. The theory is that instead of executing the instructions, you translate them into mechine code instructions for your system and cache them in code blocks. The idea behind this is for optimization, because most code that is executed might be executed thousands of times, so if it is cached and optimized, it will execute much faster. Here is a great tutorial by one of thr PCSX2 authors, CottonVibes on Dynarec.

Emulators like PCSX2, ePSXe, PJ64, 1964 and Dolphin use Dynamic Recompilation. You can freely download the PCSX2 source and the 1964 source and take a look at there recompilers, 1964 even has a pdf document floating around somewhere with details on there recompiler, ask me if you want it, ill upload it somewhere for you.

Benefits of dynarec
1. Speed
2. Speed
3. Speed
Drawbacks of dynarec
1. Not portable
2. Difficult to debug
3. Hard to impliment
There is another method called static recompilation, but I won't go into that as I feel that the benefits are few and far between.

Peace

By the way, i have no idea why this post won't format correctly, sorry. I tried.

A C++ wallpaper

2010-08-30T13:07:00.000-07:00

After seeing the antiRTFM's C++ tutorials on youtube, I saw that he had an awesome wallpaper that he designed. People kept requesting it so I thought I'd make my own impression of it. Do what you will with it. Enjoy :)

Peace

Writing an emulator

2010-08-30T11:56:00.000-07:00

In this quick post, I'll go over the processes that led up to me writing emulators.

*First of all, a disclaimer. I am not an expert, or even a particularly advanced emulator author, but I am learning more everyday and really enjoying it. If you want to speak to expert emulator authors, go to a site like PCSX2.net. These people deserve enormous respect in my humble opinion.

From the very first time I used an emulator, I knew that I wanted to learn more about them, I don't even think I was a programmer at that time, it was the interest that motivated me from the start. The reason I chose to actually attempt to write emulators is simple, I love playing games, and I love low level programming tasks and learning what makes machines "tick", emulation is ideal for me. Unfortunately, I noticed that learning the theory behind emulation is easier said than done, not to mention that lack of simple documentation on the basics which can be maddening. Emulating a games machine, or any machine is not a simple thing to do (in my opinion), although obviously writing a PS2 emulator is going to be alot harder than writing a Gameboy emulator for example, so it's subjective.

Here's a few suggestions.

First of all, you obviously need to learn a programming language, i recommend C and/or C++ as most software, including most emulators will be written in this language, even Windows is written almost entirely in C.
Emulation is not really a good project for learning your language of choice, be confident in your language before you attempt writing any emulator, as you don't want to be discouraged from emulation by your lack of knowledge of a language, a language should be used like any other tool, which you should know how to make full use of before attempting projects like this. Although, I have heard of people saying that they learned to program by writing emulators, but I digress.
Don't ever just copy somone elses source code because you can't figure it out yourself, this is a huge mistake and will ultimately screw you over, it feels so much better to know you have witten it all yourself.
Learn about the system you're trying to emulate before writing any code.
Learn about computer architecture before trying ti write an emulator.
Learn about bitwise operators like OR, EOR and AND. Also, learn about different numeral systems like binary and hexadecimal.
Find as much documentation as you can on the system you're trying to emulate.
Don't give up.
Have fun. :)
???
Profit!

Here are some links that will get you started writing emulators.

Don't know how to program in C++? Here's a good tutorial.
Don't know how to program graphics and GUI in C++? Here's a good tutorial.

Take a look at this video before writing an emulator, it will help you understand what the basics are. (not sure about the copyright, but I tried to contact the author, no response). If the link goes down, please tell me, i will re-upload it for you.

Confident in your language of choice? This is an awesome blog taking you step by step through how to write an emulator. From the Chip8, to the Gameboy Classic, to the Master System, to infinity... and beyond!

A great site for emulator source code and such.

The NO$ series of emulators and documentation. (great, great documentation on various systems like the Gameboy Advanced, Nintendo DS and the NES etc...). this will probably be your main source of documentation for a few emulators.

And of course, if you want more documentation, don't be afraid to use the official documentation released by the system vendors (if they have of course). For example, the 6502 processor used in the NES has a whole manual. Same with the GBA CPU, the ARM7TDI manual.

One last thing, don't forget to actually play emulators, they are so much fun. try the latest ones, the PCSX2 and Dolphin, they be bitchin!

Peace

Decoding the THUMB instruction set

2010-08-27T16:13:00.000-07:00

Recently, I have began work on a GBA emulator which is keeping me busy. The emulator that I worked on before this (and still do) is a Nes emulator, so this is a huge step up for me, but where is the fun without challenge?

So far, i haven't even finished decoding the instruction sets so don't expect much yet, the ARM7TDMI is a pretty complex CPU. I will outline the method that I am using to decode the instruction sets of the ARM7TDMI, incase it's useful to any other GBA emulator authors who were stuck like I was blankly staring at the ARM7 opcode format for ages.

Keep in mind that it is very difficult to explain the exact way that i decode each instruction without alot of text, but I will try to explain as best I can with some abstraction.

The ARM7TDMI effectively has two instruction sets, one that makes use of full 32bit instructions called the ARM instruction set, and another which only uses 16 bit instructions called the THUMB instruction set which reduces code density but removes some instructions as well as limiting the immediate values that can be used. You can independently switch between these two instruction sets on the fly using the BX instruction.

THUMB instruction set

As the THUMB instruction set is the easiest to decode, I will tackle this first.

Binary opcode format of the THUMB instruction set.

Each instruction is made up of 2 bytes (half word), and each instruction has it's own format that is decoded by the CPU. As you can see, some instruction formats like format 1 have an opcode field which will specify the particular instruction that this is, for example, the "Move shifted register" format has a 2 bit opcode field. If you want more detail on the specifics of the instructions and the fields, then take a look at the manual here, or check out NO$GBA specs here.

Now, the way I decode an instruction is by taking the upper 8 bits of the instruction and checking it's value. For example, if I took the upper 8 bits and the value was equal to 0 to 7, I would know that this must be a "LSL Rd, Rs, Offset". Why? This is because while the upper 8 bits equal 0 to 7, then the opcode field (move shifted register format) is equal to 0 and all the other bits for this format are correct. here is a more visual example.

Let's say our upper 8 bits look like the ones in the picture

00000101

If we check the instruction format, we can see that the "Move shifted register" format allows for this value, as the bottom three bits of 8 bit value we are using are the top three bits of the offset5 field (bits 8,9, 10), which could therefor be anything as they are arbitrary, so the following binary values can therefor reperesent the same instruction. ("LSL Rd, Rs, Offset5").

00000000    (0)
00000001    (1)
00000010    (2)

00000011    (3)
00000100    (4)
00000101    (5)
00000110    (6)
00000111    (7)

If we were to get a value of 8 (00001000), this would mean that the opcode field had increased by one, so the instruction would now be "LSR Rd, Rs, Offset5". So now, we need to do the same again, as the bottom three bits could be anything. these binary values will all be the same instruction.

00001000    (8)
00001001    (9)
00001010    (A)
00001011    (B)
00001100    (C)
00001101    (D)
00001110    (E)
00001111    (F)

Now to decode the rest of the instruction set, you just follow this logical pattern.

Here is a coded example of how you might decode the first couple of instructions...

<textarea>u16 instruction = fetch();

switch (instruction >> 8)
{
    case 0:
    case 1:
    case 2:
    case 3:
    case 4:
    case 5:
    case 6:
    case 7:
    {
        // LSL Rd, Rs, Offset5
    } break;
    case 8:
    case 9:
    case 0xA:
    case 0xB:
    case 0xC:
    case 0xD:
    case 0xE:
    case 0xF:
    {
        // LSR Rd, Rs, Offset5
    } break;
}

or you may choose to use an array of function pointers.

void (*CPU_Thumb_Instruction[0x100]) (u16 instruction) =
{
    Thumb_LSL_Rd_Rs_Offset,        // 00h
    Thumb_LSL_Rd_Rs_Offset,        // 01h
    Thumb_LSL_Rd_Rs_Offset,        // 02h
    Thumb_LSL_Rd_Rs_Offset,        // 03h
    Thumb_LSL_Rd_Rs_Offset,        // 04h
    Thumb_LSL_Rd_Rs_Offset,        // 05h
    Thumb_LSL_Rd_Rs_Offset,        // 06h
    Thumb_LSL_Rd_Rs_Offset,        // 07h
    /*-------------------*/
    Thumb_LSR_Rd_Rs_Offset,        // 08h
    Thumb_LSR_Rd_Rs_Offset,        // 09h
    Thumb_LSR_Rd_Rs_Offset,        // 0Ah
    Thumb_LSR_Rd_Rs_Offset,        // 0Bh
    Thumb_LSR_Rd_Rs_Offset,        // 0Ch
    Thumb_LSR_Rd_Rs_Offset,        // 0Dh
    Thumb_LSR_Rd_Rs_Offset,        // 0Eh
    Thumb_LSR_Rd_Rs_Offset,        // 0Fh
};
</textarea>
I will explain how to decode the ARM instruction set at a later date, as it is considerably more complex, and requires much more thought and care.

Peace

Welcome

2010-08-27T15:18:00.000-07:00

Hi, this is a blog I thought I'd start just to note my progress and thoughts of various coding projects I am working on. Nuff said, let's do this.