netbooting Ubuntu, a cautionary tale of NFS3 and tcp_wrappers...

One of the things I like to have available on my LAN is a decent live Linux system that I can network boot into.  It's incredibly handy for those occasions when you need to do something to, or with, an installed system that requires it not to be running.

This little tale starts a few days ago when I wanted to upgrade my Fedora 13 box to Fedora 14.  No big deal, but I keep a copy of the old root filesystem on a separate partition in case of problems, said copy typically being made (e.g. with dd, and filesystem UUIDs, etc. adjusted as necessary) from a live Ubuntu.  Why Ubuntu?  Because it's really easy to network boot it, competent/complete enough for every issue I've needed it to fix so far... and sometimes it's just nice to see how 'the other side' does things.

So, anyway: my backup in preparation for my Fedora 14 upgrade.  I told my box to boot from the network, selected Ubuntu 10.04.1 from the menu and watched the kernel/initrd load as normal, but then something I'd not seen before happened.  Immediately after mounting the root filesystem, and instead of the normal live Ubuntu startup messages, there was just a string of short read: 24 < 28 messages dumped to the console, one per second.  After a while it just gave up and complained that it could find no usable root filesystem.  Same story for all the other live Ubuntus I had handy.

Uh-oh.  Thing is, this used to work just fine.  And, of course, I hadn't changed anything.  Now, nobody has ever changed anything, right?  Of course I had changed something, but I'm getting ahead of myself.

A quick google turned up something interesting about the order of the kernel arguments mattering (it shouldn't) and leading to that peculiar short read: 24 < 28 message.  "Funny," I thought, "It never mattered before...  And I don't remember changing them in the PXE menu config. wotnot either."  Nonetheless, I fiddled with them and got precisely nowhere.  Something was causing that NFS mount to bork, and I had no idea what.

So it was time for a different approach, and perhaps to get some more idea of what's going wrong...  in the pursuit of which I tried mounting the NFS export on my box, which failed.  Specifically it failed with an error message that left me even more puzzled: mount.nfs: Argument list too long.  "WTF?!" I said, nonplussed.  Naturally, I tried googling that and got pretty much nowhere.  It's not exactly a 'normal' error to get from a simple mount command and, come to think of it, it's not an error I've seen in a long time -- typically it's caused by insanely successful wildcard matches in shell commands, etc., not by mount 192.168.3.154:/export/netboot/ubuntu-10.04.1-i386 /mnt/tmp.

By that point I was scratching my head and thinking "This used to work.  Clearly something has changed.  Something unexpected, perhaps.  Now...  What have I changed since I last definitely had this working?"

And then it hit me:  My network had changed since I last knew for sure that it was working.  Specifically, I added an extra router to provide wifi for guests, etc.  There's more to the why than that, but that's a long, miserable, story in its own right, starring a Netgear D843G router as the villain eventually exposed by an plucky young Android phone and a single remote wget command.  Anyway, the relevant part is that I now have an extra router/AP that thinks my LAN is the internet.  It has a LAN of its own, of course, and that's actually a good thing since it means I can very effectively keep 'guest' wifi use under control.  There's a difference between "Sure, use my wifi." and "Sure, use my wifi... and maybe rummage around on my fileserver as well." after all.

With that in mind, I'd added some rules to my hosts.allow and hosts.deny to explicitly allow NFS 3 access from my regular LAN but not from the 'guest' LAN.  Shouldn't be relevant, right?  Oh, but it was...  and not just because I'd botched it.

Here's the thing:  there's a few ways you can specify a range of IP addresses.  192.168.3.0/24 means the same as 192.168.3.0/255.255.255.0 means the same as 192.168.3. and I'd gone with the /24 version in my config.  Error number one, right there:  tcp_wrappers is old.  Old and unloved.  It does understand that form of netmask, but only for IPv6 addresses... and only just.

"Hooray!" I cried, having found the problem.  But would you care to guess what happened when I corrected my netmasks by changing them to the 255.255.255.0 format?  That's right: nothing changed.  Still that short read: 24 < 28.

That's just not fair, really, is it.  I mean, sure that config cockup shouldn't have caused those problems, but it was what had changed since the thing last worked properly...  and, well, "Bother," said Pooh.

For the sake of testing, I threw an ALL : ALL rule into my hosts.allow and...  suddenly...  everything was working as it should.  Live Ubuntu, mounting from a normal box:  no problems at all.  Aaaaargh.  So it was tcp_wrappers that was causing the problem!  But... WTF?  That's when I decided to try the 'trailing dot' method of specifying the network...  and...  that worked.

So, to recap:

192.168.3.0/24 -- bad.  That style of netmask is only for IPv6.  Oops, my mistake there.

192.168.3.0/255.255.255.0 -- bad.  No idea what tcp_wrapper's problem is with that.  Smells of bug to me.

192.168.3. -- good.

Oh, for completeness' sake, tcp_wrappers also allows the use of asterisks as wildcards in some circumstances and I could potentially have tried 192.168.3.* but since it was now working and I had things to do, I didn't get around to trying that.

So, long-story-short version:  for some reason a perfectly normal and valid netmask in hosts.allow was causing NFS to throw wobblies leading to that peculiar short read: 24 < 28 message and the equally confusing mount.nfs: Argument list too long.  Who'dathunkit.

But do you want to know what the real kicker was in all of this?  Sure you do, if you've read this far.  And it's a real facepalm worthy one too...

The kicker is that the whole thing was an exercise in Forgetting Something Important:  That extra router/AP is doing NAT, so everything 'behind' it appears to come from it... and it's part of my regular LAN.  In other words: there's no bloody point in trying to restrict access to the 'guest' IP addresses, what I actually need is to restrict access from the 'guest' router's IP address.

Wait, it gets worse.

All this tcp_wrappers malarky is only relevant to NFS3... and the only things I export via NFS3 are my local package repositories and the necessary stuff to network boot things - all read only, and none of it even vaguely in need of protecting from accidental guest access.  All the 'real' stuff is exported via Samba and NFS4.  For what it's worth, Samba is easy enough to lock down sufficiently, and I've already done so.  NFS4 is slightly more fun, and doesn't use tcp_wrappers at all, but a couple of simple firewall rules suffice.

Anyway, given the dearth of relevant google hits when searching for the two specific error messages I was seeing, I figured it might be worth sharing the story.

For the love of eye-candy

Compiz-fusion is lovely, it really is... spinny cube, sproingy windows, neat effects - and even some stuff that's genuinely useful when it comes to organising today's clutter of windows. In short, I like it and find it just useful enough that I'd really hate to have to do without it.

Of course, since this is a Really Cool Thing that I really like, there are some problems. And, of course, these are problems that nobody else in the whole wide world seems to have suffered from, at least as far as google can see (and I've searched and searched and searched...).

I'm actually fairly used to not finding stuff with google - generally when I have a funky problem all I can find is forum posts by other people with the same problem, and maybe something in a language I don't understand that looks like it might be relevant, but isn't.

What makes my compiz woes so much more interesting is that for once I can't even find other people with the same problems. Sure, I can find a few people with problems that look a bit similar at first glance but turn out to be quite different, and I've read plenty of those pages just in case their problems actually turned out not to be that different after all. No joy.

It's not even one thing, either. There are three major problems I had with compiz, of which one is solved, one is mostly worked around, and one continues to baffle and frustrate me. Since I had such a bad time of searching for help on these problems, I figured it was probably worth writing them up a bit. Maybe I'm not so alone after all and somebody will descend from heaven to tell me how to fix them properly. Or maybe what I've discovered will help somebody else in the same position that I was.

Just to add to the fun, I'm unable to reproduce these problems on other boxen locally, even with cloned configuration. And, speaking of configuration, the problems exist for a completely 'clean' user also, so it's not some hairy old piece of config lying around in my setup. But, of course, only on my box.

Anyway... First of all, some background info: I'm using x86 Fedora 8, which has compiz-fusion 0.6. My boxen are all AMD/Nvidia based. The specific box that has the trouble is an Athlon64 X2 5200 with 2GB of RAM and an 8600GTS card (I'm using the x86 architecture to keep things homogeneous here). My desktop environment of choice is KDE (3.5.8), but again that seems to be irrelevant - the 'clean' user has the Fedora default of GNOME.

"Problem 1, if you were an ice-cream, what flavour would you be?"
"Choc-chip, so I could get smeared all over you and leave big splotchy marks."

Problem number 1 is the solved one - a simple change to my xorg.conf file sorted this one out, but I'm getting ahead of myself.

Shortly before I started using compiz in earnest, I discovered VirtualBox and was happily using it to host various OSes for testing/compatibility/whatever. With compiz on the scene, it all started going a bit wrong... whenever the VB window resized there was heavy screen corruption around it. Occasionally the whole X server would crash. Not good, in other words. Smacks of driver/X bug, or similar. It's also worth noting that this problem isn't actually a compiz problem - the exact same thing happens with KDE's compositing manager - it's just that compiz is probably the most common compositing manager out there, and the one I had the problem with.

As it happens, as part of troubleshooting problem 2, I'd made some changes to my xorg.conf file as recommended in one of those 'not quite the same problem' forum topics. The specific change that lead to the problem seems to have been enabling backing store, thus:

Option "BackingStore" "True"

(Incidentally, that didn't make any difference to the problem). Removing that line from the xorg.conf file sorted out the corruption, and now VirtualBox is running just fine again. Yay.

"Problem 2, what would you be doing while you waited for me to get ready to go out?"
"I'd be looking at pictures of old flames."

Problem 2 is my "mostly worked around" one, for those keeping score at home.

I use the 'Animations' plugin in order to have the beam effect for minimised/restored windows, and the burn effect for closed ones. Oh, and some zooming for newly opened windows. All in all, it makes for a visually cool desktop that somehow feels a little more 'tactile' than one where windows just appear/disappear 'whole'. It gives the windows some sort of 'life', elevating them above being mere rectangular regions of a rectangular screen. And, naturally, I'm not willing to do without it. If my windows don't burn when I close them, they might as well not do anything.

So, what's the problem? Well, if I leave my box idle for any significant length of time, for instance overnight (or overday, I suppose - I tend to being nocturnal) then the next animation to be displayed gets jammed for several seconds. The length of the 'jam' seems to be proportional to the period of inactivity, and until it sorts itself out the entire X session is wedged. The effect is noticeable after even an hour or two of inactivity, but really comes into its own after a night/day or so.

What happens is that the effect begins to play, then freezes. So, if I close a window then the fire effect will render its first frame and then everything comes to a complete standstill. The same happens with the other effects provided by the Animations plugin, but not for ones provided by other plugins. My wobby windows are fine, my cube rotates, etc., etc. But that first 'animation' effect gets stuck, with 100% CPU load.

The box is still running fine while this is happening - I can ssh in to it just fine, for instance. I can't switch to a VC though - X handles that, and X is frozen until the effect finally deigns to finish playing several seconds later.

So, what's my workaround? Well, since the Animations plugin is the only one affected, and since I'm hardly likely to miss it when the machine is sitting there with the monitor off, I knocked up a little script that watches for the monitor being turned off by DPMS and disables the Animations plugin. When the monitor is turned back on, the script (re-)enables the plugin. Overall effect: problem solved as long as DPMS corresponds to idle time, which it pretty much does.

The script (and a little more info) can be found here.

"Problem 3, sometimes I feel like my clique is out of control. What alternative could you provide?"
"None. And I'd be sure to get you out of those shift dresses, too."

Ah yes, problem 3. My current Nemesis. The Unsolved One. The great Dunno. Etc.

I make heavy use of VNC: my 'media player' box runs Amarok in a VNC session, my IRC client is also running on that box and accessed via VNC. VNC is great - it's screen for X servers, and what's not awesome about that? Nothing, that's what. Sadly, VNC becomes a good deal less useful if you can't actually use it properly, say if certain mouse-clicks or key presses didn't work. And that's what's happening to me.

Specifically, I can't use the Control, Shift or Alt keys in combination with the mouse buttons. They just get ignored completely and the click happens as though I wasn't pressing any keys at all. Naturally, this makes it rather hard to do various things that require shift/ctrl/alt-clicking/dragging something - and there's actually quite a lot of things like that, as becomes abundantly clear when your ability to do them goes away.

My VNC client of choice is the standard RealVNC vncviewer as installed from the Fedora repos. Before compiz all was well, but now no modifiers. Naturally, I've tried some other VNC clients with mixed results. TightVNC has the same problem, but a really old tightVNC client I have lying around for some reason doesn't. Vinagre doesn't have the problem, either, but it's not really useful for how I use VNC.

So currently I'm stuck using an old tightVNC whenever I think I'm going to want to shift/ctrl/alt-click /drag anything, which sucks.

Try as I might, I can't get the other F8 box here to behave like this - it just works there.

Gah.

Best. Straw Man. Evar.

Last night I watched a fascinating video on YouTube: 10 answers that every intelligent Christian must have. This video is a response to some other guy's video (10 questions that every intelligent Christian must answer) and far surpasses it in sheer pseudo-logical douchebaggery. But still I watched, and watched with a smile on my face, because I deeply enjoy well crafted irony.

This guy is awesome... he starts out by claiming that the 10Qs video is nothing but a set of straw man arguments, something which I suspect either makes perfect sense or not depending on whether you actually believe in God or not. But that's not what amused me. What amused me was the example of a straw man argument that he crafts in order to explain what one is. Brace yourself, it's a killer: If I can grab a box of crackers, you have no parents. Really. That, by the way, is a specific 'straw man' attack on the proposition that you have parents.

Best. Staw man. Evar.

How better to start an argument than by creating a straw man of a straw man, then tearing it down to show just how egregious straw men are! That loud clang was a huge lump of irony hitting the floor :-)

The rest of his arguments are every bit as bad, by the way. To be fair, he does at least attempt to answer the 10 questions, albeit with such impeccably douchelike logic that "attempt" is probably the best way to describe it.

On the bright side, I do now have a new phrase: crackerbox-grabbing insane.

Today I learnt...

Been caught out in a deception? Or maybe you've had your woeful ignorance of some topic brought to light... Well, never fear, with just four simple words you can in all honesty contradict your accuser even if they're actually right!

Repeat after me: "I would say that..."

That magic little caveat can be used to prefix whatever you like, and best of all it makes the whole statement not only true but self evidently true.

Here's a fine example: A Conversation with Expelled's Associate Producer Mark Mathis

It seems to me that the words "I would say that" have an unspoken implication - a parenthetical "because otherwise I'd have to admit to being wrong, a pillock, or both"

But then, I would say that, wouldn't I?

Marketing... "Not really... the power of suggestion!"

Excuse me while I blither a little... Having failed to get a good night's sleep yet again, I find myself sat in front of my keyboard and bored waiting for the missus to wake up. Hmm... let's see, Brain not quite engaged? Check. Bored, but with nothing much to say? Check. Internet? Check. OK, must be blog time.

I had a rather nice bagel for breakfast. It was a healthy bagel too, with "less calories than 2 slices of bread*". I have a couple of gripes with that claim, actually.

Let's start with the word "less". Why do people use "less" and "fewer" as though they are the same? It really, really grates on me when the wrong one crops up in a sentence (or, more likely, an advert). Is it really that hard to grok that "less" is appropriate for continuous values whereas "fewer" is appropriate for discrete values? Nobody would say "There was fewer water in the bathtub due to the leak.", so why do they not feel the same dissonance over something like "I had less ten pound notes than I expected." ? Is it because people are thinking of the money instead of the notes? But then again, "calories" is a continuous value... is the problem here actually that common usage typically refers to whole numbers of kcals, thus rendering calories discrete? Is it that we're referring to "calories" the unit (which is basically the same thing).

Bah.

I don't really care - "fewer calories", "less bagel". Hmm... Actually, there's a much better example: "less bagel for the money" vs. "fewer bagels for the money".

Where was I? Oh yes, bagels. With "fewer calories than 2 slices of bread*". Hmm, let's check that * out, shall we... Ah, here we go: two 60g slices of thick white bread. So that's 120g of bottom-end-of-the-scale bread. OK, I can believe that - especially since the bagel itself only weighs 95g. I guess that marketing didn't think that "Less food than two slices of bread*", or "More calories by weight than 2 slices of bread*" would get the package off the shelf and into your basket. And why stop there? "Fewer calories than a bucket of lard*!"

Actually, the claim has more to do with the subjective nature of the whole food/calorie thing. The point, apparently, is that a single bagel is as satisfying, if not more so, than two slices of bread* due to the more chewy texture... and all with fewer calories.

That's one of the things I hate about advertising, actually - it's manipulative. It doesn't matter how much we require advertising to be truthful, as long as it can be technically honest in a suggestive way, we're just as lied to as we were before. At least when adverts could get away with lying we knew not to trust them... nowadays people seem to think that "they couldn't say it if it wasn't true!" which sort of misses the whole gap between what the advertisers are saying and what their audience is hearing.

Of course, if one is aware of the difference then the ads can sometimes make for interesting viewing. Take a recent-ish ad I saw for (hair) conditioner, for example. This is a product that is very relevant to me, what with the long flowing locks and all. Now then, do you sometimes worry that your conditioner is actually stopping your anti-dandruff shampoo from working? No, of course you don't, and neither do I. But that's the question the ad poses as it opens, and by asking the question it tells me all I need to know...

First of all, if there was any evidence that conditioner could impair the performance of anti-dandruff shampoo, wouldn't they be leading with that? Or at least mentioning it? I rather think that they would. I mean, let's not forget that the "hair care" industry loves to present evidence of its claims, for example that shampoo/conditioner that can reduce breakage by up to -100% (they actually said that at one point - "up to -100% less breakage"... so that's, what, twice as much?! These days they seem to have caught on to the double negative). Anyway, where was I? Oh yes, that incredible anti-breakage shampoo/conditioner (which I do actually use and like, FWIW). That claim? Based on something like seven hair samples washed, etc. in a laboratory environment. Junk science, in other words, but necessary for the claim to be "meaningful".

OK, but what about my anti-dandruff shampoo? I mean, how am I going to get women to stroke my hair if my damn conditioner is conspiring against it? Argh! If only there was a conditioner that didn't do that... like, say, oooooh, most (all?) of them. And thanks to Head & Shoulders' advertising I now know that I don't need to bother with their conditioner, which I might otherwise have given a whirl.

Hmm, come to think of it, the first shampoo/conditioner I really liked (now long since defunct), back when my hair was first getting long, was "Finesse". A brand that claimed that their shampoo was "activated by dirt", like, oh I dunno, let's say: any detergent. Also, the conditioner worked more the longer you left it on. No, really. That's what the ads were pushing.

Anyway, in other news, wifey is now awake and enjoying fewer calories than two slices of bread*, so I guess it's time to make the internet-to-real-life transition...

*sniff*

Today I failed, badly... because today it took me over eight hours to make a cup of tea.

OK, that's nothing startlingly new (although it is pretty bad, even by my standards). The whole turn kettle on, get distracted, repeat until actually getting as far as drowning a bag, get distracted, repeat... process is, thanks to the ADD, perfectly normal for me. So a few hours to make a cuppa is perfectly normal, even if that number is uncomfortably large.

What's bothering me is that today it took me eight hours to notice that the kettle wasn't plugged in.

I don't know how many times I thought I was reboiling the kettle only to get distracted before noticing that it wasn't working.

On the bright side, I nailed that cuppa on the first attempt once the kettle was actually plugged in. Yeah!

But still... Gah.

Night of the living Beebs

I've just had a funny few days (well, nights really - but they're logical days to me, even if they're physical nights to the rest of this timezone). It all started with a box of Beeb Micros that were gathering dust (and worse...) in a friend's place, so were offered to me since it's well known that I just can't get enough of 'em.

So, Job no.1 was to find out what exactly what I'd just been given. Looked like a 128K B+ (yay! I didn't have one of these before) that was in very good condition, a couple of filthy Bs (issues 3 and 7, one with 8271 DFS) and a couple of Master 128s that were positively vile. When I said that these machines were gathering dust, and worse, the worse consisted mainly of dead insects, cocoons, insect droppings and so on. Keyboards full of gunk, with some keys barely readable through the grime. Filthy to vile, in other words. The good news was that all the machines with the exception of one of the Masters actually powered up OK, or with a bare minimum of the laying on of hands (i.e. reseating ICs) in the case of one Model-B. That's pretty amazing, really. There was also a couple of (mostly working) disc drives and a (dead) monitor.

On to Job no.2 then: cleaning. I'm fairly sure that it's not abnormal to be in the shower at 5am clutching a sponge and a 23-year old, muttering words of filth and tenderness. OK, so maybe it is abnormal when the 23-year old is a lump of beige plastic in two halves. Still, TLC gradually overcame the filth and that left me with some nice clean cases. Cleaning the PCBs was fairly easy - just dust them down, for the most part. No sexual innuendo required. That just left... the keyboards. A few hours' work ripping them apart, dunking things in soapy water, rinsing and drying them, and then reassembly and I was good to go.

Sadly, although I was good to go, two of the machines weren't really interested in getting with the program.

The previously working Master was now being intermittent. Maybe it wasn't working well before either - I did nothing more than power it on and type a *command or two - or maybe some piece of vital dirt was now missing. Either way, given the lack of socketed components in the machine, it was beyond the critical "worth the effort" point. As luck would have it, the problem with the other Master was in the PSU, so I had an entire spare Master transplant... and \o/ all was well. Having a dead Master wasn't the end of the world, either - I already had a sickly machine that it could donate some parts to.

Since I was putting so much effort into these beasties, I replaced the CMOS battery pack in the good Master, and used the dead one's pack to make a new one for my existing machine. Great fun there - leaking Duracell AAs aren't overly nice.

Final score on the Masters: I started the day with one damaged Master and ended it with two working ones in excellent condition (and some spare parts). Win.

I didn't do so well with the Beebs, when it came time to give them a more thorough test. One died fairly soon - and resisted all my efforts to bring it back. Again, it was past the effort/worthwhile horizon, so I let it go to be spare parts and/or wallpaper.

The second B seemed OK, and I went to the effort of fitting a disc interface to it before I noticed that it had some interesting problems - the screen display would (after a while) start to corrupt itself in interesting ways. Some letters (MODE 7 FTW) would change, others wouldn't. Given the characters that were affected, it was obvious that bit 3 of something was being lost. Not all instances of the characters were affected - it was dependent on screen position too. Worst of all, using the cursor/copy keys reproduced the bit3-deficient characters so that meant that the problem was in the CPU/RAM side of things, not the SAA5050 side. "Ah well," I thought, "this might make for a fun one to fix."... and then I noticed that after a time the corruption got much worse, and that moved it into the effort side of the effort/worthwhile balance.

Final score on the Beebs: gained a 128K B+ and a fair few spare parts, including an 8271 upgrade I didn't have before.

So, disc drives... One was fine, but only a SS 40T drive. Not the best news, but functional. A second SS 80T drive didn't seem at all happy, so I ditched it. That left a dual drive with one DS 80T and one SS 80T drive. The SS 80T drive wasn't happy, so out it went to be replaced by one of my spare DS 80T drives... once I'd dealt with the remaining drive. It worked, but only if I held the disc in the drive and pressed down on the clamp. Looking at it, it was pretty obvious why: the clamp mechanism was bent. A bit of fun and games stripping the drive down to fix that and I was good to go, so in went my existing drive alongside the new one... and failed to work. Seems that my existing drive's head-load solenoid was sticking. On the bright side, it was the same model as the new one, so I'd just had a crash course in stripping that type of drive down.

Final score: gained a SS 40T drive I'll probably never use, and a dual DS 80T drive that I will.

With my Beeb nostalgia freshly stirred, I figured it was about time to play with some of my existing machines a bit. "It's been a while since I played Exile!" I thought, and then on a whim read a little online about it. And now I have to play Exile - this year marks its 20th anniversary! And what better machine to play it on than the Master Compact... can't be beaten in terms of Beeb keyboard quality and comes-with-a-monitor-stand-ness.

New problem: transferring Exile from a 5.25" DFS disc to 3.5" one (maybe ADFS, maybe DFS - I can be flexible with these things having fitted a 1770DFS ROM to the Compact), or hooking up a 5.25" drive to the Compact... although the way I saw it, if I was going to go to the effort of hooking up a 5.25" drive, I might as well do it properly and transfer stuff to 3.5".

You might wonder why adding a drive to a BBC machine would be anything other than a doddle, but you see the Compact has a non-standard connector - it's a 25D that I (eventually) found corresponds to pins 8-32 of the normal 34 pin connector. Luckily, I just happen to have things like IDC 25D plugs and sockets lying around the house, and even a spare 'normal' beeb drive cable to cannibalise. So now my Compact has an external 5.25" drive as well... and I could copy Exile across to the 3.5" drive. Excellent. (I went with DFS in the end - ADFS would have offered me more space for savegames, but I would have had to disable the 1770DFS (and supply some 'placeholder' *DRIVE, etc. commands - hardly a big problem) to make it work and that seemed like more faff than it was worth).

That then lead to a bit of a head-scratch... did I want to stick with my legally purchased Exile (I bought a second copy direct from Superior about 12 years ago, shortly after buying a Master 128 to play it on), or skip all that "type this annoyingly located word in from the novella" malarky and use a version downloaded from the interwebs. In the end, I gave my genuine Exile disc a loving stroke (in its envelope, of course) and put my working copy back alongside it. Haxx it was, even if it did involve using a RiscPC to transfer the downloaded data to the Compact via an L-format ADFS disc.

Actually, I used two RiscPCs since my main one decided that then was a good time to die. It's most likely a problem I've seen before with the PSU, but I put all of that to one side because, quite frankly, I was fed up with b0rked machines and just wanted my Exile fix.

Then I had some fun with Exile's save game facility - it was often ignoring the filenames I gave and using the drive number instead. Freaky (and not something I remember seeing happen before). Worst of all, it was often doing it, not always. I.e. it was going to be a bitch to figure out/fix. I dunno, maybe it has something to do with using the normal version on a Compact (the Compact had its own version, necessary since the Compact has no DFS by default and the 'normal' Exile uses DFS commands). That doesn't explain the problems I had reproducing the glitch, but hey: I don't need to use the game's own load/save routines at all.

I really wish that I'd known just how optional the game's own load/save feature is back when I was first playing (and hooked on) Exile.

You see, Exile is such a big game that it uses damn near every scrap of memory that a Beeb has available... and that means that there's no room left for the filing system, so no built in load/save. The way that Exile solves this little conundrum (and believe me, Exile with no load/save option would be exceedingly cruel) is by having the load/save functionality in the loading program. The game itself, upon a particular keypress, squirrels all the necessary data away in safe spot in memory, corrupts the rest, and then hangs. You then hit ctrl-break to restart the machine, and run the loading program which allows you to save your game, etc.

Sounds a bit convoluted, but not necessarily all that bad, huh? Well, when I was first playing Exile, it was the tape version. So "quickly" saving my game actually took about twenty minutes. Really. No hyperbole used, because none is required. Ah, but I digress. So let's get back to my filename mangling problem and the hint as to not needing to use the game's own load/save features.

Since the savegame data is squirrelled away safely in memory, all I actually have to do is to save that block of memory to disc, and a simple *SAVE command will do just fine. (In case you're wondering, or have stumbled across this entry whilst actually looking for such info and made it past the showering with a filthy 23-year old scene, the command is: *SAVE filename 2C00 +400). Better yet, I knocked up a couple of quick programs in assembly to function as *QSAVE (to quickly save the game as Q.SAVE) and *QLOAD to load Q.SAVE into memory at &2C00 and then run the game. I still gots me some beeb-smarts after all :)

Naturally, something that was by this point going so well had so have a problem. And sure enough, this evening my Compact started doing something strange. Every now and again when I was playing Exile, the screen would corrupt - and then recover. I was a bit surprised that the game didn't crash, but screen corruption isn't necessarily that fatal for beebs. Master series machines have even more scope for "screen goes screwed but nothing crashes" since there's the possibility of shadow RAM involved.

And then things got annoyingly familiar. Every now and again, when I reset the machine in order to load/save, the normal "Acorn MOS / Acorn 1770 DFS / BASIC" messages would flicker into lowercase. A little (literal) prodding revealed that the issue was brought on by holding the ctrl key down which pushing the machine down onto the table. Pressing the underside of the case also caused the lowercase thing, and it would last as long as I pressed in a certain area. It was annoyingly familiar because, just like my dead beeb, it's a 1-bit difference (bit 5, if you care). On the bright side, there wasn't the extra "and if I wait a few more minutes, it craps itself all over the memory anyway" problem that the beeb had. On the other hand, the Compact would hang hard if I tried to do anything with it whilst the text was in lowercase.

So there I was, at "bedtime", with a machine that had a problem. A machine, furthermore, that I was very much looking forward to enjoying the fruits of my Exile-related labours with. So that most definitely lands on the worthwhile side of the effort/worthwhile balance. Just to force my hand in the issue, I'd actually downloaded the Master Compact service manual a few days beforehand.

Who needs sleep when you have a malfunctioning computer and a circuit diagram?

Long story short (cries of "too late" from the Airplane! fans), there are some plastic "support" thingies moulded into the bottom tray of the Compact's case. One of these had pressed a leg from IC14's socket (which is where the Acorn specific serial chip would be fitted if I had it) into the track that ran next to it and over time the nice green coating had worn away leaving a little patch of exposed metal. Once that had happened, all it took was a little pressure to make a connection and presto: the system VIA's PB5 was pulled to logic 1 in step with the SERPROC's ¬CS signal. Ouch.

I guess that when they said "THIS PRODUCT MUST STAND ON A HARD FLAT SURFACE" they really meant it. That alone would have prevented this issue, or at least massively reduced the chance of it happening.

And the moral of this rather long and mixed up story? Frankly, I have no idea. I was going to make some off-colour joke about fiddling with 20-year olds, but now I've forgotten it. Maybe I'd have done better if I'd gotten any sleep... Oh, wait, I have Exile and a Master Compact to play it on instead...

You gon' git yours, Triax...

Oh, and I guess I should fix my RiscPC, too :(