I seem to have a thing for plotting things.

Plot also available in SVG format. Both should be updated vaguely daily.

Jasna and I don’t have cable or an antenna for our TV, which means we download everything we watch, or borrow it from friends on rare occasions. My MacBook was starting to run near the end of its useful life as my main work computer—the trackpad was becoming unusable which meant I couldn’t depend on it when travelling—but it’s still got some life in it as a server. It was wireless networking (no cables to string around), uses very little power, is completely silent, comes with media software (Front Row) and comes with a remote control, is really small (less than 2cm tall), which makes it more or less the perfect media server.

The only downside is it was a pain to get shows onto it to watch, as you have to search for the shows manually, download them, then copy them manually over to the server. So, I decided to make a web interface.

Check here for screenshots of the new web interface for the media server. EasyNews, our Usenet provider, provides very handy services like global searches, thumbnails and AutoUnRARing. A big benefit to this is not having to wait until something has finished downloading it before watching it. So far I’ve got services for downloading from Usenet—which is where we get almost all of our TV shows to watch, downloading CFL games from TSN and just uploading individual files from your browser. At some point I need to set up scheduling so that it automatically downloads new episodes of shows when they’re released, but I guess that’s for another weekend.

I’m kind of embarrassed at how proud I am to have actually finished it in a weekend like I’d planned, especially considering I haven’t done any web development in years and years. The astute of you may have noticed I used straight-up CGI instead of technologies the cool kids are using: no love from me for PHP or RoR or Ajax or anything. Since I haven’t put any password security in yet—that’s for another weekend yet—and the box is publicly addressable via IPv6 I’ve had access to the web interface to just within our local network, but if IPv6 takes off some day it’ll be cool to be able to download movies while I’m away from home.

I’ve all but given up on trying to give the computer an extra useful player in shootout mode. Giving the computer an extra player who stands and does nothing is trivial. Unfortunately, the “AI” for shootout mode is—maybe not surprisingly—hard-coded—it doesn’t even take into consideration the position of the goalie—and rewriting the AI in 65C816 assembly is beyond the scope of my free time. This is easy to show by watching the differing behaviour between when the computer gets a breakaway (in regular mode) compared to how it behaves in shootout mode.

So I play in regular mode with a 3-man handicap. E.g., we play 5-on-2. If you watched the first video from my last post, you’ll notice that handicapping yourself makes the game beep constantly. It’s very very irritating. Fixing this is actually not completely trivial. For those that are impatient, here are the memory addresses I’m using:

Address	Description	Example value
7E17A6	Number of players for the home team	3
7E18BA	Good question! See below	12
7E1864	Number of seconds left in the penalty	40

Using the values above will stop the incessant beeping.

I haven’t had time to fully explore the implications of 7E18BA. Just from observation, it seems that that the 7E1860–7E18C0 range is an array of player state and 7E18BA is an offset into that array which pertains to the penalty. By setting 7E18BA to 0x12, it seems, you indicate which element of the array from which to draw penalty-time-remaining information. I only use the value of 0x12 and the associated address 7E1864 because those are what came up for me during debugging (Mike Gartner, if you’re curious). I haven’t found any rhyme or reason to the number 0x12 yet, but I don’t really care too much at this point.

As a side note, someone really needs to come up with a better tool for “RAM cheating”. For those unfamiliar, the general procedure for this style of black-box debugging—usually used for cheating, though in my case I guess it’s anti-cheating—is to snapshot RAM at various stages of play. You then compare the RAM images according to what state you’re looking for. E.g., if you want to know where the numbers of players on the ice is stored in RAM, you snapshot when you have 6 players on the ice a few times and again when you have 5 players on the ice and look for the numbers “6” and “5” to consistently appear in RAM.

If you have a hacker mentality, this way of doing things can be productive, but it’s pretty crude. Generally the tools available don’t allow you to compare bit-values, only byte-values, and comparison operators are pretty limited. After half-heartedly trying to follow along with Jasna’s AI assignments, I’d be surprised if this problem hasn’t been solved generally and properly in the AI academic community. Oh well.

The methodology is quite simple. Once I’ve got all my groceries, I go to the same spot near the checkouts. To avoid biasing myself, I check my cell phone to determine whether to go through the self checkouts or the normal checkouts. Because my cell phone lacks a random number generator, I check the last digit of the time: an even digit means I go through the normal checkout and an odd digit means I go through self checkout. I then start the stopwatch and time how long it takes for me to go through the checkout and leave the store.

I’ve got 31 data points and have finally decided that if one type of checkout is faster than the other, the difference is small enough to not really matter. Here’s the scatterplot:

A sample size of 31 is unimpressive, to be sure, but it’s large enough that I can finally rest easy knowing it would be a waste of time to collect more data. Trying to get out of the grocery store in the fastest way possible seems to have more important factors, such as the number of jerks ahead of you in line.

As a side note on how that scatterplot is presented, it probably would have made a lot more sense to measure the time taken as a function of how many items I bought, rather than the cash value of the items I bought. I’m far too lazy to count things, though.

So, from now on I’ll be deciding on self checkout versus normal checkout based on how social I’m feeling. I suspect that means I’ll be using the self checkout a lot.

There’s one serious problem with NHL ’94, however: the AI is absolutely terrible. Playing in single-player mode is way too easy. Playing as the worst team (either Florida Panthers or Ottawa Senators) against the best team (All Stars East) I can win 5–0 without much effort.

In shootout mode the AI is even worse. If you put the goalie on automatic mode (the computer controls your goalie) then the opposing team does alright, but it’s no fun. If you put the goalie on manual mode (you control your goalie) I’m not convinced it’s actually physically possible for the computer to score on you.

I had the brilliant idea that maybe the game would be more fun if the human player were handicapped. Maybe shootout mode would be more fun if the computer had 2 players instead of just 1? I have my doubts, but it got me thinking.

So one idea was to disassemble NHL ’94, add in some 2-on-1 shootout code and reassemble it. Fortunately there are people out there who take hacking the Super Nintendo more seriously than any sane person should, so there are some tools available. Learning 65C816 assembly code, disassembling the game and then tracing through and debugging sounded like the sort of thing that one does after they’ve finished writing their thesis, so I filed that under “plan B”.

Plan A became to track down where certain delicious global variables, such as the number of players on the ice, were being stored in memory and modify them as the game was being played. After about 20 minutes of toying around, I got something to work.

Here’s me in regular hockey mode, but with only 1 skater instead of 5:

The constant beeping (sorry) is due to NHL ’94 foolishly thinking that since I’m down 4 men, the other team is on a power play which is ending soon, in 0 seconds to be exact. Note the game mistakenly gives credit for the goal to Zhitnik and Hrudey of the LA Kings instead of Schneider and Roy of the Montreal Canadiens. Weird.

Here’s me in shootout mode:

Unfortunately I accidentally gave myself an extra player instead of the computer, but it still demonstrates that my idea won’t work without a lot more fiddling. The extra player just stands there doing nothing. Sigh.

The good news is my duct taping and super gluing worked. The camera didn’t move an iota—though sadly I had to tilt it a bit to the left to get it seated properly—and the servo controller stayed where it was supposed to.

Before I get into the downsides maybe I’ll just show the video.

So the first downside is that the video ends about five minutes earlier than it should have. When I rolled the car it rolled onto the shutter button, unbeknownst to me. It’s too bad since the crazier/more abusive stuff came after that.

The second downside is that both the camera and car took more abuse than they have before. The metal casing on the camera got scraped off on one corner. One of the front shocks on the car came apart, which is especially bad considering it’s an oil-filled shock absorber. I haven’t decided what I’ll do about that.

The third downside is that since I had to run the car without a body in order to get the camera on, it got more water damage than usual. Currently it only goes in reverse. I’ll take another look at it after it dries out.

I think I’m going to put this short-lived remote controlled car videography project aside until I figure out a way to get things to survive better.

1. Do it on pavement instead of snow.
2. Attach the camera more securely.

Since it’s been crazy nice lately—4º for the past couple days—we’ve had a lot of dry pavement coming out, so I took the camera/car combination out again today. I attached the camera directly to the chassis with the help of a styrofoam shim, rather than to the body like I did last time.

It started off promising! Up until the last ten seconds I think it counts as a modest success! There’s not so much bouncing and you can actually see what’s going on.

Sadly, those last ten seconds…yeah, I turned left when I should have turned right. It not only knocked the camera off, but it knocked the controller off the chassis. The design of the car is rather stupid in this regard: the controller is just cantilevered, held in by adhesive, in my case super glue. I’ll re–super glue it and see if I can’t try again tomorrow.

My ultimate plan was to take it off some sweet jumps. Now I’m wondering if the camera will survive the trip: it was just held in place by the aforementioned styrofoam shim and some duct tape. I’ll try it with more duct tape and see if I can’t get it to survive a jump tomorrow.

Right, so sadly that never happened as a kid, largely due to the fact that the smallest video camera in my day weighed as much as a small child and used a full-sized VHS (or BetaMax!) tape to record. But thanks to advancements in camera technology, Jasna getting me an awesome car for Christmas, and some help from a roll of duct tape, I finally managed to put this dream into action.

Across the street from us is an elementary school. Cruelly five days a week there are kids there (the nerve!), which means I can’t play there, but on the weekends it’s free. It’s an open sea of hard packed snow—almost ice, but not quite—which makes drifting a lot of fun, and it has a nice area of some fenced off trees that make a wonderful obstacle course. I took the camera there today to show up my mad skills.

Well so I’m posting this video mostly to show the absurd hilarity of it. Turns out if there were a tiny little driver in a remote controlled car, he would be subjected to shaking and whiplash so severe he’d probably pass on within a minute. Highlights of the videos include hitting a tree, hitting a post so hard at the very end that the camera came off, and minutes upon minutes of the horizon jumping up and down. If I ever try this again, it’s either going to have to be on smooth pavement or I’m going to have to have to find a way to stabilize the camera better. I should point out that, even by R/C car standards, the shocks on this car are really soft.

P.S. Yes, there will be a video of chasing the cats around, at some point (duh). We have to clean up the apartment better before making any such videos public, though, you understand.