Crushed under the weight of my own fun

I find myself, routinely, in the odd position of having so many fun things to work on that all I can do is sit motionless, trying to pick one. Most of the time I look forward to it; other times I feel confused or overwhelmed, watch TV for four hours, go to bed, then watch more TV in bed.

But still: Most of the time I look forward to it.

So, what is running around in Trixter’s head at any given time? What is the nerd nectar he drinks to keep him going? What electronic dreams keep him awake?

Here is a list of projects that I am working on. Some you already know about, some I have hinted about, and others I haven’t mentioned yet until now. Some have very close completion dates; others I am scheduling to start in 2009 and 2010. No, I’m not going to tell you which ones have which dates! You’ll just have to wait until I announce their start… or completion. (Hint: I’m not even sure when some will start.) And lest you think me a monster, I only work on these after the kids are in bed (and usually after the wife is in bed too).

MONOTONE V1. Most people know about this, but probably haven’t heard much about it since Block Party. I’m still working on finishing up my original milestones for the project, which were PC speaker and IBM PCjr/Tandy 1000 support, a serviceable interface, and an open architecture. Of all my projects, this one really is close to completion (mostly because I want to move on).

MONOTONE V2: Volume control, more device support, more effects, more capable file format. While I’m mostly happy with MONOTONE, the interface was the most irritating to program, especially since I was patently aware of how much wheel reinventing was going on. Since I’ve always wanted to give Turbo Vision a whirl, MONOTONE V2 will probably be converted over to Turbo Vision (if the memory requirements aren’t rediculous).

Halving my collection. I have too much hardware and software, period. I’m holding onto a lot of it needlessly, so I need to pick my priorities and sell/donate at least half of it. Some of the machines will be easy to give up: I have a few 1984-era Macs because I wanted to show my kids what the dawn of personal graphical computing looked like; they’ve seen them, so I don’t need them any more (the Macs, not the children).

Soundcard Museum. The aspect of personal computing that has fascinated me the most during the first decade of my hobby was the multitude of ways you could produce audio with a computer. While I’ve had my share of Apple IIgs and C64 gawking, the history of the IBM PC’s awkward attempts to produce audio holds a special place in my heart because there were so many different ways to do it. Some were flawed (CMS), some odd (msound), some ahead of their time (IBM Music Feature). So, I would like to open up a Soundcard Museum, with history, pictures, audio clips (recorded with a much better card than the one producing the audio, obviously!), programming information, example programs that can really show off what the card(s) can do, etc.

An oldskool PC demo. While there have been tens of thousands of demos released for the C64, Atari ST, Amiga, 386-era DOS, and Windows platforms, I can count the total number of 4.77MHz 8088/CGA demos ever released on one hand. I can count the total number of Tandy 1000 demos on one finger (hi Joe Snow!). There has never been an IBM PCjr demo. That’s where I come in.

Oldskool PC Profiler. I love DOSBox but am frustrated by how it isn’t anywhere close to being cycle-exact, for any CPU that ever supported DOS. I also love my fellow vintage computing community, but am frustrated by how they rely on benchmarks like Landmark CPU Speed and Norton SI to compare machines, which are just plain buggy and inaccurate. I feel it’s time for a utility that can serve two purposes: 1. Accurately determine what hardware a machine is made of (8086? NEC V30? 80386? etc.) and profile CPU, memory, and video adapter to come up with a metric, and 2. Provide a continuous display of how fast DOSBox is running by doing said benchmarks realtime and outputting what machine the reported metric is closest to. By running this utility on your classic machines, you can compare like machines to see how fast they are. By running this utility inside DOSBox, you can “dial” the speed of DOSBox up and down by hitting the emulator keys F11/F12 so you can FINALLY get DOSBox to closely match, a 386sx-16, or 486-33, or 80286-12.

Convert oldskool.org to a real content management system. I built oldskool.org in Zope almost a decade ago. I never quite liked python programming (not because python sucks, but because I suck) so I think it’s time I ditch my nice little code (it automatically builds the navigation tree, puts headers/footers on stuff, etc.) and commit to something like Plone.

Convert all my high-school era cassette tapes to CD. This is more than just every nostalgic adult’s hobby. I hit my darkest time as a human around my junior year of high school, where I was deeply depressed, contemplated suicide on a weekly basis, and attempted it once (which I somehow managed to hide from my parents — hope they don’t read this) I credit three things for keeping me alive during that time: Royally screwing up the dosage, gaming and programming on my AT&T PC 6300, and The Wave. I made many recordings of music I heard on my local Wave affiliate (106.7 here in Chicago until around 1990 when it got switched to Christian talk), and I really want to preserve them. (Plus, they had cute little station IDs, where the time was announced with a little sketch, which I’d like to make available.)

Finish at least one text adventure game. I have started at least 15, but the only one I’ve ever finished was Tass Times in Tonetown, and that was kind of a hybrid, and it took me 11 years (I got stuck from 1986 until 1997 — seriously). So I guess the real goal is Finish at least one Infocom game. Any suggestions?

Convert my rare videotapes to DVD. I have some rare tapes, like some Missing Persons concerts, Urgh! A Music War, The Best of Sex and Violence, and Gadget, that will probably never see release on DVD due to rights wars and lack of interest. I want to give these the full video noise-removal inverse-telecine enhancment treatment.

MindCandy 3. Well, you knew this had to be on the list somewhere. While I dearly love the work our team has done, and I love all of the admiration of fans, I simply don’t have the motivation to think about volume 3 right now. Hint: Cheaper technology will probably raise this motivation.

BLAZE. I have written what I believe to be the very fastest LZSS decompressor for 8086, utilizing all segment and offset registers and using 1-byte opcodes without any segment override prefixes. My decompressor is less complex than LZO and should significantly outperform it on 808x. I just need to write the compressor…  I call this system BLAZE, because I am pretentious to think that I have created the very fastest decompressor and the project should have a similarly pretentious name :-).

8088 Domination.  I have some more animation systems I’d like to pursue.  I have thought of a compression mechanism for the 8088 Corruption video system that guarantees realtime decompression (mainly because REP STOSW is faster than REP MOVSW, and REP nothing is fastest of all of course).  I would also like to adapt the concept of compiled sprites into compiled differential sprites (like Autodesk Animator FLICs but compiled) to see if graphical animation is possible at high speeds.

I think I’ll go watch some TV now.

Collecting and Programming

Just a quick note that Slashdot posted a main-page post about software collecting, one of my oldest hobbies.  I personally weighed in, of course.

For those not following MONOTONE, I released another alpha yesterday with Adlib support and more effects.  Still not finished, but it’s starting to become usable and interesting now :)

MONOTONE Party Release

It’s very basic, but it functions. Leech.

I’ll be working on MONOTONE very lightly until May, when I’ll dedicate more time to it. Why? Because I’m editing together the Block Party compo/awards footage for online release.

It’s Alive

I’ve finished what I consider to be a workable alpha of MONOTONE and am distributing it to a few testers. I hope they forgive me :-)

It is functional enough to compose tunes on, but the real work will be done at Block Party next week, hopefully in the demo room if we have enough space there. I’m bringing a PCjr and am hoping to add support to what will be the world’s first PCjr tracker. If you’re attending, please stop by and feel free to mock me :-) or just talk about hacking, programming, the demoscene, whatever. But no heckling me during my talk Saturday afternoon!

Video for the curious and bored:

More Procrastination

I have one major and two minor things to add to MONOTONE and then I simply can’t work on it any more before the party (I have to work on my presentation). So what do I do? More procrastination!

Today’s experiment is in HD; while the encoding didn’t work quite the way I wanted it to, you can still make out the text on the screen.  View it full-screen for your best chance at doing so.

Progress… I think

The good news: MONOTONE made some noise last night.  The bad news:  It was noise.

Now begins a complex series of compile-time debug DEFINEs so that I can try to get a handle on what is going on.  Step one is probably turning the 60Hz interrupt code into a single-step manual advance so that I can debug it.

The worst part?  50% of the notes were correct.  The rest were wrong.  And it wasn’t consistent.

Argh.

Internal conflicts

My work-in-progress tracker is my first object-oriented program. This has obvious advantages, such as making a fundamental change in the “abstract” portion of a chunk of the program, and having that change “inherited” by all of that chunk’s “descendants”. For example, I created a “screen” object with descendants for CGA, EGA, monochrome, VGA, and VESA. There was a bug in the cursor handling. I found it (turned out to be a bug in the ROM BIOS, if you can believe that), fixed it, and POOF all of the EGA/VGA/etc. objects now had the fix. From one change. Programming like this is somewhat intoxicating and it results in extremely readable and portable code.

On the other hand, OOP programming results in slower code. There are many C++ and Lisp/Smalltalk programmers out there who will defend to their grave this is not so, but they aren’t coding on a 5MHz machine like I am. (Yes, I am truly programming ON THE HARDWARE ITSELF, not cheating and using a fast PC to develop.) On such a slow machine, I can actually compare different techniques and can notice — sometimes visibly to the naked eye! — how OOP results in slower code than non-OOP. This is mostly due to the fact that nothing in an OOP program is “static” — it’s dynamic, which is best illustrated thusly:

Static program: I want data. I know exactly where the data is. I load the data. I process the data. I put the data back exactly where I found it.

Dynamic/OOP program: I want data. I don’t know where the data is, but I know someone who does. I ask them. They point me to another location. I go to that location. That location has a note saying “the data doesn’t live here any more; you can find them at their new location X.” I go to location X. There is my data! I load the data. I then want to process the data, but my engine was removed and replaced with a note saying “your engine was relocated over at Y.” I go to Y to pick up my engine. I fire up the engine and process my data. I travel back to X to put back my data.

Essentially, pointers no longer point to data or code, they point to other pointers. On fast machines, this double- and triple-pointer loading is no big deal. On an old slow machine where one byte takes 4 cycles to access (as opposed to today’s machines where EIGHT bytes can be accessed in ONE cycle, at clock cycles 800 TIMES faster than me), it adds up quickly. Real world example: My first attempt at repainting the pattern display was asking the song object for every single note in the pattern, then painting each one as I got it. It took two seconds to paint the display. So my optimization was to ask the song object to GIVE ME ONE ROW OF SONG DATA RIGHT NOW, DAMMIT and I process the entire row at once and paint the row. Now it repaints in about 1/10th of a second, which is doable for now. I am angering the OOP gods by doing this. I can hear their displeasure every time it rains.

The obvious tradeoff is flexibility. Let’s put my craptastic illustration skills to work again, this time explaining why OOP is a good thing: Let’s say I want to make something to eat. I have a recipe. I follow the recipe. I get a chocolate cake. I then wish to make apple pie. I change the word “chocolate” to “apple” in my recipe, then “cake” to “pie”. Here is what happens:

Static program: I get a chunk of food matter made of solid apples shaped like a cake and covered in chocolate frosting.

Dynamic/OOP program: I get an apple pie.

So where’s the internal conflict? My project is to create a music program that must be both flexible AND fast. Leaning toward the latter can completely screw up the advantages of the former.

My goal is to have actual music output before I go to bed tonight. Local time is 9:30pm. Better figure it out soon.

I can see it in my head

I ran across a wonderful quote the other day regarding programming. It almost perfectly describes what exactly I enjoy about programming and why:

Programming…is an act of creation. From a simple thought, and the arrangement of a few words and symbols, a reality is created that did not exist before.

No other activity can keep you in the moment the way that writing software can. At each step, one hundred percent of your concentration is applied to the solving of the current problem. Time disappears.

A well written program is a work of art. From conception to final presentation, the activity is that of an artist – the embodiment of a dream world expressed as an interactive experience for the user. — Peter Jennings

I can see MONOTONE in my head; how it works, how it sounds, and what it is like to use it. I hope I can finish it this weekend.

Slowly, Come, Together

In the last two weeks, I have achieved the following in my quest to finish MONOTONE before arriving at Block Party:

• Gotten the flu (took up three days right there)
• Wrote a completely customizable abstract input routine (complete with keyboard configuration utility — with tipsheet writer!) because some composers will throw a hissy fit if the basic interface isn’t exactly like ${FAVORITE_TRACKER}
• Wrote a keyboard interrupt handler (complete with human-readable labels so that “410Ah” reads like “Ctrl+LShift+Alt+F7″) because you never know when some hissy-fit composer will demand the use of Ctrl+LShift+Alt+F7
• Wrote instantaneous-fast (not an exaggeration) text routines, including multiple virtual screens that use hardware video pages where available

…and I haven’t sounded a single note yet. But you can actually watch the pieces slowly come together now, and it’s pretty damn fun writing from scratch what is essentially turning out to be a miniature operating system.

Next up: The main framework request handler/dispatcher and a finalized abstract Song object (and MONOTONE-specific descendant). Hopefully both tomorrow night, or I’ll have to stop development to work on my presentation :-/

How I Learned to Stop Worrying and Love the Project

One of the things that contributed significantly to MindCandy 2 being delayed for 18 months was self-inflicted implosion. I got so hung up in the project — worrying about what to do, how to do it, when to do it, who was waiting for it, what was affected by it, etc. — that I self-destructed and sought out anything that would help me avoid working on it.

Oh, I wanted to work on it. I love capturing video, especially from older computers doing their thing. I love processing it without touching the picture detail; I love compressing it to within an inch of its life without affecting picture quality. I love distributing it. And I especially loved the subject material. But left unchecked, my mind tends to enter a recursive death-spiral feedback loop during moments of stress and I just spin my mental wheels.

I started to get that hung up over my Block Party plans and obligations. Should I attend? If so, what should I bring? Should I give a talk? If so, on what? Should I bother with a compo entry? If so, what compo? Is it worth going if none of my very close friends will be there? If so, who will I talk to? What talks should I attend? Ahh! Aaaaaaahh!!

Five weeks ago, I was in #blockparty telling s_tec how much I enjoyed the invtro, and after a brief conversation, he innocently stated something that reminded me, after so many years, why I love the scene and all its related offshoots:

[14:49] <__Trixter> Almost makes me want to write a demo again :) but I'm not sure I will. I can't compete with the big boys and this hunk of junk is much slower than my imagination is
[14:50] <s_tec> So? Making demos isn't about winning, it's about making.

It is indeed. Thank you for the reminder; it was cathartic.

With my head cleared, I was able to sort out all of my thoughts, organize them, and get them down on paper (well, into a text file). I have a very clear direction on what I want to accomplish and how to accomplish it. Whether I get it done in time for Block Party ‘08 or not, I make daily progress. This is a good thing. The experience, like all fun programming, is not unlike relaxing in a trance-like state punctuated by occasional moments of pure exhilaration.

I am working on creating a nearly useless piece of software. Only a handful of people will ever use it. It serves no practical purpose. But it is mine, created with my bare hands, where nothing like it existed before in the hardware space it commands.

For the curious, here is the some insight into my madness: MONOTONE development notes