Code, Amiga, Sound Engineering and other things of interest...

Apollo Vampire V1200 Review

| Comments

After months of being on the waiting list, I recently recieved my Apollo Vampire V1200V2 accelerator! Since then, my Amiga has had a new lease of life so I thought I’d write an update covering all the stuff I would have wanted to know while I was waiting for the package to arrive. What follows is a review/retrospective on my first month or so of usage of this card – I’ll cover the ordering experience, hardware, installation, updates and software and wrap up with my thoughts and reflections on the project. This has ended up as one of my longer blog posts, with lots of screenshots and photos, but if there’s anything in particular I have missed that you would like to know about please feel free to leave a comment or get in touch with me. So grab a coffee and read on below!

I would imagine that most in the Amiga scene are familiar with the Vampire range of accelerators, but here’s a brief recap: The Amiga was always a very expandable and flexible system – over the years, a wide variety of add-on cards were produced that pushed the machine beyond its original design limitations and opened up a whole world of expansion possibilities. Faster processors, more memory, PCI expansion boards, graphic cards, network adapters… There really is seemingly no limit to the ingenuity of the scene, even going so far as to re-purpose the A1200 clockport into providing USB connectivity!

New products are being designed and released even today, with the accelerator scene – providing faster processors and often other additions – seeing a resurgence of late. Notable examples include the open-source TerribleFire range, and the new Warp 1260 which utilises a Motorola 68060, the fastest of the 68000 series of processors produced by Motorola and used in the original Amigas.

The Vampire boards from Apollo take a different approach: Rather than sourcing original Motorola processors (or requiring the end-user to find and separately purchase a processor, as in the case of the Warp series of cards), they designed a new 68000-compatible core and implemented it in FPGA form. This reports itself as a “68080” processor and being a FPGA-based solution, it can also be updated on a regular basis with downloads from the Apollo site. The FPGA solution has also enabled the team to add extra capabilities beyond that of purely providing a faster CPU: The Vampire range of boards includes features such as a “SAGA” graphics chipset with Hi-Res HDMI output, Faster IDE port, SD Card slot, Ethernet expansion and much more besides. Quite an impressive technical achievement!


The ordering process was pretty straightforward even if it did involve a long wait – which, frankly, is nothing new in the Amiga scene ;) I also want to just add that this is by no means a complaint, it’s simply the reality of a small but dedicated team working as best they can in these strange times of shipping delays and supply chain issues. I put my name down on the waiting list around December last year and had honestly forgotten about it until I recieved this exciting and unexpected email towards the end of June this year:

The process that followed was quite straight-forward and well explained in the subsequent emails. I had to make payment to a German bank account and then send proof of this transaction to the specified email address. Once that was done I then received a follow-up email thanking me for my order and confirming the board had shipped. I was provided with a tracking number on request but the “trail” stopped after leaving the origin country – Serbia, I think. I say “I think” because a lot of the tracking links were on Cyrillic websites which I can’t read, but I knew from reading posts on the Apollo forums I was in for around a month’s wait.

UPDATE : On the forum, Vojin Vidanovic was kind enough to correct me – apparently, the Vampire cards come from the beautiful city of Banja Luka, in Bosnia and Herzegovina, which is next to Serbia. I also learned that the Serbian language uses both the Latin and Cyrillic alphabets; Cyrillic is official and traditional, but both are equal in use. Thanks for the information!

This did give me plenty of time to read through the excellent online wiki at and purchase a few extra things I knew I’d need at some point:

  • A HDMI to DVI cable for the Vampire’s SAGA video output
  • A DVI-switch so I can swap between the Amiga’s native video output and the Vampire
  • A 32GB SD Card to use as my Work: volume
  • A new 32GB CF Card to use as the boot device
  • The Ethernet module so I can get rid of my PCMCIA network card
  • The FPGA “USB Blaster” so I can flash new updates to the card (this proved invaluable later on!)

Then I waited. Sure enough, just under a month later the box arrived and I was ready to start!

Unboxing and Installation

Here’s what was inside the box:

There was the card itself, neatly packaged in an anti-static bag along with an instruction sheet pointing out the key connectors and ports. This provided basic installation advice, but for anything more detailed I found myself referring to the wiki.

The first step was to open up my A1200 and have a look at what I was dealing with; the last time I opened the case up was when I re-fitted the floppy drive at the end of last year. I’m always a little hesitant to go rooting around in there as it is an old machine and things are also pretty jammed in pretty tightly. Fortunately it all went smoothly, but I did end up having to open it all back up several more times than I was expecting over the course of the next few days, for reasons that are all covered below.

This was the inside of my Amiga before the Vampire installation:

It’s a Revision 1D motherboard fitted with a few extras:

  • CF-IDE card replacing the old IDE hard disk with a 32GB Compact Flash card
  • Indivision AGA MkII (the red circuit board with cable attached under the CF card). This sends the native video modes over DVI for use with modern monitors.
  • Blizzard 1230 Mk IV accelerator, 50Mhz 68030 processor and 16Mb RAM (the lighter green expansion card attached to the main board)
  • Kickstart 3.1.4 chips, fitted when I got my A1200 working aagin.
  • New PSU bought from a seller on eBay, a good strong power supply is essential as the original stock one can easily get overloaded by the extra power draw required by accelerator cards, hard drives and other expansions.

Next, I had to remove my old accelerator card. I’d been using an original late-1990’s Blizzard 1230 accelerator in my A1200 ever since I got it and it’s proved a reliable and solid little board but it was time for retirement!

In the next photo you can see the old Blizzard and new Vampire cards next to each other for size comparison. It really demonstrates how far the technology has come. Despite offering so much more in the way of features, connectivity and speed, the Vampire is substantially smaller. I prefer the blue colour too :)

At the top right of that photo you can see a 3D-printed vented trapdoor cover I ordered from eBay, originally to help with the cooling and stablity of the Blizzard. I can’t say I’ve noticed any heat issues on the Vampire but improved airflow always helps.

The Vampire card was easily installed, no problems with the socket or anything. It just slotted right into the motherboard edge connector with a little pressure. Here’s what it looked like installed in the Amiga:

Due to the smaller size of the card there’s nearly a full third of the trapdoor expansion bay free for routing cables etc. I had hoped to use the space to the right for the network card but couldn’t quite get things to fit. Here’s the HDMI and cable to the network module, run underneath the floppy drive and out the back:

Note the CF card attached to Vampire’s IDE port, wrapped in a make-shift insulating sleeve of an old business card and tape. From reading forum posts, I expected the Vampire board to come with core 2.11 flashed. This version of the core doesn’t support the onboard IDE port (or PCMCIA slot) on the Amiga motherboard, hence having to hook it up to the Vampire. Version 2.12 of the core fixes this, but disables the Vampire’s fast onboard IDE. There is however an update coming which will enable both IDE ports, along with re-enabling the PCMCIA slot. I’m really looking forward to this update as amongst other things, having both IDE ports enabled will mean I can easily dual-boot and try out alternative distributions.

It was a bit of a tight fit, but here’s a photo of the cables coming out the back of the case:

Squeezed through there are the small card and DVI socket attached to the Indivision (wrapped in red insulating tape), the HDMI-to-DVI cable from the Vampire, and the ribbon cable attached to the network adapter.

So now to test the basic operation of the card! I knew I wasn’t going to see much but I wanted to check everything powered on OK, so I re-connected the power, turned on the monitor and saw the Vampire Kickstart screen coming over the Indivision DVI output!

The Vampire contains a licensed Kickstart ROM (with customised version messages), so I could in theory remove the 3.1.4 chips. Switching over to the the Vampire HDMI output, I saw the splash screen for core version 2.11:



Now came the task of getting an OS up and running again. I tried booting from my existing CF card with a heavily customised OS 3.9 installation, but I was just left with a black screen on both outputs. A pretty stock OS 3.1 installation I had on an old 2GB CF card did however boot fine, so I knew the culprit was one of the many tweaks I’d made to it over the years. I tried hacking things out of the startup-sequence but gave up as I decided in the end to build my new system on CoffinOS.

Since I started writing this post, there have been a number of interesting developments regarding AmigaOS distributions for the Vampire such as the famous AmiKit XE and even a fully open-source fork of AROS. However, at the time CoffinOS was the “go-to” solution: It is a distribution of Amiga OS that comes ready-built for the Vampire series of accelerators – Coffin, Vampires, get it? It includes a ridiculous amount of software covering everything from the Vampire SAGA chipset drivers and utilities, to a comprehensive selection of tools, emulators (including full classic-68k MacOS environments!), applications and development tools. It also comes with a huge WHDLoad installation of games and demos; pretty much any classic game you can think of is pre-installed and ready to go.

I’m not going to link to it directly, as there’s possibly some legality issues with it; I’m not going to add anything more about that topic (perhaps another day), other than to say I think most Amigans these days are pretty fed-up with the seemingly never-ending cycle of lawsuits that the Amiga scene seems to consist of in some quarters.


I downloaded R56 of CoffinOS, which comes as a disk image you can write to a CF Card using something like dd on Unix systems, or Etcher on Windows or MacOS. According to the README document, it said that it required Core 2.12, I had 2.11 flashed but I hoped it would still work well enough and I could download and flash the update from within the OS once I’d got it booting.

I was again met by a black screen when booting, but I could get into the A1200’s Early Startup menu by holding down both mouse buttons on boot. From there I could boot without a startup-sequence (Unix users: you can think of this like booting straight into /bin/sh).

Good news : I found a text editor that worked without any extra assigns being setup. Bad news : It was MEMACS. Ugh. Still, it did the job – I used it to edit the startup-sequence:

Aha! That looked like the likely culprit:

The lines relating to VampireMap and CoffinLib were doing something that presumably expected Core 2.12 to work. For those interested, there’s a page on the wiki that discusses VampireMap, it’s a tool for temporarily loading a Kickstart ROM image file into the Vampire’s memory.

As you can see in the screenshot above, I commented those lines out with the semi-colon character, saved and rebooted. Success! I was greeted by the setup wizard on the SAGA output.

After running through the short setup wizards (input preferences, location, and network setup), I was dropped into the CoffinOS default desktop: A colourful dock at the bottom provided by AmiStart, and Vampire-themed background, icons and startup sounds.

I found it a bit too “busy” for my liking but it with a bit of work I’d convert it into something a little more to my taste. First thing I did was have a look at the disk space I had available, and to see what the partition layout was like.

There’s a small System: volume of 277 MB in size, and most of the rest of the space is taken up by a Programs: volume of nearly 26 GB. This had 3.6GB free for my own files, but I wanted a little more so decided to use the Vampire’s SD Card slot to hold my data and any new software installations on a new Work: volume. This way also means I can keep the internal drive as close to “stock” as possible which should make upgrading or re-installing easier.

There is one more partition of interest, the Restore: volume on DH2:. This is used by a built-in maintenance mode which can backup and restore preferences and the system volume. I had limited success with this it has to be said, but I have my own backup strategy anyway.

Speaking of backups, if (like me) you’re going to be doing a lot of customisation, you’ll want to backup the dock preferences file that lives at System:System/AmiStart/sm.prefs. While adding programs and changing icons, I found it all too easy to get it into a broken state where half the icons suddenly no longer worked and couldn’t be selected for editing.

I set my screen resolution, configured a new background and so on but hit a few snags more or less straight away. The system was really unstable – I couldn’t make it more than 5-10 minutes on average before it locked up in a variety of interesting ways. There was a suggestion on the forums that this was due to the trial version of Roadshow (the TCP network stack) expiring after 15 minutes of use, but even with this disabled the problem persisted.

This turned out to be because CoffinOS R56 does really, really seem to require Core 2.12. It unfortunately seemed to be particularly sensitive when doing any network operations which ruled out downloading a new core from with CoffinOS itself, but I’ll cover that in a bit.

I did get to experiment a bit though, and even tried out the included MacOS environment which was a blast. My first summer job as a teenager was doing support on a network of MacOS 7 and 8 systems, so this brought back a whole bunch of memories. Even this environment comes with a bunch of extra goodies installed like some classic Mac games:

But as much fun as this promised to be, the instability was just too much to put up with. Time to go flashing a new core…


Without being able to get a core onto the system – and even then, I’m not sure I would have trusted it to remain stable while flashing – I had to resort to using the USB Blaster to flash the board from a Windows laptop. I’m really glad I purchased it now, and would definitely advise anyone buying a Vampire card to also invest in one.

The process for installing cores via the blaster is all covered in the wiki here. The downloads for the Quartus Programmer wouldn’t work though due to the Intel website being horrendous. To save anyone else the hassle of signing up only to discover that the download links don’t actually work, here’s direct link:

Here’s the blaster hooked up to my Windows laptop and connected to the Vampire through the JTAG port. Fortunately all cables came with keys and notches to make sure everything is aligned in the correct direction, and it was all very easy to set up:

The installation process was easy, just make very sure you have the right JIC file! Here’s the programmer with the JIC file loaded and ready to go:

And here’s what it looked like after a successful flash operation.

I had to expand the little status panel at the bottom to see the full output including the “success” message. On firing the Amiga back up I saw the new minimalist 2.12 core splash screen (if you squint, at the bottom right you can make out the core “2.12 x12” core version):

I then had to move the CF card back over to the Amiga’s internal IDE port because the 2.12 core disables the use of the Vampire’s onboard IDE, you can just make out below that it’s moved back over to the original position on the left of the A1200 motherboard:

The system booted and was stable, so that’s another success!


I did have one more slight issue which I’m covering now in case anyone else has the same issue : my Indivision AGA Mk2 card, which converts the native Amiga chipset graphics output into modes suitable for modern monitors with a DVI connector, was showing no output once the SAGA driver had loaded.

I had it hooked up through DVI switch so I can switch between the Vampire and Amiga screen modes (e.g. for playing old games) with a button press, but no matter what I tried, once CoffinOS had booted and the RTG graphics had taken over no output was sent over the Indivision.

It also seemed like others were having similar issues on the forums. As a workaround I used an old Amiga video->SCART cable, plugged that into a converter and tested.

It worked fine (although a little fuzzy), so there wasn’t a problem with the Amiga native graphics output. If I booted with no startup-sequence, the Indivision also worked fine so it was something to do with CoffinOS. Eventually I found support on the Vampire Slack channel (which has now moved to Discord) which suggested loading the default settings in the Indivision prefs utility and re-flashing the Indivision card.

This worked, but then everything was displayed in a narrow “letterbox” format. I remembered this from the past – the Indivision usually needs screen modes and details configuring by hand to match your monitor. It’s an exercise that reminds me of the horrors of hand-tuning XF86Config files on ancient Linux distributions. Anyway, I can’t even remember now how I arrived at these values, but here’s what eventually worked for me and got a nice, full-screen on my 1280x1024 display again when using classic software:

No idea if that’ll help anyone else, but at least it’s recorded here now if it happens to me again!

Roadshow and Network

I then wanted to connect my new Vampire’d system to my home network so I could transfer data to and from it and properly “move in”. I’d purchased the ethernet module which attaches to the Vampire card through a thin ribbon cable.

Now I had a stable system, I needed to be online for longer than 15 minutes permitted by the trial version of Roadshow. I purchased and downloaded the full version of Roadshow from another computer and transferred it to the A1200 via my Synology NAS acting as a FTP server, using the included AmiFTP as the download client:

Installation was very simple – you just copy over the bsdsocket.library file, you do NOT have to run the main installer. Once Roadshow was downloaded and unpacked (lha x Roadshow.lha) to my Downloads: assign, here’s the commands that were required to make a backup copy of the system trial library and copy the full version over:

copy LIBS:bsdsocket.library LIBS:bsdsocket.library.original copy Downloads:Roadshow/Workbench/Libs/bsdsocket.library LIBS:

Moving over

I’d fitted a 32GB SD Card to the Vampire following the wiki instructions, which I formatted with PFS3 and was using as my new Work: volume. This means I can easily remove it and back it up using dd or similar, and I also keep all my customisations, downloads and projects on a separate volume to the system drive. I have a backup/restore script so if needed, I can just re-flash the system drive, mount the SD Card, run the script and be back up and running. This is particularly useful because there isn’t really a method of updating CoffinOS other than writing a new image over your CF Card.

To move all my data over from my previous OS 3.9-based system drive, I attached the CF card to my AmigaOne X5000. As I discovered when I first got that system, OS 4 can mount and read the drives from my A1200, so I used that to copy a few packages, license keys and configuration over to the Vampire system via the network.

I again had to change the drive names so they didn’t clash with the Amiga OS 4 system; Here’s a screenshot of the X5000 showing the CF card opened in Media Toolbox – all I did was change the partition Name field to CF0 instead of DH0 and so on.

I could then mount and copy things over to the FTP server where I could pull them down again using AmiFTP on the A1200.

I also copied over a set of Faenza icons that I’m working on packaging for AmigaOS.

Here’s what my customised Vampire Workbench looks like now:

And some windows showing some more of the Faenza icons:

For comparison, this is what I was rocking on the Blizzard Amiga at a 640x512, 256-colour resolution that was pretty much the highest I could set things to while pushing the limits of comfort – any higher resolution was just too slow to be usable:

And now, the system is just incredible. It’s lightning fast – boots in seconds (even on the “slow” internal A1200 IDE port), programs open instantly and I can really use it comfortably for things I’d previously only ever been able to do on the faster PowerPC-based X5000 or UAE emulators. Even browsing Aminet and downloading packages is snappy:

I can also finally watch those incredible modern demos that typically require a fast 68060 processor, my current favourite is “Shake Off The Dust” by Elude:

It’s simply amazing to see that running on a real Amiga, particularly when a 68060-based system and RTG board would have set me back thousands of pounds and would have required a full tower-build out with PCI busboards and so on.


So how well does it run all classic software ? Well, I can’t speak for everyone, all I can say is that everything I wanted to run did so perfectly. I had a bunch of licensed software I’d purchased over the last few years like the updated iBrowse and CubicIDE, all of which worked without a glitch.

Going further back in time, my collection of floppy disk games and demos mostly seemed to work, even productions from my old Scene group:

Tools like Protracker worked great and brought back many memories:

And for the odd thing that didn’t seem to work quite right when booted from floppy, the huge WHDLoad collection bundled with CoffinOS covered all the bases, even relatively obscure Public Domain games like Transplant that I spent hours on as a teenager are included and set up to go at the click of a button.


I’ve avoided benchmarks in this post because as far as I’m concerned, they’re mostly pointless and it’s all been done before. They’re all pretty much the same anyway: With a few exceptions the Vampire leaves other classic systems and processors in the dust. It’s simply the fastest you’ll make a classic 68k Amiga go. And it’s not just a faster CPU, consider all the other add-ons, updates and possibilities. You’re not buying into a dead-end “vintage” system; there’s a constant stream of updates and community around this board. And it can all be had for a fraction of the sky-high prices that 68060 processors and graphics cards go for (and without having to fit everything in a tower case, too!).

Sure, you can go faster with emulation but then that’s not really the same for me. If you’ve read my thoughts on the floppy disk, you’ll know it’s all about the feel of the system. With the Vampire, I have a real system running in that iconic A1200 case that can still for example load games from floppy disk but can also instantly drop into a whole library of games and demos and modern Amiga applications straight from CF card:

A few seconds later, I’m back in my childhood:

That’s the really amazing thing for me. With the Vampire in my A1200, I can still take part in all that classic magic but it makes me actually also want to use it as a real productive system. There’s so much I always wanted to do on my classic Amiga but even with the Blizzard accelerator, it was just too slow and clunky for many tasks. There’s lots more I’d like to say about this card and many more projects I have in store, but as this is already one of my longest posts ever, I’ll save it for another day. I’ll just finish up by saying that the Apollo team should be heartily congratulated for what they have managed to accomplish: This is an absolute beast of a card, the fastest I have ever seen a classic Amiga go, and also the most FUN I have had in ages. They have also consistently delivered on their promises with new core updates, performance improvements and even a new OS in the works.

It’s also worth mentioning that it all also opens up a whole new world of possibilities for the classic scene – with the supply of original systems and parts slowly dwindling over the years (not to mention the endless legal hassles over the OS), the standalone V4 board which doesn’t require a host system also offers the possibility for many to buy a “new” Amiga system. And with the promise of a full AROS port in the future, it’s a future where the destiny of our beloved platform is back where it belongs: In the hands of the fans and coders.

I can’t wait to start developing for it!


| Comments

Just looking through some old videos and found this footage of me going off on one at our gig in February earlier this year, before the pandemic had really hit in the UK.

Feels like a lifetime ago now. I miss it.

Migration to Kubernetes

| Comments

Well, that went better than expected :)

I’ve given my whole public-facing infrastructure a belated spring-clean. I have now largely moved off my collection of VPS systems provisioned using Ansible, to a stack much more in-line with what I help customers build at my job. I’m now hosted on a managed Kubernetes cluster provided by DigitalOcean, and everything from this blog to the infrastructure automation is expressed as code in git repositories and rolled out using Concourse.

The whole thing has all been torn down and recreated from scratch several times a day with no issues so I’m feeling pretty pleased with it. I also have:

  • SSL Ingress through Traefik
  • Monitoring through Prometheus & Grafana
  • ELK stack for logs

Publishing this post is now a simple matter of committing the updates to git and then waiting a few minutes for my Concourse pipelines to pick up the change, build new containers and deploy. All of which means I now have far less excuses not to write more!

Back to the Floppy

| Comments

A few months ago, reading the news about Linux dropping support for floppy disks set off a whole bunch of memories and emotions around this long obsolete and “dead” data storage format. I hadn’t thought about or used floppy disks for around 20 odd years now, at some point I must have copied my last disk but I honestly can’t remember what it was or when. The floppy disk was one of those rare things that became part of my everyday life like my keys or school pencil-case. It was something from childhood and my early career that was everywhere: Scattered through my school bags, coat pockets and occasionally – if I was feeling organised – a disk box. And now, apart from a “save icon” meme, it’s gone.

For various reasons (mostly because I’ve just become a Dad!) I’ve been on quite the reminiscence trip recently and I decided to get reacquainted with this old and quirky relic of my past. Here’s the first of my disk boxes now, filling up quite nicely with little 3.5” slices of nostalgia after a few day’s worth of converting my ADF collection back into their original physical form:

I’ll cover the technical details of the “How” as per my usual Amiga blog posts but I want to talk a little more about the “Why” aspect. Be warned, I’m going to ramble on slightly more than usual as I go on a meandering stroll down Nostalgia Avenue.

An Icon

I won’t deny the convenience of tools like WHDLoad but having nearly every single Amiga game and demo available at the click of a mouse has resulted in “the paralysis of choice”. I liken it to having a Spotify subscription: I have access to pretty much the entire recorded output of every band, ever – but there’s just so much choice I usually end up sticking to one or two playlists or putting it on random shuffle, invariably getting bored halfway through a song and endlessly skipping tracks until something catches my attention.

There really is something about the act of having a sort through the disk collection and picking something out akin to the ritual of pulling a vinyl record from it’s sleeve and placing it on the turntable. And the noises! That “schonk.. chonk…” as the disks slid in, followed by the “chnk…chnk…chnk…ddddddrrrrr..chnk…chnk” noises… So satisfying!

All these years on and it seems stranger still that this literal icon of obsolete technology once seemed like the future to me. Coming from a cassette tape-loading Sinclair ZX Spectrum, when I was younger the floppy disk was symbolic of the then next-gen systems like the Amiga. I started collecting and trading games and demo disks with school friends in anticipation before I even got my first A600. After all, the floppy disk was literally the first thing you saw when you switched on your Amiga, displayed right there on the boot screen:

Then from Kickstart 2.0 onwards we got the funky animated version:

Demo groups parodied it and riffed on it:

Whilst thankfully a damn sight faster than loading from cassette tape, most games would have a screen like this somewhere to remind you that they were actually doing something and not just aimlessly clicking away for several seconds:

And of course, without the floppy, we would never have been “treated” to the cultural milestone that is MC Double-Def D.P. performing “Don’t Copy That Floppy”. This is possibly the most awkward 90s thing I have ever seen – and that’s coming from someone who once wore a shell-suit, Global Hypercolor t-shirt and Hi-Tec basketball boots at the same time (yeah, it was a different era…):

If you’ve never seen it before, I challenge you to try and make it the whole way through. It’s just… it’s amazing.

There were other rituals associated with the floppy too; when I recently purchased my first new packs of disks in well over two decades, I realised how much I had missed the ceremony of labelling them! Here’s my fresh supply, halfway through being stickered up:

I remember there was something just so satisfying about lining up the labels just right and of course, deciding when a particular disk was important enough to warrant the permanent pen instead of having a tentative pencil scribble on the label. Or even, for those select few disks you made for your closest friends, you’d decorate the label with some home-made artwork in the same painstaking way usually reserved for your most important mix-tape covers.

Even those favourite disks occasionally had to be recycled; We usually ended up running out of blank disks at some point and then a friend would come over with something so cool you just had to copy it and then…. Well, time to pick a sacrificial victim and write over it. I’m sure we all had disks that ended up looking like this:

Which led to a fascinating geological-type effect, where the strata of previous games and demos were left exposed but scribbled out from your history of interests. You could see what provenance that disk had, remember gaming sessions of old and look back in time like some sort of 16-bit archaeologist sifting through ruins. Magazine coverdisks usually suffered this fate with me. As a subscriber to various Amiga magazines I was guaranteed a monthly supply of new disks which I could re-label and put back into use by the old “hack” of taping over the write-protect hole.

A Community

One of the interesting side-effects of floppy disks being an actual, physical medium is that you needed some way of obtaining and exchanging them. This in turn I think really helped the early computing scene become so much more personal than the modern era where everything is a quick download away.

Aside from the tradition of visiting your friends house and having a good old rifle through their disk-box to find things of interest, there wasn’t an easy way to get hold of new software like there is now. Back in the day, no-one was “online” and very few of my friends had modems. Those that did usually also had PCs which couldn’t read or write Amiga floppies. We therefore usually couldn’t simply download the software we wanted, which led to the proliferation of PD Libraries which advertised their wares in most magazines of the day. A typical example is this full-page advert from “17-bit Software” (which was interestingly enough the roots of the legendary Team 17 games publisher which brought us the likes of Alien Breed and Project-X)

Flicking through the back-pages of Amiga Format and CU Amiga was a regular past-time for me; I’d carefully read all the adverts, circling the titles that sounded the most interesting and then go and pester my Mum to phone them up and pay using her card over the phone. I’d then wait in excitement over the next few days for the postman to deliver the disks – it was always a good day when just before school, one of these bad boys would land on the doormat:

Later on, when I eventually got involved in The Scene, floppies brought us together in a way I think is now sadly long-gone. Because we traded disks with each other – and groups typically had members whose sole “job” in the group was as a “trader” or “swapper” – we also wrote to each other. As a particularly awkward teenager (with a bunch of the usual teen issues and a healthy side-order of angst), some of the closest friendships I formed during those years were with the other members of my group. Alongside the floppy disks we’d write long, rambling letters to each other full of everything and nothing. We’d fill our envelopes to each other with “Jiffy Junk” – little trinkets we’d collect and swap: Kinder surprise toys, trading cards and the occasional mix-tape. As the splash screen from an old disk magazine said:

Even though I think I only ever met one of the guys from my group in person, I still think about them often to this day and wonder what they’re all doing now.

As the Amiga scene gradually died and the BBS (and later, the Internet and FTP sites) became the primary means of obtaining software I think a lot of those friendships were broken. Even though The Scene is still a very close-knit community, I’d be interested to know whether those same bonds exist today when most communication is probably electronic in nature.

Back to the floppy

So, now down to business (skip to the “But seriously, why?” section below for more of my musings if you want to gloss over the technical details). My A1200 had been fitted with a HXC Floppy emulator: a nifty little gadget that loads ADF files from a SD card and plugs into the floppy socket on the motherboard. I’d installed this years ago for the sake of convenience and is what I had been using for a “floppy drive”. This had to be disconnected and I also had to make a cardboard insulating cover to shield the Indivision AGA DVI card which sits right underneath where the new drive was going to sit.

I purchased a refurbished floppy from which I then installed :

Fortunately it sat secure enough with all the other cables around it, but it should have had a little bracket holding it in. It’s working fine now though without it and as it was a very tight fit with all my other expansions, I don’t much fancy opening it all back up any time soon! After a little fiddling with power supplies and working which way round the ribbon cables were supposed to go, it started up and proceeded to chunter away with that regular “click” of the Amiga waiting to detect a disk being inserted. Hurrah!

Now, to feed it.

There’s two types of floppy in circulation you can use with your Amiga. The first type is the native Double Density (DD) type which on the PC could support 720Kb of data and on the Amiga 880Kb. Although later Amiga models did sometimes come with a High-Density drive, this DD type was by far the most common type of disk in circulation at the time. They’ll work without issue in any Amiga drive but they are also the hardest to come by these days; the only reliable source for new DD disks I have found so far is from sellers on eBay. There are also plenty of “bucket of random magazine coverdisks and pirated games” auctions as well if you want to get really cheap.

The second type is the far-more common High Density (HD) type that most PCs used with a capacity of 1.44Mb. Again though, as they are no longer being produced they are now relatively expensive. You can still buy these brand new though, on sites like Amazon but there is a draw-back. They use a completely different magnetic medium than the DD type with different characteristics and as such they may or may not work reliably.

I tried 3 different batches bought from Amazon with mixed results. I bought a pack each of rainbow-coloured and plain black disks manufactured by Verbatim, Plain black disks from Sony, and a box of mixed-colour disks from 3M. In order to get these working I discovered the most reliable method was to use XCopy to format them several times in my external Cumana CAX354 drive.

I bought this drive from eBay as I wanted to recreate my then-pimpin’ dual drive setup I had on my first A1200. I think the write mechanism in this drive is somehow “stronger” than in my internal drive as I had a lot less issues once I used this to do the initial formatting. Here it is crunching through a X-Copy (Yeah!) format and verify:

"Xcopy on the Amiga 1200"

Once I’d formatted and verified the disks each time, they usually worked OK but on average there seems to be 1 or 2 “bad” disks in each batch that either refuse to be formatted or eventually start throwing CRC errors.


I also needed some extra software tools to convert things back and forth. As my A1200 is connected to the Internet I went over to Aminet. There are many similar tools there but one I kept seeing recommended was TrackSaver GUI which could write all my ADF files back to a real floppy. It has a very simple GUI which takes care of reading and writing floppy images:

As well as ADF files it can also handle DiskMasher DMS archives which were commonly used on the Amiga back in the 90s. I remember this output was a common sight on magazine coverdisks and BBS downloads:

TURBO GENERIC, indeed. One last thing to consider would be a virus-scanner of some type. The Amiga bootsector virus was quite the thing back in the day, and it still persists on some ADF sources or old floppy images. It’s rare but it’d be a real shame to screw up a system by doing the digital equivalent of re-introducing smallpox. Again, Aminet has plenty to choose from.

But seriously, Why ?

I’ve been thinking a lot recently about what it is exactly about the Amiga that captures me in a way that no other computer ever did. Part of it is I think because the Amiga was the last system that was simple enough that one person could reasonably hold the entire machine in their head.

It was complex, true, but with enough studying and time you could know pretty much everything about every single bit of the Amiga’s memory space, workbench, the custom chips and so on. That’s what makes it so special and endearing.

That simply doesn’t exist on other platforms. I mean modern systems are amazing – and I’ve worked on some serious big-iron hardware in my time – but you could spend an entire lifetime now simply becoming an expert in one tiny piece of the whole system. Modern computers just don’t have the accessibility that the Amiga had, and it straddled the divide perfectly between being simple enough to know it and love it, yet powerful enough to do things you’d never dreamed possible.

But I would also suggest that an even more important aspect is the community that grew up around it – which was made possible in a big way by the humble floppy disk. It enabled a whole generation of bedroom coders to reach out to the world, sending their software around the globe and making real connections. Like the bootleg tape scene of the 80s we traded disks, wrote letters, made friends and connected in a way that now, like the floppy itself, seems antiquated. But it was a lot of fun while it lasted!

XCopy for life, yo.

Monitor Upgrade for the A1200

| Comments

When the Amiga was introduced in the mid 80s, pretty much all displays available to consumers were 4:3 ratio TVs, and you plugged your computer into your TV via a RF modulator box. Later, dedicated monitors like the Phillips 8833 Mk2 (which I originally had as a teenager in the 90s) became available and these offered a much improved, sharper image but were still in the 4:3 ratio as this is what the native Amiga, PC and gaming console screenmodes had been designed around.

Nowadays however (with the odd exception) all commonly-available displays from TVs to flat-screen monitors are all in wide-screen 16:9, 16:10 or wider ratios. These displays tend to make everything designed for a 4:3 ratio look stretched and a little blurry. This is because the native screenmodes of the Amiga – such as 320 x 256 for most games and demos – cannot be expressed as even, equal fractions of modern widescreen resolutions. So you either end up “cropping” the display leaving black borders down the side, or you attempt to scale it up but end up with rounding errors and “pixels” that are wider than they are tall.

For reference, here’s a cropped photo I took when I first got my A1200 working again:

In this picture, I am using a standard modern widescreen monitor with “FHD” resolution of 1920x1080 pixels. It’s connected to the Amiga using an Indivision AGA board, and while I sort of adjusted to how it looked, it never felt right to me because of the squashed and stretched feel.

I can’t say exactly what triggered all this off, but I realised a little while ago how unnatural this looked and how much better screenshots always looked when presented in the correct ratio. I then remembered years ago that before everything went wide-screen, “square” 4:3 ratio monitors were pretty much all you could buy, especially the early wave of flat-screen displays. So I went searching through eBay and various other second-hand sites but I finally found a site selling brand new, unused 4:3 ratio monitors – it seems like there’s still a demand for the old ratios which is great news for us Amiga and other retro-computing enthusiasts.

I picked out the cheapest option which was an ASUS VB199T-P, a 19-inch SXGA LED IPS monitor with a native resolution of 1280x1024 pixels. This works out to be the perfect resolution for me as all the Amiga screenmodes I tend to run can be expressed as even fractions of this.

For example, my Workbench is 640x512 pixels in 256 colours which for my setup (50Mhz 030 with 16Mb RAM) is a good balance between speed and display quality. This means that every pixel in this screenmode can be displayed by the monitor as a 2x2 pixel square (640 x 2 = 1280, 512 x 2 = 1024). This can be seen most clearly when you look at an extreme closeup of the new display:

It’s perfect! No stretched, blurred or odd-shaped pixels, just lovely crisp and clear squares. This is what my Workbench environment looks like now:

Compare this with the photo at the start of the post; the effect is most pronounced in the text underneath icons, and in the EaglePlayer (music player that looks like a HiFi) window. Total “night-and-day” difference and I was blown away by how much better everything looked, not to mention how it felt so much more like my Amiga of old.

This monitor also works out wonderfully for most games and demos as these are usually (in PAL mode) in a 4:3 ratio of 320 x 256 resolution which works out as “pixels” of 4 x 4 on the Monitor. Demos in particular looked fantastic and it was great to see them as intended once more:

I got carried away and ended up working my way through all the classics, before eventually re-watching some true vintage gems from the late 80s and early 90s:

At which point it was getting dark outside and I realised I should probably call it a day and go to bed! In short, this is easily some of the best money I have ever spent on the classic Amiga and has totally changed the feel of the system for the better. All those classic games and demos now feel brand new to me once again; If you’re currently using a widescreen monitor on a classic ‘miggy, I cannot recommend enough trying out a 4:3 ratio screen. If you don’t want to go for a new one, you can probably pick up one for nearly nothing at your local second-hand store or website as they’re mostly seen as obsolete these days. Far better they end up in the hands of retro-computing fans than landfill!

Until next time… I have to go and have a couple of rounds with Project X now :)

My OS4 Development Environment

| Comments

It’s been a busy few months here, but I’ve still found time to enjoy my Amiga systems. I’ve been grabbing the odd hour here and there to continue my efforts setting up an Amiga development environment and “dip my toe in the water” again. My setcmd utility is progressing nicely and I’ve learned a lot about the tools like AmigaGuide and the Installer that I used on my A1200 back in the day. I thought since it’s been a while, I’d write a quick “brain dump” post and cover two of the big things I’ve finally got sorted out: Picking an editor, and getting Git working so I can publish and share my code.


There’s a huge selection of code editors available for the Amiga ranging from simple text editors to full-blown IDE systems, and everything in between. I started off using the built-in editor MultiEdit which was installed as part of the Enhancer Software pack from A-EON. This is a bare-bones editor but does have some nice features like the ability to open multiple files and so on – think of it like a “Notepad” on steroids:

I did miss syntax highlighting and other advanced editing facilities, though.


At the opposite end of the spectrum is CubicIDE. This is a full-blown IDE based around the GoldEd editor. Although it’s 68k-native software, it works perfectly under OS4 thanks to the built-in emulation in OS4. I purchased the full version which arrived on a CD-ROM and I also intend to install this on my A1200 when I get around to starting the port of my proof-of-concept setcmd shell script into Amiga C.

CubicIDE is very obviously geared mostly towards C development and includes a whole host of features around that but is still quite usable for shell programming. It also understands Installer scripts and provides some useful features, such as the ability to add commonly-used snippets such as dialog boxes and so on straight from a menu:

For my current stage of development though, it was overkill for editing and managing a shell-script based project. The syntax highlighting for AmigaDOS scripts was also a little basic, it only really seems to differentiate between comments, strings, and “everything else”. I’m still probably going to use it a lot later on when I get back into C development, but for now I needed something with more features than “MultiEdit” but not quite as advanced as an IDE.


OK, so some might say it’s “too Unixey”, but (Fun Fact Time!) VIM was actually first developed to bring vi to the Amiga. It’s been my editor of choice for years now due to my work with Unix-based systems and when I first got my X5000 I did try an old port of VIM. But I quickly discovered when run from the AmigaShell the terminal emulation wasn’t really up to scratch. I couldn’t get full-colour syntax highlighting working and various things just didn’t work as well as they do on other platforms, so I’d abandoned it as an option.

Back in May though, an updated version of VIM with a MUI user interface was uploaded to OS4Depot. This was an absolute game-changer for me – with a proper GUI and decent colour terminal emulation, VIM is now as usable (or not, depending on your point of view!) as it is on any Unix systems. It also feels like home to me and I can fly around it very efficiently.

Customising it is pretty much the same as it is on any other system. The documentation says that when you create a HOME: assign, VIM can look in there for a .vimrc file. So added the following in my S:User-Startup that points this to my Work: volume, which is essentially the equivalent of a Unix $HOME directory anyway:


With this in place, I could drop in my usual .vimrc (although I was sad to see that the netrw file browser is not supported under Amiga-like OSes) and I was off! It supports highlighting of pretty much any file I throw at it, although it doesn’t auto-detect AmigaDOS scripts. To resolve this, I enabled modelines in my Work:.vimrc file with the following additions:

set modeline
set modelines=5

And then added the following modeline near the top of my setcmd script:

; vim: set syntax=amiga ts=2 expandtab:

Here’s what a typical development session looks like for me now:

I have Vim running in graphical mode with a couple of tabs open, an AmigaShell session for testing and debugging and of course, AmigaAmp playing some classic MODs in the background. Bonus points to anyone who recognises where the currently playing track comes from ;)

I also spent some time making a nice dark colour theme for my AmigaShell to match the Gvim theme; while I did love the default grey and blue look of the shell for sheer retro appeal, I do much prefer working with this setup.

By the way, you may notice the background is slightly different in each of these shots – the little light-blue “bubbles” are actually drawn by CANDI which is part of the A-EON Enhancer Software pack. I remember the first time I clicked around some of the presets, I didn’t like any of the backgrounds so never really played much with it. But I then discovered that you can add your own backdrops, so now I have my favourite Amiga Keys wallpaper with lazily-drifting spheres over it. It’s really quite hypnotic, and very cool to watch!

So that’s what I’ve ended up on for now anyway. I’ll probably change my mind a dozen times in the next few months but for now I’m very happy with my setup and workflow :)


Last time around, I had experimented with the sgit client to try and make use of Git. Sgit is available from OS4Depot (link below), but there’s now currently an effort by another developer to update it and then merge the changes back into the upstream project. If you’re interested, I suggest you subscribe to this thread on

My goal with using sgit was really two-fold: I wanted version control for my own use (it makes development so much easier when you can track your code changes) and I’m already familiar with Git due to my work. But I also wanted to publish the source of my projects somewhere like GitHub so that they’re available to others. I feel very strongly that as much software as possible for the Amiga should be open-source by default, as there’s so much great software that has been published without the source available and then later abandoned. Which means that it’s effectively frozen in time and can never be updated, so we’re either forced to use old software or constantly re-invent things when a working solution has already been found. In an eco-system as small and fragmented as the Amiga Next-Gen platforms, this is ever more important. Anyway, I’ll get off my soapbox…

The good news is I got everything to work but it took a little trial and error on my part. I finally got it all playing nicely together, so for the benefit of others, here’s my steps:

Firstly, there’s a couple of things that need to be setup in the Amiga environment. I downloaded sgit from here and unpacked it into my Work:c directory. I do this to keep everything I download and add to the system separate from my System partition, so in my S:User-Startup I have a line which adds this directory to my path:

PATH Work:C add

As sgit uses a statically-linked (and somewhat old) OpenSSL build, you’ll need to set an environment variable telling it not to verify SSL certificates. I did this by adding the following line to my S:Shell-Startup script as I only ever use sgit from the command-line:


Not great from a security standpoint, but I’m just happy to have a working Git client at this point!

With those things in place, I was good to go. I did however discover that I couldn’t seem to create a new, empty project with sgit init and push it to a GitHub remote; each time I tried, CPU usage shot up to 100% and my system locked up. No idea what was going on there, but a workaround is to simply create a new repository through GitHub, then you can pull that and add to it once it’s been cloned to your system. For example, after I created a new repository for SetCmd, I cloned it:

sgit clone setcmd

I could then change into the newly-created directory, and set the username and email address for commits:

cd setcmd
sgit config MDR
sgit config [email protected]

Then, I could add a file and commit it:

sgit add 
sgit commit -m "Added first file"

And finally, push it to the origin:

sgit push origin master

I then get prompted each time to enter my GitHub username and password – which turns out is not actually a password, but a developer access token. You’ll need to create one of these and then keep it safe somewhere as you’ll need it each time you push.

It would be nice if I could somehow cache this, but looking at the source for sgit, it looks like it’s currently not supported. No big deal though as it only happens when I interact with the remote end, and it looks like once I get a cross-compiling environment setup it would be fairly easy to add support for e.g. reading a token from an environment variable. I’ll see if I can do that at some point to help out with the project.

Here’s an example run from the AmigaShell showing some of the other sgit commands such as status and diff:

And the final proof – this is what I see in my browser from my Mac!

This is awesome. Once I’ve added a decent and tidied up my code a bit, I’ll make the repository public and look at making a first proper release. Exciting times ahead!

To wrap up for now, I just want to say that modern developer tools such as a Git client, IDEs and editors are a real necessity for any platform to survive so I am very grateful to everyone working on these projects. Big fist-bumps to all involved in making all this possible :)

The Two Worlds Meet

| Comments

The A1200 lives!

My A1200 has been on the “repair shelf” since September last year, when it suddenly stopped working. It was quite hard to diagnose the exact issue as the combination of my Indivision AGA and monitor meant that it never synced up in time to see any error message, and I only got the very briefest flash of colour before the display went black. I thought I saw a purple flash a couple of times; this colour doesn’t appear in any of the diagnostic charts I could find, but it may have been my monitor’s attempt at displaying a red flash. In which case, it could be the Kickstart ROMS at fault, but I couldn’t be sure. I had tried replacing the ROMs with another old set of 3.1 chips, but there was still no improvement.

I tried disconnecting all expansion cards, accelerator and so on, but it seemed to be “bricked”. I pretty much stopped working on it when I got my X5000 but always wanted to get the A1200 back up and running; Emulation is great these days, but there’s no substitute for the feel and “soul” of an actual classic system.

Anyway, I recently ordered a set of 3.1.4 ROMs, mainly because I wanted to add OS 3.1.4 to my set of emulated systems on the X5000 but as I had ordered the physical chips, I decided to try replacing the ROMs on the A1200 with this set as well.

Installing the chips was quite straightforward but I strongly recommend the use of a chip replacement tool to help you. As I was pretty sure the main board was somehow dead, I didn’t use too much care and I just used a flat screwdriver to lever the old chips out. This bent and damaged the pins so they would have been unusable if I decided to swap them back in. Here’s what the new ROMs looked like inserted into the mainboard:

You can also make out the CF card holding my 3.9 OS and software, an Indivision AGA underneath (the red board) and a Blizzard 1230 Mk IV clocked at 50Mhz with 16Mb RAM. I put everything back together and not expecting much, flicked the power switch.

And, oh my word…. IT WORKED!

All I can guess at this point is that I somehow ended up with a couple of pairs of faulty ROMs before I tried the 3.1.4 set. It’s fantastic to have the old beast up and running again, and I spent an afternoon rediscovering all the projects I had been working on, got it back online with a PCMCIA network card, listened to some classic MODs and played some classic games.

The X5000 was not happy

The next morning though, disaster struck. I went to boot up the X5000 so I could get them networked together and share files, and….

Yeah, that doesn’t look good. Every time I pressed the power button on the X5000, the case fans briefly twitched but that was it, no further activity and the system wouldn’t power on. It was almost like it had died in protest at the A1200 being resurrected – like “Highlander”, There Can Be Only One!

I contacted AmigaKit where I purchased the X5000 from as it was still under warranty and they helped me through a very thorough set of trouble-shooting steps. Big thanks to Chris at AmigaKit who responded to my emails, and as it turned out was the person who originally put the X5000 together for me when I ordered it.

I guess this is one of the advantages of the Amiga scene being so “niche” – there can’t be many places where you can talk to the person who built your system and have them help troubleshoot it with you! Here it is with the sides removed while I was working on it (the inflatable Boing Ball came with my 3.1.4 ROMs):

We ran through what the status LEDs on the motherboard were doing, checked the SD card holding the BIOS, removed all expansion cards and also tried disconnecting the front-panel I/O and starting the system by connecting two jumper pins (to rule out a simple button failure or short in the case). The final step was to try a new PSU, and it finally span back into life!

A big relief, and I want to again thank Chris and AmigaKit for their help, and also to everyone who replied to my thread at AmigaWorld.

Together at last

And to round off this exciting few days, here’s what I had been hoping for the last few months – the “next-gen” and “classic” worlds side by side:

Some awesome Amiga times await!

SetCmd Amiga Development Part 2

| Comments

As I mentioned in my last post, I’ve been developing a new “SetCmd” tool for my Amiga systems, both for my own practical usage and also to serve as a re-introduction to the Amiga developer environment. This series of blog posts will cover the progress of this tool, as well as explore the challenges and technologies from my perspective of a returning AmigaOS fan.

I’ve learned a lot over the past few days and even though the tool is currently very much a “prototype” AmigaDOS script, it is working well enough at this stage that it has really helped my day-to-day activities at the Amiga shell. There’s a few screenshots at the end of this post showing my current progress, but to start off with I wanted to share my first “brain dump” covering some of the things I have picked up and/or re-learned :

Installer progress

As I want to make this tool as Amiga-native as possible, I also want to provide documentation in AmigaGuide format (an interactive hypertext-based system, somewhat similar to HTML), and an installer using the standard Amiga Installer utility. I decided to tackle the installer script first, and have already learned quite a bit.

There is apparently a new Python-based installer system present in AmigaOS 4 which can create much nicer and more modern-looking installer wizards (such as the SDK installer – I looked at this amongst other things in another post), but I chose to stick with the “classic” installer tool for several reasons:

  • At some point, I would also like to provide this tool for classic AmigaOS 3.x so I don’t want to make too many choices at this point that limit my options.
  • There are many Installer scripts to use as examples.
  • Pretty much every Amiga user is familiar with the Installer tool.
  • I remember it well from my classic Amiga days and always wanted to learn it!

I started off by examining some existing Installer scripts to get an idea of what the language looks like. It’s an odd sort of LISP-based system, which uses some patterns I found extremely jarring at first. For example, in most languages I am comfortable with, comparision is done like if thing == value. In the Installer language, it looks instead like (if (= thing value)). Still, once I’d got used to that it wasn’t too bad, and I discovered the language is pretty full-featured with procedures, control statements and lots of useful helper commands/functions.

As an example, here’s a block of code which copies the setcmd program file over to a previously created directory, the value of which has been assigned to the #dname variable:

  (source "setcmd")
  (dest #dname)
  (prompt ("Copy SetCmd program file?"))
  (confirm "expert")
  (help @copyfiles-help)

And there’s also a variant which can copy wildcards which is handy when copying .info files along with something – note the pattern parameter is now used and source is empty:

  (source "")
  (pattern "")
  (dest #dname)
  (prompt ("Copy SetCmd AmigaGuide documentation?"))
  (confirm "expert")
  (help @copyfiles-help)

And for running commands, you can use the run command, along with cat (short for “concatenate”) to build up the command string :

(run (cat "C:MakeLink FROM " #dname "/cmds/setcmd/release TO SETCMD:setcmd SOFT"))

I initially found it very difficult to find any definitive guide for this language as nothing was showing up on web searches. After struggling through with trial and error and only example scripts to help, I remembered that this is Amiga-land so there’s probably documentation in a native format. And sure enough, searching Aminet brought me to the Installer dev package. It dates from around 1996 which is shortly before I first left the Amiga scene but still seems to be a relevant source of information. The supplied is a great resource, and you can see it open below along with my Installer work in progress:

I also discovered that you can pass useful information and configuration which controls the Installer tool through standard Amiga tooltypes:

The more I get back into the Amiga, the more I appreciate these details and features that never seemed to make it into other systems!

Version control

As I use version control (usually git) for all my other projects on Unix, Mac and other systems like Haiku[1], I wanted to do the same for this project. However, this is something I’m kind of stuck with at the moment, so I’m curious what other Amiga developers use. Simply put, the only tools I could find (after an admittedly short search) were either very old or incomplete. There is for example, a port of Subversion to AmigaOS 4, but I consider that a technical step back and the port is already 10 years old.

My options for using git seem quite limited – all I could find was sgit. This is sort of working OK at the moment, I have managed to initialise a local repository and commit code but various things don’t seem to work quite how I would expect. I still haven’t worked out how to add and push to an origin at, for example. Diffs and .gitignore files also don’t seem to work although that’s probably something I’ve done wrong, and many of the commands don’t accept the same arguments as I’m used to.

Still, I’m extremely grateful for it as having a limited SCM system is infinitely better than the old approach of millions of files all called things like final_1.bak-v2-bug-fix_DO_NOT_DELETE which you can never remember what they are or why they were labelled like that!

I’ll keep investigating – one option might be to see if the bundled Python installation is up to running Mercurial. I once submitted a patch for this to work on Irix, so maybe in the future they’ll get another patch from The Weirdo Who Likes Old Systems ;)

Remote access

This is more a “nice-to-have” but I admit to being stumped right now. The only way I have of developing this tool is by sitting at my Amiga X5000 which is fun (especially with AmigaAmp blasting some classic 90’s MODs in the background!), but it would be nice to be able to continue on with my work while sitting with a laptop in my living room. So far, the only route seems to be emulation on a Mac/Windows/Linux laptop which is not ideal.

I can’t seem to find a SSH or Telnet server for AmigaOS 4 (plenty of clients are available) which would have let me work from the shell remotely. There is a port of VNC, but using that for development work over Wifi is painful. I’d appreciate it if anyone has any insights – is there anything obvious I’m overlooking ?


Brief shout out to whoever maintains the AmigaOS Documentation Wiki – this has been an invaluable resource. I managed to get myself back up to speed with AmigaDOS after a multi-decade absence using the great documentation, particularly these fantastic guides :

  • AmigaDOS Commands – all commands described along with plenty of helpful usage examples and tips. The documentation for the list command is a revelation – I had always been mystified by that command back in the day!
  • Using Scripts – lots of great examples and tips on how to write scripts, accept arguments and so on.
  • AmigaDOS Advanced Features – more useful tips including a whole section on escape codes for colourised output. I remember working these all out by hand on my A1200 and working out what codes I needed to build up ASCII-art screens for my old scene group!

I saved all these guides locally as PDFs using the “Save as PDF” option from the Odyssey browser. I would have loved to have a resource like this back when I was starting out on my old Amiga, so again a big “Thank You!” to whoever is responsible for maintaining this wiki.


I am now able to use the setcmd running through itself to develop it. This has been very useful and has further validated my need for such a tool – take a look at the example below, where the setcmd installation is pointing to my development version in my Work: volume :

But now I want to switch to my release version, where I’ve installed it to my usual Software:Programs/ directory :

Note that the version number changes in the header of the command, and setcmd show setcmd shows the versions changing. Also note the liberal use of AmigaDOS Assigns – one of my favourite features of this OS, and one that I really miss on other systems. VMS had something similar with System Logicals, and of course Unix systems have symlinks but they don’t work in the same way, and aren’t nearly as useful or efficient.

My next steps are to finish the Installer script, then learn enough AmigaGuide markup so I can together a set of documentation for my tool. A few more bug fixes and general polishing, and I should be ready to release it to the world! This is just the start, however. I have more plans like supporting AmigaOS3.x – probably limited to OS3.9 as that’s all I have readily available at the moment but I do have a set of 3.1.4 ROMs being shipped.

I’d also like to try out different editors, and use my setcmd tool as a jumping-off point into re-learning C on the Amiga, eventually re-implementing it as a pure C program instead of the “prototype” script.

Part of the reason I started off on this journey was to develop my skills to a point where I can eventually start contributing more to the Amiga scene anyway, so hopefully learning enough C (and working out the build process, accessing Amiga libraries and so on) will get me to a point where I can help bring some more tools across to our platform.

Until next time…

[1]=Haiku is a recreation of the BeOS, which I used extensively after I left the Amiga scene. I’ll write more about this OS in some other posts, but it’s nothing short of amazing what this small group of dedicated developers has accomplished. I’ve also been continuing in my mission to submit patches to open-source projects for obscure platforms ;)

Amiga Project in Progress - Setcmd

| Comments

I’ve been having a lot of fun with my X5000 over the past few weeks (more blog posts to come!) but I’ve been working on something recently that I wanted to share. I’ve been enjoying re-learning AmigaDOS and as an exercise for myself, set about building a tool I plan on releasing in the near future. Inspired by some Linux distributions’ “alternatives” system, It’s called setcmd (short for “Set Command”) and lets you easily and quickly switch between different versions of a command while in the AmigaDOS shell.

It’s been particularly useful for me as I experiment with different versions of the UAE emulator. I wanted to share a quick “sneak peak” at my work so far, but bear in mind this is all a “work in progress” and I have a lot more to learn! Anyway, here’s the “usage” screen that provides an overview of the program options:

And here’s a quick walkthrough demonstrating how I use it: First, let’s add a new command under setcmd control. I picked “UAE” for this test, as I frequently want to switch between versions while I’m testing compatibility with my various emulated systems:

I added the command, and now setcmd list shows that there is a new uae command available (note that the setcmd script is also managed by setcmd, so I can easily test new versions!)

A setcmd show uae shows that it’s just a “stub” entry for now; As no versions have been added, if we try to run it we just get a message telling us to add some versions.

OK, so let’s do that – I have two main builds of UAE I switch between: the system-provided one, and the new UAE-1.0.0 I downloaded from OS4Depot:

I’ve now setup two “versions” of UAE, one called system, and another called 1.0 – versions in setcmd can be any format so it’s easier for you to label them according to your needs. So, let’s see it in action! First, let’s try setting the version to “system”, and run the which command to verify that it’s pointing to the correct location:

And now, let’s switch it to the “1.0” version and again verify the path has changed:

There you have it! I can now easily and quickly switch between multiple versions of tools. It’s been a really fun experience diving back into Amiga development again, and I hope to release setcmd on soon. First though, I have to tidy it up, remove some bugs and I also want to learn the AmigaGuide and Installer languages so I can provide documentation and an installer to turn this into a “proper” tool. I look forward to my first proper Amiga software release in decades!

Backups on the Amiga X5000

| Comments

Happy New Year everyone! I’ve got big plans for my Amiga projects in 2019, but thought I’d start off the New Year with a blog post on a not-particularly “exciting” topic, but an important one nonetheless: Backups. As I am experimenting more with my X5000 and Amiga OS 4.1, I’ve been getting particularly “twitchy” that I didn’t have a solid backup/restore plan in place, particularly as some of my experiments will invariably go wrong and I’ll need a way to roll back my changes to a known-good state. I spent a few days researching and implementing a backup strategy that’s ideal for my needs and hopefully there will be something of use to other Amiga owners too.

My requirements were:

  • Create a spare bootable system partition that always has a working copy of Amiga OS 4.1 complete with all my settings and tools
  • Backup my system and other partitions to directories on another disk
  • Create archive files of these backups so they can be stored on another system

I’ll run through my steps for each of these areas in turn. Firstly, I wanted to create a spare bootable partition so that even if I totally screw up something in the AmigaOS boot process, I can still get back to a working system. To do this, I decided to use some of the spare space I had left unpartitioned when I set up my X5000.

Preparing the backup boot partition

The first step was to run Media Toolbox and select my internal boot device which is connected to the on-board p5020 SATA ports:

Next, I selected my boot device which is the 256GB Sandisk SSD installed by AmigaKit:

And here’s what my partition layout looked like, with a decent amount of space free for a secondary boot volume:

I know AmigaOS is a pretty light operating system, but I first checked how much space was actually in use on my current System volume using the AmigaDOS info command:

Not bad, just around 900Mb in use. I decided to create a 5Gb partition for my new boot volume; this was way more than I needed but then disk space is cheap, and it’s always better to have spare capacity in the future:

I named this partition DH3 as I’d already used DH0 to DH2 for my System, Software, and Work volumes. I then set the filesystem to SFS2 as that’s what I’m using on all my other volumes and it’s proven to be reliable so far. It doesn’t however have any recovery tools unlike NGFS, which means that a backup plan is even more important as I’ll have no choice other than to reformat and restore data if any corruption occurs!

The next step was to make sure that I had set the various options needed to allow booting from this new partition. I ticked the “Bootable” checkbox, and gave it a Boot Priority of -20, as that is lower than my current System: volume, which has a boot priority of -15. So this means it should only be picked automatically as a boot volume if my main system volume is unavailable:

With that done, I clicked on “OK – accept changes”, and back at the unit selection screen I clicked on “Save to disk” to write the new partition table to the SSD:

I then formatted the volume (using “quick format” – never do a full format of a SSD!) in Workbench, named it SystemBackup and I was ready to start copying data over.

Making the backup

I wanted to make the backups using something a little more efficient than the plain old AmigaDOS COPY ALL. On Unix systems, there’s a fantastic tool called rsync that can be used to archive directories by only copying over the changes between them. This means that the first time may take a little while as it has to do a full copy, but after that any subsequent runs will be much faster as only the delta will be transferred.

I tried a few of the available tools that can do incremental copies (as well as correctly preserve all the AmigaDOS file attributes) and eventually settled on the fantastic BackUp from OnyxSoft. It’s a 68k binary but works very well on both classic and NG systems – another great example of how AmigaOS 4 can run old system-legal classic software. It has a nice GUI for one-off operations and can also be scripted from the CLI (more on that later). I unpacked this tool into my usual Software:Programs directory, and ran the first backup manually. I did this by picking the Source and Target volumes and clicked the “Backup” button:

This started the backup running and produced some short output showing which files were being worked on:

And a short while later, the backup had completed:

I then ran the backup again to verify that incremental backups were working; sure enough, it completed in a fraction of the time and only transferred modified files.

Uboot modifications

Now I had my backup boot partition ready, I somehow had to find a way to boot into it. On my classic Amigas this would have been straightforward, using the “early boot menu” you can access by holding down both mouse buttons when powering on the system. There didn’t appear to be anything like this in the Uboot firmware on the X5000, though. The only options I saw on that menu are for booting into AmigaOS, MorphOS or Linux. The “Boot options” submenu just lets you pick whether to boot from HD, USB or optical media. So I knew I’d have to mess around with Uboot configuration directly, using the “Command Line” option from the boot menu.

Update : Trevor Dickinson of A-EON has provided a comment below that corrects my assumption above! There is apparently an early boot menu, you just have to press the mouse buttons together at the right time. Many thanks Trevor, for the update! My steps below are still valid, but it’s good to know about this extra environment. I’ll explore this in more detail later on…

The first thing I wanted to do was run a printenv command from Uboot and note the values. This is very important as it’s quite possible to make your system unbootable by changing things here, so having a record of settings is very important in case you need to roll back your changes:

The first parameter caught my eye – amigaboot_quiet. I had no idea what this did, but I hoped it would show some more verbose output during boot. I thought I might then see something in the boot logs which might point me in the right direction to set up multi-partition boot. So I set this value to N (hopefully to disable “quiet booting”) using the setenv command, and then ran boota to start the AmigaOS boot process off:

By sheer luck, this turned out to be exactly the parameter I was looking for! Now, when the boot process starts, I get a menu allowing me to pick a boot volume:

I was really happy that my first guess seemed to take me in the right direction :) I then simply used the cursor keys to move the selector arrow down to select the new backup boot volume, and pressed Return:

This started booting and loading kernel modules:

And then a few moments later, I got the OS 4.1 splash screen and then my Workbench desktop appeared. I celebrated briefly, but I quickly noticed there was a slight problem as it didn’t appear to have worked as I had expected. The system did boot, but when I checked my assigns I saw that SYS: (the boot volume) was still pointing to my System volume on DH0, along with all my other assigns:

This meant that although it appeared that the Kickstart kernel and modules etc. had been loaded from my backup partition on DH3, the boot had continued from DH0, run the startup-sequence from there and so on. So I was getting closer, but there was still obviously a last piece of the puzzle to put together.

I then went back to reading more about Uboot and the AmigaOS 4 boot process. I eventually stumbled upon a thread on the forums where someone was trying to do exactly the same thing as I was!

It turns out there’s one more important variable to set: os4_bootdevice should be set to auto. With this in place, the boot sequence will continue from whichever volume the Kickstart and Kicklayout file were loaded from. Otherwise, it appears the boot process will continue from whichever partition has the highest boot priority – which would always be my original installation on DH0:. I tried setting the two Uboot variables again before trying to boot from the new partition again:

I again picked the backup partition from the boot menu and this time, I had success:

You can see above that my SYS: volume is now pointing to my backup volume, along with all the other assigns. With that work verified, I went into Uboot for the last time, set the two variables I needed and then saved the configuration to the flash device with the saveenv command to make my modifications permanent:

Now, every time I boot I get the boot selection menu and can pick which partition to boot into.

Remainder of backups

Now that I had my bootable System: backup partition, I wanted to also create clones of my other volumes to make sure I have backups for my Software: and Work: partitions. For this, I just wrote a very simple AmigaDOS script (saved into my Work:c directory for all my personal scripts and tools) that runs OnyxSoft BackUp in CLI mode. It first updates my bootable clone, then clones everything (including the System volume again) into a Backups:Clones/ directory on a separate disk. This means that even if the SanDisk SSD holding my volumes dies, I still have a backup on another disk:

SET backup_bindir Software:Programs/BackUp

SET system_source System:
SET system_clone SystemBackup:
SET software_source Software:
SET work_source Work:
; Bootable clone
echo "Cloning $system_source to $system_clone"
$backup_bindir/BackUp SOURCE $system_source TARGET $system_clone BACKUP AUTOQUIT

; Backup clones on separate Backups: volume
echo "Cloning $system_source to Backups:Clones/System"
$backup_bindir/BackUp SOURCE $system_source TARGET Backups:Clones/System BACKUP AUTOQUIT

echo "Cloning $software_source to Backups:Clones/Software"
$backup_bindir/BackUp SOURCE $software_source TARGET Backups:Clones/Software BACKUP AUTOQUIT

echo "Cloning $work_source to Backups:Clones/Work"
$backup_bindir/BackUp SOURCE $work_source TARGET Backups:Clones/Work BACKUP AUTOQUIT

; Display backups usage
info Backups:

This took a long time the first time I ran it, but thanks to BackUp only copying changed files, it now takes only a minute or so each time I run this script.

I was now feeling a lot safer with my volumes all backed up, but I had one more step to complete, namely taking these backups and turning them into single-file archives which I could then transfer off my X5000 to another system, such as my home NAS and S3 for off-site backups. After all, it’s no good having all your backups on one system if that system completely fails or is damaged in some way. My years of running Unix systems professionally has taught me the “3-2-1” backup rule: A good backup plan must have at least 3 copies of the data, 2 of which should be on different media, and 1 should be stored off-site.


So, the final step was working out how to take these backup directories and archive them into single files. My first thought was to use LHA which is pretty much the standard Amiga archival utility. But there was a problem: As it turns out, most “classic” Amiga software is not large-file aware, which means that LHA could only create 2GB archives (which would have been unthinkably huge back in the day!).

This was OK for my system volume which was under 1GB in size, but it would not suffice for my Software and Work volumes which were much larger. I went searching for an alternative solution which could handle creating large files, as well as preserving all the important Amiga filesystem attributes. I posted a question over on the helpful AmigaWorld forums and quickly got a suggestion to try AmiDVD which sounded like a good tool to try as it’s bundled with AmigaOS 4.1.

I’m pleased to say this worked out very well, and was simple to use. I just used the “Create Image” tab, and tested it first by using my Work: volume which was around 40GB in size:

With this done, I then mounted the resulting .iso file and browsed it to verify that my files were all present and still had the correct filesystem attributes set. In the screenshot below you can see the ISO file mounted as a virtual drive, and you can see from the shell and Workbench window that the ISO file is around 40GB in size. I also browsed to the backup of my Work:c directory where I work on my own scripts and verified that the AmigaDOS filesystem attributes were still set correctly:

I then just had to re-run through the process again to create backups of my other volumes. Here’s the results, showing again the large filesizes created with no problem:

I could then transfer these files off my X5000 and onto my Synology NAS and other systems. I would ideally have liked a tool that could be driven from the command-line so I could include in my backup script, but AmiDVD is very straightforward and it doesn’t take much effort to click a few times to create updated backup archives. Still, I’ll continue searching and if I find something I can use from the shell I will update this blog post to cover it. Maybe mkisofs would be a good starting point…

Anyway, now I have a solid backup plan in place (and learned a lot more about my X5000 and the world of Next-Gen Amiga systems!), I can press on with having fun experimenting with my new system and I look forward to blogging more this year. Hope it’s a great year for all you Amigans out there and remember: Only Amiga Makes It Possible!