These are just some of the assignments I've worked on over the past five years at university. Most of them are pretty anaemic, especially the early ones. But they do get a little bit more interesting as they progress, so don't be disheartened - just skip the first couple of years. :)
License - everything is covered by the BSD license, except where otherwise noted. All files should have the license information in their header.
Introduction to Programming in C++ (IPC) - playlist (11,203 bytes)
Very boring. Just reads in a "database" (i.e. line-delimited text file) of song titles, artists and lengths, and allows you to do... well, not a lot. Display it, pretty much. Apparently I never got around to actually adding sort functionality, which would have been about the only non-trivial part of this program.
Of course, this was one of the first C/C++ programs I'd done that wasn't just a tutorial out of a book. I was quite happy with it at the time. It has relatively good input validation, among other things. I've always liked doing strong validation.
It's funny that I complain in the source that the design sucks; it should have been done using classes for proper data abstraction. But we weren't allowed to, apparently - mere first year's aren't suppose to be able to write C++, apparently.
Object Orientated Programming - species (19,801 bytes)
Slightly less tedious than the first semester assignment, this one had us load a database of fictional species, each with various properties - such as it's type (animal or plant), environment (e.g. land, sea, etc), and so forth. The idea was to permit the user to find a particular species by answering questions about it. If it was then determined that it didn't already exist, they could add it.
I can't recall exactly how intelligent or not this is... I think it'll at least skip questions which don't provide any clarification, although whether it priorities it's questions in order of usefulness I don't recall.
Object Orientated Programming - subject (13,802 bytes)
An extended version of the 'species' program, this one adds classes and my own memory model. Yes, even this far back, when I'd been coding in C/C++/ObjC for just 9 months or so, I was already sick of C++'s lack of object management. So, I wrote just the first of many of my NSObject C++ clones.
That said, this one's UI seems to suck compared to 'species'. I don't know why. It seems to ask questions at random, as well... I guess that was part of the spec. But rather than give you a list of all possible results to make it much less ambiguous, it just demands you know exactly what "size:" means. Okay... This is what happens when you let academics write specs. Don't try this at home, kids.
It's also embarrassing that at this point I was still making the classic beginners mistake of having a header file for my main() file. They way it's taught in academia, header files are where you put all the declarations, source files the implementations. That's not always true... you only have header files if there's someone around who wants to import them... if there isn't, there's no point having them. Thus, since you should never import your main() file from any other, you should never have a header file for it.
Systems Programming - tidyup (14,653 bytes)
This assignment was pretty trivial... create a shell script (possibly using awk) which could find certain types of files (based on their file extension or permissions) and archive them, or modify their permissions. Duh. It really should be done in a couple of lines using 'find' and so forth, but I couldn't figure out how 'find' worked back then. So it's done recursively. Nasty. But it works, and has very good input validation. :)
Systems Programming - billing (5,313 bytes)
The second SYS assignment, this one focusing on good old vanilla C. Since I'd already done IPC and most of OOP by this point, plus my own hobbyist tinkering with Objective-C, this was pretty trivial. All the program does is let you create a database at runtime of customers (e.g. students, I think the example the lecturer used) which have some balance, some payment due, and some date by which that's due. Whatever. You can then list customers according to a few primitive criteria (e.g. unpaid). Input validation is pretty bad in this, oddly enough... entering "1,000,000" for the opening balance is treated as $1 by the program... whoops.
Physics - Waves (8,388)
I think this was actually in response to someone releasing a RealBasic application for doing basic physics & engineering calculations. I suggested they could do it just as easily using Cocoa, and did this tiny demo to prove it. I don't think they ever did move to Cocoa. Shame.
Anyway, it apparently works out the average power (and a few other properties) of a parameterised sine wave. I recall vaguely that it did actually come in handy for my first year physics; I presume we studied this particular equation at some point. It's worth noting that this is probably one of the first programs I wrote using Cocoa. I'm pretty sure it wasn't the first, since I wrote it to prove how easy Cocoa was, meaning I must already have known a bit about Cocoa, but anyway... it's an early one. It contains an entire method. :)
Also note that adding the entire BSD license to the three source files adds an entire 18 bytes to the compressed size. Cool. :)
Algorithms, Data Structures and Compilers - electoralSort (15,744 bytes)
This was actually a pretty cool assignment; to implement various sorting algorithms and test their performance. It also entailed a fair bit of theoretical work, examining big-O performance of the algorithms and other such metrics. I actually did a quite pretty web report - entirely for my own benefit - as well as a formal report (156 KiB).
This code won't actually compile as-is. Despite my best efforts, I couldn't get an AVL tree of my own making to work. I did get something, which appeared to work correctly, but which was unbelievably slow. So, I conceded defeat and just used the AVL tree implementation we were offered. Thus, given I cannot redistribute that code, you'll have to comment out references to it (or implement your own).
Sadly, the best part about this subject - the compiler work - I cannot distribute. We wrote a compiler that used a basic Pascal-like language, and output an arbitrary intermediate assembly-like language. Unfortunately, we started from a basic framework provided by the lecturer. I'm not sure now which is my code and which is not... in any case it'd be pointless to try and separate it. One day I'll write my own compiler from scratch; I've always wanted to. The coolest thing was when I combined this with our work in another subject, where we were working with a very crappy computer simulator called the ELMC (Extended Little Man Computer). I adapted our compiler to output into the numeric language used by the ELMC. It actually worked! It was awesome. I also started implementing optimisations, such as compile-time evaluation of fixed expressions. Funnily enough, this typically resulted in all your code becoming a bunch of print instructions, since with the limited I/O of the ELMC (the user could enter numbers, that was it), it was pretty hard to actually write useful dynamic code. :)
Artificial Intelligence - tokenRace (11,754 bytes)
This was actually a pretty cool assignment, too. Although I've always mocked Scheme as an annoying language, it does let you do some pretty trippy things. It also seems to perfectly suit some part of my soul which really really likes to strongly indent things. ;)
The assignment is just to implement Backgammon, basically. The trick was to implement an AI to drive the computer player. Although, stupidly enough, this wasn't actually a requirement of the assignment, and instead was given to the bonus section. Yeah, brilliant, an assignment in an Artificial Intelligence subject which doesn't actually require any AI.
I was quite fond of this at the time. As simple as it, it is somewhat amusing. You'll need DrScheme or some similar Scheme compiler/interpreter to run it. Enjoy. :)
Microprocessors and Assembly Language - MAL (51,975 bytes)
I really didn't like MAL. Aside from being all about how awesome the 8086 is (pfft), it was taken by Richard Hall, whom I just don't seem to get along with. The assignment was a real pain in the ass; some kind of really basic database implemented entirely in 8086 assembly. It was a pretty big disaster, as I recall. And even though my program worked well enough, I didn't get a very good mark for it.
I suppose it was useful, though, as it did enforce the notion that x86 assembly is horrible, and should be kept away from as much as possible. I've since done a little bit of x86 assembly, but only where it was needed (writing hand-tuned SSE2, for example), which isn't so bad.
Databases - DB (59,236 bytes)
This was another subject I just didn't do well in. I quite liked it; I like doing database stuff. ER diagrams aren't far off class or data models, and combined with PHP you can do some pretty cool stuff with them.
Alas, I was just too stubborn to really adopt the relational pattern... I was trying to force an object-orientated paradigm onto Oracle. It didn't like that. Neither did my lecturer. Can I help it that today's popular databases are using a 40-year old paradigm? Pfft.
There's not a whole lot of interest to look at here, except perhaps for my N-dimensional ER diagram. ;) I was particular proud of it. It did actually solve the problem perfectly well. It was just too relational, really... I was trying to eliminate redundancy, but relational databases require a lot of it to function.
Electronic Design Automation - Decimal Clock (312 KiB)
I really liked EDA. Really liked it. FPGAs are awesome. And so much easier to work with (i.e. not having to worry about code size nearly as much) as the CPLDs we were using at the same time in CDP.
This assignment was a simple decimal clock. That's it. Easy. Tony & I worked on this one together. It was written entirely in raw VHDL - we had FPGA Advantage available to us at the time, thus why we used Notepad.
So yeah, it works... not especially exciting, and I guess you'll need a spare FPGA or at least a software simulator to check it out. I can't remember what board we used... I think it was an Altera one. There's a photo of it on the front page of the report. Best of luck finding it. :D
Electronic Design Automation - Clock/Stopwatch/Timer (3.2 MiB)
This is the project that followed the assignment, above. It was done with Rob & Tony. It expanded the clock to a proper one, and added a stopwatch and timer to it. This was, in hindsight, quite a big conceptual jump for a lot of people. For those used to the comfy procedural nature of software, an FPGAs brute parallel nature can be quite scary. Many groups somehow managed to produce a product that couldn't work in more than one mode at a time. Ours, on the other hand, worked perfectly well concurrently. You could only view one mode at once, of course, but while you were looking and interacting with one, the other two were ticking along just fine.
We were all quite proud of this at the time. While other groups were having trouble just getting basic functionality to work, ours was being tuned and having extra little features added.
The design was also worth some credit... we adopted Rob's assignment as the basis (which is to say, Rob asserted we use it until Tony & I caved in :D ), and then each of us took responsibility for one of the three modes. It was all very block-box; Rob defined the interface our modules would get, and we implemented them with that. It would have worked splendidly, had Rob not implemented one interface and specified to us a completely different one... doh. But once we got wind of this and updated things, it worked well. :)
In hindsight though I think I would have booted Rob off doing the core and the interface... he has some strange ideas about internal signalling that seem to create headaches. Course, that's just this one man's opinion. ;)
As with the assignment, I guess you'll need either a suitable FPGA board, or a software simulator, to actually play with this. The report is included, of course, so you can at least get an idea of how it all works.
Introduction to Computer Graphics - SpaceInvaders (5.9 MiB)
I've always had a bit of a thing for anything relating to computer games... and not just playing them. ;) So I thought GRA, as a games subject, would be pretty cool. It kind of was... except that we really didn't do anything that great. We were supposed to use the lecturer's own little graphics library (IGL - so-called Ideal Graphics Library), which only provided support for 2D rendering, and was pretty mediocre. Since I wanted to do this on my Mac, not on a PC using Borland (ick), I rewrote IGL to use OpenGL. I thought that was pretty cool in and of itself.
Because I don't have the rights to distribute IGL, even the modified OpenGL version, I've had to include just the static library. Hopefully that's enough to get it compiling; I haven't actually tried. In any case, all my source is included, so you can poke at it. I wouldn't use this as the basis of your next big hit title, anyway; it's very primitive, and hopelessly slow. It does have particle effects, at least, which really don't look that great since they use OpenGL points instead of textures. Beginners mistake. Ah well. What a silly idea, thinking writing to a single pixel in the frame buffer would be faster than orientating each triangle to the view plane, pushing that geometry to the GPU, applying a texture and rasterising the result. Yes, what a silly idea.
Although now that I play with it again, I'm tempted to rewrite it properly, with decent graphics, pure OpenGL, and actual performance. But of course, that's just one of a thousand ideas on my todo list. :/
Multimedia Systems
I'd really love to put this up, but it's pretty huge, and it's going to take me a while to sort through it all... someday perhaps. Unfortunately you really can't appreciate it unless you can use it live, but that requires a host which gives me both PHP as well as MySQL or Postgres, which .Mac does not. :(
Computer Networks - Network Simulator (156 KiB)
I really liked this assignment. We had to simulate a pretty bloody basic network, nothing exciting at all - a single PTP link. 'course, that's not good enough for me... :D
My implementation isn't configurable at runtime, but that's not too difficult to add if anyone wants. Internally it's very flexible; I went for a nice object model which allows you to have all sorts of crazy network objects. I didn't implement all that many - just the ones necessary for the assignment, really - but it's trivial to add more.
I've recently been working on a similar thing that I'm calling, for the moment, 'Deadlock'... I've always wanted to put a decent GUI on this assignment... maybe I'll combine them one way or another. 'course, for something like this Objective-C is far more suitable than C++, which this assignment was written in. Ah well, so much for code reuse.
Operating Systems - Scheduler Simulator (49,027 bytes)
This was another assignment I really liked. We just had to write a simulator the scheduled processes using a variety of algorithms. If you were doing a real simulator you obviously wouldn't use real processes, since you have all sorts of timing issues and unnecessary complexity, but that aspect of the assignment was to introduce fork() and IPC. I was already familiar with them, but many people weren't... it seems a sad fact that the vast majority of people graduating in computer science these days don't know the basics of multi-threaded execution.
CS Project - Mission to the ISS
This was our major project for our CS degrees. It wasn't the full-year version, just half year, but it was still pretty crazy. It's the largest project I've worked on at university, including my thesis and engineering project. I can't recall what it finally weighed in as - something in the vicinity of 60,000 lines all up, from memory. A good 20,000 or so of those were mine. There were over 3,000 CVS commits (nearly a thousand of those mine). It was big.
Course, the result was pretty crap, largely because of the requirements that were set for us - i.e. that it use Borland, that it run on Windows, etc. Nasty. I fought tooth and nail to ensure the server remained purely POSIX, so it worked on all platforms (except Windows, which doesn't support POSIX). Ironically, when we mentioned to the clients during the presentation that we had partial Mac support, they were most interested; turns out they'd been looking at using Macs, not PCs, anyway. I've no idea what they went with in the end, or if the project even went ahead. Our groups was probably the best in terms of internal design, maintainability and extensibility, but really sucked when it came to actual functionality for the user. That's just a matter of work, of course; that sort of stuff was just left too late in the process and was rushed through.
Anyway, the project's now hosted on Sourceforge, BSD licensed. The server can be built using make, and just run. Duh. The client... I've no idea... it requires some arcane process with a hundred steps, pulling resources from a dozen locations. I was never able to build the client myself. This must be some new-wave management paradigm I've missed.
Computer Architecture - SimpleCacheSim (3.5 MiB)
Another assignment I really liked. This one's pretty straightforward - it simulates a single level cache. It's quite fast, uses the same input format as the dineroIV cache simulator (from which we referenced our results), and supports a wide range of features - including things like non-power-of-two sizes. It's feature set overlaps with dineroIV's; both have capacities that the other does not.
The archive includes a lot of nice charts and whatnot from the sample set we used. This sample set was created somewhat artificially - I believe it originally came from a real program trace, but was fudged to suit our purposes (such as masking all addresses down to 16 bits). It's only a small trace, though.
Distributed Systems - suma (38,883 bytes)
I can't recall exactly what this stands for... I think it's something like "Stupid Unoriginal Messaging Assignment". Which is probably a little harsh... but it is a trivial assignment. Just fork a few copies of the process, message between them using pipes, and write the collective output, atomically, to a single file. Pretty easy; only a few dozen lines of code. It was merely the precursor to the second assignment, checkpoint.
Distributed Systems - checkpoint (36,531 bytes)
The second DIS assignment, this one was quite a bit interesting. It extended the previous assignment to add checkpointing and rollback. This was done in a true distributed fashion (that's what the subject's about, duh). It wasn't too difficult to implement... I threw in two similar algorithms just for the heck of it. Surprisingly it pretty much worked properly the first time. Again, not a hugely complex assignment in terms of size, but with a reasonably intricate algorithm to think about.
I/O Devices and Interfaces - IDI (240 KiB)
This was yet another clock - are you sick of them yet, 'cause I know I am - this time implemented on a PIC (a 16F8X, in particular). It works. Yep. It's all good. Again, you'll probably need the same dev board we used (unless you want to fiddle with pin assignments, which are done in software, so have fun). It works. It was reasonably fun to program; PIC assembly is quite simple and sort of elegant, in a kind of twisted way. It's certainly much nicer than x86 assembly, that's for sure.
Thesis - Thesis (30.9 MiB)
Ah yes, the infamous thesis. I didn't much like doing this... the topic was actually quite interesting, but what you can write into a thesis isn't. Also, the hardware just didn't work out very well... I was perhaps a little slack, in terms of initiative to get the project going to start with, but the biggest failure was in a proper roadmap from my supervisor and the department in general. Not necessarily their fault... we just couldn't seem to find a common understanding.
Anyway, it might be of some vague interest as a casual skim-read, but I certainly wouldn't put it up there with other forms of entertainment, such as a ball and cup.
Also, the literature review (16 MiB) is available. In a ways probably more interesting than the thesis itself, since it contains some useful history of the industry and whatnot.
Real-time Fault-tolerant Systems - Chameleon Review (2.9 MiB)
This assignment was simply a review of a paper presenting a software fault tolerance system called Chameleon. Since it hasn't changed the world as we know it, and apparently hasn't really been heard of much since the original paper (in 1999), I'm guessing it wasn't all that flash. It's not a bad system per-se... just difficult to apply to real problems, as the sample usage scenario in the report - a *NAMP setup - demonstrates.
I recently completed it, having to pull an all-nighter (till 5am) to get it done in time. I'm not too thrilled about the finished quality as a result... there's a few things in it I'd change if I could be bothered; now that it's handed in, I'm not so inclined to toy with it. I wouldn't mind actually implementing the system for my own amusement at some point, as it is in line with my core areas of interest, but it's just another thing on my enormous todo list.