moises' blog

Emulation Basics: Write your own Chip 8 Emulator/Interpreter

2012-06-30T05:14:00.001+08:00

It has been quite a while since I last posted here; I've been keeping myself busy with work and developing stuff for the iOS. I bought a developer ID 2 years ago (for both iOS and Macs), and promised myself that I will create apps for both platforms at least twice a year, just to get back what I spent.

So anyway, I recently got my Raspberry Pi from the mail, and was looking at things to do with it. The first thing that came to mind was to PLAY GAMES OBVIOUSLY, but the little thing is ARM-based, and not many emulators are built to maximize its powerful GPU.

That got me into thinking - what if I wrote my own emulators for it? A ~700Mhz processor is reasonably fast, and the experience may teach me a lot of things. Plus, the thing comes with Python. Who doesn't love Python? The less I think about code boilerplate, the more I get done.

So let's get started.

The CPU: CHIP8

To get started with emulation, let's start small. Oh let's say a theoretical machine. With less than 50 instructions (if we did the Gameboy, which is based on a Z80, that would be ~250 instructions, and is a bit too much for a blog article. Or maybe I'm just lazy).

AHA! One machine actually fits this bill - CHIP8. CHIP8 isn't really a machine in the physical sense - it is actually an interpreter, which runs its programs in a virtual machine. It was developed by the late Joseph Weisbecker. It first appeared in graphing calculators - and was the reason for the drop in their productivity due to playing too much PONG.

The first step in emulation is trying to understand the innards of the hardware. Luckily for us, CHIP8 is pretty well documented - my favorite is Cogwood's CHIP-8 technical reference. It even includes the extension SuperChip instructions. Wikipedia is also a great resource for this - their opcode descriptions are actually the ones I first used before I discovered Cogwood's article.

So let us begin. First, understand the hardware. Basically, all machines are made up of 3 parts (at least for me :)):

1. Input
2. Output
3. CPU
4. Memory

Inputs
For the CHIP8 virtual machine, the input comes from a 16-button keyboard (pretty convenient that the number of keys falls within a nibble). The machine is also fed with the programs it is supposed to run.
In python, we just need to store key input states and check these per cycle:
self.key_inputs = [0]*16

Output
For output, the machine uses a 64x32 display, and a simple sound buzzer. The display is basically just an array of pixels that are either in the on or off state:

self.display_buffer = [0]*32*64 # 64*32

CPU and Memory
Now for the "hard" part. The Chip 8 CPU has several parts of note, and all are important to understand how it works. I'll run through them here, but for more info see the Cogwood reference I linked to earlier.

Memory
CHIP8 has memory that can hold up to 4096 bytes. This includes the interpreter itself, the fonts (more on this later), and where it loads the program it is supposed to run (from input). In python, this will be:

self.memory = [0]*4096 # max 4096

Registers
The CHIP8 has 16 8-bit registers (usually referred to as Vx where x is the register number in Cogwood's reference). These are generally used to store values for operations. The last register, Vf, is mostly used for flags and should be avoided for use in programs. In python, we will be storing our register values as:

self.gpio = [0]*16 # 16 zeroes

It also has 2 timer registers, that basically just cause delays by decrementing to 0 for each cycle, wasting an operation in the process. Again, in python, this will be as simple as defining two variables that we'll decrement per cycle.
self.sound_timer = 0
self.delay_timer = 0

It has an index register which is 16-bit.
self.index = 0

The program counter is also 16-bit.
self.pc = 0

There is also a stack pointer, which includes the address of the topmost stack element. The stack has at most 16 elements in it at any given time. Since we're doing this in python, which has a list that we can just pop/append to, we can ignore this. In python, just make a list:
self.stack = []

On to the code!

For our input/output, we are going to use pyglet, a module for python that wraps around OpenGL boilerplate so we can easily output graphics. It can also handle sound output. And oh, it does keyboard handling too! Now all that's left is the CPU.

A little notes on my implementation. Since we are using pyglet on Python 2.6, and since pyglet doesn't work with threads, basically what we're gonna do is subclass pyglet's Window class and run our CHIP8 interpreter from there:

class cpu (pyglet.window.Window)

The added benefit is we won't have to make our own input handlers - we just need to override the keyboard input methods:

def on_key_press(self, symbol, modifiers):

def on_key_release(self, symbol, modifiers):

Basically all emulators have a main loop structure like this:

def main(self):

self.initialize()
self.load_rom(sys.argv[1])
while not self.has_exit:
self.dispatch_events()
self.cycle()
self.draw()

Let's go into this code a bit. The first step is to initialize our variables. Set all registers to zero, reset all key inputs to zero and reset the program counter (self.pc). Load a rom, then perform each cycle, updating the display as needed.

A program counter??? What is this madness? Well basically, a program counter is a pointer to the address in memory of an instruction that we are about to process next. In CHIP8, since the interpreter occupies the first portion of memory, we need to point this to the offset, which is equal to 0x200 (See Cogwood's reference; we'll be doing it a lot). Most of these is done in the cycle() method, which we'll delve into later.

BUT WAIT! Didn't I say the fonts were gonna be stored in memory as well? Why yes, and maybe if you stopped interrupting me, my imaginary friend, I would have got to that. Basically CHIP8 uses "sprites" for graphics. Sprites are basically a set of bits that indicate a corresponding set of pixel's on/off state. For example, a sprite of the number zero would look like this (taken from Cogwood's reference, the excellent resource):

"0"	Binary	Hex
**** `* ` ` * * * ****`	11110000 `10010000` `10010000 10010000 11110000`	0xF0 `0x90` `0x90 0x90 0xF0`

Now, CHIP8 (at least the original implementation) has sprites in memory for the 16 hexadecimal digits. Since each font character is 8x5 bits, we'll need 5 bytes of memory per character. So our init function will now look like this, with font loading included:

def initialize(self):
self.clear()
self.memory = [0]*4096 # max 4096
self.gpio = [0]*16 # max 16
self.display_buffer = [0]*64*32 # 64*32
self.stack = []
self.key_inputs = [0]*16
self.opcode = 0
self.index = 0

self.delay_timer = 0
self.sound_timer = 0
self.should_draw = False

self.pc = 0x200

i = 0
while i < 80:
# load 80-char font set
self.memory[i] = self.fonts[i]
i += 1

I put in a should_draw flag in there so we only update the display when needed. Also, self.clear() just clears the pyglet window.

With this knowledge, now we can start loading our ROM into memory. ROMs can be read into memory simply by opening them as a binary:

def load_rom(self, rom_path):
log("Loading %s..." % rom_path)
binary = open(rom_path, "rb").read()
i = 0
while i < len(binary):
self.memory[i+0x200] = ord(binary[i])
i += 1

BTW, the log() function I just put in there so the user has an option to turn on/off log messages when running.

Now to start processing!

The cycle()

Each cycle does this:

def cycle(self):
self.opcode = self.memory[self.pc]

#
# TODO: process this opcode here
#

# After
self.pc += 2

# decrement timers
if self.delay_timer > 0:
self.delay_timer -= 1
if self.sound_timer > 0:
self.sound_timer -= 1
if self.sound_timer == 0:
# Play a sound here with pyglet!

An opcode is basically the instruction we need to perform. So at its heart, we are just basically reading the binary, line by line, and performing associated actions per line (this is actually pretty slow - CHIP8 is simple so we won't notice it, but for other emulated machines, other approaches are possible, which is beyond the scope of this article). Now let's think about the TODO for a bit.

Each opcode in CHIP8 is 2 bytes long. The program counter points to the current opcode we need to process; after getting the op and processing it, the program counter increments by 2 bytes. Then the process repeats until the program ends.

Here is the tricky part. In C, we could easily just create a switch statement for the opcodes to perform what we want. But we're using python. Pythont doesn't have a switch statement - we'd have to go through a compound if-else. Since CHIP8 is pretty simple, we actually can do this, but it will be pretty ugly code, we don't want this. Luckily, in python, we can use dictionaries to store opcode-method pairs. So the TODO part will simply be like this:

self.vx = (self.opcode & 0x0f00) >> 8
self.vy = (self.opcode & 0x00f0) >> 4
self.pc += 2

# 2. check ops, lookup and execute
extracted_op = self.opcode & 0xf000
try:
self.funcmap[extracted_op]() # call the associated method
except:
print "Unknown instruction: %X" % self.opcode

A little info on CHIP8 opcodes. They are usually in the format XXXX. Usually, you can already decipher the instruction from its first (leftmost) nibble, so we extract the op with a bitwise AND, and look it up in our function map (self.funcmap). If it isn't there, then we will just raise an error. NOTE: self.pc is incremented BEFORE cycle(), so any modifications to it (e.g. in jumps) are retained.

There! we already have the basic skeleton to our emulator. Now we just have to implement all of the instructions one-by-one. (the "fun"part).

Sample instruction: Clear a screen with 00E0 and return with 00EE
Cogwood's excellent reference lists all the necessary instructions in the previously linked document. Here, we will implement the first and simplest one - the instruction to clear the screen. This corresponds to the opcode 0x00E0. But wait; since at our cycle() we just used the leftmost nibble, there is a possibility that we might conflict with another instruction that falls in the 0x0XXX format: 0x00EE, or the "return from subroutine" opcode. So what we can do is to do another extraction:

def _0ZZZ(self):
extracted_op = self.opcode & 0xf0ff
try:
self.funcmap[extracted_op]()
except:
print "Unknown instruction: %X" % self.opcode

Here, when we encounter an opcode which has 0 as the leftmost nibble, we extract the first and last 2 nibbles and look the associated method in the function map. 0x00E0 should map to CLS, and 0x00EE should map to the return subroutine:

def _0ZZ0(self):
log("Clears the screen")
self.display_buffer = [0]*64*32 # 64*32
self.should_draw = True

To return from a subroutine, we just need to pop the topmost address from our stack:

def _0ZZE(self):
log("Returns from subroutine")
self.pc = self.stack.pop()

And in self.funcmap:

self.funcmap = {0x0000: self._0ZZZ,
0x00e0: self._0ZZ0,
0x00ee: self._0ZZE,
....

where self._0ZZE will be the "return" method. Why don't we just set 0x00E0 and 0x00EE to the methods needed? Well, we actually could have, but the 0x0xxx instructions are actually special cases, as they don't have inputs. Usually the last three nibbles contain inputs to the operation, and aren't constant, so they can't be mapped as is. For example, let's look at the next instruction, which performs a JUMP:

Sample instruction: JUMPing with 1XXX
The JUMP opcode, which starts with 1, is followed by three nibbles corresponding to the address of the instruction to be executed next. Now you see why we needed to extract nibbles bit-wise - the jump address changes, but the opcode identifier doesn't, and we can use that to identify the instruction.

To perform a jump, simply set the program counter to the address of the next instruction, so it will be performed in the next cycle:

def _1ZZZ(self):
log("Jumps to address NNN.")
self.pc = self.opcode & 0x0fff


And in our function map:

    self.funcmap = {0x0000: self._0ZZZ,

                    0x00e0: self._0ZZ0,

                    0x00ee: self._0ZZE,

                    0x1000: self._1ZZZ,

    ....

That's it! Now, rinse and repeat for each of the opcodes defined in the instruction set, and voila! Your very own CHIP8 emulator.

Notes on the important opcodes:

Opcodes using the registers V0 to VF:
Note on my cycle() implementation. You will notice these two lines:

self.vx = (self.opcode & 0x0f00) >> 8
self.vy = (self.opcode & 0x00f0) >> 4

Some opcodes use the general purpose registers. For example, 0x4XNN, which "Skips the next instruction if VX doesn't equal NN". To handle this, the above instructions just extract the nibbles with bitwise operations to get the associated registers (which are usually stored in the 2nd and third nibbles). Then, I can use this to perform the skip:

def _4ZZZ(self):
log("Skips the next instruction if VX doesn't equal NN.")
if self.gpio[self.vx] != (self.opcode & 0x00ff):
self.pc += 2

The same goes for comparing:

def _5ZZZ(self):
log("Skips the next instruction if VX equals VY.")
if self.gpio[self.vx] == self.gpio[self.vy]:
self.pc += 2

Using the carry flag
You have to be careful in reading the Cogwood reference, as some operations require setting the VF flag. For example, operation 0x8XX4 uses VF as a carry flag in addition. Why is this needed? Remember when we said that the registers only store 8-bit values? If we add 2 8-bit values, there is a possibility that the result will overflow (1 byte has a maximum value of just 0xFF). If the result is greater than the maximum, the carry flag is set.

def _8ZZ4(self):
log("Adds VY to VX. VF is set to 1 when there's a carry, and to 0 when there isn't.")
if self.gpio[self.vx] + self.gpio[self.vy] > 0xff:
self.gpio[0xf] = 1
else:
self.gpio[0xf] = 0
self.gpio[self.vx] += self.gpio[self.vy]
self.gpio[self.vx] &= 0xff

It is also used in subtraction as a "borrow" flag:

def _8ZZ5(self):
log("VY is subtracted from VX. VF is set to 0 when there's a borrow, and 1 when there isn't")
if self.gpio[self.vy] > self.gpio[self.vx]:
self.gpio[0xf] = 0
else:
self.gpio[0xf] = 1
self.gpio[self.vx] = self.gpio[self.vx] - self.gpio[self.vy]
self.gpio[self.vx] &= 0xff

Drawing:
Now for the most difficult part. Well, actually not really. Drawing is pretty straightforward in the CHIP8. A pixel is either on or off, and we store the states in the display_buffer we defined earlier. There are two op codes that do drawing: 0xDXXX, which draws sprites loaded from the ROM, and 0xFZ29, which just draws a character. Let's implement the simpler one first; drawing a character.

def _FZ29(self):
log("Set index to point to a character")
self.index = (5*(self.gpio[self.vx])) & 0xfff

Yup, that's it. This op just sets the index register to the address of the first byte of the corresponding character. This is because the main drawing code, which we will now implement, uses this register to find the sprite it needs to draw. To understand this better, let's read the documentation again. DXYN means, according to Cogwood:

Display n-byte sprite starting at memory location I at (Vx, Vy), set VF = collision.

Remember our discussion on font sprites earlier? It applies to custom sprites too. Each row (byte) corresponds to an 8-pixel row on the screen. But here, instead of being a fixed 5 bytes, the N value can correspond to a custom sprite height. Also, the bytes are XOR'ed onto the screen. This is actually ingenious - since CHIP8 resources are limited, it used the actual display to store sprite states! So XOR'ing a pixel to the new value will tell you if the state changed, and therefore indicate a collision. Here, a collision is flagged in VF: if a pixel changes from 1 to 0, then VF is set to 1. Now to implement the buffer update code:

def _DZZZ(self):
log("Draw a sprite")
self.gpio[0xf] = 0
x = self.gpio[self.vx] & 0xff
y = self.gpio[self.vy] & 0xff
height = self.opcode & 0x000f
row = 0
while row < height:
curr_row = self.memory[row + self.index]
pixel_offset = 0
while pixel_offset < 8:
loc = x + pixel_offset + ((y + row) * 64)
pixel_offset += 1
if (y + row) >= 32 or (x + pixel_offset - 1) >= 64:
# ignore pixels outside the screen
continue
mask = 1 << 8-pixel_offset
curr_pixel = (curr_row & mask) >> (8-pixel_offset)
self.display_buffer[loc] ^= curr_pixel
if self.display_buffer[loc] == 0:
self.gpio[0xf] = 1
else:
self.gpio[0xf] = 0
row += 1
self.should_draw = True

What are we doing here? Basically we are going to the pixel indicated at x,y - then we compare each pixel in our sprite to that in our buffer, and XOR as needed. Then, we just set our draw flag to True, so our draw() call catches it.

Some noted on our draw() method. I used pyglet, which is a wrapper to OpenGL, but it is really slow with low level stuff, like doing pixelwise drawing. So here, I am actually drawing it pseudo-pixelwise - I have a 10x10 pixel (which makes my window 640x320), and I draw the pixel at x*10 and y*10:

def draw(self):
if self.should_draw:
# draw
self.clear()
line_counter = 0
i = 0
while i < 2048:
if self.display_buffer[i] == 1:
# draw a square pixel
self.pixel.blit((i%64)*10, 310 - ((i/64)*10))
i += 1
self.flip()
self.should_draw = False

This will be slow for other applications, but is fast enough for the purposes of our demonstration.

Keyboard input

Since we subclassed pyglet's Window, we can just override the keyboard input methods:

def on_key_press(self, symbol, modifiers):

log("Key pressed: %r" % symbol)

if symbol in KEY_MAP.keys():

self.key_inputs[KEY_MAP[symbol]] = 1

if self.key_wait:

self.key_wait = False

else:

super(cpu, self).on_key_press(symbol, modifiers)

def on_key_release(self, symbol, modifiers):

log("Key released: %r" % symbol)

if symbol in KEY_MAP.keys():

self.key_inputs[KEY_MAP[symbol]] = 0

The code above is pretty self explanatory - we are just updating the key states as inputted in the keyboard. In the emulator, we can just read the values as necessary. Input with the keyboard is handled by 0xExxE and 0xExx1:

def _EZZE(self):

log("Skips the next instruction if the key stored in VX is pressed.")

key = self.gpio[self.vx] & 0xf

if self.key_inputs[key] == 1:

self.pc += 2

def _EZZ1(self):

log("Skips the next instruction if the key stored in VX isn't pressed.")

key = self.gpio[self.vx] & 0xf

if self.key_inputs[key] == 0:

self.pc += 2

BCD: FX33

This instruction is where most people encounter a problem, and I will leave it as an exercise to the reader. But basically, you just need to store the value in VX as a BCD of three digits, starting with memory[self.index] as the most significant digit, to memory[self.index+2] as the least significant digit. So for example, if:

self.gpio[self.vx] = 123

then:

self.memory[self.index] = 1

self.memory[self.index+1] = 2

self.memory[self.index+2] = 3

Finally, done!

And that is the bulk of it! Implementing the other instructions should be pretty straightforward. As always, just refer to documentation if in doubt, and always be testing. Cogwood's reference is an excellent resource; bookmark it for your own good. For testing, you can always download public domain CHIP8 ROMs from the internet (a simple Google will give you a wealth of links). Also, the source code for the (partially) completed emulator is on github, download it from there! I say partially, because I haven't implemented the SuperChip instructions yet - maybe you can do that and give me a pull request? It works with PONG and PONG2 though, which is all that matters to me.

That's it for this (LONG) article. I haven't written anything in a while, so forgive me for this. Enjoy, and have fun playing PONG!

DOSRunner on googlecode

2010-11-12T00:23:00.001+08:00

Created a repository in Google Code for DOSRunner today. (http://code.google.com/p/dosrunner) It's under the MIT license, so if anyone finds it useful.

why everyone should use project hosting services

2010-09-29T22:56:00.004+08:00

... even for open source projects. I have a new PC at home, which is awesome, but someone thought reformatting the older PC's hard-drive was a good idea.

Sad to say, but gsmGPS is now dead. Not because I've grown tired of it, but because I've lost all of the sources.

All my other projects are still alive, though. Thank Google Code for that.

snarltraynotifications: code to bypass the default balloon

2010-08-09T10:08:00.005+08:00

Did a few updates to Snarl Tray Notifications (see the project page) - the app now hides the original message; only the Snarl notification is visible. It's usable now, except for messages requiring interaction with the mouse.

You may also notice, it has an icon now. Thanks to Sekkyumu at deviantart. The icon display code is temporary, as I plan on grabbing the original icon from the original message, so we'll see what happens.

Until the next update!

Snarl Tray Notifications

2010-08-08T09:33:00.005+08:00

I mentioned Snarl being a notification system option when I wrote about setting up SSBs in Windows. Windows notifications are bearable at best, displayed only with text, and a pale yellow balloon background. My frustration also stems from the fact that I code for both Mac and Windows, and although aesthetically I like Mac and Growl, I must admit that I still go back to Windows (Bootcamped in an MBP) due to its usability.

To solve the notification problem, I hacked up a companion app to Snarl, Snarl Tray Notifications. What it basically does is grab the text from system notifications and push them to Snarl. It would be a lot better if I turned off the default balloons, but this will have to do for now. 4 straight hours of poring through the Win32 API are starting to hurt my eyes.

To follow the project's progress and download the latest builds, visit the project's Google Code site: http://code.google.com/p/snarltraynotifications/

Here's a screen capture of a Windows notification captured and passed to Snarl:
I'm still working on how to grab the original message's icon and message title, but it's looking a lot better now. Even better, you can download additional Snarl styles and choose whichever suits your taste.

DOSRunner

2010-04-02T05:26:00.006+08:00

DOSRunner is a Windows shell extension that allows you to run a DOS program easily with DOSBox, without having to do with DOS commands. Just right click the executable, select "Run in DOSBox", and play away.

It works with any version of Windows (from XP to Win7, 32/64 bit), as long as you have a version of DOSBox installed. (See their website for downloads).

Download:
Setup file: Download here

Requirements:
- Any version of DOSBox
- .NET Runtimes (For Windows XP users). You probably have these installed already.

How to use it:
1) Install DOSRunner using the setup file.
2) Setup will prompt you for the path of your DOSBox folder. Use the "Browse" button to find the dosbox.exe executable.

3) After installation, right click any executable you want to run in DOSBox, and select the "Run in DOSBox" option.

4) Play away.

- Uninstallation is as easy as clicking the Uninstall link under the "DOSRunner" Start Menu entry.

- If you want to use it with another DosBOX version, just use the DOSRunner Configurator tool in the Start Menu (Under DOSRunner).

NOTE: For this to work, you must not have modified DosBox to mount any path by default! just remove any mount commands you might have added to dosbox.conf.

If you didn't understand that, it probably won't be a problem.

Thanks!

[Blender] RC211v model - Finishing up

2010-03-09T04:11:00.003+08:00

Just the body kit and we are good to go for the final render. I have spent 9 hours total on this thing.

http://maranas.deviantart.com

[Game] 20XX

2010-03-03T01:14:00.004+08:00

Back when I was in college, everytime I went home to Quezon City from Manila, I would drop by SM North EDSA's Quantum. They had this little arcade game called "19xx". And it was fucking awesome. I would buy 5 tokens at 7 pesos each and have a great time.

This game I created as an homage to the legend. It isn't 19XX, but it's fast, it has lots of different enemies, and has the Big Boss fights everyone loves.

20XX - Download Here

Controls: Just press F1 for in-game help.

[Game] Missile Command

2010-02-19T07:43:00.004+08:00

Another day, another one of my old creations.

Yesterday we had Tank Commander. Today, I give you, wait for it:

Missile Commander.

The game is basically a clone of "Text Missile Command", but with graphics. And explosions. Originally just a test of my particle generation system in Game Maker, but turned out to be really fun, so I made a game out of it.

Controls:
Just use the mouse and click on any direction you want to shoot missles at.

Download it from here:
http://www.mediafire.com/?w1tuyzmt01j

[Game] Tank Commander

2010-02-18T02:54:00.005+08:00

Was rummaging through my files in the old laptop when I found a whole folder full of games I made from back when I was in college. Those were the days. I'll try to upload them all, but for now here's Tank Commander.

Download it from here.

Didn't get that? Here's the link: http://www.mediafire.com/?ytj2zgdznm2

It's a top down shooter where you get to control a tank deep within enemy lines.

Controls:
W,A,S,D - drive the tank
Mouse - control the turret
Mouse click (left or right) - shoot with your machine gun (save your rockets, use this on infantry)
Mouse click + space - shoot a rocket (useful for enemy tanks and barriers)

Press F1 for the in-game help. Enjoy!

[Virtualization] Haiku on VirtualBox

2010-01-21T22:50:00.012+08:00

Remember BeOS? Those of you missing the BeOS's beautiful simplicity would be glad to know that Haiku, an open source OS project inspired by BeOS, is already in alpha1. The great thing about it is, it is mostly compatible with your old BeOS software.

So let's get it running in VirtualBox.

1) If you haven't already, download and install VirtualBox.

2) Get the latest haiku ISO file from the haiku project website. Unzip it to any convenient location.

3) In VirtualBox, Create a New Virtual Machine with the following settings:

Name: haiku

Operating System: Other

Version: Other/Unknown

Base Memory Size: 512MB. (you may be able to get away with less, but this one worked for me)

Select "Create a new hard disk". It is up to you how you want to set up your hard disk, but preferably, just select the Fixed Size hard disk and give it the amount of disk space you prefer. I gave mine 5GB.

4) Once that's done, you should be able to see the new virtual machine in the list. Select your virtual machine, then press the "Settings" button.

5) Go to the "Display" item. Give the virtual machine some video memory. I gave mine 128MB. You may get away with less, but again, this worked for me.

6) Go to the "Storage" item. Click on the CD-like icon in the tree, then click on the button beside the drop-down box with "Empty" as a value. (See the button marked with the red box in the screenshot). This will bring up the Virtual Media Manager. Just click on the Add button, browse to the Haiku iso you downloaded and extracted earlier, then select it from the list.

7) Go to the "Network" item. Click on "Advanced". Select any Adapter Type EXCEPT for the PCInet ones. They don't seem to work with haiku. The Intel PRO 1000/MT Desktop (82540EM) worked for me.
8) Click "OK". You are now ready to boot the ISO you downloaded. Select haiku from the Virtual Machine list and click on "Start".

Haiku boot screen

9) Once it boots, click on the "Installer" button. Read and agree with the license.

10) In the next dialog, click on "Setup partitions...":
11) Select the disk you created earlier. Then click on Partition->Initialize->Be File System. After initialization is done, you can close this window (By pressing the small square on the top-left corner of the window).
12) Select the drive you initialized in the "Onto:" drop down, and press Begin. This will install haiku onto the hard drive you created earlier.

13) After installation, close the virtual machine. Go back to the "Settings" of the virtual machine. under "Storage", deselect the haiku ISO you loaded earlier by clicking on the drop-down and selecting "Empty" (see screenshot). This will prevent the virtual machine from booting into the install ISO when you restart it. Click "OK".
14) You're almost there. select haiku again from your list of virtual machines, and press "Start". After a few seconds, you will be greeted with the Haiku desktop.

Haiku Desktop

GLTeapot demo (running at 227.5FPS) and Bon Echo (Firefox port) browsing Google

There you go. Your very own haiku VirtualBox. Don't forget to check out the following sites for software:
http://www.haiku-os.org/ - Haiku project page
http://www.haikuware.com/ - Haikuware - Software for Haiku OS
http://ports.haiku-files.org/ - Haiku Ports
http://zeta-games.com/ - Zeta Games - games for BeOS/Haiku
http://www.bebits.com/ - BeBits - BeOS software

[Tools] Keylogger utility

2010-01-07T23:28:00.013+08:00

I was playing around with CodeProject when I came across this article by Michael Kennedy on how to create global system hooks in managed code. I know local hooks are possible with C#, but for global hooks you would need to build a DLL in C++ (there are no methods for hooking to system events in C#.NET), then use P/Invoke to access the DLL in C#.

Using his managed system hook library, I created a keylogger that logs keyboard input into a textfile:

Download here

Note: It may or may not work with 64-bit PCs. I only tested it with 32-bit XP and Vista.

Usage:
Just run the program. It is hidden (there is no visible form); you will only see it in the Processes tab of task manager. It will save the log into the directory it is stored in.

To quit the program, just press Shift+F11.

Output Files:
The filename is of the following format: Month-Day-Year.txt
The keylogger outputs the key events as readable text. The words will be readable as much as possible, and the output is case sensitive. But, since other types of keys are also handled (e.g. Fn keys, Ctrl, Alt, Home, End, etc.), there will be non-readable portions.

Sample output:
Filename: 1-8-2010.txt
Contents:
KEYControl was pressed.
a
KEY Control was released.
the quick brown fox
is

KEYBack was pressed.
KEY Back was released.
KEYBack was pressed.
KEY Back was released.
KEYBack was pressed.
KEY Back was released.
was not megan
12345
asfaf

KEYHome was pressed.
KEY Home was released.
KEYEnd was pressed.
KEY End was released.
KEYDelete was pressed.
KEY Delete was released.
KEYDelete was pressed.
KEY Delete was released.
KEYDelete was pressed.
KEY Delete was released.
KEYDelete was pressed.
KEY Delete was released.

I am not responsible for anything you do with it. It is provided as-is, without any warranty of any kind.

[Blender] RC211v model - Day Eight

2010-01-02T03:10:00.005+08:00

Today I was playing around with the materials I will use for the bike. I figured, since the only thing left to be modeled is the body kit, I would prepare the materials for everything underneath before I cover it up.

(click the image for a larger view)

The chrome material isn't looking too good; it is reflecting the ridges of the radiator. And it doesn't look like chrome at all.

The rubber on the tires look OK, but will still need some tweaking. The leather seats look OK too, but you can't see it that well from the screenshot. The black plastic material is a little too black, I think. Comments are welcome here. I just couldn't stand another render with Blender's internal renderer - took me 15 minutes. After two test renders I was done.

Also, I realized, the materials don't work in Yafaray. So I'd have to redo everything for a Yafaray render.

The gradient background isn't supposed to look like that. I just wanted a plane to show the shadows. I should have just used a cube. Come to think of it, if I had used a cube instead of a subsurfed plane, the render wouldn't have been that time-consuming. Dammit.

The body paint looks good. I actually downloaded this material from blender-materials.org (it isn't up yet, but it points you to the old site here, which has the actual database). Materials are my weakness in blender. I do not yet fully understand the blender materials system, but I'll get there.

That's it for today. Tomorrow - model the body kit. I wish.

For more works, see my deviantart gallery at:

http://maranas.deviantart.com

[Blender] RC211v model - Day Seven

2009-12-31T03:18:00.004+08:00

It is day 7 of my holiday blender modeling marathon. And with another day comes another unproductive hour of modeling.

Handlebars are done, the brakelines too.

Only the bodykit remains to be modeled (along with the windscreen).

The screenshot isn't that smooth; all subsurf modifiers are set to level 1 for modeling purposes. I will set them to level 3-4 when I'll do the final render.

I cannot wait to put materials on it, but I tend to go lazy when I rush things. So I will continue tomorrow.

Plus, I have my FIFA10 season to play with. As the manager of Crystal Palace.

Yafaray render:

For more works, please check out my deviantart gallery:
http://maranas.deviantart.com

[Blender] RC211v model - Day Six

2009-12-30T04:58:00.003+08:00

Another unproductive day modeling-wise; I only spent 1 hour on the model today. Damn you, FIFA10! Oh well - it IS the christmas/new year break.

I was barely able to finish the front and rear brakes. The model is almost complete, though. Only the handlebars, wiring and bodykit (windscreen and engine cover) to go.

Yafaray render:

For more works. see my deviantart gallery at:
http://maranas.deviantart.com

[Blender] RC211v model - Day Five

2009-12-26T04:07:00.007+08:00

Today wasn't really productive modeling-wise; I wasn't able to meet the goals set yesterday (brakes, handlebars). I spent most of this night scouring the Blenderart site for the magazine issues. So much information! You have to check them out.

I also found the perfect tutorial on spin modeling (see issue 5), a whole issue on modeling vehicles (issue 8), and an issue with an article on making tracks (issue 11), which may prove useful if I decide to stop putting off modeling the chains.

Note: When downloading their issues, try using the mirrors as much as possible, to help them lower their bandwidth costs. Better yet, use the .torrent.

As for my current progress, I finished up modeling the wheels. I did not start on the brakes yet, as I realized, I have to model the wheels first. You may notice from the screenshots that the subsurf level is set to 1; I am having issues with slow response time due to high facecounts with subsurf on a level higher than 2. The model you see above has subsurf for all parts at level 1 only, hence the blockiness.

It is starting to look like a complete "naked" bike.

Yafaray render:

For more works, see my deviantart gallery at:
http://maranas.deviantart.com

[Blender] RC211v model - Day Four

2009-12-25T03:26:00.004+08:00

It's Christmas, just had some noche buena and I am full to the brim. Remind me to run at least five miles tomorrow.

So before sleeping I thought I'd put in a little work on the RC211V. I am giving myself a break from violin practice today; my ears are starting to hurt.

I was able to finish the exhausts and radiator. Spent most of the time on the radiator, though; I had to manually extrude the ridges. Each one. Awesome.

The facecount is pretty high now, and it is starting to slow down my PC; I had to group the parts with similar materials into their own layers and lower the subsurf levels to make it a little snappier.

Tomorrow, I'll do the handlebars and the brakes. I still haven't found out how to do the chains, but if I have time left over I might start doing the wheels.

One more thing, blenderart.org produces the BlenderArt magazine, and all of their issues feature tutorials on several aspects of using blender. I highly recommend checking them out.

Yafaray clay render:

For more works, see my deviantart gallery at:
http://maranas.deviantart.com

Merry Christmas!

[Blender] RC211v model - Day Three

2009-12-24T03:16:00.007+08:00

Another day, another hour. Tomorrow's a holiday!

Finished the seat and the fuel tank.

I realized my proportions were all wrong when I couldn't fit the fuel tank. I made the engine too big. This is one of the reasons why you should always use reference pictures when you have them.

Also, it is a little funny how I put a lot of detail into the engine, even if no one will see it in the final render. Oh well.

Yafaray clay render (sorry, I accidentally checked the "use alpha" tickbox):

You may have noticed how I am trying to put off modeling the chain, gears, brakes, wheels, etc. I am new to blender; this is just my fourth blender model. I am still looking for an adequate explanation/documentation on how to do spindups and how to use paths for duplication. I don't know which tool/command this is equivalent to in blender. I don't even have an idea if I'm calling it right. If I don't find one, I might make my own tutorial after I figure it out.

For tomorrow, the fun parts: I'll model the radiator and the exhausts plus additional engine detail.

For more works, visit:
http://maranas.deviantart.com

[Blender] RC211v model - Day Two

2009-12-23T01:53:00.007+08:00

Day two of my modeling project. I didn't touch the model last night; today I got home late from work, and had to practice with my violin, so I only modeled for 1 hour. It is starting to look like a real bike this time. Here's a Yafaray export:

Rendering with Yafaray has never been easier, you just need to setup your lighting in blender. Once that's done, export it to Yafaray. That's it.

It is also really fast; doing a clay render takes less than 10 seconds for low-polygon models (like this one; i haven't applied the SubSurf modifiers yet) so you can easily check for modeling errors.

I am getting sleepy. Hope I get some work done on it tomorrow. At least the fuel tank and seat.

For other works, see:
http://maranas.deviantart.com

[Blender] RC211v model - Day One

2009-12-21T00:28:00.004+08:00

It has been quite sometime since I last updated my deviantart account, and my Blender skills are getting a little bit rusty, so I decided to make a model of something. Plus it's the holidays; plenty of free time and no football practice.

So here is what I was able to produce: A partially modeled RC211v by Honda. I love modeling motorcycles. Maybe because this is the closest I will ever get to owning one of these babies. Plus I get to learn how they are made; much like when I'm modeling cars.

I plan on spending 2 hours a day into modeling random things; right now I am modeling this bike based on a Tamiya model kit I bought from Japan a few months back. No scanned-in blueprints; just straight-up modeling from real life. It is a little harder.

Windows 7: Solution to No Internet Access (Local Only) problem

2009-12-11T23:37:00.008+08:00

I was having problems with a Windows 7 installation for a new MSI VR220 laptop; Whenever it connects to any network, it gets Local Only access. Other computers on the network get Internet access. It gets an IP and there are no conflicts with other computers. I tried connecting wirelessly via the WiFi card and through wire via the RealTek adapter but nothing worked. I tried searching the web for answers, but to no avail.

Several users suggested turning off IPv6; that wasn't the problem in my case; I was correctly getting a v6 IP from the router. Most suggested reinstalling the driver; obviously this wasn't the problem as it was able to connect and identify properly with the router. (Also, any solution involving "reinstallation" usually means the speaker doesn't know what the problem is. Ask someone else.)

The gateway and DNS were correctly configured; I learned this by doing an "ipconfig /all" on a Vista laptop (with Internet access) connected via wifi to the same router (A TP-Link with 4 ports and wifi), and comparing the DNS and gateway IPs with the MSI Windows 7 laptop. They had the same settings.

I tried diagnosing the connection by right-clicking on the adapter and clicking "Diagnose"; the application says that my DNS is not responding. Which is weird, because when I try pinging any website URL via command line, e.g. google.com, I get a response. (The DNS just resolves IPs to domain names. The fact that I can ping google.com and get a response from google's IP means the DNS works.)

By this time I was suspecting that it may be due to conflicts with a firewall/antivirus software. But this was a fresh install; no apps installed yet, and used only for browsing for 2 days.

What a difference those two days made. When I tried logging in via user Guest, I noticed that the WiFi icon on the taskbar now tells me I have internet access. I thought the problem was solved, so I downloaded avast!, tried installing it as Guest. The UAC prompt appeared asking me for an Administrator user and password. I inputted the details, and when the avast! installer tried downloading setup files, it couldn't access the internet! Applications in Guest can access the internet, but not the setup file run as Administrator!

I switched again to the Administrator account, and tried accessing the Internet to confirm this; again the problem appears.

At first I thought this was for security; maybe, just maybe, Windows 7 wouldn't let you surf the web as Administrator (which would make sense; it would be the equivalent of doing your everyday tasks in Linux as root). For the next step, I tried creating a new Administrator user. I logged in to that account, and voila, it was also able to connect to the net.

The original Admin account may have been corrupted; probably by malware. From the laptop's user surfing the net with it for 2 days unprotected. What a difference those two days can make.

I still haven't found the exact cause of the problem, though. For now, I created a new Administrator account and installed the latest avast! into it. Then I passworded the Administrator account, created a regular user account, and haven't heard complaints since.

Lesson learned? Do not connect to any network without antivirus/anti-malware software installed. End of story.

Android on an HTC Touch Viva (Opal)

2009-11-27T00:19:00.010+08:00

The thing I love most about HTC phones, and non-iPhones in general, is you can do practically anything you want with it, and if you're clever, you won't even void the warranty. I had an HTC Magician a few years back and booted it up with all kinds of Linux distros, an OpenMoko distro included, and learned a lot on programming for mobile OSes in the process.

A few months ago I was able to boot into Linux and Android on my HTC Touch Viva (Opal) using Wing Linux, but the driver in the distro wasn't working with the touchscreen, and the key mappings were off. Today, reading from xda-developers that a new release of the distro, for OMAP850 devices, was available from the sourceforge page, with crossed fingers, I tried installing it again.

And what do you know? Touch screen now works! I can even call and SMS from within Android! The Wi-Fi and Bluetooth don't work, though. And the audio. But since my phone really isn't for calling, but for developing, it isn't too much of a problem.

Here are the steps I followed to make it work on the Opal:

1)Download the distro from here.

2)Extract the files from the archive. In the archive, there will be several .CAB files. You will have to choose 2 of these files to copy to your device.

File 1 is the one with rootfs in it's filename. (I can't remember the filenames, but it will be obvious).
File 2 is the one that is specific for your device.

3) Copy the files to your device. Install the CAB for the root filesystem first (File 1), then install the device specific CAB next (File 2)

IMPORTANT: Install on you SD card. Do not install in your device's flash memory.

4) Go to Programs->Wing Linux

5) Click on the Run button

6) The Haret bootloader will start booting the Angstrom Linux distro, then Android. This may take a while, so you might want to get a cup of coffee or read a good book or something.

At certain points in the install, it will ask you for input. For the Opal, since we do not have a keyboard, you just have to wait for it to timeout. The default settings will be selected when you do not enter any input.

7) After a few minutes, maybe 15, check back on your device. You should see a Screen calibration screen. Calibrate the screen and wait. Again.

8) At this point, it will show the Angstrom boot screen. After that, the Android 1.5 boot screen. Again, more waiting.

9) If all goes well, you should now be booted into Android.

- If at some point in the install, the screen hangs and you see a blinking cursor, and you are sure you have waited long enough (or until after the screen calibration), perform a soft reset by taking out the device's battery. Try booting into Android again. In most cases, it will be successful.
- If the above doesn't work, delete the rootfs.img file in the linux directory and boot into Wing Linux again.

*It is a prerelease build, so it's not yet perfect, but the install is quite easy. You can't complain.

10) To soft reset in android, long-press the Red button and select Power Off. This will soft-reset the device and put you back in Windows Mobile.

11) To install .apks (application packages for Android), copy everything to your device's storage card before booting into android. When in Android, use the AndExplorer application to copy the .apk files to your /system/app directory.

Additionally, Wing Linux doesn't just work for HTC's Opal; it is for OMAP850 devices, so there is a chance that it will boot up with your device if it's OMAP850. See their "Device Status" page for known working devices, or add your own.

As always, there is a chance that you may damage your phone while doing this, so backup your data if you can't live without it. Enjoy! Screenshots to follow!

latest movie by stephenie meyer

2009-11-20T07:47:00.004+08:00

team edward? team jacob? team pacquiao!

i got this from my email, so i don't know who i can attribute it to.

and why not watch the hatton knockout while you're at it?

How to make deadlines

2009-08-22T02:39:00.002+08:00

I just came upon this great article from gamasutra: http://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php?page=4

This one takes the cake, though:

The Programming Antihero

I was fresh out of college, still wet behind the ears, and about to enter the beta phase of my first professional game project -- a late-90s PC title. It had been an exciting rollercoaster ride, as projects often are. All the content was in and the game was looking good. There was one problem though: We were way over our memory budget.

Since most memory was taken up by models and textures, we worked with the artists to reduce the memory footprint of the game as much as possible. We scaled down images, decimated models, and compressed textures. Sometimes we did this with the support of the artists, and sometimes over their dead bodies.

We cut megabyte after megabyte, and after a few days of frantic activity, we reached a point where we felt there was nothing else we could do. Unless we cut some major content, there was no way we could free up any more memory. Exhausted, we evaluated our current memory usage. We were still 1.5 MB over the memory limit!

At this point one of the most experienced programmers in the team, one who had survived many years of development in the "good old days," decided to take matters into his own hands. He called me into his office, and we set out upon what I imagined would be another exhausting session of freeing up memory.

Instead, he brought up a source file and pointed to this line:

static char buffer[1024*1024*2];

"See this?" he said. And then deleted it with a single keystroke. Done!

He probably saw the horror in my eyes, so he explained to me that he had put aside those two megabytes of memory early in the development cycle. He knew from experience that it was always impossible to cut content down to memory budgets, and that many projects had come close to failing because of it. So now, as a regular practice, he always put aside a nice block of memory to free up when it's really needed.

He walked out of the office and announced he had reduced the memory footprint to within budget constraints -- he was toasted as the hero of the project.

As horrified as I was back then about such a "barbaric" practice, I have to admit that I'm warming up to it. I haven't gotten into the frame of mind where I can put it to use yet, but I can see how sometimes, when you're up against the wall, having a bit of memory tucked away for a rainy day can really make a difference. Funny how time and experience changes everything.

- Noel Llopis

PocketTweet

2009-04-14T00:51:00.015+08:00

PocketTweet is a small Windows Mobile application that lets you log-in to and update your Twitter account using an active data connection.

Screenshots:

PocketTweet version 0.1(Download Here):
http://www.mediafire.com/?zilgxyoyyx2

Requirements:
- Windows Mobile (2003 and later)
- .NET Compact Framework 2.0

To Do:
- Skinnable interface
- Direct messaging
- twitpic support
- saving tweets.
- friend view
- replies
- account settings