Category Archives: random

general stuff not having to do with anything specific

CREATING a GameBoy game with PHP

by terry | Leave a comment

Previously on, I’ve been decompiling the DuckTale GameBoy ROM using only PHP. That got me curious if one could MAKE a GameBoy ROM with PHP.

Assembly

My first stop was to better understand how the games were originally created, which led me to the RGBDS site with tons of info about GB game creation. It was actually one of the sites I used to find out what headers the Nintendo ROMS used, and how to access them. But for actually making games, it has everything. My main focus was looking at the Assembly code, and seeing how I could re-construct that from PHP.

Helpfully, there are a lot of boilerplate examples out there, so I pulled in some and created a very basic “main.asm” file. It handles all the setup, game loop, and arrow key presses. Then I did another very basic “game.asm” file.

You have to manually set values to specific memory addresses, like for the player’s x and y locations:

DEF player_x EQU $C000
DEF player_y EQU $C001

On the GameBoy, those are the start of the “Work RAM” locations. There are ~8k of those, if you wanted to store 8,000 integers between 0 and 254. It gets more complicated when you want to store larger numbers or other objects. I’m keeping it simple for now.

Then we set the initial state of the game…

    ld a, 76           
    ld [player_x], a
    ld a, 68            
    ld [player_y], a
    ld b, 76
    ld c, 68

This gets interesting, because “a” is the specific memory register any calculations are done. So here, we put (load) the number 76 into “a”… then load the value of “a” into the player_x memory location ($C000). Then do the same thing with the Y location, and then finally put them into the “b” and “c” registers. Honestly, I’m not exactly sure what the “b” and “c” are for at this point… but they’re used in the main.asm file. Looking at GameBoy code, it’s so much “load {value} into ‘a’, then load ‘a’ into {memory}”

Next is the game loop. 

GameLoop:
    call WaitVblank
    call UpdateInputs

    ; -- Right --
    call KeyRight
    jr z, .noRight
    ld a, [player_x]
    cp 152              
    jr nc, .noRight
    inc a
    ld [player_x], a

WaitVblank keeps the system and screen synced up, and UpdateInputs is checking if any buttons are pressed. For this first pass, we’re only checking for up/down/left/right, but this also handles start/select/a/b/bumpers. For checking if the “right” arrow is pressed, it calls KeyRight and then checks if the z bit is set. If it IS, that means the button was NOT pressed, so you jump the .noRight symbol.

The next couple of lines are boundary checks, which I didn’t include in the PHP compiler. But from what I understand cp 152 is comparing ‘a’ with 152 (the right side of the screen). If ‘a’ is less than 152, it sets a “carry” flag, which means it’s fine to keep moving. The jr nc, .noRight line is “there is NOT a carry flag, so stop moving and go to the .noRight section”. Next increments ‘a’ and then updates the player’s X value with ‘a’. So the whole thing is checking “is right pressed? is left pressed? is up pressed? is down pressed?”, in order, every 1/60th of a second.

Then the one sprite:

SpriteTileData:
    db $18, $18         ; ...XX...  binary for 0001 1000
    db $3C, $3C         ; ..XXXX..  binary for 0011 1100, etc
    db $7E, $7E         ; .XXXXXX.
    db $FF, $FF         ; XXXXXXXX
    db $FF, $FF         ; XXXXXXXX
    db $7E, $7E         ; .XXXXXX.
    db $3C, $3C         ; ..XXXX..
    db $18, $18         ; ...XX...
SpriteTileDataEnd:

I know the sprites are set as 2 bits, a high and low bit. For this, it’s the same value for both to keep it simple. The main.asm files loads all these in the correct place so they display on screen.

At this point, I was able to run the needed commands, and got a .gb file that ran.

The PHP game file

My next step was to see how I wanted the PHP game file to look. I stubbed out a super basic idea. Setup fairly similar to how the assembly file is organized.

wait_vblank();
update_inputs();

Then I have function calls, that I plan on PascalCasing when calling the “main.asm” files. Other than that, not a whole lot going on. To compile it, I decided to just read each line of the file, do some preg_match … and build up an assembly file.

The PHP compiler

So this is currently a bit of a mess (but it works on my machine).

I changed a couple of things, like instead of defining variables with memory locations, I’m just using the locations directly. And I’m not doing boundary checks. And I renamed the “noRight/Left/etc” symbols to be a bit more flexible later on.

And when I ran my game code through it, it worked!

I even made a build script to do the whole process.

I have ideas for next steps. Like splitting up the compiler code to be more object-oriented, and less spaghetti. And hopefully will be easier to add new functionality. Part of the process is getting more indepth on the actual assembly code side of things… which I’m not sure I have much time to do. We’ll see.

Decompiling DuckTales for Game Boy… with PHP

by terry | Leave a comment

I’ve been pulling apart the DuckTales Game Boy ROM byte by byte using PHP. Just PHP with file_get_contents() and a bunch of bitwise operators. Just out of pure curiosity, and whether it was possible. It’s been… interesting, so I figured I’d log what I’m doing.

It began when I got more into making games, and made a very simple platformer that ended being 50MB in size… but I remember playing DuckTales on GameBoy, and I know those cartridges couldn’t hold that size.

Loading a ROM

A Game Boy ROM is a flat binary file. No compression wrapper, no file system, nothing fancy. It’s just raw bytes . Loading it into PHP is simple:

$this->data = file_get_contents('ducktales.gb');
$this->size = strlen($this->data);  // 65,536 bytes

With DuckTales, it’s a full featured platformer, and all in a 64k file. With file_get_contents the whole game is a string in memory. Every byte accessible by index. Want byte number 500? ord($this->data[500]). PHP strings are byte arrays under the hood, which helps makes all this possible.

The Header

Every Game Boy cartridge has a header at fixed memory addresses. Nintendo standardized this so the boot ROM could validate cartridges. We just read the right offsets:

// Game title lives at bytes 0x134 through 0x143
$title = substr($this->data, 0x134, 16);
$title = rtrim($title, "\x00");  // strip null padding
// Returns: "DUCKTALES"

// Cartridge type at 0x147
$cartType = ord($this->data[0x147]);
// 0x01 = MBC1 (Memory Bank Controller 1)

// ROM size at 0x148
$sizeCode = ord($this->data[0x148]);
$actualSize = pow(2, 15 + $sizeCode);  // 32KB * 2^n

No magic here. The Game Boy hardware expected the title at 0x134. Most of these locations are documented by many other people, in other languages, but I didn’t write down all the url… so just google ’em if you want.

Finding Text in the ROM

Some text in ROMs is just plain ASCII. You can find it by scanning for runs of printable characters:

for ($i = 0; $i < $this->size; $i++) {
    $byte = ord($this->data[$i]);

    if ($byte >= 32 && $byte <= 126) {
        $current .= chr($byte);
    } else {
        if (strlen($current) >= 4) {
            echo "Found text at $i: $current\n";
        }
        $current = '';
    }
}

This catches copyright strings, debug text, anything stored as standard ASCII.

Most Game Boy games don’t use ASCII for their actual ingame text though. They use a custom encoding where each byte maps to a tile in the font. DuckTales maps it like this:

  • 0x01 through 0x1A = A through Z
  • 0x1B through 0x34 = a through z
  • 0x80 through 0x89 = 0 through 9
  • 0xFF = line break

So the letter “A” isn’t 0x41 (ASCII), it’s 0x01. tile #1 in their font tileset is the letter A. Once you figure out the mapping, decoding is just a big if/elseif:

if ($byte >= 0x01 && $byte <= 0x1A) {
    $result .= chr(ord('A') + $byte - 1);
} elseif ($byte >= 0x1B && $byte <= 0x34) {
    $result .= chr(ord('a') + $byte - 0x1B);
} elseif ($byte >= 0x80 && $byte <= 0x89) {
    $result .= chr(ord('0') + $byte - 0x80);
}

it works.

The Graphics

Game Boy tiles are 8×8 pixels with 4 shades of green (well, gray on the actual hardware… the green was just the screen). Each pixel needs 2 bits to store its shade (0-3), packed in a format called 2bpp (2 bits per pixel).

Here’s how one row of 8 pixels is stored in 2 bytes:

Byte 1 (low bits):  01011010
Byte 2 (high bits): 00110110
                     ^^^^^^^^
                     Pixel: 01001310  (combine bit from each byte)

For each pixel, grab one bit from byte 1 and one from byte 2, combine them, and you get a value 0-3. In PHP:

for ($row = 0; $row < 8; $row++) {
    $byte1 = ord($this->data[$address + ($row * 2)]);      // low bits
    $byte2 = ord($this->data[$address + ($row * 2) + 1]);  // high bits

    for ($bit = 7; $bit >= 0; $bit--) {
        $pixel = (($byte1 >> $bit) & 1) | ((($byte2 >> $bit) & 1) << 1);
        // $pixel is now 0, 1, 2, or 3
    }
}

Each tile is 16 bytes (8 rows × 2 bytes per row). So every 16-byte chunk in the graphics region is potentially a tile.

ASCII Art in the Terminal

Before even bothering with images, you can preview tiles right in the terminal:

$shades = [' ', '░', '▒', '█'];
echo $shades[$pixel];

That one line turns pixel values into a quick visual.

Actual PNG Output

Once you know the pixel values, GD handles the rest:

$image = imagecreate(64, 64);

// Classic Game Boy green palette
$colors = [
    imagecolorallocate($image, 155, 188, 15),  // lightest
    imagecolorallocate($image, 139, 172, 15),
    imagecolorallocate($image, 48, 98, 48),
    imagecolorallocate($image, 15, 56, 15),    // darkest
];

imagefilledrectangle($image, $x, $y, $x + $scale - 1, $y + $scale - 1, $colors[$pixel]);

imagepng($image, 'tile.png');

Actual Game Boy sprites rendered as PNGs from raw ROM data. Using PHP’s GD library.

Assembling Multi-Tile Sprites

Individual tiles are only 8×8 pixels. Scrooge McDuck is bigger than that. Characters are usually made up of 4 tiles (2×2 = 16×16 pixels) or 6 tiles (2×3 = 16×24 pixels).

The tricky part is figuring out HOW the tiles are arranged in memory. Left-to-right? Top-to-bottom? Interleaved? Some weird order specific to Capcom? We don’t know, so… trial and error:

$patterns = [
    'sequential'  => [0, 16, 32, 48],
    'interleaved' => [0, 32, 16, 48],
    'column_pairs' => [0, 16, 256, 272],
    'reverse'     => [48, 32, 16, 0],
];

Each array is 4 byte offsets from a base address, placed into a 2×2 grid. Generate a PNG for each pattern, look at the results, and one of them will look like an actual character. It’s not elegant, but it gets the job done. For example, below is one of the extracted spritesheets… and you can sort of seen Scrooge elements in the center:

Here’s a screenshot from the actual game, and while some coloring is different, you can see elements…

Decompressing Hidden Graphics

Not all graphics are stored raw. Capcom used LZSS compression to fit more data into the ROM. It’s a fairly simple scheme with two operations: literal runs (“copy the next N bytes as-is”) and back-references (“copy N bytes from earlier output, starting M bytes back”).

The token format is one byte:

  • Bit 7 clear → literal run (lower 7 bits = count)
  • Bit 7 set → back-reference (lower 7 bits = length, next byte = offset)
  • 0x00 → end of data
while ($pos < $this->size) {
    $token = ord($this->data[$pos++]);

    if ($token === 0x00) break;

    if (($token & 0x80) === 0) {
        // Literal: copy next N bytes directly
        $count = $token & 0x7F;
        for ($i = 0; $i < $count; $i++) {
            $output .= chr(ord($this->data[$pos++]));
        }
    } else {
        // Back-reference: repeat from earlier output
        $length = $token & 0x7F;
        $offset = ord($this->data[$pos++]);
        $srcPos = strlen($output) - (256 - $offset);

        for ($i = 0; $i < $length; $i++) {
            $output .= $output[$srcPos + $i];
        }
    }
}

The interesting part is finding compressed blocks. We scan the entire ROM, try to decompress at every offset, and check if the result looks legit (decompressed size is bigger than compressed, output is a multiple of 16 bytes so it contains complete tiles). It’s bruteforce, but it turns up graphics you’d never find otherwise.

Finding Level Maps

Level layouts are stored as tile maps… grids of numbers where each number says “put tile #X here.” The game’s rendering engine reads these grids and draws the level by looking up each tile.

We scan for regions that look like tile map data using a pretty basic heuristic: if a block of bytes mostly contains values between 0x00 and 0x7F (valid tile indices), it’s probably a tile map.

for ($i = 0; $i < 32; $i++) {
    $byte = ord($this->data[$addr + $i]);
    if ($byte > 0x00 && $byte < 0x80) $score++;
    if ($byte == 0x00) $score += 0.5;
}
if ($score > 20) {
    // Probably a tile map
}

Once you have a map address and know where the tileset is, you can render an entire level preview by looking up each tile index and drawing it:

$tileId = ord($this->data[$mapAddr + ($y * $width + $x)]);
$tileAddr = $tilesetAddr + ($tileId * 16);  // 16 bytes per tile
// Decode and draw that tile at position (x, y) in the output image

Right now this handles all the data in the ROM: graphics, text, maps, compressed blocks. I think the next step is a full CPU disassembler for the Sharp SM83 (the Game Boy’s processor). So turning every byte in the code regions into readable assembly instructions, which I’m not sure if even possible?

Anyway… there’s literally no reason to do this, and I have no idea what I’m trying to accomplish.

How THIS long-time dev uses AI

by terry | Leave a comment

There’s a lot of talk about “vibe coding”, the idea of just throwing prompts at an AI and hoping it spits out something useful. A fairly new term coined by Andrej Karpathy. But “forgetting that the code even exists” might work for a weekend hack project, but it’s not what seasoned developers are doing as far as I can tell.

Experienced coders aren’t handing over the reins. They’re still designing systems, checking code. And treating AI as a helper. A recent article in The Register noted that many senior devs now rely on AI for more than half their work. I’d sat that isn’t “vibes”. That’s experience. Or as Simon Willison says, it’s “using an LLM as a typing assistant”.

Prompts with a Plan

The real difference is in the way they prompt. A non-developer might prompt, “Build me a CRM for patio furniture business”, and leave everything else up to the AI. A veteran knows enough to write out the full plan: stack, database, models, security, tests, APIs, integrations, whatever. The AI is just filling in the details.

That’s where experience shows. Knowing what to ask for, recognizing when the AI stumbles, and steering it toward code that will actually hold up.

Faster in a Different Way

Studies show senior developers get more value out of AI even though they spend extra time fixing what it produces. That’s because they’re looking at the whole project, not just one function. What used to take weeks of boilerplate work can now be sketched out in hours. Then they can focus on design, security, and scale.

AI handles the repetitive stuff: models, services, tests. The human brain is free to solve the harder questions. Where do we draw system boundaries? How do we keep data safe? Can it handle real traffic?

Always Double-Checking

Of course, AI still makes mistakes. It doesn’t understand projects the way humans do. It might try to fix a bug by piling on extra code instead of solving the root problem. In one instance, Claude Code was trying to fix some failing tests and ended up creating various debug files and “test” code in the service class. I stopped the agent, and realized that the parent class of the test wasn’t setting a mock object correctly. A simple one-line fix, but Claude didn’t find it. Experienced developers are able to understand when the agent goes off the rails, and know where to look.

My Process with Claude Code

The PLANNING.md “Trick”

One of the easiest ways to keep Claude on track is to give your project a “second brain.” Start with a PLANNING.md file in the repo, and have Claude break down the project. This doc becomes the single source of truth for the project – goals, architecture, and next steps.

Here’s how it works:

  • Plan first: Outline the stack, features, database, APIs, and deployment.
  • Break it down: Claude splits the plan into small tasks, like setting up auth or writing migration scripts.
  • Stay focused: For each task, start a fresh session with Claude and only prompt it the relevant slice of the plan.
  • Update as you go: When a task is done, have Claude mark it complete and add notes back into PLANNING.md.

This loop keeps both you and the AI synced, so the project grows in an organized way. And also gives you specific points where you can stop and debug.

Plan Mode as a Sanity Check

Another great move is to force Claude to “think before coding”. You can start in “Plan mode” and ask it to outline what it wants to do before writing any code. Approve the plan, or re-prompt if something seems off, then let it generate.

Catching mistakes in plain English is way cheaper than debugging 200 lines of nonsense later. Juniors might miss issues here, but experienced devs can spot when the Claude’s plan doesn’t fit the bigger picture.

Not Vibing, Conducting

So no, senior devs aren’t “vibe coding”. They’re conducting. The AI is the orchestra. It’s powerful and fast, but ultimately… directionless. The developer is the conductor, setting the score and keeping the rhythm.

That’s where coding is heading. Human vision plus machine speed. Less typing every line, more designing systems and guiding AI to build them right.

3 Years Between Posts – Game Development

by terry | Leave a comment

It’s been a while. My latest non-work obsession is trying out various game ideas. I’ve always had an interest, and a few ideas, but getting proficient with a game engine like Unity or Unreal seemed a daunting task.

I did start a few years ago with Videordle, a Wordle ripoff where you try and guess the “video of the day” with a super zoomed-in clip. Each wrong guess zooms the clip out a bit. One of the goals was to have it all self-contained, and only vanilla javascript. So you could technically download it and run it all locally.

Last year, I had the idea for an Android “word game”, and I created Word Stars using React Native. I utilized my Laravel skills to create an API auth and backend for the game. That went very well, so I kept going with React Native and ported Videordle to an Android app/game, also using an API to deliver the data. I haven’t touched them since release… but also, no one is playing them. Also, also, I’m horrible at marketing, so I doubt anyone knows they exist.

I also got interested in bigger games, so I started learning more about Godot, a free game engine I’ve toyed with, on and off, for a few years. That led to My First Game. After that, I started working on another platformer type game in Godot… one that I would eventually like to release on Steam at some point. That’s going to take longer, because it’s bigger in scope, and I don’t have a lot of dedicated time.

In the meantime, I want to actually “complete” something, so I’ve entered a few itch.io game jams. The first one I did was an RPG Maker game named Anxiety. I bit off more than I could, with an ambitious idea and a game engine I never used before… so it’s only about 1/3 of what I envisioned. But it’s submitted. So that’s a win.

I have a few more of just me playing around with things, and experimenting with quick ideas. The next jam I’m signed up for is Bullet Hell Jam 6, which could be fun. I’ve been playing around with the logic in Godot, so once it starts, I can hit the ground running. The next jam after that is for GDevelop, another engine I only just downloaded last week. I’m tempted to use THAT for the Bullet Hell jam, so I can learn. We’ll see.

The most recent thing I’ve completed, and fairly happy with, is Idle Hands. It’s an “idle clicker” game where the goal is to collect demons and traverse the circles of Hell. Visually, I’m happy with it… up next, I need to add some music and sound effects. This is also a game that’s vanilla javascript. It’s literally just index.html, index.js, and styles.css … plus assets. I added a package.json just for minification, and I think I’m going to release it on mobile using Capacitor.

The future: I remember having a Palm Pilot in the early 2000s, and there was a game called “drug wars” or something, where you bought goods in one place and sold them in another to try and make money… and random events would happen that could either help or hurt your profits. It was fun. I have the idea of doing a similar concept, but for music – like you’re trying to put a band together and you have to change it up as musical tastes change, so you buy and sell things like a “fiddle player” when country music becomes popular or something. I still have to work it out.

Updating a 10 year old Laravel post

by terry | Leave a comment

In November of 2012, I had a short blog post about using Laravel (at the time v3) with the Redactor javascript code for wysiwyg textareas. It’s not bad, but could use an update.

First, I see “classic” Redactor is deprecated in favor of Redactor X, and they want you to pay for it. Since I don’t plan on actually using, I’m going to assume the docs work as expected. Second, Laravel is now on version 9, which is a long way from version 3. Though interestingly, the syntax is not that wildly different.

Begin by updating initial route, now located in “/routes/web.php”. Instead of the View facade, we can do this:

Route::get('redactor', function() {
    return view('redactor');
});

Easy! We could’ve left it as is, since View::make() still works (!!!) but this is a bit nicer.

Next, we can update the HTML for that view. In the original, it was using a non-Blade view which is a bit silly in 2022. Also, the Form facade was removed from Laravel in version 5, so you either use plain-old HTML form tags, or the HTML package from Laravel Collective, which is what I did.

<!DOCTYPE html>
<html>
   <head>     
         <title>Laravel 9 and Redactor</title>
         <meta charset="utf-8">
         <link rel="stylesheet" href="css/redactorx.min.css" />
   </head>
   <body>
         {!! Form::open() !!}
         {!! Form::label('mytext', 'My Text') }
         <br>
         {!! Form::textarea('mytext', '', ['id' => 'mytext']) !!}
         <br>
         {!! Form::submit('Send it!') !!}
         {!! Form::close() !!}
         <script src="js/redactorx.min.js"></script>
         <script type="text/javascript">
                RedactorX('#mytext', {
                    image: {
                        upload: '/redactorupload/'
                    }
                });
         </script>
   </body>
</html>

No more jQuery and fancy Blade code!

Then we update the route that will accept the upload, and again, it’s still pretty close to the original:

Route::post('redactorupload', function(Request $request) {
    $validation = Validator::make($request->all(), [
        'file' => 'image|max:10000'
    ]);

    if ($validation->fails()) {
        return false;
    }

    $filePath = $request->file('file')->store('public/images');
    if (empty($filePath)) {
        return false;
    }

    return response()->json(['filelink' => Storage::url($path)]);
});

The biggest difference is the Input facade was removed in favor of using the Request object in the closure. I also removed an unneeded else statement.

The final bit of code was simply echoing out the form input if you submitted it. Instead of doing a dd() (which still works), we can update it like so:

Route::post('redactor', function(Request $request) {
    return $request->all();
});

That’s it. Now we have updated some 10 year old code!

Laracon: Saturday. 1st Laravel Conference in (others’) Pictures.

by terry | Leave a comment

Morning in Washington DC

 

 

 

Aaron Kuzemchak : Simple API Development

Demo

 

 

 

 

Dayle Rees : Laravel: An Unexpected Journey

 

 

 

 

Zack Kitzmiller : Procrastinating Code

 

 

 

 

Jonathan Barronville : Vagrant, Puppet, Laravel & You

 

 

 

 

Eric Barnes : The Care and Feeding of a Robot

 

 

 

 

Shawn McCool : Running a Small Business on Laravel

 

 

 

 

Taylor Otwell : Eloquence Evolving

 

http://instagram.com/p/WF1YHVNzR2

Links to Unemployment signup page for each state

by terry | Leave a comment

At SXSW, I spent a couple of the days at the sessions dealing with government topics.  One of the things that was brought up quite a bit was that State websites are almost universally horrible.  They’re poorly designed and finding information easily is near impossible.  Utah is one exception to this rule, but really, it’s just about the ONLY exception.

I decided to try and find the Unemployment signup pages for a couple of states, just to see how easy or difficult it was.  It was NOT easy.  I remember a couple of years ago, when I was laid off, getting to the Texas unemployment online signup was full of twists and turns, and pages of descriptions and explanation. I just wanted to go to the signup page.  So I decided to create a simple page with links to the unemployment signup pages for each state… hopefully skipping all the explanations and description pages.

As I was searching for each state, I was surprised at how outdated the sites were. So many required Internet Explorer, and a couple prevented me from even accessing the pages using Chrome.  And Pennsylvania… Netscape Navigator? Really? Well, it IS using classic ASP… so I guess it is to be expected.

I think I may do this for other commonly needed pages, too.  In one of the sessions, someone mentioned how difficult it was to find info about building permits… but since that gets into county and city pages, it may be beyond the scope of this project. I just need to figure out what pages are most commonly needed.

Terry’s Happy Place songs

by terry | Leave a comment

There are songs that just seem to always make you feel better when you hear them.  I’ve kept my own list in my head, and now I want to collect them into one post.  The list is fluid, but most of these have been set for years.  In no particular order, songs that put a smile on my face:

1) Morningwood – Nth Degree

2) Frankie Valli – December, 1963 (Oh, What a Night)

3) Glass Tiger – Don’t Forget Me When I’m Gone

4) Dolly Parton – Here You Come Again

5) Duran Duran – Hold Back The Rain

6) Duran Duran – The Reflex (yes, 2 Duran Duran songs)

7) The Beatles – Good Morning Good Morning (pretty much any Beatles, though)

8) Public Image Ltd – Disappointed

9) Radiohead – Bones

Fun puzzle – Christmas Conundrum

by terry | Leave a comment

Saw this puzzle on Chris Shiflett’s blog and was able to figure it out. Don’t read further if you want to try yourself…

 

 

 

 

First, I wrote down the numbers, and immediately noticed the first numbers “1024” and “512” were suspiciously binary… though, that seems somewhat coincidental now. However, I plotted all the numbers into a spreadsheet, then did a conversion to binary.  I began thinking that maybe the 1s and 0s were like the beat of a Christmas song, so I tapped them out, and it didn’t seem to be anything.  Though bits seemed to be like “Jingle Bells” or “God Rest Ye Merry Gentlemen”, they never played out for the entire song. I got a bit sidetracked, thinking this was a designer, that maybe the numbers should be converted to HEX values, and use those colors for something.  Again, it didn’t pan out.  Here’s where I was at that point:

Then, as I looked at the column of binary numbers, I noticed there was a pattern… not in the numbers, but in the shape of the groups of numbers. I converted the column to monospace type and started connecting the 1s. It really didn’t make sense at first… but I saw the last group of numbers made a Greek Sigma “Σ” and an “X”. So I thought “Sigma Chi”, a fraternity.  The numbers above it made a “W” and a Sigma, and I thought maybe the “W” was supposed to be a Psi, but I couldn’t find anything relevant for “Psi Sigma”. At that point, I hadn’t connected all the 1s correctly, so I went back and connected all the 1s, even diagonally. The patterns became a lot clearer… but it still didn’t make sense.  At that point, I had my table turned just a bit to the side, and noticed the Sigma could actually be a sideways “M” and the “W” a sideways “E”… so I had “E M M X”.  With that, I saw I already had the “A” and a “Y”. Once I made one more missed connection of 1s, I had the two “R”s and figured the extra bit in the first group was an “!”.  From there, it was a simple matter of re-ordering the letters to make: MERRY XMAS!

Thanks to Chris Shiflett for the fun diversion. Though, it looks like I missed submitting the correct answer by only a few minutes (congrats Cogocogo) … it was still an enjoyable brain exercise.