Demoscene: The Amiga Years, Volume 1

I had barely finished my January blog post when – THUD! – something rather heavy fell through the mail slot. I had been buying a lot of stuff online because of the Covid pandemic, so I had somewhat lost track of my orders: I knew it could be anything from frozen pizza to a framed picture of a disappointed horse. After unpacking, it turned out to be a book!

I’m not a great fan of crowdfunding but I have supported a few campaigns, mainly those aimed at documenting the history of the home computer era. As it coincided with my formative years, I now feel very strongly about things that help preserve the legacy of this wonderful technological age. So when it became known that an independent French publisher, Éditions 64K, had started an Indiegogo campaign for an extensive book about the Amiga demoscene, I was sold immediately. Considering how large and busy the scene had once been, it didn’t come as a surprise that the book got successfully funded in only two weeks.

Yet I wasn’t really expecting it when the book was delivered, mainly because the planned publishing date sounded a wee bit optimistic to me. Let me see: the campaign started in June 2020, with shipping expected for December. The publisher promised a mighty 450-page hardback covering approximately 90 demos from 1984 to 1993, in full colour print on quality paper. It was supposed to contain not only visual material but also a great deal of text describing the demos as well as giving interesting background on their development. I had previously worked for the publishing industry, so I knew you could easily deliver such a book in six months if your source material was more or less ready. But there were certain signals that the hay was nowhere near the barn. First of all, well into the campaign the publisher decided to change the title: the book was originally meant to be called – and was even promoted as – Demomaker, which admittedly was a major misnomer. Why’s that? Back in the early 90s, the Demomaker was an infamous Amiga program that allowed noobs and lamers to build simple demos from a set of ready-made effects and routines. Because such a program embodies a perfect antithesis of what the demoscene stands for, giving the book the same name would have been highly ironic.

Left: Demomaker by Red Sector Inc. Right: The original book cover mock-up.

Having chosen a much more appropriate title, the publisher then went on to announce a string of new sceners joining in and contributing their productions and stories. Which is great of course, but any such addition naturally inflates the project and adds to the production time. Given the ultimate number of contributors, combined with the fact that the demoscene is international and not all sceners are native speakers, it was clear the publisher would have a hell of a time organizing, editing, translating and proofreading the text content on top of all the graphic and typesetting work. I had a strong hunch that unless some corners were cut, Santa’s reindeer sleigh would end up short of cargo in December. So yes, the January delivery came as a nice surprise to me.

Upon unpacking I could immediately see that no expense was spared on the materials and binding. Chunky and substantial, the book presents itself as a formidable volume that will deserve a prominent position on your bookshelf. There is no dust jacket, but the cover is sturdy and very nice to the touch. It features pattern coating of glossy varnish and the book title is made in silver finish, which adds to the impression of a luxury item. Even just holding the book and flipping through its pages will make you feel that money has been well spent here.

As for the contents, I need to start with a small caveat. The book is called Demoscene, and the title may suggest that some kind of comprehensive account or analysis of the demo-making community is offered here. This is not the case, and let’s make it perfectly clear that such a thing was not the intended scope of the project. (If it were, the book would surely have to provide a more systematic coverage of two vital elements of scene life: diskmags and demoparties.) Instead, the book was conceived as a demo showcase right from the start, and indeed this is what you get in the first volume: ninety influential Amiga demos from the years 1984–1993. Although we need to add that the first three items were included mainly for historical reasons rather than for being actual demoscene productions.

If you followed the scene in the late 80s and early 90s, chances are high that you’ll be more than happy with the selection. I for sure can say that all of my personal favourites are there: the RSI Megademo by Red Sector – a demo I ran for weeks on end until the two disks developed serious read errors. Both megademos by Budbrain, showing that the scene didn’t lack a sense of humour and was not only about fame and competitiveness. The quirky Mental Hangover by Scoopex, a technological milestone that ushered us to the new dynamics of the trackmo era. Enigma by Phenomena with its phenomenal soundtrack. Digital Innovation by Anarchy, an unbelievable 30 minutes of graphics, effects and music squeezed on just one floppy disk. Hardwired by Crionics & The Silents and Desert Dream by Kefrens, epic demos that employed elements of film-inspired storytelling. And of course State of the Art by Spaceballs, a frantic visual performance that could easily be mistaken for a video taken from MTV. I could go on and on.

Left to right: Enigma by Phenomena, Revelations by Cryptoburners, and Voyage by Razor 1911.

I’m glad the demos are presented in chronological order rather than alphabetically or sorted by group. An obvious advantage of this arrangement is that you can clearly see how the scene, its techniques, skills and aesthetics developed over the said period. You won’t fail to notice certain ugliness that is intrinsic to the early “megademo” phase, and the growing artistic aspirations of the post-1991 production. Better than any sociological study the book captures the predominantly adolescent male character of the scene, which reflects in demo themes (often inspired by the sceners’ reading lists of science fiction and fantasy) as well as in graphic artwork (obsession by the feminine, an element that the scene noticeably lacked). The visual material alone provides great insight and serves as a valuable document of the times.

But it was the text content I mainly bought the book for, and as far as new information is concerned, the volume certainly doesn’t disappoint. I have seen (and yawned over) retro-oriented publications that merely rehash well-known facts and then quote people with rose-tinted glasses on how great the Amiga was. This is not one of them: the book brings a look behind the scenes in the true sense of the phrase. Although the copyright page names Christophe Boucourt as author, the text is apparently not a systematic account written by one person; it was in fact co-authored and largely collected or adapted from various contributors directly associated with the demoscene. This makes the text content rather varied and somewhat lacking in coherence as a whole, but on the other hand it adds to authenticity because you know the information comes right from the horse’s mouth. The parts where sceners introduce their computing background may come across as a bit repetitive because the stories tend to be quite similar (“I had a Commodore 64 before I got an Amiga”), but otherwise the book is packed with interesting trivia and sheds a lot of light on scene life. Group wars and animosities, membership changes, rise to fame and fall to oblivion, the challenge of technology, creativity and the spirit of competition, long nights up getting things ready for the next day’s demo contest, parties raided by the police… it’s all there, testifying to the fact that the Amiga demoscene at the turn of the decades was a vibrant and a thoroughly unique subculture.

My only gripe about Demoscene: The Amiga Years, Volume 1 is the language quality of the book. As I hinted above in one of the opening paragraphs, corners had to be cut somewhere if such an ambitious project was to meet the no less ambitious deadline. I’m sorry to say that much as I appreciate the text content of Demoscene, the proofreaders really did a sloppy job here. I understand that the text incorporated pieces sent by a multitude of different people (sometimes in different languages) and that it wasn’t easy to unify the whole thing, so I’m fine with the style being sometimes a bit rough around the edges. Similarly I don’t get offended by the occasional factual mistake: the musician Moby could hardly have bought an Oric-1 computer in 1993 (p. 421); Cryptoburners’ demo wasn’t exactly called Hunt of 7th October (p. 92); there was no member of Kefrens called “Mellican” (p. 362), etc. However, what I cannot pass over in silence is the grammar and spelling errors, the number of which is beyond acceptable. I have no idea how much the proofreaders were paid for their work, and I’m sure the book was a labour of love and won’t make the publisher rich. But a project of such magnitude and of such immense documentary value certainly deserved better. I would have easily lived with a delay if only it had resulted in a more polished text, making the reading experience even more enjoyable.

Here’s hoping that the planned second volume will receive more love in the language department, and that this much-needed project will continue to cover other periods and areas of the demoscene. I’ll be eagerly waiting in line to chip in!

Boucourt, Christophe (ed.) Demoscene: The Amiga Years. Volume 1 (1984–1993). English edition. Biarritz: Éditions 64K, 2020. 447 pages. ISBN: 978-2-9575080-0-6.

A word on project synergy

Outlining my programming activities in the previous blog post I also mentioned that I had been involved with the Amiga Developer project for quite some time. After the post went live a few people asked me whether it meant that I would work less on the project now that I develop my own software. The answer is no, not really. In fact, there is a good deal of synergy between Rear Window and the work I do for Amiga Developer, and the two efforts have benefited from each other.

I for sure am biased because of my personal stake, but I’ll say that one of the better things the Amiga Developer initiative has produced is the Enhancer Software Core classes: a free collection extending the standard GUI toolkit provided by the operating system. Indeed, the main reason why I like to promote the Core is because it brings new possibilities to Amiga GUI programming. So when I started working on my Rave audio editor, I knew I wanted to use the new classes on top of the traditional ones. What I didn’t know was that Rave would soon become an important test bed, a trial of fire in which the Core classes would have to prove themselves.

Regardless of how thoroughly you design it, a software component only reveals its true colours when used in real software. By which I mean not only that real-life use exposes bugs and drawbacks that went unnoticed at design stage or during beta testing. Actual use in software also tends to throw new light on how the component could work and what features might be missing. I’ll hazard a guess that a lot of the AmigaOS gadgetry has seen progress because a developer working on particular software was short of a particular feature. Or is it pure coincidence that the GUI toolkit received major updates while Simon Archer, one of the key OS developers, was working on his CodeBench IDE suite? I don’t think so. And that’s just one case in point.

Having access to the Amiga Developer source code repository I was, similarly to Simon, in the lucky position that I could shape the classes I’d decided to use in my software. As a matter of fact, all of the recent updates I have made to the Select Gadget (originally written by Massimo Tantignone) and the InfoData Gadget (Mark Ritter) were motivated by something that cropped up while I was working on Rave. And it won’t come as a surprise that my audio editor is also directly responsible for the very fresh addition to the Enhancer Software Core: the ToolBar Gadget class, which I have recently covered for the Amiga Developer Blog. Here’s how it all came about.

I have a habit of starting my projects by designing the GUI. Although in the end it usually bears little resemblance to the original version, I prefer to do it this way because seeing something tangible on the screen jogs my creativity. (It also tricks me into feeling a sense of accomplishment, despite the fact that the program doesn’t do a thing yet.) So I was sitting there designing an early toolbar for Rave when I once again realized how much I hate the standard SpeedBar Gadget, because it takes ages to set up. In an ensuing act of bravado I decided to put the work aside and write a custom toolbar gadget class: one that would be basic in features but extremely easy to get going. I thought, few programs use their toolbar for more than triggering action, so why not focus on the primary function? It turned out to be a relatively quick job, and it would have remained a one-off affair (and I would have no article to write now) if I hadn’t made a classic mistake: I shared my work with others.

In a way, I shot myself in the foot by offering the ToolBar Gadget as a contribution to the Enhancer Software pack. I fell prey to semantics, not realizing that if something is called “Enhancer”, people will invariably expect more features from it. Well, my gadget class didn’t have more features than the SpeedBar, it just represented a simpler alternative – which apparently didn’t come across as added value. The subsequent reactions ranged from indifference to downright scorn, and they were a painful lesson to learn. One fellow developer kindly sent a list of features my class absolutely needed to have before he even bothered to use it; isn’t team spirit great? But we Amiga programmers are renowned for our resilience (on top of the fact that we can cook a decent curry, which puts us in constant demand at registry offices), so I didn’t give up that easily and continued working on the class alongside the Rave project. This turned out to be a very sensible decision because as the program evolved, so did the ToolBar Gadget in response to my growing needs. Thus one feature led to another until one fine day (whew!) I finally felt that my dear little creation could no longer be blamed for not enhancing the Enhancer enough.

My Workbench screen showing various configurations of the ToolBar Gadget.

A brief look at the screenshot above may suggest that there is little visual difference between the ToolBar and the old SpeedBar. And yes, when the ToolBar Gadget saw its first public release, a few users seemed disappointed that the two classes didn’t look any different. On closer inspection, however, you’ll notice certain details that go beyond the default look and hint at the advanced configurability of the ToolBar. Most prominently, the new class features a borderless mode, which arguably looks more modern and helps reduce clutter in crowded GUIs. There are also smaller and less conspicuous improvements such as support for multiple image sets (and easy switching between them), adjustable inner padding of the toolbar buttons, or configurable style of the separator bars.

One feature I’m really proud to have implemented is overflow handling. What is that? Well, some toolbars can be quite long and take up a lot of space in the program window, which may complicate use (especially where screen estate is limited). Therefore, toolbar classes are typically designed as “collapsible” GUI elements, to allow shrinking the window to a smaller size. When the window becomes too small to fit all of the toolbar members, we get a situation called overflow. How this situation is handled depends on the particular class. For example, the SpeedBar Gadget employs a scrolling mechanism that is triggered by holding the SHIFT key and then dragging the mouse left/right (or up/down if the gadget is vertically oriented). I’ve always found this behaviour rather quirky and unintuitive, so I preferred a smarter solution. As the image below shows, the ToolBar Gadget reacts to overflow by displaying a selector button on the right. Clicking on the selector invokes a pop-up menu the individual items of which correspond to the toolbar members that are currently out of view. So even in a minimum-sized window it’s really quick and easy to access the program functions. (Potential naysayers will be happy to know that overflow handling is optional, so if you prefer to have a “static” toolbar that is always displayed in full, you simply don’t turn the feature on.)

Toolbar overflow in MultiEdit.

Having finally released the updated ToolBar in October 2020 I though I’d give the Enhancer classes a rest for a while and fully concentrate on my audio editor, but as every seasoned programmer knows – man proposes, software disposes. Soon after I got down to business, working on Rave provoked another idea. Now, unlike in other spheres of human activity, ideas in programming can be really dangerous because they often lead to feature creep and, ultimately, projects that never get finished. Large software companies even hire professional hunters to locate staff programmers with ideas and shoot them on the spot. But as a humble freelancer I didn’t need to worry, and because the Christmas period promised some extra free time, I decided to have one more go at the ToolBar Gadget. So, what was this idea about?

Well, the main program toolbar in Rave contains a section with buttons that control the zoom of the waveform display. Originally I had the current zoom level indicated in the status bar at the bottom of the GUI, which was OK but somehow didn’t feel right. From the viewpoint of user interface design, I believe that if a GUI element controls a particular value, the value should preferably be displayed in the proximity of the controlling element, to have clear visual correspondence between them. So I started thinking: what if the zoom level value were displayed in the same toolbar section, i.e. next to the zoom buttons, rather than somewhere far below in the status bar? Of course, the ToolBar Gadget wasn’t exactly up to this: you could create a text-only button, you could even change the text on the fly, but it would still look and act as a button. What I needed was a new type of toolbar member, a read-only display area streamlined for dynamic text content. Luckily, the internal design of the gadget allows me to add pretty much anything (as long as it’s a BOOPSI object), so before the New Year chimed in I had the textbox member type ready and on the job. This is what it looks like in the current development version of Rave:

Notice the zoom section in the toolbar that now shows the zoom-in level.

For good measure I also threw in support for colours and text styles, because it was clear to me that someone would ask for these features sooner or later. Now that I’m thinking about it, in the end I must have made the ToolBar one of the most versatile and configurable classes of the entire AmigaOS4 BOOPSI set. Why do I suddenly feel so tired?

All right, it’s getting long (and late), so time for some closing words. An old Slavic proverb says that you can’t sit on two chairs at the same time. And there’s a good deal of truth in it: working on two simultaneous projects often means that one will rob the other of your time and focus. On the other hand, projects can also inspire each other, grow together and produce a synergistic effect between them. This has worked very well for me: both the Enhancer classes and the Rave audio editor have greatly benefited from the synergy. I’m quite sure there will be more in the future. And I’ll be here to tell you, so keep an eye on the Rear Window!

The crest of a Rave

I realize it’s high time I shed some light on my Amiga programming activities and on the software I’m developing at the moment. Pressed for time before Christmas I originally planned to write just a short heads-up note but because there’s a bit of a story behind it, I’ve decided to turn it into a regular blog post in the end.

The story begins in late 1980s. I took my first steps in programming on the infamous IQ 151, a bulky personal computer that was produced in the Eastern Bloc back then. The manufacturer of the machine must have had a weird sense of humour to name it this way because there was nothing intelligent about the computer in terms of technology, features, or the user experience it provided. But it was there at the right time, and the excitement and sense of adventure programming brought to my life stuck with me. To cultivate my newly-found passion my parents bought me a second-hand Commodore 64, where the marvellous Simons’ BASIC provided everything a budding programmer could possibly hope for on an 8-bit computer. It was great fun while it lasted.

Fast forward to the 90s. Unheard-of at the time, the multimedia capabilities of the Commodore Amiga blew my generation away. It was such an eye-opener that for a few years I kept my programming pretty much on the back burner; instead I got involved with music making for the demoscene, as I already explained in a previous post. But for various reasons my demo-making flame dwindled down towards the end of the decade, and I found myself more and more interested in producing something that others could use as a productivity tool rather than just watch for pleasure. This is when I finally learned the C language and delved into documentation on Amiga system programming. Yet with hindsight I can see I was still merely fooling around, and it wasn’t before I acquired my first AmigaOS4 system that I started producing real software for real users.

Encouraged by positive feedback on my first OS4 release, an English dictionary built upon Princeton University’s WordNet database, I went on to write the preferences editor for Thomas Wenzel’s AmigaAMP audio player. I also developed several plugins for the popular CD ripping software ADRipper, and when its author Adrien decided to quit the Amiga hobby, I took over the entire development and produced two major updates to the program. (Some achievement, considering that the original code documentation amounted to a dozen comments written in French!) Not long after that I was contacted by A-EON Technology, who invited me to join their new Amiga Developer initiative, a project that brings you the Enhancer Software and that I have been part of for more than five years now. My main responsibility on the team is the development and maintenance of new GUI classes – building blocks that extend the functionality of the AmigaOS Intuition system.

The Amiga Developer team at the 2017 DevCon in Cardiff, Wales.

There’s no doubt that working alongside some of the most talented Amiga developers of today is a great learning experience, and I find my involvement rewarding in many ways. But while I have definitely enjoyed contributing to a team effort, I gradually realized that given the time constraints of family life, working on the project keeps me away from the productivity tools I wanted to make in the first place. At this point I started contemplating the idea of my very own, independent project that ultimately became the Rear Window.

As you would expect, the first question I asked myself was: “What kind of software do I actually want to develop?” Well, my academic and professional background is in languages and translation, so I initially thought I’d write something in the vein of WordNet – that is, a new dictionary, a lexical analyzer, or perhaps a translation tool. But then I remembered it was the multimedia aspect that drew me to the Amiga, and as a musician I could see logic in developing something related to audio. Incidentally, my old music-making passion was warming up again at the time and I was looking for an audio editor to use with my sample library. It didn’t take a lot of research to see that the current offering is not great: the existing editors either showed incompatibilities with OS4, choked on modern audio file types, or were otherwise too limited in features. But frustration often brings about good ideas, and so I finally had a plan and a sense of direction.

I’m now happy to report that after some eighteen months of mostly late-night work the new AmigaOS4 audio editor has progressed to a stage where I can present it as a working piece of software. The program is called Rave, as I wanted a short name bearing strong associations with music and freedom. (It is also close enough to wave in both spelling and pronunciation, which I find playful.) It’s still rather basic in features but a lot of work has gone under the hood, allowing me to easily extend the program within the modular framework it is built upon. And although it’s a little early to promise a particular release date, I’m pretty confident to say that the program is currently in beta rather than alpha stage. I might also add that I expect to be able to publish a sneak-peek preview in the first quarter of 2021. And of course that I’ll cover some of the program features in more detail in the subsequent blog posts!

For now, they say a picture is worth a thousand words, so why not have a look at a few preliminary screenshots?

And of course: Merry Christmas, Amigans!

Rave’s tabbed interface allows working with several projects within a single program window.

Applying amplitude level gain using the Level plugin.
Loop-playing a sample selection.
Opening a sample using Rave’s dedicated file requester.

Back on track(ing)

Much of my creative activity in the 1990s was related to the Amiga demoscene. I was lucky to live in a city which, albeit small, concentrated enough local talent to have formed a full-fledged demo group called Vectors, which I joined in early 1993. Unlike many other demo groups, the members of which were often scattered across different cities or even countries, we could easily meet up in person to discuss things, work on our projects, or just have some serious fun with our Amigas. This gave us a strong sense of belonging, and I dare say that our creative endeavours were driven by the fact that we were pals, above all.

Last year some good soul remembered that Vectors would soon turn thirty, and we organized a get-together to celebrate the anniversary. Most of us hadn’t met for good twenty years, so I expected a brief and rather subdued social occasion attended by life-worn, pot-bellied family guys. To everyone’s surprise the event extended into the small hours, well past the time our function room was hired for. Demos ran rampant, monitors flickered, beer flowed like a river, so it was inevitable that someone would eventually stand up and say, “Yes, we can! Let’s make a new Vectors demo!”

Vectors & friends at The Thirty Party, June 2019

The drunken idea would have been all buried and forgotten were it not for our trusty coder Defor (the tallest guy in the photo above), who sent us an e-mail a few months later saying “All right boys, so I’m working on the demo, remember? How about you make some graphics and music for it?” I immediately knew I was in trouble because I hadn’t composed any demo tune since 2000. So I first thought I’d just fish out some unused music I made in the 90s and be done with it. But as others picked up speed and kept showing new stuff, my cowardly decision became more and more embarrassing. I also couldn’t help noticing that my old Protracker modules sounded really horrible, considering today’s standards. So it was clear that my AmigaOne X5000, which I had mainly used for system programming and occasional gaming, would soon get a new task to prove itself.

AmigaOS4 is not short of music trackers, although the choice is naturally not as wide as on classic Amigas. After some experimenting I finally opted for MilkyTracker, which is actually a FastTracker 2 clone but can export songs in the Protracker format. Good – I had the right tool and now it was time to bite the bullet and do my piece of work. It’s not that I hadn’t composed any music in the previous two decades; in fact I ran a small production studio for a few years, but it was all PC-based and very MIDI-oriented, with the Steinberg Cubase sequencer being my staple software. So it naturally took me some time to put all my trust in the Amiga again and get back into the tracking mood. “Will I still enjoy it?”, I asked myself. “Will the final result be worth the effort? And will my wife not kill me when she sees what I’m doing?”

At work
Left: AmigaOS 4.1 Final Edition running MilkyTracker and AmiSoundEd.
Right: Me at work. The “Make Amiga great again” cap is courtesy of Steven Solie.

As it turned out, neither the Amiga nor the tracker paradigm were the roadblocks. But I had completely forgotten how limited Protracker was with audio samples! Although MilkyTracker was more than happy to import material from my sample collection (most of which are 16-bit stereo .wav files sampled at 44100 Hz), when working on a tune to be eventually saved in the .mod format you want to keep an eye on the Protracker specification right from the start, to avoid unwanted surprises at a later time. I learned something of a bitter lesson there before I finally decided to play it safe and just converted everything to 8-bit mono at 22050 Hz (i.e. half the original sample rate), which seems to have worked well. Compared to the sounds I used in my old songs, none of which were sampled above 16 kHz, I can hear that this project has really benefited from the increased sample rate and got the extra spark in the higher frequency range, allowing the drum track to stand out and making synth sounds more vivid. The individual instrument parts are more defined and the overall sound is less muffled. Apparently, good old 8-bit sound can still cut the mustard.

The Rear Window Studio
Left: The 2020 incarnation of the Rear Window Studio.
Right: My AmigaOne X5000 tucked away at the bottom of the rack case.

Once I got the samples in it was time to brush up my tracking skills, knowledge and techniques. To my surprise, after a few late-night sessions using the tracker was like wearing old shoes. It was still there! I even remembered many of the Protracker effect and control commands, which only testifies to the fact that human memory has a tendency to keep the most useless things of all. Anyway, to cut a long story short: I had the tune pretty much complete in about two weeks of burning the midnight oil. I spent some more time optimizing the song in order to get under the size limit imposed on me, for we had agreed that the demo would be a true retro piece running on a lowly Amiga 500 (with a 512 KB Fast RAM expansion as an afterthought). During the entire process MilkyTracker was a pleasure to work with and never crashed or locked up, which suggests that the port is a job very well done. I can certainly recommend the program to any AmigaOS4 user interested in making music for demos or games.

With all the artwork and code in place we finally released the demo at a local Amiga party held in late September, a real close shave because the government’s Covid-19 restrictions hit back the following week. We decided to call the demo Mindsurfin’, which I find a particularly apt name not only because of the laid-back atmosphere but also for the reason that working on the demo was one big trip down the memory lane. And there was one more thing in it for me personally. I was excited to see our labour of love run on a classic Amiga, knowing that my next-generation Amiga was so instrumental in the project. It felt like two worlds shaking hands in a much-delayed reunion.

Enough said, enough done. You can download Mindsurfin’ as an .adf image from the demoscene portal Pouët.net (which also hosts old Vectors productions, in case you were interested in what we did in our years of youthful folly). The demo has been tested on a genuine Commodore Amiga 500, on a Vampire V4 Standalone, and in various emulation environments including Amiga Forever and E-UAE. You can also watch it on YouTube as an alternative. Last but not least, a few people have asked me if the music .mod can be downloaded from somewhere, so I’ve made it available here for anyone interested.

Enjoy and spread the word!

Opening the Rear Window…

Browsing through old diskmags always makes me notice how much Amiga-related writing I did in the 1990s. But of course: the Amiga was my computer of choice back then, I used it throughout the decade as my main productivity tool. I used the Digita Wordworth for all my written coursework, including the master’s thesis; I composed several dozen tunes for demoscene productions in Protracker; I took my first programming steps in GFA Basic and, later, Storm C… So there was a lot to write about, and writing about it was great fun.

I haven’t written anything since I rekindled my interest in Amigas around the year 2009. The usual pressures of life are largely at fault of course, but now I realize I’ve been using “next-generation” Amigas for longer than I actually used the classic ones – so I find it quite absurd that I’ve never tried to share my experience. In a fit of self-honesty I also admit to myself that I’ve secretly missed my writing all the time, hence this little blog.

The name

There are three reasons why I decided to call my blog Rear Window. First of all, I’m a big fan of Alfred Hitchcock’s film of the same name – it’s just pure cinematic class! Second, my Amigas and I spent many years in small rented rooms with a single window looking out on the backyard. Over time, this had become such a predictable coincidence that, at some point, I started calling every man-cave I moved into after the rear window it had. And third: a backyard full of old junk and memories is an arcane place, neglected and out of sight but calling for adventure and inviting explorers; a perfect metaphor for the Amiga world today!

I am, therefore, opening my Rear Window on the backyard. Let’s see what we can see there.