1. haanigram:


    u wot m8

    (Source: diningwiththeasquiths)

  2. reuben-thomas:

    Theme from Attack on Titan but on a gameboy emulator. 

  3. Went on CSPAN this morning to talk about my son's amazing S.A.T. score →

    I truly hope this guy was trolling.

  4. Without further ado, the rumors are true. →



    What is “Saffron”? People have seen me using this name online & asked me what it was.

    Let me take you back in time. We started working on a new, top secret project codenamed “Saffron” on August 1, 2013. At the time, no articles like this one had been written, & Facebook hadn’t yet…

    Wow, that looks awesome. Too bad I don’t have a iOS device.

    May I ask what your backend stack is? You know: message storage, synchronization, etc.

  5. holmesianpose:



    I don’t even know what this is from but it’s amazing

    (Source: alisonshendrixs)

  6. machosx:

    My views towards Android have slowly changed over the past couple of weeks. I’m beginning to like what Google’s doing with it. I feel excited to download Android Studio (was using Eclipse before, a total nightmare) right now & start working on an Android port of Scapes.

    Yeah, Android Studio is much, much better than working with Eclipse. It’s based on Intellij IDEA, a very stable and functional Java IDE.

  7. gbcemu - Phase 1: The Microprocessor

    I’ve started working on the first phase of the project. Below is the current state of my approach. I’ll continually add more posts to my Tumblr every time a milestone is reached.

    If you’d like to follow development and my thoughts more closely, feel free to follow the project’s repo on Github.

    Phase 1: Microprocessor


    We begin by defining what exactly our CPU needs to do in order to run Gameboy Color games. In simple terms, it needs to be able to take a ROM filled with machine code (0s and 1s), and execute the machine code instructions one by one.

    How will the emulator interpret the machine code instructions? It will need to somehow convert the machine code into C and then execute that. For starters, we’ll need to create a disassembler that translates each machine code instruction into a form of assembly. The instruction set of the GBC’s CPU is thankfully quite simple when compared to today’s CPUs. How simple? Well, to the point that there are no multiplication or division instructions!

    The emulator could then run through the assembly instructions and execute them in C. So we may need an assembler as well - one that takes the raw assembly instructions and assembles them into a binary form runnable on modern x86 CPUs. Furthermore, all internal registers need to emulated as well so that they can be accessed.

    What about the memory? That will definitely need to be emulated as well, since the incoming instructions from the ROM will need to access some sort of memory during execution. The size of the GBC’s RAM is 64 kB and is well outlined in several documents put together by the emulation and RE scene in their early days. That could be done using an array of the given size perhaps.

    I think the above should be enough to have rudimentary CPU emulation. Each component of the CPU could lie in its own header file, and each of these can then be accessed from a central gameboy.c that spins up a GBC instance on demand.


    The CPU logic will lie in two related files: cpu.c and cpu.h. A function, run_cpu(), will be the only function that the Gameboy (or any other external file) needs to invoke in order to spin up a CPU instance. run_cpu() will do something similar to the following:

    1. Initialize the internal registers.
    2. Allocate the necessary memory (RAM) for the device.
    3. Setup the different sections in the memory and set default values if applicable.
    4. Run a fetch-execute loop that takes one clock per iteration (not sure how this will be implemented).
    5. On each iteration, the next instruction is fetched from the ROM, interpreted (ideas below), and then executed depending on its opcode.
    6. At the end of the iteration, the sound and graphics output is updated (this will be worked on later).

    The CPU itself will be represented by a standard struct. The struct will house a pointer to the memory, the internal registers, and the a pointer to the current instruction. It may also house the current state of the CPU (busy, free, off, etc.).

    The ROM itself will be stored somewhere on disk, so the ROM location has to be provided (command line argument maybe), and then a FILE pointer will be setup to be able to work with it. Before processing, the ROM could maybe be copied into the RAM, but I doubt that this was the case with the Gameboy, as the ROM was provided on-cartridge and was usually larger in size. I’ll have to check the specs for that.

    Instructions will be fetched one by one from the ROM file, and then interpreted. The interpreter could be a simple function that takes the value and passes it to a static lookup table that contains all instructions. The C implementation of each instruction will basically be a function that takes a value as an argument (if applicable) and do something with it. I doubt any of them should return anything.

    CPU Implementation

    The CPU is represented by a single struct called cpu_t (may be changed). For the time being, this struct contains pointers to the memory and the values of the internal registers. More may be added as development progresses.

  8. :(

    (Source: iraffiruse)

  9. One of the best Dexter episodes ever.

  10. machosx:



    I published MetroMate for Android on January 1. For some reason, I didn’t tell people till today. So go get it on Google Play!

    Congratulations man! I tweeted it out a few days back but I guess another one wouldn’t hurt. Too bad I don’t have many followers.

    How the hell do you reply on Tumblr? I can’t figure it out. :D
    Thanks, mate! Really appreciate the love. :)

    Well, you just replied :) The whole idea behind Tumblr is reblogging stuff. So to reply, you just quote the post, and add your reply.