Say for example, we have our C library in a folder named c; there are two files: c/functions.h and c/functions.c.

/* c/functions.h */

int foo(int a, int b);
const char * hello();

/* c/functions.c */

#include "functions.h"

int foo(int a, int b)
{
	return a * b;
}

const char * hello()
{
	char * s = "Hello from pure C!\n";
	return s;
}

Firstly, we need to compile a object file which contains the above functions which can then be used via Vala.

gcc -c c/functions.c -o c/functions.o

Now thats done, we can move onto creating a VAPI file which is similar to a C header file, it contains the same prototypes as functions.h, but in Vala syntax.

/* functions.vapi */

[CCode(cheader_filename = "functions.h")]
namespace functions {

	[CCode(cname = "foo")]
	int foo(int a, int b);

	[CCode(cname = "hello")]
	unowned string hello();
}

The VAPI file makes use of several attributes (in a way similar to how C# does), for example, cname="foo" is simply what the function is referred to in c/functions.h, which allows us to change the name exposed to Vala for greater OOP clarity if necessary.

The method modifier unowned is used as an equivalent to C’s const. Try omitting unowned and see what happens when you run the end program, bonus points if you can explain why .

Moving on to the main program, which should be self explanatory:

/* main.vala */

using functions;

public static int main(string[] args)
{
	stdout.printf("\nfoo(7, 6): %d\n", foo(7, 6));
	stdout.printf("hello(): %s\n", hello());
	return 0;
}

Almost there now, we just need to link it all together using the Vala compiler. Open you favorite terminal and enter the following:

valac -X "-Ic/" -X "c/functions.o" --vapidir=. --pkg functions main.vala

A quick explanation of the above and we’re done…

The -X flags specify arguments to pass to the C compiler: we need to pass the include directory of our functions.h, which is the -l flag and we also need to specify the object file which contains our C functions (c/functions.o).

Next up is the --vapidir parameter which simply points to the folder with our VAPI file in it. We specify which VAPI file to load using the --pkg functions parameter. As you can probably guess the pkg name must match the base name of it’s respective VAPI file.

Now finally, the end program can be run:

$ ./main

foo(7, 6): 42
hello(): Hello from pure C!


The idea is pretty simple, it’s a site built around Facebook which allows users to maintain a list of films they have watched and recommend them to friends.

Whilst the concept isn’t particularly new or exciting, it has been a very interesting project to do, giving me the opportunity to brush up on my PHP and Javascript skills and give my brain a rest from the torture of emulator debugging.

It needs a few performance tweaks and cross browser compatibility checking however. If more than a handful of people use it (which I doubt), I have a few more features to add.

http://moviehat.co.uk

The suggest box is open for a better sexier Web 2.0-esque name

james@jameslaptop:~/Projects/Emulation/ZZ80E$ ./a.out z80/zexall_sdsc.sms
Z80 instruction exerciser

ld hl,(nnnn)................. CRC:350e5018 expected:5f972487
ld sp,(nnnn)................. CRC:45f3041a expected:7acea11b
ld (nnnn),hl................. CRC:c9f9ffd8 expected:a3608b47
...etc...

My first guess was that there was a bug in one of the opcodes used to calculate the CRC because I know for sure that the ld opcodes are fine.

However after going through the list of opcodes involved in the CRC with a toothpick, I still can’t find any glaring or even minor mistakes The problem with emulator debugging, especially at such an early stage, is that it’s hard to tell if you’re looking in the right place; the bug might be in a seemingly unrelated piece of code, the effects of which have simply cascaded down the chain.

It’s going to be a long night.

Not bad.

This Windows-killer took me the better half of a week to figure out, I’m sure I’ll have a fully functioning GUI, Nvdia drivers and a TCP stack by next Tuesday

I’ve had to pick up a bit of x86 assembler on the way, with hopefully a lot more coming. A few of the functions look like this:

; Initial entry point
[extern kmain]
[global load]
load:
    mov esp, stack_end
    push eax
    push ebx
    call kmain
    cli

hang:
    hlt
    jmp hang

; Returns CPU details
[global get_cpuid]
get_cpuid:
    push ebp				; save the base pointer
    mov ebp, esp			; move the current stack pointer to ebp
    mov eax, [ebp+8]		; get first parameter (mode)
    mov ebx, [ebp+12]		; get second parameter (pointer to string)
    push ebx
    cpuid
    pop eax
    mov [eax], ebx
    mov [eax + 4], edx
    mov [eax + 8], ecx
    leave
    ret

[global is_in_protected_mode]
is_in_protected_mode:
	xor eax, eax
	smsw ax
	and ax, 1
	ret

call kmain transfers control over to a C function which inits the rest of the (insignificant) kernel.

void kmain(void * mbd, unsigned int magic)
{
	gfx_init();
    gfx_clear();

    if(magic != 0x2badb002) {
		oops("Invalid magic number: %d", magic);
    }

    kprintf("Booting ZoofOS...\n");

    char cpuid[20];
    get_cpuid(0, cpuid);

	int mode = is_in_protected_mode();

    kprintf("CPU is a %s, and is running in %s mode.\n", cpuid, (mode) ? "protected" : "real" );
}

The most interesting thing with kernel development is that you have to do everything from scratch, no standard libraries, no nothing.

ZoofOS isn’t much right now and never will be, but it will be an incredible learning experience.

Progress has been remarkably quick, with over a hundred of the most used opcodes implemented so far. One problem with the C# version was that as I wanted a built in disassembler and thought it would be cleaner, I had to have an individual method for each opcode which added the opcode’s mnemonic to the debug output. This time around, I have placed the vast majority of the opcode code in the switch statement, with common parts of code outsourced to inline functions. This has made the code a lot cleaner and manageable. To handle disassembly, I have created a Python script to convert a list of all the Z80 opcodes and their mnemonics to a C function which contains a huge switch statement to return the mnemonic. It might not be the fastest method, but it’s adequate for debugging.

This has been my first experience with C, and so far, it’s been a good one, I love the low level sexiness of it all. Would implementing a C standard library for Master System development using SDCC be too ambitious?

Unlike WPF (and also I think Winforms), Gtk# does not complain when a GUI object is accessed or modified from a separate thread, so I incorrectly assumed that the issue wasn’t related to cross thread safety. As it turns out, my assumption was wrong (they usually are ).

In order to alter Gtk object from a separate thread, a method similar to the WPF Dispatcher can be used:

Gtk.Application.Invoke(delegate {
      randomGtkWindow.Title = "blah";
});

Now, if we don’t invoke on the original Gtk thread, sometimes it will work, sometimes it won’t, with quite disastrous results. From what I’ve experienced so far, generally no error is thrown and if it is, then it’ll be quite cryptic.

Maybe the Gtk# developers should cause Gtk objects to throw an exception when accessed in a different thread?

I had honestly, never expected Linux to ever be ready for the desktop, yet maybe now after almost two decades I think it nearly is. After using Kubuntu for two days, I’m very impressed at how far it has come. Setup was a snap, KDE looks pretty (I used to only use GNOME), it feels solid and everything is nicely abstracted away from the command line, though obviously, all the flexibility and control which Linux provides is still available under the surface. I’m a geek and as such I don’t mind getting my hands dirty compiling sources, screwing with grub or rolling my own kernel, but sometimes it’s nice for things to just work without any hassle, especially when you have other things to focus on.

All it needs now is for Microsoft itself to port .NET to Linux and not Novell *ducks*

http://zoofware.com/zoofware-matrix-machine/

using System;
using System.Collections.Generic;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;

namespace ConsoleApplication3
{
	class Program
	{
		static void Main(string[] args)
		{
			Dictionary<int, int> bar = new Dictionary<int, int>();

			ScriptEngine engine = Python.CreateEngine();
			ScriptScope scope = engine.CreateScope();
			scope.SetVariable("bar", bar);

			string script = @"

from System import Console

foo = 'Hello from IronPython!'
Console.Title = foo

for i in range(0, 10):
	bar.Add(i, i**2)";

			engine.Execute(script, scope);
			Console.WriteLine(scope.GetVariable("foo"));

			foreach (KeyValuePair<int, int> kvp in bar)
			{
				Console.WriteLine("{0}^2 = {1}", kvp.Key, kvp.Value);
			}

			Console.ReadKey();
		}
	}
}

This is a great way to allow custom user defined scripts to alter a program without changing the actual code base. The embedded Python has complete access to the .NET library, likewise the calling C# has complete access to the embedded script.

I can’t see much practical use for this in a chat client, but I’m working on it