A while ago we ran a news piece on the NASA mission sending a probe to Jupiter because the probe had finally arrived in orbit. The spacecraft was named Juno, for the roman goddess of marriage, queen of the gods and also Jupiter's wife. How clever is that?

My ears perked up when I heard that bit of trivia, because I immediately recalled this is not the first time I'd heard of Juno and Jupiter together...

I forget where I saw it... okay, I remember exactly where I saw it but I'm not going to admit it here. But it turns out that Heidi Klum has a bit of a thing about dressing up for Hallowe'en. In fact, she throws an annual Hallowe'en party and as the hostess, she has to come up with some pretty impressive costumes. So what can you do when you're a supermodel and can bring an entire special effects department to bear?

Well, maybe you go as Jessica Rabbit. Or Vishnu. Or you could completely flip the script and go as an elderly grandma... or go skinless! She's even gone as a cat and a raven.

But this... this is what got my attention. Unbelievable.

Could someone please get Heidi to attend a furry convention? Can you imagine what kind of costume she'd bring?

I'm really enjoying season 2 of Mr. Robot. The plot keeps me guessing and there's been one or two "holy smokes" moments. And the episode that started out all 80s Family Sitcom was great, even down to the throwback commercial break in the middle of it. But one thing that's been tickling my geek side is the writers' commitment to keeping it real.

There's an episode where the hacker group wants to plant a femtocell among an FBI work group. And while they're prepping the cell, we watch them ssh into it and see the OpenWrt log in screen spill down the terminal. Or after FSociety records another video to post on the internet, we catch a glimpse of ffmpeg being invoked (from the command line, of course) to encode the video into a suitable format for posting. And when there's trouble with the femtocell and the network interfaces need to be bounced, we listen to one of the hackers feeding the commands over the phone to the operative that's on site: "Okay, type ifconfig wlan0 up and then ifconfig wlan1 up..."

Eliot is helping someone else migrate their website to a new server and this person runs Windows 7. Eliot fires up PuTTY and makes an ssh connection to the server. We even get to glance the MOTD of the server as he logs in. Later when he's starting over, he buys a laptop and we watch him download the ISO for Kali Linux (which just about all of the hackers in the show are running) and next thing we know, we're watching the ncurses configuration screens that anyone who has installed Linux would recognize. And when they use Linux, they really do use Linux, right there on the screen.

But this latest episode... Angela is ushered into a room and upon seeing the contents of the room my first thought was "Wait, is that a 1701?" (Like I haven't seen enough of them in Halt and Catch Fire lately) Sure enough, it took only a few more seconds to recognize the silhouette of a Commodore 64 and a 1541 disk drive (later model, with the turn-down locking lever, instead of the "garage door" locking lever). And when a child sat down and powered it all on, my heart leapt with joy to see them type LOAD "$",8 and then LIST the directory structure, before loading and running one of the programs. But then, by this time I would have expected nothing less from the show.

Even the malware in the show is real: the hackers pwn a bank using CryptoWall.

The writers could have used any kind of fantasy hacking "tools" and "shells". They could have invented pretty OSes with fantastical powers. Instead, they're totally keeping it real, using the software and hardware that you and I could get our hands on. And I, for one, really appreciate that.

---

The episode titles have been fairly clever, too. They're all filenames, and in season one they were all video files (.mpg, .mov, .avi, .mp4), This season, they're security files (.asc, .p7z, .p12, .aes).

There's also a strange continuity sometimes... in the episode "k3rnel-pan1c.ksd" Eliot has a bit of a mental breakdown. That is followed by "init1.asec" where he gets past his mental issues and begins recovering. Several episodes later is "init5.fve" where things are supposed to get back to normal... little Easter eggs like that are appreciated by those who recognize them.

She was walking cross George Square in the rain
I was high. I was so high in a plane.
I was trying to see through the clouds,
Looking for places we’d been,
Like a sign, like a sunburst, like the letters in her name.

She was walking quite slowly all alone.
All the lights in the windows were aglow.
But the statues they were so silent,
With the rain splashing their heads.
How bad she wanted to hear them tell her which way is best.

---

This was a pure accident, laying on a hotel room floor, plugged in to Digitally Imported's Chillout channel, trying to drown out the snoring of a fellow volunteer. It was Monday morning, con is over and listening to this, I felt the crushing weight of how in less than 8 hours I would be on a plane myself back home. And on that flight, the metamorphosis from awesome Director Kerosel to plain Ordinary Kerosel would be complete. A feeling of despair so deep, I had to wipe tears out of my eyes as I lay there on the floor.

At that time I hadn't written my PHP web interface for the Audio Addict family of stations and my phone was ignorant of ShoutCast ICYINFO metadata so I had no idea what this song was or who wrote it. I clung desperately to the phrase "the dress she wore was yellow and the rain was in her hair", searching it out until I could get a hit solid enough that would lead me to "George Square" and ultimately to Mirco De Govia's Downbeat Mix of it.

---

That trip home was the second year in a row that despite leaving LAX at a reasonable hour, I didn't make it back to my home airport until after midnight. That year it was simply a late flight out of LAX causing me to miss my connection in SEA and the next plane out wasn't until much later. I hunkered down, had some dinner and tethered my laptop to my phone for a little MUCK socialization.

The year before, I was stranded in SFO from 16:00 to 00:00 because that was the very same weekend Asiana Airlines Flight 214 came in short to 28L at SFO and crashed. When an airport that handles as much traffic as SFO is forced to a single inbound runway, the entire nation feels the effects.

I got the first e-mail notice on the light-rail inbound to the airport that my original flight set to depart in two hours had been cancelled. The replacement flight I was to take from LAX -- three hours after my original flight would have left -- was an hour late simply getting in. Then it had to be turned and prepped before we could board and fly to SFO.

It was a long day, but it did have one amazing reward: I happened to be seated on the left side of the aircraft at a window, so as we crossed the threshold to 28R, I looked out over the airport grounds to see scattered debris and the battered fuselage of the Asiana flight, still sitting there while investigators combed over the remains. It was the most surreal thing I think I've seen from an aircraft window. But then, I'm not William Shatner.

Lookin' for the soul in a plastic world
Lookin' for the skin on my plastic girl
Oh yeah

Champagne smile and a camera flash
Bubble gum lips in a bubble bath
Oh Yeah

Won't you stop me stop me stop me...

It wasn't my dream but it fits like a glove
Nano narcotic bringin' peace and love
Oh Yeah

Could you help me scratch my electric itch
It makes me look good but it's startin' to make me twitch

Won't you stop me stop me stop me stop me stop me stop me stop me...

Sendin' me the message, it's crawlin' underneath my skin.
Sendin' me the message, it's crawlin' underneath my skin.
Sendin' me the message...

---

I was introduced to this tune by Planet Funk via Nostromo's Galaxy Pad video... and hooked immediately. Big mechanical beat, brooding... and then it just absolutely breaks open at the chorus. Can't get enough of it!

---

By the way, you ever tried searching "Galaxy Pad" on YouTube? So many Samsung devices...

---

Random Thought: It would seem that Genius Party is good fodder for Anime Music Videos...

Well here we are
So close to midnight.
And I can barely see your face
It's hidden in a silhouette.

But we continue
Into the centre.
You feel your heartbeat starts to skip
(but) It's the only way out of this.

Yeah...
Just nice to meet you.
Better believe in me tonight
And I will not let you down.

If you see me fall, I will get up again.
I'll make you a promise that this is not the end.
Just like I said, get a hold of yourself.
You've got to trust me, just get a hold of yourself.

---

This song sends prickles up my spine and makes the hair on the back of my neck stand up every time I hear it. But when combined with Nostromo's amazing video editing to form "Binary Overdrive"... it literally brings me to tears. Something about the breakneck speed, the struggle, the thundering bassline... and then the sentiment of if you see me fall, I will get up again...

You know, when Samsung announced their top-loading washing machine with the built-in sink, I thought it was a neat idea. How convenient, to have a place right there on the machine to pre-treat clothes and then dump them right into the wash basket. Why didn't anyone think of this before?

It took a few weeks of mulling it over to find the answer: it wasn't necessary before.

I grew up in a house with an attached garage (but no direct entry from the house) and the washer and dryer lived in the garage. And what was next to them? A deep laundry sink, where you could pre-treat anything that needed it.

Once the addition was put on to our house, there was a service porch with a place for the washer and dryer, getting them out of the garage and into the house proper. And what was across the traffic lane to the back door from the washer and dryer? A laundry sink. It also doubled as a sink for the three-quarters bathroom that was back there too.

Now in these enlightened days, the washer and dryer are often relegated to a closet. In my current house, they're behind double doors right off the kitchen, taking up space in the wall divider between the kitchen area and living room area. There's no space for a laundry sink, and nobody wants to use the kitchen sink. Even if you could, you'd be hauling wet laundry across the kitchen from the sink back to the washer.

It wasn't until the demise of the laundry sink sitting alongside the washer and dryer that we really needed a washing machine with a built-in "sink". The generation before would have shrugged their shoulders and asked why pay for that when they already have something that does the same job.

The constants are changing, my friends.

---

Samsung calls this built-in sink and water jet "Active Wash". Which is funny, since the only activity will be you scrubbing your clothes in that sink.

"Trinity... doesn't exist, man. He's not real. He's a figment... a cypher... a jabberwoky.

And who am I? Who the hell am I?"

I like to carp a lot about wages and salaries because I believe I'm being underpaid. Granted, we're probably all underpaid, but it's hard to argue the IT pro knocking back six figures is being underpaid compared to the rest of us.

Invariably in the course of my griping, someone will say, "Oh I'm making far more than you, but the cost of living here is outrageous!" And that's usually true... have you seen the rent in San Francisco lately? It makes Los Angeles look sane. So the idea is that the higher wage is justified because the cost of simply existing in the area is so high.

But let's take a closer look.

Let's imagine we have an IT worker in Los Angeles bringing home $60,0000 a year. And let's say the cost of living (rent, utilities, car insurance... stuff like that) comes to $40,000 a year, about two-thirds of their salary. That leaves them with $20,000 a year to spread around on fun things. Not bad, not bad.

Our theoretical IT worker gets disillusioned by the big city and decides to change location, moving to a smaller community. They land a job making $30,000 a year, but it's all good because the cost of living is half what it was back in LA. So after giving up $20,000 a year to live, they're left with $10,000 to buy some nice things and amuse themselves. Makes sense... everything is proportionally halved.

Here's the kicker: the price of living expense is halved, but the price of those recreational expenditures remains the same. Disneyland will set you back $100 a day regardless if you drove 10 miles or 1000 miles to get there. You can't walk into a Best Buy and get an XBox One for $150 with a "small town" discount. A gee-whiz brushed steel refrigerator is north of $1000 all across the country. And that brand new Golf R is always gonna set you back $39,000 at every dealership everywhere. That's twice the leftover income in LA, but four times that in the small town.

So the next time you wanna give the cost-of-living argument to justify your salary, by all means go right ahead. It's certainly not untrue that places with a higher cost of living tend to pay higher wages. Just remember that it tends to leave one with more leftover income to play with. And the cost of playing never changes, no matter where you live.

Let's talk braking. Time was, racing games had brakes like a switch: on or off. This evolved into more analog systems where the amount of braking could be dictated, from a slight correction through a kink to full-on hauling down for a hairpin. The thing is, it's still not that simple, even if there are a lot of games and simulators that would lead you to believe that.

Let's review what I've learned over the years from GTR2. And let's go to the Circuit de Spa-Francorchamps for a great example of coming off a long, high-speed straight into a slow corner.

Cresting the top of Eau Rouge, GT cars can be going over 120 miles per hour. There's only a slight right-hand kink before dumping out onto Kemmel Straight. Almost all cars will top out on this straight, either running out of power or dancing on the rev limiter. GT cars can come into Les Combes at over 180 miles per hour. Time to get on the brakes for that right-hander. And by that I mean squeeze the brakes. One does not "jump on", "slam on" or "stab at" the brakes in a race car. One "squeezes" the brakes, very firmly but smoothly.

The reason for that is the first thing that happens under braking is the weight of the car shifts forward, putting more weight on the front wheels. This helps press them down to the racing surface and is why the front brakes usually do more of the work stopping a car than the rear brakes. The brake pressure is not necessarily biased toward the front (although it often is, even just a little) but the front brakes might be bigger than the rear brakes. If this weight transfer happens too quickly, it can upset the car, especially if driving on the edge while racing.

The second thing that happens is that the brakes begin to heat up. We're all familiar with how overheated brakes are not as efficient at stopping a car, but brakes that are too cool are similarly inefficient. Racing brakes on GT cars are most effective in a range between 700 and 1000 degrees Fahrenheit. After flying down Kemmel, a car's brakes will be relatively cool (by that I mean 350-400 degrees).

Here's the conundrum: the brake cooling ducts could be restricted to keep the brakes from cooling off on Kemmel, but when they get used through Bruxelles, Pouhon, Campus and Stavelot, they're guaranteed to overheat. If enough cooling is used to keep temperatures in check during the technical parts of the course, they will cool off to the point they're not working as well as they could after the long straights. The latter tradeoff is usually the better choice.

So when braking is first applied coming in to Les Combes, the car won't slow as well as it should for a given pedal pressure. However, as the car slows down the brakes start heating up, and as they heat up into their working range, they stop the car more easily. Braking for the corner, the brakes literally get stronger as they are used.

The third thing to consider is aerodynamic force: flying down Kemmel at 180, aerodynamics are in full effect, pushing the car down against the track. And the harder the car is pushed to the track, the more it enhances the traction of the tires. When the brakes are first applied, the car is still being pushed down by the aerodynamics. As the car slows down, that aero force starts going away, until at the point of turning, the aerodynamic force may be completely gone.

When the second and third items are combined, they create quite a dynamic: braking for a corner from a straight, the brakes are getting stronger while the traction due to aerodynamic force is going away. And because of this, a driver will need to ease up on the brakes while braking for a corner or the combination of stronger brakes and weaker traction will lead to tire lock-up.

It seems totally counter-intuitive to ease up on the brake pedal when staring down a slow corner ahead, but it's absolutely necessary to keep control of the car.

---

Locking a tire during racing is bad, but how bad is it really?

First, a sliding tire has almost no grip, which means all braking force is lost on that tire. When hanging it out on the ragged edge racing, braking with only three tires is not good enough. If it's a front tire that locks up, steering direction is lost and trying to wrestle a car through a corner with one tire doing the turning is a big handicap.

Second, depending on the severity of the lock-up, it creates a flat spot on the tire. This is bad for two reasons: first and most importantly, a tire that's on the verge of locking up (and they should be during braking, see below) will tend to stop and lock-up more easily at the flat spot because of the extra force necessary to get over the "edge" of the flat back to the rounded surface. Locking up again on the same flat spot makes it flatter, further aggravating the problem. Also at racing speeds and the rotational speeds tires turn, a flat spot can cause intense vibrations in the car.

Tire compounds suffer from something called hysteresis. Suppose we have a tire with a certain amount of traction force. Asking for 105% might cause the tire to turn more slowly, scrubbing over the racing surface, but not fully lock up. This is in fact called "threshold braking" and slows the car better than a tire at 100%. If a tire is pushed to 108% and it locks up, releasing braking back to 100% traction force will not start the tire spinning again. The force may need to be released back to 93% for it to stop sliding. But releasing braking force for one tire means releasing braking force for all tires, so sometimes the best policy may be to lump it and leave the tire locked through the braking zone.

---

Brakes fade when they get hot for a variety of reasons, but here are a few that come to mind.

Very often, the brake calipers can get hot enough to boil the brake fluid inside of them. This creates air pockets and physics takes over: air compresses the way hydraulic fluid does not. This will reduce the effectiveness of the brakes, the pedal getting spongy. There are brake calipers made with water channels cut in them, designed to be water cooled while racing and keep temperatures under the boiling point of the brake fluid.

Brake rotors can get so hot that when the pads are applied, the pad material vaporizes and creates a layer of gas between the pad and the rotor. The brake pad wants to skate over the rotor surface on this layer of gas, reducing the friction between the two and therefore reducing braking force. This is what slotted brake rotors try to reduce: the slots give that gas a channel to escape from under the pad. It's not unlike the treads of a tire letting water channel away. In fact, that's an excellent analogy: the brake pad is "hydroplaning" (aeroplaning?) over the surface of the rotor.

Finally, there are the limits of physics. Slowing a car is all about energy transfer and the kinetic energy of the car is turned into heat energy and dissipated. There does come a theoretical point where the brake rotor absolutely can not absorb any more heat energy, so the kinetic energy has nowhere to go. The pads can be applied to the rotor as hard as possible, but no energy transfer will take place, and the car will not slow down.

I mentioned the type-in game "Viper" for the Commodore 64 and how it was a basic program with an assembly core. That led to some weird occurrences when the normal flow of the game was circumvented...

The way it worked was the BASIC portion of the program would run the menus, take the selections, set up the play field (drawing a border around the screen and the mazes if necessary), put the first star (the mouse/food) on the board and load relevant information (such as the selected speed) into memory locations. It would pick the starting location of the snake and load that location into memory and then flash the diamond character different colors at that starting location. Once the joystick was not centered, the BASIC programming invoked the assembly code.

The assembly would take joystick input, move the snake, update the tail, make the movement sound effect and delay for the proper amount of time based on the speed selection. If the location the snake was moving into was not an empty space, it would load the character code for what was occupying that location into a memory location and drop back to BASIC.

BASIC would then pick things up, checking the memory location to see what the snake had hit. If it was a solid block or the snake's own body, it jumped to the snake's death (head becomes a yellow star, simple sound effects, proceed to game over and score screens). If it was a star, it would do the appropriate sound effect, update the score, put a new star on the screen and jump back into the assembly routine. And if it was another character that it didn't understand, it would fall back into the assembly code.

Normally everything stayed contained, because there was always a solid-block border around the edges of the screen. The snake could not exit the screen without being killed. But there was a time I was fiddling with the program, looking at it and I started the BASIC code in the game loop. I ended up playing the game on a screen full of the BASIC program listing, instead of the standard arena.

Moving off the left or right side of the screen only caused the snake to wrap around to the other side, because they were all contiguous memory locations. But trying to exit the top or bottom of the screen... well... you might recall that the C64 had no memory protection and would let you gleefully alter any memory you'd like. And then you have to realize that screen memory sat right above "zero page" (containing all kinds of critical vectors and indexes and settings) and right below BASIC memory.

Moving the snake off the top of the screen was a recipe for crashing or at least scrambling the brain of the computer. It was just a matter of running into that critical register and the assembly code overwriting it with the snake character. Sometimes it would freeze, sometimes it would do an interrupt reset (the RUN/STOP-RESTORE combination, for those familiar) and half the time even after the reset it would be scrambled enough that you had to power off and back on. While researching this journal, I accidentally moved the snake off the top of the screen. I maneuvered blindly but after a few seconds the emulator barfed up a rainbow of graphic characters across the screen and froze solid.

Moving the snake off the bottom of the screen would send it tearing through BASIC memory. And it would corrupt BASIC memory as it went. The thing was, the main loop of the BASIC program was only two or three lines as long as the snake didn't collide with a character that mattered. You could run roughshod over the program and it would keep going as long as those three lines didn't get corrupted. Once they did, it would stop with a SYNTAX ERROR and if you listed the program you could see the damage and corruption that had been done.

Kinda funny... it gives a whole new perspective on a worm (or a snake, in this case) in your computer, damaging your data.

---

Viper had two unintended things that could happen.

The snake "moved" on the screen by updating the position of the head, drawing in a body character where the head used to be and then writing an empty space into the last piece of the tail (and a space or two beyond, to be safe). Because the body character made a nice repeating pattern and the snake moved a character space at a time, it was a convincing animation of movement.

But there was an edge case with the placement of the star. There was a subroutine to pick a random spot on the screen that was empty and this was used to pick the location of the new star once the current one was gobbled up. Every once in a rare while, the location picked for the star was directly at the tail of the snake. The star would be placed by the BASIC code, it would jump back to the assembly, which would animate the snake and write spaces into the locations at the end of the tail... erasing the star! You were then pretty much boned: there was no way to advance because there was no longer a star to gobble.

The other oddity had to do with the length of the snake. The number of stars eaten was kept in a BASIC variable and then poked into memory for the assembly code to reference. That number was doubled to come up with the length of the snake's body, i.e. every star eaten lengthened the snake by two spaces. The assembly code probably kept a table somewhere of the spaces the snake body occupied, adding to the front of it while erasing the end of it.

When the BASIC counter got to 128, the assembly code that handled the table look up would wrap around... an 8-bit memory location can hold a value from 0 to 255. So suddenly the assembly code would go from erasing the snake body 250+ characters down the line... back to two characters down the line. In effect, the snake would "shed" its long body and go back to being short, leaving the old long body in place on the screen as an additional obstacle. While this was a cool difficulty increase, it was also easy to get screwed: a star that ended up inside the coils of the shed skin could not be eaten.

I also discovered while researching that bug that if you were good enough to shed the skin and get the snake back to the point it was about to shed again, that the BASIC variable holding the number of stars eaten would reach 256. When it attempted to poke that value into memory for the assembly code, the program would crash with an ILLEGAL QUANTITY error because memory locations can only hold a value up to 255. But I assure you: if you could survive that long, then crashing the game is a testament to the sheer magnitude of your skill and luck.

When I was young it was always a good time to visit the Los Angeles Museum of Science and Industry. And one of the exhibits I remember was off in a corner in the Communications wing. It was called "The Mouse is the Message" and was a two-screen maze game. One screen had a joystick in front of it and was the human controlled mouse, the other was the computer controlled mouse and the idea was to run the maze and beat the computer to the goal. I don't know that I ever read the exhibit explanation (or if there even was one) but I'm guessing it was an exercise in message routing and how computers were better at it than humans.

The evidence from the win counters atop each screen seemed to show that computers were better than humans and if you watched for a while, you'd see why. Of course the AI's path-finding was infallible, so even if the human made the same moves as the AI the best one could hope for was a tie. But inevitably the human would go down the wrong path, or hesitate and then it was over. It was a wonder the human side had any wins at all.

The reason the human side had wins was because at times, in the middle of the run, the maze would shift and change. Simulation of changing communication paths, I suppose. Of course the AI could instantly re-path to the goal and was on its way. The only way I remember seeing a human win was having the great fortune for the maze to change in their favor, where it put them closer to the goal while the AI had to backtrack.

But here's the kicker: when the human won, the game would congratulate them on the win and then say, "Let's play again... at my speed." The game would reset with a new maze, the countdown would run and then before you could blink, the AI mouse would be at the finish line. The game would run at full-bore machine speed, giving the human no chance at all of winning and demonstrating the superiority of computers in their speed.

And that also explained why the computer side always had more wins than the human side. Always.

---

There were a couple of Commodore 64 games that would do something similar.

The first I remember was "Viper", a clone of "Snake" with the snake that grows every time it gobbles down a pellet/mouse/star. You had to avoid the snake's body, but could also add mazes into the mix if it wasn't difficult enough (but you did get a score multiplier for having mazes). The framework for the game was written in BASIC, but the core of the game was a small bit of assembly code.

At the start, you could choose a speed from 1 to 20. Speed 1 would put you to sleep. Speed 11 was a good place for most players to start. Speed 17 was good for advanced players with no mazes. Speed 19 was like skating on ice... about the best I could do was turn constant circles hoping to loop around and eat the star on the screen.

As for Speed 20? Well... I know some snake clones would start with the snake already in motion. Viper would start out with a diamond at the starting location, waiting for a direction press to start the snake moving. And at Speed 20, when you pressed in a direction the snake would instantly be in the wall in that direction, already dead. Speed 20 was unadulterated machine code speed. The only way I ever scored points on Speed 20 was because the star just happened to line up in a cardinal direction with the snake's starting point so it could be collected on the way to smashing into the wall. I might have done that once.

The other came I remember was "Cut-Off", a clone of the TRON Light Cycles idea. It also had a Speed 20. And it also was at full machine speed and totally unplayable. But it was good for some laughs.

Hey baby.
This is not a challenge.
It just means that I don't love you
As much as I always said I did...

I was wrong.
I have been laughable wrong.
Sandpaper, paper mache, chalk, and hung out web
of the city and your skin now.
Na na na na, na na na.

I didn't have to be afraid
I didn't have to feel so stupid
I can see myself! I can feel...

That just the slightest bit of finesse,
Might have made a little less mess.
But it was what it was,
Let's all get on with it...
Nooooooooowwwwwwwwww!

<3

I've got an interesting question for you.

As some of you may know, I like to play a great little air traffic control simulation called ATC Windows. The fact that I play an air traffic control simulation to unwind might tell you something about the way my days usually go, but I digress.

There are many different commands you can issue pilots in the simulation, one of which is an altitude crossing, such as "cross MAZIE at 11000". This tells the pilot that they can (in this example) descend at their discretion as long as they cross the MAZIE fix at 11000 feet altitude.

These days, most commercial airlines are very conscious about fuel costs and pilots are encouraged to stay at altitude for as long as possible before descending. However in ATC Windows, it is no secret that the pilot AI is programmed to look for aircraft crossing their path and if they've been issued a descent at their discretion, they will descend to purposefully cause a loss of separation with that crossing aircraft.

I'm torn about this. Obviously, pilots in the real world don't watch their TCAS for other aircraft and do their best to mess with the air traffic controllers. In the above example, on approach to Philadelphia, aircraft enter New York Center Sector 97 at the north border of the sector with the MAZIE fix almost 100 miles down their route. When a pilot first checks in, if you told them to cross MAZIE at 11000 feet (they ordinarily enter the sector at 17000), I think it would be reasonable to expect them to stay at altitude until only 10 or 20 miles before MAZIE, depending on the aircraft and its performance profile.

On the other hand, just because pilots like to stay at altitude doesn't mean they will. As an air traffic controller, if you issue a descent at pilot's discretion, you should be ready for them to descend at any time. Their path should be clear of all other aircraft that could cause a conflict. There are several flight paths that cross under the Philadelphia arrival stream, and if the controller decides to descend LaGuardia jet arrivals early, they cross under the Philly arrivals as well. All of these are conflict sources.

The simulation author's reasoning is that the AI behaves this way to break you of bad habits. And while I can't disagree, it still irks me to know that the AI is programmed to act in a way no real pilot would ever behave. If the goal is to simulate the real world as closely as possible, the AI should behave like pilots in the real world.

What do you think?

(10 points to anyone who's now humming AC/DC)

Not to long after the release of Half-Life 2, there were rumors that Valve would port the original Half-Life over to the Source engine. There was considerable excitement! Source was like nothing that had been seen at the time and to have the classic that started it all get a facelift to look as good as HL2 was certainly something to be excited about!

Alas, when it did happen... it was nothing more than a port to the new engine. Graphics remained the same, sounds remained the same and the levels were... pretty much the same. About the only difference were the particle effects (primarily explosions) looking better, but that was likely already something the Source engine already did. I can't speak for everyone, but it was a bit of a let-down.

After a while, more rumors swirled. Rumors of an independent, renegade team that wasn't going to just port Half-Life over to Source, they were going to rebuild it from the ground up and make it what everyone was expecting from the original porting project. It was a massive undertaking, but there were pictures! Proof of high-res textures, familiar levels and beautiful models.

The project fell off my radar for a long time until one day I decided to search it out again and found it with it's new name: Black Mesa. I downloaded the compressed package and integrated it into Steam (there were easy-to-follow directions, but it wasn't an automated install). And holding my breath, I launched it. It was, in a word, amazing.

For those of you who never got a chance to play the original Half-Life, it was a chance to catch up and see where it all started. To be there when Gordon Freeman creates a resonance cascade, opening portals to another universe. To run for cover when the military shows up to... uh... "help". To get your hands on strange new weapons, both Earthly and alien. And to band together with the surviving scientists and security guards to survive and get the hell out of Dodge alive.

But for those who have played Half-Life, this is Half-Life in stunning HD. All new textures, new music, re-recorded voice tracks (and additional dialog!) and expanded levels. Not just expanded like getting new rooms, but super-detailed. The opening sequence tram ride doesn't just start in the tunnels. It starts at the station, where other scientists are milling about waiting for their own trams. The open sections of the tramway tunnels have sunlight streaming in or let you look out over expansive desert landscapes.

And it comes with a strange sense of deja-vu. More than once I would be wandering down a tunnel with this nagging feeling something bad was around the corner but not able to remember exactly what it was. And then I'd turn the corner, see the giant alien beast pounding the military into the ground and think, "Ooooh yesss... I remember now." And maybe it was because I had played it through already, but looking out from the tunnel during the tram ride, I recognized places I would end up going through as events progressed.

Not everything is exactly the same. Some some things have been modified to take advantage of the shiny new game engine and beefed-up hardware. In the original Half-Life, the satellite launch control room had an open window looking out over the launch site. When you started the launch sequence, a blast shield would lower, leaving only a small slot that you could catch glimpses of light and smoke to let you know the rocket was being launched. But in Black Mesa, the window starts closed, and when you trigger the launch sequence, it opens and reveals the rocket launch in all it's amazing, smoke-belching, blinding-glare glory. No doubt HL-era hardware (or the original game engine) couldn't have handled something like that, but six years later, it was easily possible.

There are small details too. In the laser test room, be sure to watch for the ripples in the air coming off the hot upper assembly after firing. And as you're wandering through the wreckage of the laboratory, stop and marvel at the room where a liquid nitrogen tank has been punctured. It's spraying super-cooled liquid into the water coming down from the fire suppression system, causing five-foot snow drifts to pile up in the corners of the room. And some of the more frustrating puzzles (usually involving jumping) have been toned down and reworked to be less "challenging".

Even though it was an unofficial mod to Half-Life 2, it still went above and beyond. Little touches such as integrating with the start-up menus, showing a scene from your current place in the campaign as a backdrop. It's the same thing you'd see in Half-Life 2 or other official Source engine releases.

It wasn't complete, though. The programmers had not yet created Xen, the borderworld where the last part of the game takes place. But even with that limitation, things are wrapped up tidily. Gordon steps through the portal, the world fades to black, and up comes the text: "Subject: Gordon Freeman. Status: Suspended". A clear indication that the narrative is not yet over. There is more to come, even if we're not sure when it might arrive.

In short, Black Mesa is the port that should have been delivered the first time. But taking into account the years of work that went into making it (and the years that will undoubtedly follow) it's easy to see why Valve couldn't have delivered on that kind of promise without tying up their own resources for a long time. All I can say is go give it a try and experience the Black Mesa Research Facility for the first time. Or remember all the reasons you fell in love with Half-Life in the first place.

---

When I first played Black Mesa, it came in a pair of compressed files and had to be manually installed and integrated with Steam. Now I see that Black Mesa is officially available via Steam, and until July 4, it's on sale for only $8. I still have the old version, but I'm gonna buy up the new version. It'll be an official Steam app, it'll be easy to upgrade and let's face it: these folks deserve the support for driving the project this far.

Let us hearken back to the days of Compact Disc Digital Audio...

The Redbook specification had a feature that was seldom used outside of professional audio, and that was the Track Index. An index was not a sub-track but more like a bookmark of a certain time in a track. Think of it like the "&t=" URL property in YouTube videos when someone calls out a specific part of the video in their comments.

The only place I've really seen indexes used is in sound effect libraries. The advantage of using indexes in a track rather than only tracks is that CDs have a limit of 99 tracks. If you use strictly tracks in something like a sound effect library, and your sound effects are on average 10 seconds long... those 99 track would get you about 16 minutes of audio. Kinda lousy for a disc that should hold 70 to 80 minutes. Fortunately, each track can have up to 99 indexes.

You could use the tracks to classify a category, say... 1957 Chevy Corvette. And this track would contain all sorts of sound effects from a '57 Vette, with indexes. Index 1 might be the door lock, 2 the door opening, 3 the door closing, etc. You lay down 5 minutes of '57 Vette effects on a single track... that's a lot more efficient use of the space. And the indexes get you right to the sound you want, rather than having to search the whole track.

Of course in the music industry, tracks do just fine filling up 70 minutes with songs, so indexes other than the first are never used. In fact, when consumer CD players first hit the scene, they showed track and index on their display. With the lack of indexes on the vast majority of CDs, the index indicator was quietly dropped on later models and nobody missed it.

There is one special index that was used on everyday CDs and that was Index 0, also known as the "pregap". I'm sure some of you owned CDs that had silence between tracks, and during that silence the elapsed time would go negative and count down to the start of the track. That is index 0. The start of the music would be index 1 and at that point the elapsed time would count upward. The special trick with index 0 was that when CD players would seek to a new track (including track 1 at the start of playback), they would start playing at index 1. This means on a track seek (manually, programmed or shuffle), the pregap is never played. It only plays when playing linearly through a CD. And this makes sense: if you're shuffling around, you don't want to hit that two seconds of silence before a track starts, or at the end of a track before seeking to the new track.

Unfortunately, sometimes it is used badly. I know on my Lion King soundtrack, the pregap to track 2 is nearly five seconds long and includes the last few seconds of the final thunderous finish to "Circle of Life" fading away. Not an issue when playing linearly, but when shuffling... track 1 ends when the pregap to track 2 begins (because it's track 2 index 0) and the player will jump off to the next track before the fade out is fully finished. Which is somewhat irksome.

Most of the time, it's used as it was inteded: for silence spacing between tracks that otherwise wouldn't need silence when playing non-linearly. But it's also been used cleverly... on The Crystal Method's debut album "Vegas", there's a little intermezzo piece between "High Roller" and "Comin' Back". It's not really part of "High Roller" and doesn't fit with "Comin' Back"... and it is in fact in the pregap to "Comin' Back". The only reason I realized something was different was one time I was listening to the CD and during this piece, I realized the counter on the player was counting down instead of up. And when it hit zero, "Comin' Back" started. And if you think about player behavior in the previous paragraph, the only way you will ever hear this piece is if you're playing linearly through the CD. If you shuffle or use programmed play, the intermezzo ceases to exist.

Which leads to the next thing: the pregap doesn't have to have silence in it. It's an index to a track and can contain anything and be any length. And this has given rise to a sinister element: the truly hidden track. You remember the "hidden" tracks on CDs where the last track would have a song, then maybe 8 minutes of silence and then something bonus that wasn't listed on the track list? There was still a tip that something was afoot... the player would keep going after the last song.

What a number of bands have done on quite a few CDs is hide a track in the pregap to track 1. Think about it: when you start playing a CD, the player seeks to track 1, index 1. So you'll never hit it even playing a CD linearly. If you seek back to track 1 from a different track, it starts playing at track 1, index 1 so you won't find it that way. The only way to find it is to start track 1, pause the player and rewind. The counter will hit zero and then start counting an increasing negative count. But who in their right mind would do that? What would possess someone to rewind at the very start of a CD?

I learned of this phenomenon on Mono Puff's CD "Unsupervised". And there are a whole lot more out there apparently.

---

So how do computer players handle pregap? I suppose it depends on the player these days, since the raw data is pulled off the CD and played back by the software. I fired up "Vegas" on Banshee and the intermezzo track is put at the end of "High Roller", as if it was part of that track. Your mileage may vary, depending on the software used. And if played right out of the CD drive (as in the days of yore) all bets are off.

I am reading on-line that some CD Drives do not like track 1 pregap and will report errors when reading the track or pretend like the audio is being extracted but deliver a file of silence. I'd try it out on mine, but I don't think I have a CD with such a hidden track.

---

One of you is thinking, "Wait! The pregap to track 1 would be a great place to stow CD-ROM data without exposing people to those teeth-cracking frequencies on conventional audio players!" This is true, and it was used for a while. In time, the Windows DLL was changed to make reading the track 1 pregap impossible. Thoughts are this was done on purpose to steer people toward the "CD-Extra" Bluebook format.

("Teeth Cracking Frequencies" courtesy of the warning on a PSX demo disc that had both data and Redbook audio on it)

If you've ever had an interest in Formula One racing, now is the time to dip your toes into the pool. This weekend the racers are at the fabled Monte Carlo Circuit and the race will air on NBC networks at 07:00 Eastern Sunday morning.

Monte Carlo is an iconic street circuit that winds through the city, ducks under a hotel and then races along the bay. It has a hairpin so tight, the teams have a special front suspension and steering gear that is used [/i]only[/i] at Monte Carlo. And God forbid you miss the turn in point and go wide, because the car just won't turn any tighter. It has been said many times that if someone wanted to design a course like Monte Carlo today, it would never be approved. Thankfully, it's been around since 1929 and is grandfathered in to the series.

Afraid you don't know enough to understand the races? No problem. When the races are aired on the broadcast network, the commentators tend to explain a bit more than usual. They don't "dumb it down", but perhaps mention a thing or two that regular fans already know or that might have been picked up earlier in the season. They make sure everyone is included, regardless of fanaticism or experience.

Of course, once the F1 race is over, you have an hour to catch your breath before you can turn around and catch the Indy 500 on ABC... and then stay tuned 'cause the Coca Cola 600 happens after that on FOX! Formula One, IndyCar and NASCAR in a single glorious day of racing!

If you think it would be tiring to watch all that, consider this: in 2000, Tony Stewart raced in the Indy 500 and then turned around and raced in the Coca Cola 600! That's some dedication right there.

"Wow, I did it. I worked hard and stuck with it and I'm actually living my dream. But what happens when it turns out your dream sucks?"

Imagine in the fifth grade, you took a field trip to a graphic art studio. You saw the people at work, making art... and something just... clicked. You thought "This is it! This is what I want to do with the rest of my life!" That field trip would make a deep, lasting impression and start a lifelong devotion to art.

So when you got to college, completely set on getting a degree in computer science (because let's face it, you've always been fascinated by computers too), you suddenly went spearing off on a tangent and instead went for an art degree. You took the classes, put in the work, even got a job at the art lab helping others learn about art and make their own. When you got out of college, you scored an internship at an art studio and got to watch the professionals at work and help out now and then.

As a career, you ended up in and out of art... never quite being able to keep a hold of it, always ending up in computers instead. But you still attended conventions, did artwork there at the cons on a totally volunteer basis. Maybe you weren't getting paid, but you were so happy to be there and doing what you loved, and working with a tight-knit group of comrades.

After your second career reset... success! You get hired at an art production house! Not as an artist, but as supporting staff. And for years you'd pal around with the artists and walk past their design room and peer enviously through the windows at all their great tools and gear. And there would be the mandatory detour through IT and engineering, but suddenly there's a seismic shift at the company and you're offered not only a position in the art production group, but as the lead artist! Needless to say, you accept.

It doesn't take long to figure out things aren't the same. Part of that seismic shift is that nobody will be hand-drawing art anymore. Instead the artists build scenes by selecting from a library of clip-art, putting it where it needs to be. Sure, every now and then there's a request for a clip that doesn't exist, so you get to sketch out something new... but those times are few and far between. Day to day, it's all clip-art into the scenes, then sending it to a plotter to let the machines draw out the finished product.

And those conventions? Haven't been able to go back to them and draw art. There's just no time... the work keeps you from getting any time away. But... at least you're making art...... right?

---

That's my life in a nutshell. Except of course, instead of graphic art, it's television. I trained for years on my chosen instrument, starting in school on a Grass Valley GVG-200, working with a Sony DFS-700, or a Panasonic AV-HS450n or a Ross Carbonite at conventions, and now in the presence of the granddaddy of them all, the Sony MVS-8000G, Except the days of hands-on, "playing" the keys of the switcher are over. Instead you program the shots ahead of time and sit there, George Jetson-style, pressing the button to advance to the next shot.

And my experience is not a fluke. There is still at least one station in town that has an actual director running a switcher. I could apply to work there, they're looking for a director. But why bother? That station is looking at automation as well. The people who took the time to go to school and learn a craft or a trade are being pushed aside by machinery that makes less skilled people able to do nearly the same job at a fraction of the compensation.

I have to think this is how the loom operators felt when the first punch-card power looms hit the scene. The inevitable march of progress, running over you until you're crushed to death under its wheels.

You're afraid to be an artist? Perfect, you might actually make something interesting.

And you know what, nothing pisses me off more than people being too daunted to share themselves 'cause they haven't been artists since preschool or whatfuckinever. The truth is, art isn't about artists, it's about putting a microphone in front of something you feel strongly about and recording it so your ideas escape your head before you die like rafts from a sinking ship, because ideas are immortal and you're not so rescue them and they'll prove you existed and hopefully it'll make other people want to do the same thing because everyone is dying and has ideas. And then maybe you'll find yourself developing the strongest possible identity anyone can have in the process, because if I seem like I have confidence it's because I think this is the greatest job in the world. Because it is.

I'm sick of artists and fans who bury people in shop talk and jargon to seem more exclusive like the fucking assholes who turn you off bike riding by dressing up in fucking spandex and making it look like it's harder than it is, and then you're sitting here with fucking great ideas feeling like you can't use them because you don't look like the people on stage and you have no history. Fuck anyone who wants art to be a clubhouse, fuck 'em sideways -- this is the best place in the world and I met my three best friends here and I go to bed happy with a smiley face fucking alarm clock and if you're envious then I promise you fucking should be. You sit in bars and you talk about "Oh, wouldn't it be fun if..." Well yeah, it is fun actually, and I think as artists we undersell how rewarding it surely fucking is to make others feel less alone and have your identity survive in the public consciousness in that process, and there's no human who doesn't deserve that.

Being an artist isn't for special people who all know each other and talk in waves of in-jokes, it's you as an individual honoring your fundamental need for self-expression, and it's wanting to do something that's fucking important and lasting and helps other people get through the night, and it's wanting to have a job you don't ever need to take vacations from, and it's wanting to be fucking buried face down when you die to keep your soul from escaping because you scare the shit out of people but yours is the one grave that people are still leaving flowers on a century later, so if you need the license to believe that your thoughts matter then I'm fucking giving you the license!

Just a quick note...

The 40th anniversary of Rush releasing "2112" recently passed, and in honor of this a video comic set to the music of the entire 2112 Suite has been released. Word is it's only available until Monday 09:00 EDT.

Put it up on the big screen, turn up the volume and enjoy...

Good piece of fiction from Road and Track magazine back in 1973, looking into the future of automobiles and driving and safety.

I'd say give it a read, it's only about two pages long.

When I find myself in times of trouble, father Francis has this to say: there ain't no way to delay that trouble comin' every day.

If you know the words, sing along!

One of the things I love the most about it is that in a single song, he takes a swing at rioters that destroy their own neighborhoods and smash the local markets and shop owners, the media falling over themselves to get it on TV, ignorant people out to cause harm to everyone else and finally at the great society that keeps people in crap jobs just to keep on living another day. Unless, of course, your uncle owns the store...

It was true when Zappa wrote it after watching too much TV coverage of the Watts Riots, and 50 years later, it's still as fresh and relevant as it ever was.

And they say it served 'em right
Because a few of them are white,
And it's the same across the nation
Black and white discrimination
Yellin' "You can't understand me!"
'N all that other jazz they hand me
In the papers and TV and
All that mass stupidity
That seems to grow more every day
Each time you hear some nitwit say
He wants to go and do you in
Because the color of your skin
Just don't appeal to him
(No matter if it's black or white)
Because he's out for blood tonight!

"But I'm under no illusions too, you know?

I know I'm not well off here, and I know it's not getting any better, and I know I'm probly gonna be gone, you know, in not that many years. Might as well just say it, right? I'm still around 'cause I still hope for the best I guess. Like, I know that of all the good things I've gotten, none of them I ever would have seen coming so sometimes you have to kinda hold the fort for future you in case something cool's coming their way, but I can just as easily imagine that one morning I'm gonna be older and still the same and it's gonna be yet another day and it's gonna be obvious that yeah, probably not much is ever gonna change. I guess I can see that happening as much as anything."
-- Zoe

Today we're going to learn about another interesting Commodore trick that depends on another minor exploit. We're going to learn a way to make a program automatically run once it's loaded. There's a bit of technical know-how in here, but I'll try to break it down into easy steps.

First you remember from a previous post that when programs are saved, it includes the memory address to start loading from. For Basic programs, this is always the start of Basic memory. For Machine Language programs, it could be anywhere there's enough memory to contain the program. The loading routine starts at the address specified and increments the address for each successive byte until it hits the end of file marker.

Second we need to learn about how memory works in the Commodore 64. The Commodore 64 really did have 64K of RAM, despite the boot screen saying there was 39K-and-change free. The problem here is that the Commodore 64 can only address a total of 64K of memory space. If all of that was devoted to RAM, there'd be no addresses left for kernal ROM routines. No I/O routines, no keyboard reading, no screen painting... nothing but RAM.

If there really is 64K of RAM, but there's also ROM for the kernal, how does it all co-exist? The answer is bank switching. The address space is divided into 4K blocks that can be switched between ROM and RAM. Some of it, like Basic memory, is always RAM. But other parts, like kernal I/O or the Basic Interpreter are blocks of ROM that sit "on top" of RAM. When you try to read those addresses, the result is whichever bank (ROM or RAM) is currently switched in.

But a funny thing happens if you try to write to a bank that has ROM switched in: because you can't write to ROM, the RAM "underneath" it is written. Of course if you try to read back what you wrote, you'll get the ROM information unless you switch it out for the RAM.

Armed with those two bits of information, let's get to how this can be used to make a program that automatically runs when loaded. The program to auto-run is put in memory and a utility is executed to save the program to disk with a customized loading address and some extra code.

When the program is loaded, the loading address is way up high in memory, in RAM that is underneath the kernal ROM. First some utility and bootstrapping code is loaded, and then the code from the actual program is loaded after that. The load address is calculated so that the end of the program lands at address $FFFD, two addresses short of the end of memory. At this point there are four bytes left to load.

The first two go into locations $FFFE and $FFFF. These two addresses in memory are special: they're the interrupt vector. Every 1/60 of a second, the code pointed to by this vector is executed. Normally it's housekeeping stuff: flash the cursor, read the keyboard, things like that. These locations are written to point to the bootstrapping code that's been loaded. But nothing happens yet, because all this is being written into the RAM hiding under the ROM. The system is still reading the ROM and executing the standard interrupt.

So we just wrote the last two locations in memory, but we still have two bytes in the file that need to be written. Now what happens? What happens is the bug/exploit/flaw that makes this whole crazy thing work. Computer geeks know what happens when you have a register maxed out and add one more to it: it "wraps around" back to its minimum. And the same thing happens here. When the load routine tries to add one to $FFFF, it gets $0000. The last two bytes are loaded into the first two addresses in memory.

And the first to addresses in memory are also special: they control the bank switching. The last two bytes of the file are loaded into the bank switching registers and they swap out that high-memory ROM, revealing the RAM underneath where all the code was just loaded. And it also reveals the altered interrupt vector.

And within the next 1/60th of a second, the system checks the interrupt vector and runs the code at that location. Which is now... the bootstrap code. The bootstrap code copies some utility code into a safe location in RAM that's normally available and then copies the program into the location where it originally resided. After this, it jumps to the utility code. This code resets the bank switching back to normal (restoring kernal routines and the factory interrupt) and executes the program.

An automatic execution, thanks to the hijack of the interrupt vector. But that hijack wouldn't really be possible without that subtle flaw in the memory loading routine that lets a load wrap around from the top of memory to the bottom.

This is another development that trickled over into commercial programs. In the latter part of the Commodore 64's life cycle, it wasn't uncommon to find software that not only ran automatically after being loaded, but also loaded up a fast load routine for the disk drive.

---

Notice it was never said that the loaded code is erased out of the RAM under kernal ROM. It isn't. It's still sitting there, hidden away. Which has some interesting side effects. Once the auto-run program exits, the high ROM can be manually switched out and the program will immediately run again because the altered interrupt vector is exposed and the bootstrap code executes.

But it can be even crazier if the auto-run program happens to be written in Basic. It's possible to type NEW to clear out Basic memory, and verify the memory is clear with a LIST command. Nothing up my sleeve... manually switch out the high ROM... and not only does the Basic program immediately run, it's back in memory again! Resurrected from the dead? No, only copied back into Basic memory from the high RAM when the bootstrap code runs... but it's a startling effect!