I've pushed out a new version of my NES emulator sources, flushing out the last six months of accumulated changes. It has been so long that quite honestly have no idea what most of the changes are versus the previous release, except that they don't improve emulation accuracy at all (in fact, I suspect it has been steadily regressing since release 2.

I intend for this to be the last release with an ambiguous license. Right now I am constrained by the terms of the M6502 code, which has some "no commercial use" clause in it, preventing me from applying my preferred MIT-style license. I began writing a replacement 6502 core with no strings attached, but that effort has taken a six month hiatus. Rewriting the CPU core will also get me one step closer to cycle-accuracy - close enough that if I were really serious about it, I'd have to rewrite the video... again. Bleh.

Here are a few changes I do remember:

• Keyboard input now works correctly when there's no joystick connected
• Stripe recording (see http://ahefner.livejournal.com/13165.html)
• "Screenshot movie mode" (toggled by Control-F12)
• FUSE filesystem support, disabled by default (see http://ahefner.livejournal.com/14789.html)

The source tarball lives here: http://vintage-digital.com/hefner/software/nes/nes-emu-4.tar.gz

Also, I've started including the git repository in its tarball, tripling its size. I think this is terribly inconsiderate, but I deleted the old git repository on the web server, so I feel like I have to back it up somewhere. I still don't understand these mixed messages from the git enthusiast crowd, where on the one hand they claim that pushing to a central repository isn't really done, but then go off and appear to use github for exactly that purpose. Whatever. They are strange people.

I've successfully downgraded my Debian machine from Squeeze (testing) to Lenny. I'd never really meant to upgrade to Squeeze in the first place, but my machine has been set to track testing for a while now. I was more than a little suspicious when it decided it wanted to download over a gigabyte of new packages, but I'm a fool and I was flailing around trying to get something working, so I figured "what the hell". Anyway, big mistake. I've been able to keep using the machine, but the domain resolver is on the fritz, sshd is seemingly in a coma, Firefox Iceweasel is crashing considerably more often than usual, and my printing (which I only got around to configuring two weeks ago) broke. I'm not bitter, but this is a little more bleeding edge than I'm interested in, so it was time to downshift into Debian stable.

Apparently people have downgraded systems from testing to stable using APT, but this sounded tricky. Just changing the sources list and doing dist-upgrade doesn't work, and apparently people who have done this have to pin a bunch of packages and somehow fool it into downgrading. Given that most of the info Google turns up on this is seven years old, I didn't want to risk it. Normally I'd just do another install into a spare partition, but having had such a smooth ride with Debian for so long (I ran the same install for something like five years, until finally moving on to 64-bit), this is the first Linux machine in years I didn't bother making such a partition on.

Instead, I installed Debian stable into a subdirectory (/lenny) using debootstrap, chrooted in to install packages, and prepped the /etc directory. Now I was ready to switch systems. I got the statically linked version of busybox and, while still in X11 with music, Firefox, and IRC going, did the following:

lightworks:/# mkdir sqeeze
lightworks:/# mv bin emul/ etc lib lib32 lib64 sbin usr var squeeze/
lightworks:/# cd lenny/
lightworks:/lenny# mv bin emul/ etc lib lib32 lib64 sbin usr var /      
lightworks:/lenny#

Now I'm running Debian stable. Everything is working just fire, except I had to restart firefox, and install some xfont packages for emacs. This is one of those rare instance where I'm genuinely pleased with my operating system. There's some loose ends to tie up, like configuring X11 (I'm still running the one from sqeeze; I'll fix it next time I quit X), and some miscellaneous packages to track down, but at this point I think I'll declare this stunt a success.

Every so often, I dust off the code for an NES emulator I wrote years ago and tinker with it. It isn't a particularly good emulator, but it can play Super Mario Brothers, and it's fun to hack on. I wrote it using SDL, and one issue I always had was the overall timing. The SDL documentation rightly warns that timers can't be relied upon for accurancy less than 10 milliseconds. An NTSC NES runs at 60 Hz, so we need to update the video every 16.67 ms. For whatever reason (portability foolishness, probably), I used the SDL timers anyway, with the result that it got rounded up and the machine effectively ran at 50 Hz. You can downsample from 100 Hz instead, but it's jittery, and jitter looks horrible with 2D scrolling. Tonight I'd intended to hack on the audio, and I just couldn't suffer listening to the music play that much slower, so I set out to fix it.

I really didn't want to spin and use 100% CPU, so my first attempt was to record the time before and after the frame processing using gettimeofday, then sleep for that interval using usleep. This didn't work any better than the SDL timers work, generally missing the scheduled wakeup time by six milliseconds or so every frame. The usleep manpage says "The sleep may be lengthened slightly by...", which seems like an understatement. nanosleep did no better. I mostly expected this.

Relenting, I changed it to spin in a loop, checking the time with gettimeofday until the scheduled 1/60th of a second elapsed. Predictably, this worked perfectly, but used 100% CPU. Here I had an idea - if I have to wait for, say, 15 ms, I ought to be able to sleep for a little bit (10 ms, perhaps) then wake up and just spin the last 5 ms or so until it's time to run the next frame. That way I can stay off the CPU for 2/3 of the time, and still meet my timing obligations. So, I added a conditional 10000 us usleep when the time between now and the next frame was greater than 10000 us. This left me missing my wakeup time again, generally by around 3 ms - I guess the sleep time gets rounded up sometimes. Experimenting with shorter sleep periods, I've found sleeping for 5000 us or 6000 us actually works really well. The CPU usage stays at 30-35%, and the timing is just as tight as if we'd spun 100% of the time. I don't understand precisely why this works as it does, but I'm happy with the result. Here's the code from my emulator which sleeps until it's time to run the next frame:

void sys_framesync (void)
{
    struct timeval tv;
    long long start = time_frame_start.tv_sec * 1000000 + time_frame_start.tv_usec;
    long long target = start  + (1000000 / 60);
    long long now;

    do {
        if (gettimeofday(&tv, 0)) return;
        now = tv.tv_sec * 1000000 + tv.tv_usec;
        if (target-now > 10000) usleep(5000);
    } while (now < target);
    
    // if (now-target) printf("framesync: off by %lli\n", now - target);
}

Funny me forgetting that Debian doesn't package xmms anymore. This is a shame, as I'm not aware of a superior alternative. As recently as a year or two ago, I was using packaged xmms and plugins, and everything was wonderful - there were plugins for all the oddball stuff, modules and half a dozen chiptune formats, and everything worked swimmingly. Lately, I'm stuck using half a dozen different players from the command line, usually through aoss, and some of them (such as adplay) stutter and spit unless the machine is otherwise completely idle (just clicking around in firefox is enough to glitch the audio, four cores or no).

Audacious - No, this one is a step backward. The file dialog (which I suppose is just the Gtk2 file dialog, tarted up with their obnoxious theme) is noticeably slower than the one you get in xmms (the old Gtk 1.2 file selector, which responds practically instantaneously under any reasonable circumstance), and the loss of the "Add selected files" button destroys the workflow - I'm not going to make ten round trips in and out of that dialog just to pick a handful of files in different directories. This program would be much more useful to me if this feature were restored.

xmms2 - Imagine my dismay when installing xmms2 didn't yield any UI except a command-line interface, and expected me to run a separate server process. A client/server music player? Thanks, but no thanks. Enough with the servers. Trying to be a good sport, I apt-got a graphical client, gxmms2, and attempted to play a song. Oops, "xmms2d" isn't running - why can't it start the goddamn thing itself? The UI is a bit clumsy, but I poked around and added an mp3 to the playlist, or so I thought. Upon hitting play, it instead played "/usr/share/xmms2/mind.in.a.box-lament_snippet.ogg" very loudly, a noise so horrible and unexpected that I slammed the "kill window" shortcut as fast as I could and hastened to torch the whole mess. This is probably a great system for people who enjoy configuring sendmail.

iTunes style players - These don't really compete - the style of use is different. I often run Quod Libet and xmms at the same time, but most music is played through xmms, for at least two reasons - first,  iTunes-alikes have large windows that deserve a whole desktop to themselves, whereas xmms is tiny and fits on whichever desktop I'm working without cluttering it, such that I use xmms just because it's closer. Second, having organized my music into a reasonable tree on the disk, I can find whatever I want just as quickly as you might using a fancy overengineered browser based on id3 tags, and without the headaches of bad or missing tags, multiple spellings of artists names (plus the mess of various artist + collaborator combinations), etc. Indeed, even in Quod Libet, I usually use the "Filesystem Browser" mode.

Although think Quod Libet is the most usable of the iTunes-style players, it's been a couple years since I last surveyed them and settled on it, and there are some very irritating things about the UI - that the volume and seek bars are hidden inside of little popup menus, or the height of the "queue" not being resizable (such that if you want to rearrange songs in the queue, you can only move them a few spaces at a time between scrolling, like some kind of goddamn bubble sort).

In fact, the whole reason I reached for xmms is because I'd been using Quod Libet on this machine to sort through some new music, but this particular instance of it frequently misbehaves such that I'd just prefer something simpler.

Search seems like a promising way to find files to play, but I haven't used a player that embraces this concept. I used the search in iTunes on occasion, but it was unnecessarily sluggish. Quod has a search feature too, but it's hidden in another tab with no obvious keyboard short cut, and is outrageously slow (many seconds to conduct a search). I never understood why this sort of thing should be anything less than instantaneous, even over many tens of thousands of files, so one day a couple years ago I quickly hacked together something in Lisp that used a Boyer-Moore search across the filenames and showed the matches interactively as you typed with a simple mcclim gui, and it didn't take more than a few hours of effort to get this fast enough to feel instantaneous, even running synchronously inside the text field's "value changed" event handler. So all the really fun stuff I imagined implementing, like doing the searching in a background thread, and pipelining the search to refine the results of previous searches as you continued to type (rather than searching the whole data set on every keystroke, as it currently does), turned out to be completely unnecessary! So you'd type, and as you did the matches would appear in a list below the search line, and you could click one to play it in xmms. Very simple. I used this on and off for a few weeks, and had some ambitions of turning it into a genuinely useful music player, but never got around to it due to short attention span and various mcclim issues which I am unable or unwilling to fix, such as the focus insanity and difficulty in establishling workable keyboard controls. I think I'll just wait until I have a better substrate for the UI. A fuller implementation would have to do several times as much work due to searching metadata in addition to filenames, but several times a small number might still be a fairly small number, so no problem.  Anyway, with Lisp's reputation for being slow (or within the Lisp community, mcclim's reputation for being slow ;), maybe the authors of the more ambitious music players can be shamed into improving their search and making it fast.

And now I'm off to compile xmms and see how many of the plugins I can 1) locate and 2) succeed in compiling.

The irritating 1/2 second delay between when xterm appears and bash printing its prompt? That's the time spent executing /etc/bash_completion, for a feature I don't want anyway. Easily fixed!

Another little land-mine that linux planted for me to discover is that upon installing this Debian system with Linux 2.6.26, my vfat filesystem (a USB key) has suddenly become case sensitive in ways that no combination of mount options seems to fix. Granted, I'll probably go to hell for depending on it to work in the first place, but for the moment it means that I've spent 45 minutes trying to do a CVS update from the key (which probably wouldn't be an issue in the first place, if it hadn't already changed the case of my filenames in unpredictable ways, which - regardless of whether it's imitating Windows conventions or not - is obnoxiously sleazy). Indeed, playing with the mount options in seemingly innocuous ways, such as setting check=normal, which should be the default anyway, breaks in entertaining ways - such as being able to create files which you can't delete on account of the schizophrenic case normalization.

I hates it!

Incidentally, this sort of ranting and raving is precisely the reason I was reluctant to create a blog for a number of years. Well, screw it. I need to vent.

After losing an argument with Gnome's network-manager last week, I found myself faced with the prospect of attempting to repair my deteriorating Ubuntu 8 install, or reinstalling Linux. I'd grumbled for months about reverting to Ubuntu 7 (mostly on account of Firefox 3, which gets into fits where it refuses to run until I restart X), so either I'd reinstall that, or follow through on my threat (to no one in particular) to switch it to Debian (which I strongly prefer, but anticipated some extra effort getting everything working - the machine is a laptop, so the bar for everything having to work Just So is already considerably higher). I elected to go with Debian this time around, and additionally tackle the chore of stripping it of the Gnome nonsense.

First, a few words about desktops environments. I've never met one I liked. They clutter the screen, and their branded applications are usually lame and redundant. The few genuinely useful bits garner resentment for threatening to lock me into using their pet window manager, panel, file manager, etc. I don't think it's a simple matter of not yet having found the right desktop environment to suit me, either. Instead I suspect they are not unlike political parties, diverting energy into self-aggrandizement with priority over their essential duties.

Specifically, with respect to Gnome, I don't like Metacity, and I really don't like the panels. I've tried to configure Metacity to my liking, and even gotten close enough to live with, but it's always felt off - clumsy, claustrophobic, maybe even a little slow. Granted, the claustrophobia might just be the gaping maw of the two Gnome panels, threatening to crush my windows which linger perilously between them.

The default two-panel setup loses on a number of fronts:

• Horizontal window-selector of the bottom taskbar can't devote enough width to each button to read the labels unless there's so few windows open that you don't need help managing them (implicit in this is that I'm not concerned with hidden/minimized windows, but if you can't read the labels, the taskbar is not the ideal mechanism to help you locate a minimized window anyway).
• Pagers are a pointless gimmick - you have to change desktops from a hotkey rather than clicking around the pager, or they become too cumbersome to be worthwhile, and a tiny rectangle inside the pager doesn't help in identifying which desktop I want anyway.
• The top panel bar is mostly empty space, and the only really indispensible bits are a couple of the tray icons.
• The vertical dimension is (within reason) more valuable than the horizontal, and neither of these panels provide utility in proportion to the space they occupy.

Of course many of these complaints are addressible via the numerous configuration options, but I dismiss that line of argument out of hand - wrestling with configuration options costs time, and that time is at least as productively (and certainly more satisfyingly) spent replacing the offending software. The default configuration is so thoughtlessly awful that there's little question as to whether seeking alternatives is justified. (Another interpretation is that I'm too lazy to learn new keyboard shortcuts and will fabricate any rationalization while clinging desperately to a Sawfish configuration I've used since 2002, but I'll assume for the moment that isn't entirely true.)

That's more rant than I intended, but there's really just the two problems to solve:

1. Where to put the init scripts, so that I can start everything up automatically - I noticed some time ago that my .xinitrc didn't seem to work as I remember, I guess due to GDM, but it isn't an issue on my desktop because it only reboots every few months, so I've never taken the time to automate things. My laptop power cycles much more frequently, so this isn't acceptable.
2. How to use network manager without running the Gnome panel.

This turned out to not be terribly difficult. As for #1, using the "Run Xclient script" session does the trick, provided I have a .xsession file. I don't know what the correct relationship between .xinitrc, .xsession, .Xclients is, but in the course of flailing around I ended up symlinking them all together. Whatever. It works.

For #2, I discovered here that we need a system tray, and to run nm-applet. A program called Trayer does the job admirably, although it's a little fussy:

• It seems like the command line arguments have to be in a certain order if enabling transparency.
• I don't know what the underlying X11 magic is, but the transparency only works when you set your root window image with certain programs. Esetroot works here.
• Certain gtk2 themes break transparency (you'll see a gray panel with correct transparency old under the applet icons).

Having gained a system tray, we can run nm-applet and gnome-power-manager, which get us the two essential applets for a laptop (wireless control and battery). Trayer has lots of fun knobs and dials to turn, and I set mine up running vertically along the left edge of the screen, with the ability to place windows over it if I like. I'll probably change my mind and move it to the right side.

I also found a nifty program called yeahconsole which provides a togglable xterm as a quake-style console. I'm trying it out with hopes that it could help combat the proliferation of abandoned xterms strewn across desktops.

In the end there wasn't much to it (the hardest part was getting GDM to run my damned script!), and I seem to have all I need for laptop use. There's quite a bit more in the standard gnome desktop that I don't have running (volume manager, software update applet, file manager), most of which won't be missed.

Here's the final .xsession / .xinitrc / .Xclients / whatever:

#!/bin/sh

Esetroot ~/morning-clouds.jpg
xset b off
xmodmap ~/.xmodmap-conjugate
trayer --edge left --SetDockType true --tint 0x0 --transparent true --alpha 180 &
nm-applet &
gnome-power-manager&
yeahconsole&

exec sawfish

And the obligatory screenshot:

I've just discovered the Linux Hater's Blog. I love it. It gives me enormous peace of mind to know that someone is already out there complaining not only about all the same stuff that drives me up the wall, but also various topics I think I hate but can't be troubled to confirm (Fedora, KDE), and all kinds of exciting new stuff I never realized I need to be pissed off about (PulseAudio? What the fuck is PulseAudio?). Linux Hater puts the fun back into Linux.

Why does it take so long to resize a window using OpenGL with NVIDIA's linux drivers? It's always been sluggish, but with the current drivers it's out of hand. Freezes X for a second or more whenever a window is mapped, unmapped, or resized. Annoying as hell.