Summary: For ECE437: Computer Architecture, my partner Jeremy Tryba and I wrote two fully functional CPUs in VHDL -- multicycle and pipelined -- then tested them in hardware. These included memory-mapped I/O, full forwarding, early branch handling, a set-associative instruction cache, a direct-mapped data cache, and they fully implemented a MIPS-like ISA.

Why it's cool: In this class, we really got to see the flip side of programming -- instead of writing programs to run on processors, I got to write processors to run programs! These projects also gave me some great insights on how to write programs to take into account processor peculiarities. Many of the concepts are in fact terms you hear all the time when programming (for instance page faults), and now I know better what implications this could have on performance. I'm certain that having this class BEFORE making the GPU below would have drastically affected our design (for the better)! (A note on the sources: I've chosen to not distribute these since the solutions are viable answers for future classes.)

Summary: For this project, we designed and built a 3D Graphics Processing Unit. The unit supported w-buffering, hardware line rasterization, 3D projections, and matrix operations. It was actually tested on FPGA hardware using a simulated LCD controller/display written in C. We were awarded the ECE 495d AMD Wafer Award for Design Excellence. I should also note that this design is not pipelined (as you can plainly see in the block diagram). The team members were James Doty, Kyle McGhee, Allan Patterson, and myself.

Why it's cool: Everyone on this team was extremely dedicated, and the output was of amazingly high quality. The design document alone was about 70 pages without including source code! The final product worked excellently, rendering a cross pattern for testing 2D pixel plotting and a 3D cube to test everything else. This really gave me amazing insight into how real digital electronics work, and better yet it allowed me to take my low-level graphics experience (see below) to a new level!

Summary: This was the first major hardware project I embarked on, consisting of a Motorola HC12 processor controlling a bank of eight 7-segment LCDs to play a game of Memory. The user inputs his selection on a nearby computer which communicates with the processor through a serial port. This interface could easily have been connected to buttons instead. My team members were Andrew Keller and Kevin McCann.

Why it's cool: This could have very easily been a handheld unit. This was my first experience using a microcontroller not connected to a motherboard, and it was surprising to me how easy it was to use and debug! Experiencing other ISAs from the x86 was fun, but overall they were pretty similar and easy to pick up. This was a fun, straightforward, and fairly quick project.

Summary: A program I wrote for high school physics that computes the frequency spectrum the long way (Discrete Fourier Transform) from a given sound wave.

Why it's cool: Uses 100% Windows SDK, but it's a big pain to implement some elements like scroll bars. MFC's a better choice for something like this. This is a pretty cool science app too because it's one way for me to tune something like a guitar.

Summary: Short for "Parashooting Aliens", this game was the second produced by the CGCT, and it's a hellofa lot of fun. Seriously. Well, just resist the urge to shoot the motherships right off the bat, because then it isn't much fun at all. Hordes of aliens parashoot down to take over your prized pig ... try shooting only the alien, then only their parashoot. Oooh, and try the number keys 1-? for some awesome weapons and sound effects. And for some reason right-click stops the game, so don't click it!

Why it's cool: Again, it uses my XMedia programming library. But more than that, it uses a really cool system I devised for loading in batches of images at once. This game actually has a noticable delay due to loading in assets! Also, I'm using some data structures here -- linked lists to keep track of all of the aliens. Highly recommended game. It also has a menu system and all in the code but not the executable, so it's your task to get that running if you're up for a challenge.

Summary: This is quite possibly the largest library I've written to date. It encapsulates ALL of DirectX 6.0 (minus networking and most 3D stuff) into one easy-to-use library. I'll just let you discover everything else.

Why it's cool: Largest library to date, it works, used in an Intro to C++ class. The image to the left is a CGCT demo I made that demonstrates my panning and animation classes. One of my first big projects with C++, so unfortunately it doesn't use C++ quite as well as it could. XMedia was a terrible choice of name, however, simply because DirectX had a relatively new DirectMedia component, and it would be very easy to get my library confused with theirs.

Summary: Written for AP History, this is a trivia game where two players face off about their Civil War history knowledge. Uses the above XMedia library.

Why it's cool: To its credit, it might actually have about a hundred questions! This is a pretty good example of XMedia's capabilities too. The font is amazingly bitmapped, but I admittedly used another guy's routine for that because the project emphasis was more on getting the questions done.

Summary: I wasn't really interested in developing the OS anymore, so my plans for turning this into the video core of an OS were shot. So instead, I developed it all into a presentation system, similar to MS PowerPoint (minus the WYSIWYG). I developed two entire presentations for it, presenting these at school (one on viruses and the other on psychologist Jung), making the "slides" in Paint Shop Pro. It has neat transitions, animation effects, could run external programs, all in all I was pretty impressed. Oh yeah, and just to dispel my disgust for cancelling my OS project, I prefixed each presentation with a DanOS Loading... screen, when in actuality virtually no loading wait was required.

Why it's cool: I actually did something with the graphics library I wrote.

Summary: A complete programming graphics library that'll do everything you'd ever want, mostly in hand-optimized Intel 386 assembly according to the Video Electronics Standards Association (VESA) Video BIOS Extensions (VBE), which are incidentally still on modern BIOSes (you just can't access them due to WinXP). This implementation was somehow derived straight from the many VESA VBE manuals that VESA produced. Before video cards had enough memory to implement linear framebuffers, they used page buffers where you had to (inconveniently) switch between different video memory pages every 64000 bytes, which could rudely be in the middle of a scan line (note in VGA cards, for example, bit planes even existed which specified one plane per primary color!). We'll just say my library supports this "banked" option because the linear framebuffer implementation is "too easy". Also, interestingly enough, to get around the fact that processors now operated in "protected mode" to get at > 640k of RAM (and thus the BIOS interrupts couldn't be called like in real mode), I had to physically copy the ROM into memory, find the offset of the VESA VBE, then execute that code manually. Interesting way to do it.

Why it's cool: See the summary.

Summary: We used to joke that this game would run on anything, and indeed it does, even today! (Edit: Confirmed it does not run on 64-bit Windows 8!) Control a ship and make it through field after field of asteroids, visiting planets and upgrading your weapons. Pretty entertaining, if I do say so myself ;-)

Why it's cool: Wow, lots of reasons here. My longest program at the time of its writing, In C and graphics in 100% inline assembly. Manually loaded PCX files, had a global 8-bit palette, had the experience of managing a large production team, PC speaker sound effects, mouse assembly routines, high scores, developed my own custom data packing system to pack all assets into one data file. Note that the digits for the points received that float up are actually copied directly from ROM, and they are distorted on modern computers because they changed the character set stored in ROM so that my 1/2 pixel scaling routine doesn't work as well. Also, egad! Windows changed around their color palette system, so unfortunately the black color isn't the same as it used to be, leaving an ugly white mask around every "transparent" object. (So yeah, you got me. I "cheated" ... but I only did it because the assembly code was much easier if I just directly drew the black colors rather than skipping transparent pixels.)

Summary: This is a really short program, but it has an amazing effect -- it generates SIRDS (Single Image Random Dot Stereograms) from 4-bit color images, using the palette for different depths. Further, I extended the algorithm so that instead of generating random dots, you can input another image to have the background be a set of repeating cars for instance.

Why it's cool: Well, it generates Magic Eye® images! Not only that, it compiles under DJGPP and uses the Allegro graphics library (now THAT brings back memories!). The algorithm was from the text PC Graphics Unleashed, and it is surprisingly simple. Maybe I'll explain it here sometime. In the meantime, just check out the source.

Summary: A game set in the old world of knights and wizards, it's a dual to the death as two mages wield their magical powers against each other to win fame and fortune.

Why it's cool: Mode 13h 320x200x8 (palletized color), bitmap loading and animation routines, assembly routines linked to the object file for mouse input and Sound Blaster® sound effects, two players.