Archive for the ‘Amiga’ Category

Using SNTP time on Amiga

Sunday, May 23rd, 2021

I never really cared too much about having correct time information available in my Amiga. Maybe not least to the fact that the battery backed-up real-time clocks on Amigas are usually not backed-up by a battery.

Getting started

Today, I got triggered to change that. Bubbob42, one of the AmigaOS 3.2 developers, mentioned that he relies on the sntp-client wrapped up in That would certainly be good enough for me. After installing and reading the docs of the package and reading up on NTP (e.g. at again I discovered that “sntp server” would get me a correct date, but NOT my local time in Germany. I would just be behind by a few hours. Bummer!

Homing in

After scratching my head for a bit I checked up on the docs for the Amiga sntp-tool bundled up in UHCTools at Turns out it needed an ENV-variable called TZONE and that I would have to set that to be happy.

From the SNTP-docs: “It will adjust for both timezone offset from UTC and daylight saving time using the TZONE env variable. [..] Unless you set TZONE manually or install AmigaOS4.1, you can use the following comprehensive list of utilities which maintains a TZONE env variable:

After getting and running that, I got TZONE set to “CET-1CEST”. Running sntp again then got me the correct time.

Finishing up

Now, all I needed was to have this run everytime I turn on my Amiga 4000. Since it is already setting up a network connection upon loading Workbench, I wrote a small script at s:NTP-Startup like this:

wait 20
sntp server

and run this from s:user-startup like this:

run >nil: execute s:NTP-Startup

Voilà! Works fine for me.

Amiga 34 Report and Discussion

Sunday, November 3rd, 2019
by Noname/Haujobb
2019 seems to be a golden year for the Amiga scene! After a fantastic demo-competition at the Revision party earlier this year, we now had the dedicated Amiga 34 event-fair which saw perfect weather and a range of highlights that this report will try to cover.
Amiga 34 took place at the “Rheinisches Landestheater” in Neuss, Germany, on October 12 and 13. This was the same place as for Amiga 30 and Amiga 32 in Germany (mind you that Amsterdam, Peterborough and Mountain View saw similar events for the 30th anniversary). But unlike its previous instalments, Amiga 34 was now a two-day event with an extended program and more time to roam and socialise. Due to taking place in a theatre it was also ticketed event, and tickets sold quite quickly earlier in the year. So with a bit of foresight, I already bought my two-day ticket in January.
As the event came closer, I found out that my friend Dascon was also planning to go and that he had even reserved a table and a speaker-slot for demo-scene purposes. Fantastic! Back then, we didn’t know exactly how to fill those spaces, yet, but we were eager to represent the demo-scene and support the event somehow.
Amiga 34 featured 33 exhibitors, 14 user-tables (like ours) and about 30 time-slots that featured different kinds of presentations, be it a talk, a musical act, a quiz, or a panel with contemporary witnesses. It was visited by about 750 unique visitors, with about 520 on Saturday, and 400 on Sunday.

Location gallery:

Exhibition Highlights

Amiga 34 saw a number of highlights, mostly notably on the hardware side, but also some new software and accessories. So let’s take care of the rocks first and look at the hardware!

1.1 Hardware

Remember that the Amiga community split into different camps after Commodore’s demise in 1994, and is now partially divided by CPU-architecture, but most notably by OS-versions. Originally rooted in the M68000 family of CPUs (a.k.a. 68k) since its inception, this is where traditionally most of us would rightfully locate their Amiga. And for the 68k-side of the Amiga, we saw a number of interesting new developments at Amiga 34.
Warp 1260 & Warp 560
From a demo-coder perspective, the Warp 1260 and the Warp 560 from look really stellar. They are full-blown, real 68060 accelerator boards for the Amiga 1200 and 500 respectively, clocked at the regular 50 MHz, with the option to overclock to 100 MHz. In addition to the core functionality of offering a fast CPU and lots of RAM (256 MB DDR3), they also provide integrated retargetable graphics (RTG) over HDMI and audio (RTA), and a fast IDE-port with CF-adapter. There was also talk about Wi-Fi and SD card, an ARM co-processor, and an optional scan-doubler. Seems like these could be the new 68060 cards the Amiga scene has been waiting for for so long. If you are into AGA/060 demos running on original Motorola CPUs, the Warp 1260 is surely going to be worth a look, as the compatibility and timing-accuracy should be a lot higher than with FPGA-based solutions. Expected delivery date is early 2020.
Vampire V4
Another exiting news was the official launch of the Vampire V4 stand-alone, sold as a kit with 512 MB DDR3 RAM, keyboard, mouse, and a 32 GB CF-card. It also comes with a MicroSD-slot, USB and Ethernet, but the drivers for those latter two were still under development. The initial batch of about 30 units was sold-out quickly. Forthcoming batches are said to be sold at the end of the year, or early 2020, via listed distributors only.
The Vampire team also show-cased their existing V2 cards for A500 & A600. An A1200 version is in the pipeline and it will also be based on the V2, meaning that the V4 is reserved for the stand-alone for the time being.
The ZZ9000 is a new graphics card for Amigas with Zorro II/III slots, and probably the most powerful so far. It’s actually a bit crazy, in a good sense. For its core graphics functionality it sports a Xilinx ZYNQ XC7Z020 FPGA and 1 GB (!) of DDR3 RAM, and displays screenmodes up to 1920×1080 in 8, 16, or 32 bit colour depth. In addition to that it also features an Ethernet interface, a video-slot adapter (to get your native chipset modes out via HDMI), and two 666 MHz ARM Cortex A9 coprocessors! Right, so they are said to be used in later versions of this rapidly improving open-source project for offloading computing tasks like JPG, MP3 decoding and graphics acceleration. This might be a welcome addition, as the card will be limited by ZII/III bus speeds when operating in traditional 2D screenbuffer RTG-mode. For the upcoming third batch of production, it is announced that the already mounted USB ports will be activated, as well. Existing users can update the firmware via the SD card interface. For sure, this card will save you a slot or two.
Classic 520
There was also a new accelerator board for the A500 named the Classic 520 which is a successor of the HC508. As the name suggests, this is an 020 board, more precisely hosting a 68EC020, with 8 MB RAM, a fast CF/IDE interface, and a hot-swappable SD-card interface.
New PCBs
There were a number of new PCBs to provide fresh blood for our aging computers. showcased their latest project, ReAmiga 3000, which is a reverse engineered and updated remake of the A3000 motherboard. They also previously did the ReAmiga 1200, as well as the Commodore A3640 CPU-card, and later updated that to an 68060 version called the A3660. Further on showcase was the Terrible Fire 360, which is an 68060 accelerator for the CD32.
There were also the Amy boards, which are Mini-ITX form-factor Amiga compatible motherboard. With the same form-factor there was the 80% second prototype of the Akiko 32, which is another Mini-ITX board. The Akiko 32 is based on the CD32 and thus features the Akiko-chip, hence the name. And then there was the A1200+, which is an improved re-implementation of the A1200 motherboard. As far as I can tell, all these new PCBs were open-sourced as well.
So where would you put all the new cards and motherboards into? Of course you could take them to upgrade your existing machine, and that might probably be the norm. But you could also put them into the new cases for the A1200 which have been around for a while. Or you could put them into the Checkmate 1500 Plus, which is a modern remake of the original 1989 third-party case. It can take motherboards from A500, A600, A1200, and Mini-ITX/Micro-ATX. On the outside it looks a bit like a mix of an A3000 and A1000, with its support for a slide-under keyboard. Speaking of keyboards, you could also get new keycaps in different colours and layouts. And there was even a presentation of a new mechanical keyboard based on the popular MX-switches. The long-awaited new A500 cases did not make it to the show, but have been said to appear in due time.
Non-68k Hardware
The A314 was another interesting sight. It is a Raspberry Pi based co-processor board that fits into the trapdoor-slot of the Amiga 500. The Amiga and the RPi can communicate over shared memory. The currently implemented services provide for a file-system (a314fs) that is mounted in AmigaOS, an amiga-command to execute commands on the faster RPi, e.g. a compiler like vbcc, PiAudio to stream audio from the Pi to the Amiga (connecting ALSA and Paula), and a RemoteWB application that lets you control your Amiga via a remote web-browser.
The PPC camp also had their news with yet another announcement of the A1222 “Tabor” that should run the existing AmigaOS 4.1 and some AmigaOne computers like the X5000 and X1000 on display.

1.2 Software

Also for AmigaOS 4.1, one could see a beta-version of LibreOffice.
The MorphOS guys presented version 3.14 of their popular PPC-based operating system. And I saw an A4000D equipped with a CyberstormPPC running a beta-version of MorphOS 3.13. This would be a big update, as the last official version supporting that configuration was 1.4.5; 14 years ago!
And then there was a development version of MorphOS booting on the AMD64 architecture! This is quite some news as the hardware should be a lot cheaper and easier to get hold of. The demo-system booted on an AMD Ryzen 5 3600, but AMD64 instructions are also what drives Intel CPUs. I have been told that the system provides for on-the-fly just in time (JIT) compilation of 68k code, as well as of PPC-code.
Hyperion presented a beta-version of their 68k-based AmigaOS 3.2, which is an extension of their previously released AmigaOS 3.1.4 that caused an ongoing legal conflict with Cloanto.
There were also some new games for the players. The most prominently displayed was Reshoot R, which is an all-new horizontal shoot-em-up for AGA Amigas that is on sale in different editions (download, disk, CD, etc.). Many people, including me, seem to like it. But I have to add a word of warning, though, as the version on sale does not work on an A4000 equipped with Phase5 68060 boards out of the box! The recently released WHDLoad-patch partially solves that problem. But the game is still a bit unstable with the occasional bitplane-glitch, uninitiated pause, and even crash. Let’s hope that the developer will provide an update to this game.
Further new games to be seen were a boxed version of Gold Rush!, a remake of a 1989 Sierra game, and Rygar: Legendary Warrior, a remake of the 1986 Tecmo arcade game.
Work-in-progress demos of games for OCS nearing completion were the platformer Tiny Little Slug, and the horizontal shooter Inviyya, which both looked really good. There was also the beat’em up Metro Siege, but I sadly didn’t see if for myself.
For vanilla AGA, there were early tech-demos of the vertical shooters Proxima III and Hyperborea. The latter featured graphics by Torben Larsen of Hybris, Sword of Sodan, and Battle Squadron fame, and code by Daniel Müßener, who previously provided quality ports of the original Battle Squadron to other platforms.

1.3 Community Awards, Magazines, and Socials

What else was part of the Amiga 34 experience? Well, you would obviously stroll by the different merchants offering loads of old and new software and hardware. Factor 5 was there, showcasing their rich game-legacy, and selling and signing CDs. And they had a really cool custom bartop Super Turrican cabinet. Different retro magazine were on sale, too, such as the long running Amiga Future, Amiga User, Amiga NG, LOAD, Retrokomp, and the Return magazine, as well as a special issue of the Amiga Joker. You could also grab a copy of Brian Bagnalls excellent books Commodore: The Amiga Years and Commodore: The Final Years, which I can wholeheartedly recommend.
You would also stroll by the different user tables and speak to the proud owners of some well-preserved and sometimes even unique old computers. You could see beautifully case-modded A500 and A2000 machines, an A2500 used by NASA, and the ultra-rare A3000 Plus (even two of them IIRC)(Bagnall, 2019: p. 268, 324). The latter obviously caught the attention of its engineer Dave Haynie when he saw it. There were also quite a few demos running, not only on our machines.
Finally, the event also presented a community award based on a prior public poll on social media. The winners of the Amiga 34 Community Award were: 1.) Apollo Team for the Vampires, 2.) Bert “Wepl” Jahn for WHDLoad, 3.) Steve Jones for the Checkmate A1500 Plus case.
This was all rounded by flawless organisation, a superb location, good and cheap catering, and some pre- and after-show socials. The official social was happening at Alpenpark Neuss and reportedly got some Bavarian flair (despite the event actually taking place in North Rhine-Westphalia) and some much liked beer. A few others, like the 80 or so from the German board, went to a Greek restaurant instead. And we just went to dine at an excellent Indian restaurant in town.


Okay, so we had an awesome time and are all super exited in Amigaland! But what can be learned from it?
First of all, we want more of this! Not only the spirit is there, but the developments actually warrant for it. Luckily, organiser Markus Tillmann and his team are positive about this as well, so that seems to be covered.
Second, the media coverage was pretty good, too, with, German broadcaster ZDF, and Forbes reporting about the event, or different aspects of it. There were also different amateurs filming and putting their videos and pictures up on YouTube and Facebook, which is cool and was even helpful when writing this text. The many presentations of Amiga 34 were also recorded and will be made available on DVD as a complete set, but some are also on YouTube.
Third, the AmigaOS and its derivates are spanning three different CPU architectures by now: M68000, PPC, and AMD64. It seems clear to me that M68000 will stay the relevant branch of those three. But even as the curious owner of two working PPC machines (WarpOS and MorphOS) I am starting to think that the AMD64 branch will eat the PPC systems alive and will rather sooner than later climb to a fair #2 spot, once it is unleashed and picks up some traction.
RTG on the Rise
Supporting graphics cards, or retargetable graphics (RTG) is becoming increasingly more important for accelerated Amigas (i.e. 68060 and faster). The Warp 1260 & Warp 560 both feature RTG, and so does every Vampire, many pre-configured emulators, some big-box Amigas, and just about every PPC (and AMD64) based Amiga-like machine in existence. While typical games and low-end demos will continue to make use of the Amiga’s original chipset (OCS that is, for the record), or one of its later ECS and AGA versions, newer “high-end” AGA code should finally be written with RTG-support in mind. I know that some demo-groups like Elude or Dekandence have been doing it for years now. But many groups, including my own group Haujobb, did not do it so far, and I think that should change in light of the new hardware hitting the shelves. And while we are at it, maybe we should also finally switch to supporting retargetable audio (RTA) through the AHI audio system, maybe in addition to directly supporting the Amiga’s classic Paula and the Vampire’s Pamela audio circuitry. Also, the 16:9 aspect ratio is finally becoming the norm for RTG graphics on Amiga which is a Good Thing (TM).
Dealing with Extra Powers
It is probably quite well known to the reader that the team behind the Vampires is creating their own rendition of a 68k-based machine using their own 68080 CPU as an FPGA-based solution. It features better speed and functional improvements (RTG, and additions to the chipset like 16 bit audio “Pamela”, or Super AGA, short: SAGA) that seem to be quite welcome by the general Amiga public, testified not least to the team just winning the Amiga 34 Community award! But these Vampires also come with some darker sides, i.e. points that are worthy of discussion.
First, there are some compatibility-issues by design. Vampires currently do not work with the latest OS 3.1.4 without modifying the ROM. According to the OS 3.1.4 release notes: “since the Vampire currently does not support Autoconfig or other established means of integrating 3rd-party kickstart modules into the OS, the ROM has to be slightly patched and modified, using tools provided by ApolloTeam“. Also, like any accelerator before them, it is fighting with games and demo-compatibility (from the official V4 launch notes: “OCS/AGA: Many games- and demo I work perfectly, but not 100%“ – sic). I know the team is working hard to minimise these issues. But the situation and discussions about it in various threads on different forums also remind me somehow of the introduction of Kickstart 2.0. You can read up on the story of “AmigaOS 2.0 Incompatibility” in (Bagnall, 2019: p. 276). The lesson learned back then was that you should not break compatibility, and even if it is not your fault that you should take resposibility rather than blaming software makers. And I think this is even more true nowadays, as hardware and software are not made by the same company anymore, as they were in the Commodore days.
Second, there are timing-differences as compared to the original AGA/060 setups. Of course, a new CPU should be faster than their predecessors and the 68080 is just that, which is great news for any user in the market. But it is also difficult for developes to maintain an eye on AGA/060 performance and timing when the 68080 is so much faster. Just developing for and benchmarking on the 68080 would surely result in programs that run too slow on anything with 68060 or earlier CPUs. And this is basically the current no-go for demo-coders, as demo-competitions follow a long tradition of dealing with limits, and AGA/060 has been an established limit in the demo-universe for more than twenty years.
Third, the 68080 puts itself in the tradition of the M68000 family, but breaks with a family-rule. As a reminder, the CPUs used for the Amiga over the years were: 68000, 68010, 68020, 68030, 68040, 68060. Note that I am leaving out the EC/LC derivate versions (of reduced functionality) for the sake of this argument, as also the 68080 boldly states solely the number. Now, the family rule that I want to point out is that each new version adds some functionality:
  • The 68010 added some improvements and extensions to the instruction-set, a loop-mode as the predecessor to the instruction-cache, and support for virtualisation.
  • The 68020 was full 32 bit, improved and extended the instruction-set and introduced the instruction-cache (256 bytes).
  • The 68030 added an integrated memory managment unit (MMU), a level 1 data-cache (256 bytes), and a burst-mode.
  • The 68040 added an integrated FPU, a second MMU, and extended the data- and instruction-caches to 4 KB each.
  • The 68060 was a complete redesign introducing superscalar dual instruction pipelining, an optimised instruction-set, and bigger caches (8 KB each).
Now, the 68080 adds further improvements and extensions to the instruction-set, like AMMX, but basically dropped the 68k-MMU so far! There seem to be some own, “better” implementations of how to do an MMU, but as far as I can read and tell, they are not 68k-compatible and break a few things like established ways of debugging. And that is a problem which causes some friction in the developer-community up to ongoing discussions with OS 3.1.4 core developers about how things have to be. This, again, also reminds me of the AmigaOS 2.0 Incompatibility argument framed above. And to put this longish argument back into the context of the Amiga 34: reportedly there was a face-to-face discussion at the event between core developers of both sides, Apollo hardware and OS 3.1.4 software (namely: Gunnar, Buggs and bubbob42) whose outcome is, yet, to be announced and seen.
So how should we best deal with the welcome extra powers that appear now with the Vampires, but also the ARM- or even RPi-co-processors? Let’s treat them as what they are: as extras! By that I mean: if we assumed them as the new standard right away and optimised solely for their full potential, we would abandon the compatibility with our beloved real machines which are the reason why we still support the Amiga in the first place. And that would be quite silly! Moreover, with those new hardware add-ons, there is the risk of even more fragmentation, rather than unity. So it seems more likely to me that some of the extra power of the Vampires, as well as the ARM co-processors on the ZZ9000 and Warp boards, will be used for making the daily use of Amigas more comfortable, e.g. for faster web-browsing, audio-, image- and video-decoding (c.f. the RiVA MPEG player). For that there would need to be some standards of how to employ those extra-powers, maybe through some coordinated new library-layers. And who knows, maybe we could then even have some emulation of existing hardware abstraction, like Warp3D/Wazp3D, running on those co-processors. The wider software development activities for the Amiga could then be targeting 68060 & 68080 based systems together, and optimise for the lowest common denominator, with RTG, RTA, and potentially acceleration supported through standardized APIs.
Legal Mumbo-Jumbo
Other than that there continue to be OS-licencing issues circumventing the Amiga in general and the Vampires in particular. For example, according to the release notes, it says that the Vampire V4 will be shipped with AROS Kickstart. This is also inline with what Gunnar stated in the Apollo Forum: “The real problem with licensing is, that today there is no legal licensing available. Both companies sue each other and try to proof at court that the other side and their Kickstart are illegal. Os 3.1.4 might be declared illegal tomorrow, same might happen to Cloantos Kickstarts. We do not want to be dragged into this legal battle. Therefore the only sensible legal options for us today are: a) Ship the Vampire with AROS b) Ship the Vampire with ATARI EMUTOS. And this is what we are going to do.” But people buying it at Amiga 34 reported that it shipped with Kickstart 3.1 (said, by team-member Grond, to be licenced at the event from Cloanto); a move that was likely caused by compatibility problems.
This legal problem is not limited to Vampires. To the contrary, it concerns the Amiga scene at large. The legal situation of the different versions of Amiga OS 3.x remains unclear 25 years after Commodore’s demise, and the different parties (mainly: Cloanto and Hyperion, but there is also the “C-A Acquisition Corporation”, led by Cloanto boss Mike Battilana, lurking in the back) are continously battling each other. This is unbelievable and downright toxic for our small community! Remember that the currently active OS 3.x developers do it in the name of Hyperion, whereas Cloanto is giving out licences to prior versions, and also marketing their popular Amiga Forever emulator package with those licences. What if the currently active developers of OS3.14/3.2 loose their motivation again? Would we just be left with another branch of the OS and even more uncertainty?
The widely-used P96 library for graphics-card/RTG support is under a similar difficult situation that finally deserves to be unlocked. Actors here are Cloanto and Individual Computers. Cloanto continues to produce their Amiga Forever emulation package (also handed out as a free download goodie to every visitor of Amiga 34, and free for everyone in exchange for your email-adress and willingness to receive news from Cloanto and Heise Medien) with an included version of P96 for a high resolution Workbench 3.x display. Individual Computers claims to have acquired the full legal rights to P96 from their original authors Abt & Kneer, including one existing licencing agreement for OS4.1 with Hyperion, and subsequently freed the P96 API from former NDA clauses. The ongoing conflicts about P96 and the OS with Cloanto reportedly caused the former sponsor of Amiga Germany events, Individual Computers, to step down as sponsor as they did not wish to line up with Cloanto (read the linked press releases #1 and #2 for more details).
Reportedly, there were meetings between the parties of both topics (OS and P96), and there was an open discussion about it with Cloanto at the end of the event. Also the legal conflict seems to have been recently been put on pause for a few months. But we can only hope that it will also be solved soon, and not be dragged along for another few decades. Our enthusiastic Amiga community deserves some peace about the legal situation, especially after an up-lifting event such as the Amiga 34. And it would be fantastic to finally see joint efforts going towards a unified version 3 of the Amiga OS on a stable legal basis. In an ideal world that would then even include the version 4 of the Amiga OS, in order to allow ports between versions and unleash those developers which are contractually bound to one side or the other. Who knows, maybe we could then even see a clean AmigaOS 5 for 68k one day, once all that legal dust has settled?
Back to the Fun Stuff
Amiga 34 was a blast! I am very happy that I went and took the effort to prepare a table with two machines: an A600 with some acceleration, and my A4060/PPC which would not work anymore without the overwhelming help of jdb78 and Dajimbo (thanks again). As the A4000 could run Planet Potion effortlessly, it was my pleasure to show it to one of its creators, the musician Skipp of Potion, who was also at the event. Turned out, he had never seen it run on an A4060/PPC with CVPPC, so that became a Special moment for both of us.
Dascon and me also held a demoscene talk, covering a bit of history (going back to Commodore, the Altair and Microsoft, as well as the evolution from cracktros), tracking music, and doing cross-development. A video of the talk has recently appeared on YouTube. It was really cool that this talk was well attended in general, and even spurted some interest for the cross-dev-stuff, not least from Factor 5, whose work I used to admire as a teenager and to this day. Also, when we showed a collection of cracktros and it featured one for Katakis on the C64, I checked the audience and can confirm that members of The Light Circle (a.k.a. Factor 5) enjoyed it as well. That was going full circle in a way!
A detail from the talk that surprised me when we compiled the talk is that demoscene produced about 42.700 productions on Amiga (not counting mods and graphics), where there are “only” about 4.284 games (numbers based on searches on the and databases). Of course, games are often the more complex projects, so this is comparing apples and pears, but still this ratio showed a surprisingly high level of creativity from the demoscene. For more details, check the slides of the talk.

3 Conclusion

The Warp cards and the Vampires were my personal stars of Amiga 34 and could lead us into many more years of our wonderful hobby. Hopefully, those years will be characterised by less battles arising from legal uncertainties and camping on fractions of intellectual property (IP) from times long gone. Did I hear people talking about open-source, even? The Amiga scene is already very strong with all those problems. Imagine what it could be like when it finally lets go of its zealotry, solves those problems, and reaches the next level as a community! Amiga 34 showed all the right components. Now it is time to bring them together!

A Final Thought
With all the different developments that appeared at Amiga 34, I came to wonder: can we see a complete and fully licensed new Amiga/Vampire computer on the shelves, again?
If the Amiga managed to do that, going from the current post-apocalyptic hobbyist state back to a full production state, it would be quite a unique phenomenon. Taking a second full swing from hobbyist to production, however small, would be quite true to the tinkering roots of the home-computing movement that once started it all back in the 1970s. Fingers crossed for that!


Shout-outs to everybody I talked to at the event, and thanks to everyone who took the effort to review earlier versions of this text. Personal greetings to the a1k-guys like Apex, Amike, Ernie, Hagbard, Marcian, Nujack, o.eschi, Scrat, Slamy, and Wepl; to fellow demo-sceners like Charly, Skipp, Kiero, Ozan, Teo, Triace, Virgill, and Slimey; and especially to Comatron, Dan and Dascon for the fun dinner.

Sponsors and Celebreties

Sponsors of Amiga 34 were: A-EON,,, Alinea Computer, Amiga Future, Cloanto, KryoFlux, esatus, Rhayader Computers

Officially listed celebreties were: Dave Haynie, David Pleasance, Andrew Clitheroe, Malte Mundt, Trevor Dickinson, Dan Scott, Kevin Toms, Francois Lionet, Michael Parent, Petro Tyschtschenko, Christian Spanik, Teut Weidemann, Dr. Peter Kittel, Bernd Lehahn


Bagnall, B., 2019. Commodore: The Final Years. Variant Press.
You can grab our (Noname and Dascon) Amiga 34 Demoscene Talk from:
Links to further event coverages at:
The online-version of this article is located at:

Amiga 34 Coverage

Saturday, November 2nd, 2019

Selection of press coverage, reports, YouTube videos, and picture galleries.





Amiga 34 Demoscene Talk

Sunday, October 13th, 2019

Today, Dascon and me game a demoscene talk at Amiga 34 in Neuss, which was a lovely event with many important news for the Amiga community. I leave it to someone else to cover all the amazing hardware and software news that premiered there.

Large audience, bigscreen reading "Amiga Demo" at Revision 2018 demo party

The focus of our talk was on cross-development of music and code, with a little bit of historical demoscene and computer-hobbyist background.


The Slides are available in different formats:


Here is a recording of our demoscene talk at Amiga 34 (it’s in English language as soon as I realized I continued talking in German after the introduction, so from 01:45 onwards).

Here is an archival version of the Live-Stream of the talk by Ozan/Rebels.


Music Cross-Development:

Code Cross-Development:

YouTube Videos featured in the talk:

Further links:

Even further links (hint hint)

Haujobb Amiga Framework released

Tuesday, January 1st, 2019

Happy New Year!

As mentioned in our Evoke seminar on Modern Amiga Demo Cross-Development we were planning to make our demo framework publicly available. This has finally been done!

You can now find the release with complete documentation (currently 45 pages PDF, as well as HTML) on

If you ever wanted to code that Amiga AGA demo, but didn’t know the platform, or where to start; or you just wanted to sneak a peek at how we do our demos in Haujobb, then this is it.

Now is the time to get going. Code and debug on PC, sync with the Rocket tracker editor, and cross-compile for Amiga. Go for it!


In the news:



4 GB CompactFlash card-image for Amiga

Wednesday, March 25th, 2015

This tutorial is showing you how to create a fully partioned Amiga CF-card in about 10 minutes from scratch. The process will involve using a Windows-based disk image tool and writing a prepared image-file directly to the CF-card. The resulting card contains four empty Amiga partitions that have been set to the correct MaxTransfer of 0x1fe00 and formatted with PFS3 AIO. The resulting card is known to work in WinUAE and on real Amigas.


So when you are digging out the miggy, like I did during the past festive season, you might feel the desire to put in a CompactFlash (CF) as a hard-drive, at least if you have an internal IDE-connector that is. CF to IDE adapters come cheap and in different sizes, and so do the cards. There are many guides available on how to set it all up correctly, applying different tricks of the trade here and there. The only problem is that it all might get a bit fiddly, which is why I wrote this post.

I have spent several evening checking cards of different sizes and in different configurations of file-systems and partition sizes. To make life a little easier, I documented the process and took an image of the resulting setup that worked best for me using a Windows-based freeware tool.

I am sharing the image-file in this post under the intent that it might be useful, but without warranty of any kind. Following my instructions should not be complicated, but basically use your brain and do everything at your own risk.


  • A Windows machine with an attached or built-in CF-reader
  • 4 GB CF-Card (ideally SanDisk which is what I used)
  • HDD Raw Copy Tool from HDDGuru
  • The prepared image-file

How to create an Amiga-compatible 4 GB CF-card (the card’s original content will be overwritten, naturally):

  • Insert your 4 GB CF-card into the PC
  • Start HDD Raw Copy Tool
  • Follow the instructions laid out in the gallery below (basically: select SOURCE from unzipped image-file, select TARGET to your CF-card, hit START, wait ~10 minutes)
  • Also in the gallery: how to mount the newly prepared CF-card in WinUAE

Final notes:

  1. The described process works flawlessly for me on a current Win7 64 Bit machine. Actually, I just redid it before writing this tutorial to make sure the given information is as correct as possible.
  2. The resulting CF-card works under emulation in WinUAE with 68000 or higher CPUs, as well as on my real A1200.
    1. All drives are formatted with PFS3 AIO, which should work on any Amiga.
    2. MaxTransfer 0x1fe00 has been set on all partitions.
  3. The card is partioned into four drives:
    1. OS1 (~250 MB, put your main OS here)
    2. OS2 (~250 MB, put your alternative or recovery OS here, switch from boot-menu when needed)
    3. Work (~500 MB, put your programs here)
    4. Big (~3000 MB, put your data and games here)
  4. I found SanDisk 4 GB cards to be painless and they are what I have used (tested with “SanDisk Ultra” and “SanDisk Extreme III”, image and process works on both).
    1. Cards might have a few sectors more or less, which was not a problem when I tried it, but your mileage might vary.
    2. You don’t have to buy the faster cards, as the Amiga’s IDE-controller is the bottleneck anyway

The setup of the card is partially based on the excellent German tutorial by Kai Scherrer. His description of how to use the Windows-based diskpart was especially helpful to me.

For me, setting up a CF-card for Amiga-use is now quick and easy and I hope you can agree. Enjoy!


Developing Prototype 1 for Amiga on PC using a mixture of C and 68k assembly

Saturday, May 7th, 2011

This text summarizes the tools and workflows that we used during the development of our Amiga demo Prototype 1, which was released at Breakpoint 2010.


The development of Prototype 1 implicated programmers with different backgrounds ranging from high-level C/C++ engine coding to low-level Motorola 68k assembly coding. Hence we decided to devise a tool-chain that supported mixing C and assembly, which didn’t break backward compatibility, and which worked under WinUAE. C should be used for higher development speed of the 3D engine and some effects, while assembly should be used for time-critical parts like texture-mapping inner-loops, chunky to planar conversion, and also some effects.

Mixing C and assembly requires the use of a linker. While this might seem commonplace for the C coder, it is not necessarilly so for the Amiga assembly coder, who might be used to assemblers that directly generate executeable code and which are not useable for generating the required linkable object code. ASM-One and its derivates are popular examples of such assemblers, and I personally like them a lot. But while I previously used ASM-One as my main assembler IDE, it only played a secondary role in this development process. ASM-One has only been used for two tasks: for porting Optima’s effects to the WickedOS demo system, and for fine-tuning the pure assembly effects due to its short turn-around times. Those effects where later assembled to executable code using Devpac and called in the demo via a plug-in interface that is part of the demo system. WickedOS has also been used for handling hardware-hitting screenmodes, vertical blanc interrupts, and for providing timing facilities.

A look at the tools

The look for an alternative assembler provided two main options, vasm and Devpac, while Maxon ASM, PhxAss, and Optimizing Macro Assembler were briefly considered and then excluded for various reasons.

  • Devpac is apparantly the best and most professional assembler on Amiga IMHO. I actually always made sure that my demo-system was compatible with Devpac, but I just never used its linkable code option.
  • vasm is the assembler in the vbcc package, where it compiles the C compiler output into linkable object code. vasm supersedes PhxAss and provides a Devpac compatibility mode.

Unfortunately some of our code didn’t assemble with vasm and so we were forced to use Devpac. As Devpac is an Amiga application this meant that the tool-chain had to run under AmigaOS, i.e. in the emulator, which increased overall turn-around times.

As a compiler we used vbcc, which looked promising, seemed to be optimizing well, and had been recommended to me by Kalms at the previous Breakpoint. Using vbcc meant that we were going to programm in C99 instead of C++, which also matched Hellfire’s intent of avoiding the overhead of C++ object handling for performance reasons.

Linking was done via vlink, which is also part of the vbcc package. vlink effortlessly linked object files generated by vasm and Devpac, and so it was a clear choice.

Finally, an Amiga version of GNU Make was used to generate the executable-file of the demo.

Development workflow

Development was done on a PC, the real Amiga was only used for testing. This was for productivity reasons, as it meant that we could use modern IDE’s on big monitors, and powerful CPU’s to decrease the significant compile-times. If I remember it correctly, the demo would have taken about 20 minutes to build from scratch on the Amiga 4060 shown below.

We set up identical tool-chains on both development machines with WinUAE, vbcc, and the source folder being at the same locations. WinUAE mounted the source folder from the PC filesystem. This meant that we could use proper text-editors and version management tools for developing the Amiga sources. Using this basis we we then worked from two sides:

  • Hellfire programmed the 3D engine and some effects in Visual Studio on a PC, not even using WinUAE most of the time. To facilitate this workflow he wrote display-functions that were plug-in compatible to WickedOS, so they would later link without problems.
  • I took care of the build process in WinUAE and made sure that everything worked together as a demo.  This was mostly done in Ultraedit, with frequent builds in WinUAE. But when integrating Optima’s sources I also came to use ASM-One again 🙂


The resulting control-flow in the program simply begins with startup-code from C (startup.o) calling the main() function. After some initialisation the system is disabled by calling an assembly function that contains the INITWOS macro from WickedOS. This function also installs the interrupt handlers, starts the music, and then jumps to the mainDemo() function which calls all effects one after another. Upon leaving mainDemo() the system is restored and control returns to main(), which just exits the program. While this seems straight forward in retrospect, I initially considered inverting the mechanism and calling all C-code via the run-time plug-in mechanism I devised for the demo system a long time ago. I am glad that we didn’t do it that way as it probably would have brought us all sorts of trouble.

Our tool-chain can still be much improved. First and foremost we will have to make the AmigaOS-based build process completely optional to decrease the important turn-around time. Although the build process worked nicely, it was just too slow, even in a JIT-enabled WinUAE on a fast PC. Two steps are required for us to completely switch to cross-compilation:

  1. make all our hand-crafted code compatible with vasm
  2. have same versions of vbcc/vasm/vlink on PC and Amiga.

Both steps are relatively small, but they were low on our list and were just skipped. The former should be facilitated by exploring vbcc’s Devpacs-compatibility mode a bit further. The latter could be a bit fiddly, as Frank Wille, the maintainer of vbcc/vasm/vlink for Amiga, is not maintaing a Windows installation for himself. Therefore Amiga and PC versions tend to be a bit out of sync. Maybe recent efforts such as Kusma’s “amiga-dev” could help in maintaining identical PC and Amiga versions of the tool chain?

Regarding the age-old argument that Amiga demos should be coded in pure assembly for performance reasons, I can only describe this as obsolete for various reasons when targetting “high-end” Amigas with 68060 CPU. First, the implied theoretical advantage of higher machine performance is outweigh be the improved programmers performance when coding in a language like C, which helps optimizing on a higher level by testing different ideas and implementations. And seeing Hellfire crank out the 3D engine and its related tools in no time was surely an experience that supported this position. Second, we released another demo, which would probably not have happened otherwise. Moreover, most of the chart-topping demos in recent years on Amiga (on PC anyways) were build with the help of C-compilers (TBL, Ephidrena, Elude, …). Third, those compilers are really good, e.g. I spent an evening to convert one of the more complex texture mappers (that used more variables than available registers) to hand-crafted assembly just to arrive at the conclusion that I didn’t gain any speed! This can also be seen in support of Michael Abrash statement that “the best optimizer is between your ears” (chapter 1 in his “Graphics programming” book), meaning that you shouldn’t revert to using assembly language, or any other particular technique, as the only way of optimizing, but rather optimize your overall design. Taking this even further, I recently found a nice article by Niklaus Wirth – the father of Pascal and many other languages – who reported that for implementing their first Pascal system using assembly was “considered dishonorable”. This was in 1969, so I reckon it is time to catch-up.

What remains to be done for the next demo are general code optimisations, and maybe also getting the profiler vprof to work with our system. Furthermore we might also want to reassess our initial decision against C++.


Not diminishing the fun I had hacking on my Amiga back in the day, I am glad that we didn’t do a 100% assembly demo this time. By making our system work with a fair mix of C and 68k assembly, we harnessed the potentials of the different coders, and came to present a demo in-time (*cough*) for the last Breakpoint, which was the main point anyway.


A big thank you to our artists Muffler and JCS, for their awesome work on the audio-visual side! Big thanks also to Hellfire and Optima for writing all the effects – in the end I only had to put things together.

Thanks to Loaderror and Kalms for sharing their ADPCM players with us, and esp. to Kalms for premium support when the deadline approached. Many thanks also to Phoenix (Frank Wille) for his great tools and friendly support. And to Wayne and Britelite for testing the final version when our hardware was broken.


Please feel free to leave a comment. For ranting about the demo itself, please go to Pouet or Amiga Demoscene Archive (if available). And for watching either run it from the executable, or refer to the capture on YouTube: Haujobb – Prototype 1 [Amiga]

DCD1 – Amiga Demo CD

Tuesday, April 5th, 2011

In 1997 a friend of mine (Dr.Dreyer) and me (Noname) worked on a demo cd project for AGA Amigas with 68030 CPU, because that was what we and many others had at that time. Our goal was to include all our favourite demos and not allow any crap on the CD. Our vision was to have every demo working from CD without worrying about unpacking, setting assigns, fiddling with commandline tools, etc.. We also intended to provide it with a review of every included demo, as my friend was working on his demo guide back then, pack it all up with a nice GUI, and then provide it via the then common distribution channels at a similar price than the Meeting Pearls series.

Although the CD was never finished for different reasons, the compilation of demos was actually pretty complete. The disc lacks the intended graphical user interface, but comes with command-line support that allows running each demo by changing to its directory and running a single command (“j”, or”rs” for reboot-starting). This would trigger a script that prepares the system as required (e.g. set specific assigns, switch to PAL modes for some demos, kill AGA on others) and then run the demo.

Get the CD-image here (multi-file ZIP archive):, dcd1amiga.z01, dcd1amiga.z02, dcd1amiga.z03, dcd1amiga.z04

The ZIP contains:

  • an NRG file for burning with Nero
  • an ADF file for use with WinUAE

The ADF contains an important update (total rewrite) of the tools. Please consider using these tools and disregard the tools that are contained on the CD. Everything was geared towards A1230 with Fast-Ram. I personally had a Blizzard 1230-II 50 MHz, but it should work on other configs as well.

This 1997 project is provided here in the hope that someone will actually enjoy it.