Across the vastness of the internet, there are many resources for aspiring programmers to learn to program. Nowadays you can find the answer to most common questions with a simple Google search. Before this explosion of post-modern data availability, information was disseminated in the form of the written word.

Recently, I came across an e-book written by Zed A. Shaw entitled Learn C The Hard Way, and while I can commend the author for spending the time and energy to write it, I would NOT recommend it to anyone seriously interested in learning the C programming language. In fact, if you were one of the unlucky souls who happened to have purchased it. Go right now and at least try to get your money back!

In the same vein of the author's own "critique" of The C Programming Language , I'm going to critique the author's own work, pointing out misinformation, and rebutting his points with code and excerpts from the C standard. Although, from what I've read the author has little stomach for criticism.

Everyone loves to preach about refactoring. How you should refactor, why you should refactor, when you should refactor, etc. But, does anyone actually measure the effect of refactoring on their code? Some people do, but I'm willing to bet that a larger portion of the crowd don't. They worry about their trivial asthetic concerns and leave the compiler to its own devices in the hopes that it will magically produce better code.

Consider the case of developing an embedded application. It's one area where refactoring can substantially benfit or harm the end goal: to keep the code small and fast. With this post, I'm going to write very simple program, and then refactor it, measuring the results along the way.

Now, keep in mind the fact that optimization by the compiler may produce varied results with different compiler versions and may perform differently across different architectures. YMMV, but you can't deny that sometimes the compiler needs a helping hand. :P

Here's a little experiment...

As a follow-up to my last post, I starting thinking about simple ways to interface with the Gameboy dev cart I now own. Of course, I could just use my arduino and a couple of 74595's, but nowadays that's a bit cliche. Not to mention, plenty of people have already done it. :P
I figured it would be much more interesting to build a Gameboy cart which can interface with other Gameboy cartridges (or any other hardware that you can drive at TTL or CMOS line levels.) Since a Gameboy cart has 29 I/O pins (if you count the bus control lines,) this new cart would have to add that many lines.

And so, my decent into madness begins...

I finally got around to getting my hands on one of these little bastards. Being the first official Nintendo development cartridge I've owned, it's not too shabby. Of course, being me, the first thing I did when it arrived in the mail was to take it apart, and go to work inspecting its innards. This thing is about as yellow as Pikachu on a Sunday morning, but let's take a look inside...