Video Lecture: From NAND to Tetris

A video lecture that shows how to build a game-playing computer starting from first principles, e.g. hardware, and piling on the abstractions until you have a CPU, language processors, and a VM that can be used to write, compile, and run a Space Invaders game. If you are not sure whether it is worth investing the hour for the full lecture then try this 10 minute taster:

The full hour-long lecture, "From NAND to Tetris" is here:

As you begin the revision process ready for the exams you might find that taking a look at relevant video lectures like these will be a useful alternative to reading through your notes yet again.

Posted
 

Manchester Baby Films

Two youtube films that I found which feature the Manchester Baby. The first is vintage footage from the BBC, reporting on the birth of the baby,  which was unearthed for the fiftieth celebrations of the Baby and accompanied this article. This footage was helpfully reposted to youtube as well:

Additionally I found this footage of two of the inventors of the Baby, Tom Kilburn, who wrote the first ever program to run on the baby which was used to test the hardware, and Geoff Tootill:

 

Posted
 

Why Create Software?

One of the topics that came up in yesterdays tutorials was about whether people will create new software, will innovate, if there isn't a clear way to make money. My position is that that is exactly what people have done and will keep doing. People will always create new stuff; because they have an itch that they need to scratch, a problem they need to solve, because it is interesting, or even just for the hell of it. I personally think that, from the perspective of the innovator, money is not the primary motivation for doing anything innovative - it is just a nice bonus. The example we used yesterday was web browsers. There was a misconception that although Firefox is a good quality piece of software, easily eclipsing all current alternatives, that this only occurred because the Firefox code is based upon the code from Navigator that was released by Netscape when the company failed. The argument was made that for the most part good quality free software only exists because it is based upon commercial software made by professionals. In the case of Firefox this is factually incorrect, the codebase has been completely rewritten at least once, possibly twice. Even if it hadn't though, Netscape Navigator was, in an early incarnation, called Netscape Mosaic. This is because one of the founders of Netscape, Marc Andreesen, was the developer of NCSA Mosaic, roundly regarded as the original web browser, the original innovation. So, not only is Firefox directly descended from the original web browser, Mosaic, but its code base originated in non-commercial research. In addition, Mosaic was also developed, not because somebody decided that the web would be the "next big thing" and that a web browser was needed to capitalise upon it, but because a developer decided that it would be useful, and other people agreed, and it snowballed from there. In comparison, the most popular completely commercial web browser (you can guess which) is roundly regarded as "not very good" in comparison to Firefox anyway. However, the next best browser, in my opinion, is Opera, which is completely commercial and closed source. I suppose the upshot therefore is that whether a project is free or non-free, whether it is developed by people just doing it for the money, or because they care deeply about the project, this doesn't necessarily have any effect on the outcome of the situation, the software might be good, or it might be bad. We can't really draw any conclusions about the quality of the software from the license under which it is distributed. However, at least if it is low quality software and free software then there is a nugget of hope, because you can always improve it by making your own changes. Addendum: It turns out that three Finnish engineers might have beaten Andreesen to the invention of the first graphical web browser according to this article. There is also a discussion over at Slashdot on the subject.
Posted
 

Random Number Generators in C/C++

I found this article and thought that you guys might find it interesting because a number of you used calls to rand() in your last coursework. Basically it is comparing different implementations of pseudo random number generators in C and C++. It also gives a snippet of C++ (that you should easily be able to convert to C) that is both more random and faster than the standard version of rand().
#include <iostream>

// You need to initialize low and high to seed values.
// This would look better as a class but I’m lazy.
unsigned int low;
unsigned int high;

unsigned int GameRand()
{
    high = (high << 16) + (high >> 16);
    high += low;
    low += high;
    return high;
};

int main()
{
    high = 0xDEADBEEF;
    // usually I only have one uint32 to initialize with so I xor it
    //with a known good seed to get the second seed value
    low = high ^ 0x49616E42;
    for (int i = 0; i < 10; ++i)
    {
        std::cout << GameRand() << std::endl;
    }
}
Posted
 

Coursework #4 - Dev Project #2 Posted

The requirements for the second development coursework, "Simulating the Manchester Baby" have been posted.
Posted
 

Online C Book

I just found a useful resource for you guys, an online version of The C Book (second edition) by Mike Banahan. The essentials of the C language have not changed sufficiently since this book was published that it is no longer useful, in fact at the introductory level, which is where most of you are right now, it is ideal.
Posted
 

Art of Unix Programming

The Art of Unix Programming (TAOUP) [ pdf ] is a useful book (available online for free but well worth purchasing in dead tree edition) which underpins much of the software oriented aspects of this module. Specifically, TAOUP introduces the idea of an underlying philosophy of software development and programming in the context of Unix systems. However, many of the lessons that we learn in TAOUP are not constrained only to Unix-based operating systems but give us insights into software development in general. For example, the rule of modularity suggests that we should write small modules (for whichever value of module your problem or language requires) and that these modules should be able to communicate via cleanly defined interfaces. Meanwhile the rule of composition builds upon the idea of interfaces and communication from the rule of modularity by suggesting that we should construct our software as individual units that are designed to be joined together to form composites with a wider range of capabilities that the individual ever had. Truly a case of the whole being more than the sum of its parts. It is worth taking a look at TAOUP to help make you a better programmer and also to help you to better understand the concepts that we are studying in AC2B.
Posted