One of the side effects of designing a tracker completely from scratch, using the best software design I can muster, is that everything is virtualized. A song is an object; the player engine is an object; the output device is an object. I’m probably going to make the editor an object itself, if just to keep the source consistent.  The nice thing about objects is that they can be abstracted and used as “parents” for descendant objects. So I have done just that for the internal speaker output. So that leads to some good news and bad news:

The good news is that the tracker will probably come with basic support for the Tandy/PCjr sound chip, and Adlib, and heck probably the CMS as well, out of the box, all in addition to the internal speaker.  This is because once the parent object is done, it’s easy to create a descendant for each output device.  And it will make it easier to add more complex internal speaker support in the future, such as mixing 3 or 4 voices realtime for “true” multichannel output from the speaker.  Just don’t expect the Adlib to sound better than the rest — I have a common denominator to target, and it ain’t 9-channel FM instruments.

The bad news about all this is that the tracker is still mostly in my head and not on paper. Which means I may only have a tracker to enter into the wild compo at Block Party instead of a demo. Or neither, considering that the presentation I’m giving takes precedence over compos :)

If I were never releasing the code, I could’ve hacked something together by this time already.  But I am, and I want people to be impressed by the code as much as music (democoder background, remember?  Both form and function are equally important :-)

I couldn’t save my old XT keyboard (enter key died, and that’s pretty much the #1 most important key on the damn thing) so it has been tossed into the spare parts bin. My remaining keyboard, however, survived my pokings and I have a functional XT keyboard again. My last, but beggars can’t be choosers.

Thanks to a functional keyboard, I started working on MONOTONE again, starting with the interface (the design docs are done — yes, design docs — hey, stop laughing!) except that I was immediately sidelined by my custom keyboard handler.

A keyboard handler, for the uninitiated, is a little routine that “replaces” the “hold-key-down-and-watch-it-repeat-after-a-short-delay” behavior with “hold-key-down-and-it-stays-down-without-beeping-incessantly” behavior. This is good behavior, if you want to make your keyboard act like a piano. But my trusted old handler code locked up the machine after the first keypress.

Here is the code in question, which I had been using since 1994:

Procedure New9handler; Interrupt;
Var
  b: Byte;
Begin
  port [$20] := $20; {send end-of-interrupt to PIC}
  b := port [$60];   {read scancode from keyboard}
  If b < 128
    Then kbd [b] := True
    Else kbd [b And 127] := False;
End;

On keyboard interrupt, grab a friggin’ character and stuff it in a bitmask array. Easy as pie. Yet the XT locked up, so I am clearly doing something that the XT is allergic to (or, more likely, forgetting to do something). So now I get to research early XT keyboards/signals and try to figure out what I’m doing wrong. Luckily, I have a lot of programming books to consult; here are the ones I’m going to take to bed:

• Compute’s Mapping the IBM PC and PCjr by Russ Davies
• The Undocumented PC by Frank Van Gilluwe (founder of V Communications — thanks for Sourcer, Frank!)
• Sam’s IBM PCjr Assembler Language by David C. Willen (why a PCjr-only book? Because eventually monotone will support PCjr — ssh, keep it a secret!)
• Compute’s Beginner’s Guide to Machine Language on the IBM PC and PCjr by Christopher D. Metcalf and Marc. B. Sugiyama
• Assembly Language Primer for the IBM PC & XT by Robert Lafore

Overkill, but I want to check them all so that I can get all the info on handling a keyboard interrupt and then pick out what I need.

I know all this seems stupid and unnecessary, and makes me seem like a freak, but honestly it is the reason over the years I have gravitated towards older and slower platforms to code for fun on. It’s the same reason people still code demos on the Commodore 64 and other legacy platforms: They are fixed in nature, which means you can truly discover the absolute fastest way to accomplish a particular task on them. It’s impossible to do this on a modern winbox, because winboxen are moving targets. It also explains perfectly why modern demos have evolved in the last decade the way they have, but that’s a topic for another day.

PS: The last book by Robert Lafore is the best book you can read to learn assembler on an IBM PC. It teaches you the basics by making you assemble, by hand, in DEBUG. It sounds incredibly scary and hardcore, but it’s actually very fun!

Just a quick note that I’ve rewritten the 8088 Corruption page substantially, posted a new video player, and posted all of the sample videos in my talk along with a few extra ones.

I appreciate all of the nice comments I’ve gotten regarding my lack of motivation (ie. possible depression); again, thanks.  I’m battling it now with a mixture of work, playing Worms with the kids, trying to speed up 8088flex even more, and a mystery fourth ingredient.  What could it be?  Why, it’s mysterious!  When I finish ingesting the fourth ingredient, I’ll post about it here.  It’s… immersing.