|
My brain is built of paths and slides and ladders and lasers and I have invited all of you to enter its pavilion. My brain, as you enter, will smell of tangerines and brand-new running shoes.
| Thursday, September 28, 2006 |
  Bug alert | 
Posted - 9/28/2006 1:13:58 AM | Interesting... apparently I can post to my journal and then delete the post, without leaving the #1 spot in the journal list.
I refuse to take responsibility for anyone exploiting this. No, this is not subtle reverse psychology to tempt you into trying it.
| |
| Tuesday, September 26, 2006 |
| Yarr. | |
Posted - 9/26/2006 2:35:40 AM | I had a weird experience this afternoon.
First of all, some context - my sleep schedule has gotten totally out of whack lately and I don't know why. So I was asleep this afternoon, pretty much from 1 PM to around 10:30 PM.
At one point, I woke up - not just the sort of idle "mmmmfh, Imwake, goway" sort of waking that normally happens in the middle of sleep. I was bolt-upright, adrenaline-surging awake. Not the kind of "holy shit that was the scariest dream ever" kind of awake, but a truly bizarre thing. A sort of "it all makes sense now" awake.
Apparently, in my sleep, I discovered the secrets to all life.
I lay back on my pillow (ok, sofa cushion) and pondered, grinning like a fool at the ceiling, heart pounding in excitement. Everything was crystalline. I understood - no mere comprehension or recognition, but true, deep, oneness. My mind was unified with all truth. I grokked everything as deeply as one may grok.
More importantly, though, I understood how to communicate this astounding truth. I knew, deeply and intuitively, precisely what to say to share my newfound enlightenment with all of mankind. I lay on the sofa, composing long strains of elegant prose, weaving words and making linguistic magic. Before I fell back asleep, I had written vast tracts of perfect words, an immaculate construction that would revolutionize the way people see our world.
When I woke up again, I couldn't remember a damn bit of it.
Worse yet, I can't remember what I ate just before I went to bed, so I can't even try and replicate it tomorrow. I suspect the tuna salad is to blame, but I can't be sure.
| |
| Saturday, September 23, 2006 |
| Batchin' It: Vol. 1 | |
Posted - 9/23/2006 2:48:28 AM | Batchin' It!
Life tips for stingy, lazy singles
Volume 1
Tip of the Day: Surviving With No Electric Mixer
If you're like me, you're lazy, tight-fisted, and tend to lack some "common" kitchen equipment. Today's item of choice is the electric mixer. Most people would survive sans-mixer by keeping a whisk or three handy.
However, we're targetted directly at the truly hardcore of the stingy and lazy: those noble few who have chosen to brave the myriad, rocky challenges of life without even a whisk.
If you're in this situation, and you find yourself in dire need of mixing something (say, some instant pudding mix), do not fear: there is a solution.
You will need: one fork, and one spoon.
The fork and spoon should sort of nest a bit - it doesn't need to be perfect, but you need to be able to smush the tines of the fork into the curved part of the spoon and leave only a small gap. The smallness of this gap will regulate how fine your mixture can get; if the gap is too large, you risk chunks and other such (potentially) undesirable artifacts.
The trick here is to hold the fork in your dominant hand, and the spoon in the other. Dip them both into the stuff to be mixed. Hold the spoon somewhat steady, and nest the fork up against it. Then, move the fork in small, controlled cirles, such that every time it finishes a circle, it ends up nested with the spoon. Practice this for a bit until you can move the fork very quickly.
Now, perform this procedure, and slowly move the spoon around the mixture; vary the depth and angle of the spoon/fork to ensure you catch any stray globules that may lurk in the bottom of the mixture.
With practice you should be able to mix this way at speeds comparable to electric mixers, and results comparable to those obtained with a good whisk.
Few can attain such mastery, however - not because it's all that hard to do, but because most people will wise up and just buy a damn whisk.
| |
| 32 whole bits of hotness | |
Posted - 9/23/2006 1:21:22 AM | The other day our very own Corman dropped me a link to a great deal from NEC on an eval kit for one of their 32-bit microcontrollers. It comes with a USB-based flash programmer, some emulation and debugging software, and of course the MCU itself - for a grand total of around $60. Quite a good bargain. Here's el linky for anyone in the market for good hardware.
I haven't had a chance to rig it up and play with it yet, since I'm making a valiant effort at drowning myself in work. But it looks really cool, which as we all know is the most important thing.
| |
| Thursday, September 21, 2006 |
| Tidbits | |
Posted - 9/21/2006 1:55:06 PM | The AMD/ATi merger is starting to produce some interesting stuff... most notably, AMD's new open coprocessor socket. This is a fantastic first step towards the kind of architecture I've been envisioning for the future; in fact, it's basically already there, just on a small scale. Picture this same tech with 16 swappable cores...
| |
| Tuesday, September 19, 2006 |
| Domain Specific Languages: Yea or Nay? | |
Posted - 9/19/2006 12:30:33 AM | Floyd Marinescu has posted a great summary of the debate over domain-specific languages. I find the points particularly interesting in light of some of my own rantings here - and moreso in light of personal experience.
I'm going to make some lofty promises: herein I will both espouse and bash Lisp, prove that guns and Unix have a lot in common, and make a few morbid Star Wars jokes. I will also present a solution to the DSL debate - and no, I'm not talking about cable modems.
Programming is a tricky and complex task. Developing software can, at certain professional levels, involve juggling literally hundreds of different concerns, often mutually exclusive. Satisfy the customer, satisfy the boss, satisfy investors, satisfy the shareholders, get it done on time, get it done on budget, get it done in the first place... make sure you don't write something so horrid that it ends up in the hall of shame, or the maintenance programmer ten years from now hunts you down and axe-murders you...
You know, the everyday, routine, this-would-be-mundane-if-it-wasn't-making-me-psychotic worries of the software world.
We have some powerful tools for mitigating these challenges: development methodologies, testing practices, design applications. They're all useful and have their benefits. However, there is one weapon which remains the single most important and effective tool in our toolbox: abstraction.
Abstraction is the lightsabre of programming. It is elegant, civilised, and glows in the dark. It offers precision, control, and reliability. It can sever our bonds and lend us freedom, strike down the evil foe, or even deflect the haphazard blaster fire of the enemy to protect the innocent. And, just when we think we can't stretch the analogy any further, we accidentally sneeze while twirling the blade around, and decapitate ourselves.
Unfortunately, abstraction shares a deadly trait with rm -rf and Glock handguns: like all the best tools, abstraction is dangerous if not used correctly. There are some safety mechanisms and simple practices we can employ to make sure we sever a minimum of precious limbs, but there's absolutely no way we can stop a determined moron from screwing something up. Even an innocent newbie can point the handle the wrong way and turn himself into a Padawan Shish-Kebab. That flowing you're feeling? Sorry, Luke, it ain't the Force.
Once we get past the imminent danger of parting with our digits, abstraction looks like it may have some upsides. It may even be worth the risk. So what does it actually look like? Abstraction takes three primary forms:
- Structural or algorithmic abstraction
- Semantic abstraction
- Linguistic abstraction
I'll cover each of these in turn. (Note that this is not necessarily a chronological or evolutionary progression; indeed the relationship is much more complex, as we will see later.)
Structural/Algorithmic Abstraction
This was one of the first great revolutions in programming. For modern programmers (myself included) it's still a bit of a brain-bender that this stuff was ever considered revolutionary - let alone a mere generation ago. But revolutionary it was, and it made a huge difference.
The difference came in the guise of structured programming. This was an early but vital form of abstraction. By grouping programs into common, similar blobs (conditionals, loops, routines) we can achieve an important result: elimination of duplication. This is a fundamental principle that will crop up in all forms of abstraction; they are deeply intertwingled, to borrow Nelson's charming adjective.
To us in the twenty-first century, the benefits are obvious: the common points (incrementing a loop counter, checking it, conditionally repeating; jumping into and returning from a subroutine; and so on) are hidden from us in a way that gives us plenty of control over the loop/routine/etc., without requiring us to duplicate (and potentially screw up) the common code. Boilerplate prolog and epilog instructions that once were a part of writing any function are now generated magically behind the scenes for us by the compiler; ditto for loops, exceptions, and a host of other things we now take for granted.
A natural corollary to this structured approach is algorithmic abstraction; in many ways, they are one and the same. Common routines like searching, sorting, and so on can now be hidden inside functions and subroutines. It's all still GOTO under the surface, sure, but the layer of abstraction allows us to safely rely on the mechanism working without caring about how it is implemented.
Semantic Abstraction
The separation of interface (how we talk to a chunk of code) and implementation (how the code gets stuff done) is a vital principle which also recurs quite heavily in discussions about abstraction. Once we have begun to divide our programs up into common, similar building blocks, we run into an interesting category of challenges.
Consider, for example, the idea of "sorting." Once we have a sorting routine written, an important (but deceptively boring) question arises: what, precisely, can this sort? In the beginning it may simply accept an array, and sort the array. Maybe it's an in-place sort that ensures we don't need to allocate additional memory.
However, this quickly becomes inadequate. Suppose we also have another chunk of data which is stored in a binary tree, which we also want to sort. Or perhaps it's a linked list, or whatever. Intuitively, the concept of "sorting" still can be applied - but our code itself can't work on non-arrays without being rewritten.
This leads us to an extremely important step: semantic abstraction. This is where we begin to separate ourselves from the concern of how the computer does things, and start focusing more on what can be done. This level of abstraction gives us notions like "containers" and "iterators".
We cannot ignore the breakthrough here: whereas structural abstraction lets us easily vary the routines that act on our data, semantic abstraction lets us take the next step and fully decouple the operations from the data representation. We can now speak of algorithms that operate without knowing anything about the representation (on a machine level) of the data they handle. Generic programming becomes possible.
A whole host of improvements appears on the horizon: we can write code once, maybe with one or two special cases, and not worry about replicating simple search/sort/parse/traverse algorithms each time we change the storage details of our data.
But there is a dark side: implementing this decoupling is not always easy. In fact, in many languages, it can be downright daunting. Don't believe me? Take a look at an implementation of the C++ standard library sometime; have a look at how generic iterators work. It's enough to melt your brain.
Linguistic Abstraction
Thankfully, that's not the end of the story. We have one final layer of abstraction available to us, which handily solves the difficulties of implementing semantic abstraction. Instead of building the abstraction in the language, and then using it from within the same language, we build a new language that automatically incorporates the abstraction.
Such higher-level languages have well-proven benefits. In much the same way that hiding stuff inside a "magic" for loop helped eliminate points of failure, linguistic abstraction lets us ensure that our programs all benefit uniformly from single abstractions. For a noteworthy case, see C++'s std::list and the reasons why you cannot use the std::sort algorithm on it. In a language where the notions of "container" and "sorting" were built into the language itself, that distinction could trivially be masked and programmers would never need worry about it.
But linguistic abstraction is more than just cramming a lot of libraries into a box and calling them "keywords" instead of "library functions" - it affects the very design and whole being of the language itself. Ruby is a beautifully elegant example of the potential available here.
The Section Where I Wish I Was Douglas Hofstadter
Once linguistic abstraction becomes available, we see a fascinating phenomenon: in a sort of fractally recursive way, programs still tend to exhibit patterns and idioms. Common sequences and arrangements of code continue to crop up. In this way, linguistic abstraction gives way to a new layer of structural abstraction.
It is not entirely clear how far this recursion may extend; while it is tempting to dream up worlds where single strings of nuanced prose could invoke immensely complex computer programs under the scenes - sort of HAL 9000 meets SQL - it is difficult to imagine practial benefits which could be generic enough to apply widely throughout the software field. While certain domains may achieve incredible feats of concision and expressivity in this manner, I personally feel it is not likely that we will see more than one or at most two additional iterations of this pattern in the foreseeable future.
There Where DSLs Come In, Finally
When considering DSLs, we must keep an important truth in mind: these are, by very definition, domain specific solutions. Therefore, by nature, they will tend to involve many subtleties and specific concerns of their host domain which may not be relevant in other domains. As a result, making blanket generalized statements about the practice of employing DSLs is difficult.
We need to consider three important points: the level of abstraction which we will have in the DSL itself, the level of abstraction at which the DSL is implemented, and the level of abstraction of any code which interacts with logic implemented in the DSL but is itself implemented elsewhere.
For a concrete example, consider a DSL that is particularly fresh in my mind: KC. At Egosoft, we use a custom bytecode-compiled language which is interpreted on the fly in a VM which runs alongside the game engine itself. High-level game logic is implemented almost exclusively in KC or yet another set of DSLs which are implemented themselves on top of KC. Performance-critical code is handled by C or C++ in the engine itself.
Aside from the fact that it's a purely homebrew solution, this is a very common tactic in the games world. It strikes a useful balance: we can use the benefits of abstraction to help get work done and ensure code reliability, while at the same time dropping down into lower-level languages when we absolutely have to worry about CPU cycles.
However, all is not perfect. In fact, this separation is a cause of daily annoyance and complication. There have been a few cases where our DSLs, in the valiant attempt to save us work by providing abstraction, have in fact cost tremendous amounts of time, effort, and pain. When wielded by someone who makes too many incorrect assumptions, the KC language is perilous - it is a powered-up lightsabre juggled by a clown with bad reflexes.
Worse, wielding it correctly isn't perfectly safe, either - even the most careful and conscientious users occasionally hack off a body part they'd rather have kept attached.
Where did things go wrong? How did we manage to create such a predicament?
The problem, as Obele effectively captured, is choice. More precisely, it's change.
In the years since KC was first deployed (about 7 now, if my probing in the source repository is accurate), things have changed radically. We once targetted machines that had paltry amounts of RAM, like 128MB. (I can't even find a cheap digital camera with so little storage anymore.) Today, we're moving towards a requirement of 1GB with a recommendation of 2GB. Then, we had a relatively simple set of tasks that needed to be done at a high level of abstraction (running an economic simulation divided into about 100 "sectors").
Today, KC handles several orders of magnitude more responsibility. It takes care of mapping keys to in-game actions. It handles menus, buttons, widgets, radar screens. It juggles a few 3D engine resources. In several places, the engine actually calls up to KC to do certain tasks (more on why that is evil in a second). KC was once designed to abstract away a fairly narrow set of problems - it was a domain-specific language for a limited domain. In the years since, it has exploded into a generic language, but it's outgrown itself. The result has been costly.
This is precisely the risk Obele warns about. While he rightly points out that changing understanding of requirements can lead to mutilation of a DSL, there is an even worse danger, which particularly plagues us in the gaming business: when the requirements themselves change. If the domain shifts, the DSL must shift with it, or fail.
Problem is, shifting a DSL is a painful job. You have to respecify the language, maybe even redesign it entirely. Compilers, runtimes, and libraries must be modified. Worst of all, you run the very real risk of invalidating a potentially huge body of existing code. This is exactly what we've run into with the KC language.
Signs of DSL Decay
Ideally speaking, a DSL should accomplish one thing: linguistic abstraction. It should give us a way to talk about a problem in terms that is specifically suited to the problem domain. I want to say "ship A attack ship B until B blows up" - I don't want to have to write some loop that polls B's state and moves A around in space while it shoots at B and... blah. Hell, I don't even want to explain the icky alternative to abstraction - it's that freakin' ugly.
When this works and is done well, it is beautiful and effective. Most of the time, though, things get worse.
There are some tell-tale signs that the linguistic abstraction has leaked, and that the DSL is in danger of becoming a liability - indeed, in all likelihood, it became a liability a long time ago:
- Transparency - when logic implemented in the DSL plainly is affected by the implementation of the language itself
- Inverted Responsibility - when logic implemented outside the DSL plainly relies on the implementation of logic in the DSL itself
- Martian Syndrome - when concepts from one language have absolutely no equivalent in another; usually, this occurs in conjuction with transparency, where the DSL relies on implementation-specific quirks in the lower levels, but can't actually understand how the implementation works
All of these plague KC. We see transparency all the time: KC logic directly allocates and manipulates assets in the 3D engine itself, rather than dealing with them as abstractions. This sort of "parallel towers" situation is a common problem with abstractions, even ones that don't involve DSLs. Abstraction should be built in horizontal, onion-peel layers in order to be effective.
We get inverted responsibility on a regular basis as well; low-level DirectInput logic calls up into the KC code for handling key mapping, menus, and a host of other functionality in the game. The result is extremely tight coupling between layers that should have been decoupled via abstraction.
Lastly, we suffer extensively from the Martian Syndrome. KC is a dynamic, loosely typed language. Cram something into an array, and you have no way to know what it is when you want to get it back out: string, integer, object... we have to resort to some hacks that actually talk directly to the VM in some cases to work around this. It's ugly.
Worse, KC runs in a VM that is deeply tied to the game engine. This precludes the use of debuggers and other common tools to help analyze runtime behavior and find bugs. Hunting down flaws in KC code is reminiscent of being dumped into a jungle with a dull machete and told to escape the hungry tigers: gets the heart rate going, but ultimately is too stressful to be much fun.
For the final blow, KC is half-object-oriented: you can define classes and even simple inheritance hierarchies. This is tremendously useful and has saved us a lot of time and work. However, KC has no way to ensure that you're getting the class you expect at compile time: everything is just object. As a result, the code itself often lacks vital expressivity; the code cannot reliably indicate the type of object expected, so we have to use extensive documentation. In a well-crafted abstraction, the code itself would describe clearly what the intended object types were - for instance, via static type annotations.
The Answer
Believe it or not, there's a way to solve all of this. (Get ready; smug-Lisp-weenie-isms ahead.)
It's very simple. Earlier I alluded to using onion-layer models of abstraction; instead of having entire "parallel towers" of abstraction that each describe part of the software solution, you build up layers on top of each other. Each layer is more abstract than the last, and is implemented entirely in terms of the layer below it.
This really saves our bacon. Transparency is no longer a concern, because you can set up the physical file architecture (depending on the language) to preclude layers talking to layers they shouldn't be. In some cases, if layer 3 needs to go all the way down to layer 0, it's OK; since every layer between 0 and 3 understands 0, chances are you can't do much damage by probing in such a manner. Contrast this with the towers approach, where sticking a pipe from one tower into the core of another causes all manner of hideous problems.
Secondly, it cures inverted responsibility. Layer 2 can't talk to layer 3 because layer 2 has no possible grammar or comprehension with which to muck around in layer 3. The only way they will interact is if 3 uses 2 in some way. This eliminates the possibility of foul play provided the layers each adhere to their interface contracts correctly.
Finally, it totally blows away Martian Syndrome. If layer 0 can access Data Representation Foo, so can every layer 1..n.
Now, we still haven't actually answered the DSL question: do we craft this digital onion from a single language, or do we build each layer out of a different DSL?
As I noted earlier, it is dangerous to make blanket assertions. However, there are some general guidelines which should apply safely to most situations. Be sure to think over them critically before running off to apply them to your current project - your case may well be one I haven't considered fully.
Here's what we need:
- A guarantee that higher layers won't muck around too much in lower layers. In languages like C++, this is essentially impossible. It is remarkably easy to do in Lisp, but Lisp kind of sucks for practical projects, and most people find all the parentheses scary. Point: DSLs, or Lisp if you're blessed.
- A guarantee that lower layers won't muck around at all in higher layers. This is also impossible in C++, Java, and so on. It's also not even all that easy in Lisp, which so far has been looking like a perfect candidate for solving all these problems. Sorry, Paul, but you lose this one. Point: DSLs.
- A guarantee that concepts available in lower layers can be made available to higher layers with minimal cost. This means that vital details and semantics existing in low layers must be transparent and easily understood by high layers when needed. Lisp totally blows here because it stops at a layer of abstraction too high above the hardware, and in many domains like games, that simply isn't acceptable. Worse, DSLs also suck here, because making semantics from, say, C++ available in your DSL requires a lot of work. Point: single language design, and not in Lisp.
This may look deceptively like we've failed to reach a conclusion. However, I've wasted all your time with this long-winded grunting based on a simple hook: DSL-vs-not-DSL is a false dilemma.
Or at least, it should be, in a theoretically ideal world.
Let us suppose the existence of some language, Foo. Foo lets us build onion-layer abstractions trivially, like Lisp. But Foo also lets us talk to hardware and operating systems directly and trivially, like C/C++. Foo fixes the Three Signs of Decay, as we've seen.
What about the problem of change? What if our requirements shift, as they are virtually guaranteed to do sooner or later? As it turns out, this isn't a problem either. DSLs are fragile because a radical requirements shift can require a total reimplementation of the DSL itself. However, Foo makes implementing our abstraction layers trivial - as trivial as writing subroutines or constructing classes.
Even better, our nested-onion model has a cool property: at each new onion layer, the power of code in that layer increases exponentially. Stated another way, the amount of code required to accomplish a task decreases, on average, logarithmically as we reach higher layers. This means that the net amount of code affected is going to be smaller. Even better, the cost of converting that code is minimal, because the cost of reimplementing the abstraction is in turn minimal. This cures the change issue. I don't have conclusive proof, but my gut says that this actually handles change more effectively than a monolithic single-language approach could.
As we've seen, Foo cures all the problems. We get the advantages of DSLs (namely, linguistic abstraction) without the costs and pitfalls. We avoid the change problem, which is (to my mind) the single most serious issue with DSLs in the real world. Best of all, we only have to learn one language, rather than one language per domain.
There's only one downside to all this: Foo doesn't exist.
Yet.
| |
| Monday, September 18, 2006 |
| Me is the not happy | |
Posted - 9/18/2006 6:14:04 PM | My box finally showed up today. Turns out there's also an Acworth in New Hampshire, of all places, and they decided to send it to that one instead of the one in Georgia. This is made only slightly less astounding when we consider that my ZIP code is of the form 3nnnn, and the counterpart in the north is 03nnn. Apparently, judging by the scribblings all over the shipping label, a digit got left out.
In the wonderful way computers do, something somewhere is treating ZIPs as integers, and not strings. Therefore, instead of immediately noticing a missing digit, checking the state, and doing a most-likely-target lookup of ZIP codes, the system (or some dumbass with a barcode scanner, but probably the system) decided that it was looking at a number - a number for which a leading zero is "optional." And thus things went pear-shaped.
I still don't understand why they didn't check the state code as a sanity check on the ZIP code, but that's package delivery for ya. If they were rocket scientists, they'd work in another business.
So anyways, my stuff finally shows up: a breadboard, some voltage regular ICs, and the RCA composite video jacks. Problem is, the breadboard's pin pitch is too large for the stuff I'm working with (which I figured from the beginning, but it was worth a shot). It also didn't include the pack of assorted precut wires which was advertised in the spec sheet. Worse, the voltage regulators only supply 0.1A - not the 1.0A I need to be able to draw.
And that's how I wasted two weeks waiting for a package full of stuff I can't use.
| |
| Hey, I'm psychotic! I mean psychic! | |
Posted - 9/18/2006 12:28:55 PM | Well, I have to say with some smug satisfaction that I saw this coming fifty miles off.
The next big step is for people to realize that stream processing, while good for certain classes of problems, totally sucks for others - namely, those for which out-of-order pipelined processors have become so advantageous. Then we'll see hybrid multi-core solutions and the whole SMP thing will give way to much more sensible approaches.
In any case, it's good that there is such early recognition for the software needs in this thing. Making the software side easier is what will drive the hardware advances ever further, and incidentally it's a perfect opportunity to overthrow some of the inferior tools that dominate the business today.
Good stuff.
| |
| Friday, September 15, 2006 |
| I have seen the future, and it is hot. | |
Posted - 9/15/2006 9:40:55 AM | Oh, man.
These are the most stomach-knotting moments in the game business: there's so much stuff I wish I could talk about, but can't. I want to just blather for a few hours and flap my arms around and make lots of excited noises... alas, this may not be.
In all seriousness... if we pull off even ten percent of some of the concepts we're kicking around right now, our next title is going to be the best fricken game ever. This is some awesome stuff.
OK, back to hopping around and giggling with glee.
| |
| Tuesday, September 12, 2006 |
| Crank the Wayback Dial to 11! | |
Posted - 9/12/2006 5:07:02 PM | Holy crap.
I first started coming to GDNet in the summer of 2001; I lurked, mostly, and spent most of my time reading articles. At that point I was rather active in another programming community (which has long since gone to crap) and for some stupid reason decided I didn't like the forums here.
It wasn't until April of 2002 (the 22nd, to be precise) that I made my first trip into forum-land as an actual user. (I vaguely recall surfing as an AP before then, but don't know for sure anymore.)
Now, astute readers will note that my join date is in fact July 17, not April 22. Somehow, I'd managed to forget the password to my other account (which is really stupid, because it's the same password I used for virtually everything in those days) and created a second account, which I've used ever since.
Except for once. One time, for no apparent reason, in September of 2002 - just over 4 years ago - I found my password again and made two posts. I just now tried that username and password again, and successfully logged in to my original account, for the first time in 4 years. That's almost half a decade of loneliness and neglect. A twenty-fifth of a century. A non-irrelevant and totally measurable fraction of an aeon.
So now, I present to you for your amusement and endless mockery, the original Apoch of GDNet. Lookit that skinny little bastard go.
| |
| Truck 54, where are you? | |
Posted - 9/12/2006 1:28:54 PM | So apparently UPS forgot where Atlanta is. I had a package (containing my precious electronics components) which originated on the West coast last Wednesday. It then proceeded to make a stop in Texas. So far, so good - Texas is reasonably on the way from the west coast to the east coast.
Then, the mysterious happened. The package decided it wanted to go to Massachusetts. After that, it figured New Jersey would be a fun stop, and went to hang out over there for a day or two.
It just now - just today - managed to get out of New Jersey, and as of a couple of hours ago is in transit again. Maybe this time it'll decide to visit scenic Illinois, or maybe take a jaunt over to Hawaii for some last bits of sun before the weather starts cooling down again.
Hell, at this rate, it may as well go on safari in Africa for a few months.
I'd call UPS and yell a bit about how they promised my package would arrive within 5 business days, but there's an outside chance that they might actually manage to get it from NJ to here in a day. It'd be the first time in history (they usually take 3 days to route around through all the facilities and finally put it on a truck) but it's possible.
In any case, though, complaining takes too much energy. And, after all, I only gave 'em five bucks. That's barely enough money to pay for someone screwing up your hamburger and giving you rat entrails in your fries; is it really fair to expect someone to bungle the procedure of carrying a small box a few thousand miles, for so little money?
| |
| Saturday, September 9, 2006 |
| Huh. | |
Posted - 9/9/2006 5:56:14 PM | So I was about to crack open an IBC root beer and settle down with a good book, when for whatever reason I idly skimmed the bottle cap. It advertises a 1-800 number you can call for "nutrition information." I figured I'd give them a ring and see what it's all about.
Unsurprisingly, the line picked up with a recording about how all the lazy people were gone for the weekend, under some grand delusion about being entitled to a life and time off of work. Once the whining got finished, I got dumped into what sounded like a typical automated menu: press 1 for frequently asked questions, or 9 if you have a medical emergency requiring immediate attention.
I had to hang up here, and go consult my doctor; however, he assured me that curiosity, no matter how burning, is not a serious condition and does not constitute an "emergency." So that ruled out pressing 9.
The 1 option, however, leaves a little bit to be desired: after about 5 seconds of silence, a nasty recorded voice stutters out "One... is not a valid option." And then the whole spiel about everyone tromping off for the weekend repeats.
So I still don't know what's in a bottle of IBC root beer, but at least I know that their phone system is broken.
It's the small things that give life it's unceasing wonderment and joy.
| |
| Friday, September 8, 2006 |
| Victory is mine! ... Sort of. | |
Posted - 9/8/2006 3:28:21 PM | Editor's note: due to the GDNet server being a $&*#ing asshole and dropping this post four damn times, it's quite a bit shorter than the original version. We'll return you to your regularly scheduled uber-long posts some other day. Yes, I feel stupid for losing it that many times and still not thinking to copy/paste it into Notepad before trying to submit it. Shut the hell up.
The ribbon connectors came today; they're a bit disappointing as the leads are barely longer than the ones on the ribbon itself. The only plus side is I can bend the pins around to isolate ones that I want to muck around with.
In double-checking the pinouts, I discovered that there are in fact two parallel pins which both provide the 8V supply to the inverter; I'd missed this before since they both return over the same ground pin. After connecting things up correctly, the panel is now powered and functional.
It's a bit of a hack job at the moment, but it works; the signal decoder and backlight are both operational, giving me a nice... solid black screen.
The real problem is, the composite video jack isn't due in until Monday. That means I have to suffer through an entire weekend knowing that I've got a working LCD, but with no way to actually display stuff on it.
So it has been a day of victory... but, alas, a Pyrrhic victory.
| |
| I'm ALIIIIIVE! | |
Posted - 9/8/2006 12:09:58 AM | Crank officially wins the award for Most Awesomest Title Screen Ever.
(The rest was pretty damn good, too. "What, do you think I have **** written on my forehead? *ding!*" Pure gold.)
| |
| Thursday, September 7, 2006 |
| Motivational Paradoxii! | |
Posted - 9/7/2006 8:54:35 AM | So in a bizarre twist of fate, I have all kinds of energy right now and feel like doing a lot of stuff that, previously, I just couldn't be arsed to do. This is odd; my initial prediction was that getting up at 7AM every day would make me a bitter, drained husk of a man with no desire to do anything but sleep and curse the children who play on my lawn (which does not, in fact, exist, due to my living in an apartment, etc.).
I have no idea how long this surge of motivation will last, so I'm capitalizing while I still can.
I tracked down my old 8-bit sound card, which happens to be in storage down in Florida. So until I manage to make a road trip that direction to retrieve it, I'll have to continue my plans for legacy gaming bliss via other means. I've got a couple of leads on potential candidates, though, so that's not a major setback.
The big sticking point right now is finding a hard drive. I was originally thinking of going for one that's smaller than 2GB (so DOS can recognize it) but now I'm pondering an alternate approach. I've got a spare hard drive from an Xbox that should work; if I partition it right, I can have several DOS drives plus a bootable Windows/Linux partition that I can use for heavy-duty stuff. For instance, a Linux install would let me easily take advantage of a network card for installing games and such via the LAN rather than floppy disk, which would be pure bliss.
I just have to get around to doing all of that.
The homebrew console is moving forward apace; the Molex ribbon connectors for the LCD should arrive tomorrow, and a voltage regulator IC on Monday. I've also got an RCA composite video jack on the way in the same bundle, so sometime early next week I should be able to get the panel powered up and receiving a video signal. That'll pass my first major milestone and let me move on to the really fun bit - playing with microcontrollers.
The other thing I need to do today is pick up another cheap-o 15" monitor. This will let me hook up all these headless machines I have floating around. Most importantly, it'll give me a way to finally look at Milton and figure out why it isn't responding to the network anymore.
Milton, you see, is the server that runs the Epoch web site. And once I get Milton fixed, I can ditch the POS wiki software that's on there and install MediaWiki, which means the Epoch project can finally get moving again.
I could get used to all this getting-stuff-done business.
| |
Page: 1 2 »»
All times are ET (US) |
In locus hic, omnes res dementes sunt.
|
| S | M | T | W | T | F | S | | | | | | | 2 | | | 5 | 6 | | | | 10 | 11 | | 13 | 14 | | 16 | 17 | | 19 | 20 | | 22 | | 24 | 25 | | 27 | | 29 | 30 | | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
