Oldskooler Ramblings

the unlikely child born of the home computer wars

Archive for March, 2008

It’s Alive

Posted by Trixter on March 25, 2008

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:

Posted in Programming, Vintage Computing | 15 Comments »

More Procrastination

Posted by Trixter on March 24, 2008

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.

Posted in Programming, Vintage Computing | Leave a Comment »


Posted by Trixter on March 21, 2008

After having a cold for 4 days and hacking up half a lung, I feel less like coding and more like procrastination.

So today, we have an experiment for y’all.

Posted in Vintage Computing | 2 Comments »

Progress… I think

Posted by Trixter on March 20, 2008

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.


Posted in Programming | 2 Comments »

Internal conflicts

Posted by Trixter on March 15, 2008

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.

Posted in Programming | 10 Comments »

I can see it in my head

Posted by Trixter on March 15, 2008

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.

Posted in Programming | 3 Comments »

Slowly, Come, Together

Posted by Trixter on March 4, 2008

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 :-/

Posted in Demoscene, Programming | 3 Comments »