Author here, thanks for posting! Happy to answer any questions or chat Amiga stuff in general. Bear in mind - as I said in the article - I'm more-or-less a total newbie when it comes to all this stuff. I have been involved in the Amiga scene since I got my first A600 in the 90s, but really just observed the coding side of things from the sidelines although I did enjoy a brief stint as a Graphics Artist using DeluxePaint for a UK Scene group. My C code will probably make your eyes bleed, and I'm sure I've got some factual details wrong but diving back into this platform again (and discovering all the little details that made it so advanced for the time) after a long absence has been a lot of fun!
How do you feel about the Amiga 500 as a platform for teaching systems programming? These are a lot more accessible to kids and the like, than the fully loaded A600 that only a few of us have stashed in the attic/atop the retrocollection ..
Kids really love retro-computing (I'm a curator at such a museum, also) and the #1 request is - how do I get some hardware to get started?
What of the new-school platforms do you consider a viable answer to that question, Amiga systems-hacking wise?
Having done system programming on retro platforms, my recommendation for this specific purpose is to use a great emulator, and the Amiga happens to have UAE which is one of the best emulators around. Debugging will be a lot easier and you deal way less with the grind of using an old piece of hardware. I understand if you want the full retro experience, but the full experience won't necessarily be conducive to better learning.
This. One day I'd like to revisit Amiga coding. I did a fair bit of Blitz Basic and a little bit of 68K ASM back in the day, but learning it was challenging as a teenager in the pre-Internet era.
I'd definitely rather edit+compile/assemble code on a modern PC and do most testing in UAE. I don't need the nostalgia of slow reboot cycles and reloading things from floppy disks when my code inevitably crashes/hangs, let alone editing blurry code on a 14" CRT TV...
The tricky bit is deployment to the Amiga. My only way to put files onto my Amiga at present is a CompactFlash card (or 3.5" floppies)
I don't have ethernet hardware on my Amiga (and may not have enough RAM for that approach), but maybe there's a slower-but-simpler solution with a parallel/serial port link?
UAE makes that deployment easy, making a PC folder accessible as an Amiga drive. The downside is the lack of smooth 50Hz (PAL) display. Although I do have a g-sync monitor, so maybe that's a solveable problem these days...
It’s semi modern, it has everything a modern system has, only less of it. (Except a GPU.) It’s nevertheless very simple, and it’s thoroughly documented.
This means you can treat it as an embedded target and code it without any operating system, or you can take advantage of the OS. (AROS m68k if you are putting together a course, rather than the original proprietary ROM files.)
Modern systems ? I dunno. I wouldn't use anything like Linux, Mac or Windows - there's just way too much indirection and the system as a whole is just too opaque for a beginner. I think the A500 could make a fantastic platform for systems programming teaching. I mean, it's probably going to be AmigaOS 1.2/1.3 so very basic compared to later releases but there's enough in there to hold attention and create something interesting. Plus it's always nice to have something like the original beige "wedge" to hack on, it's a lot more interesting and "real" than working on an emulator.
I think the thing that would hold you back on an un-expanded A500 would be choice of programming language; a C compiler is probably just too heavyweight to use on a basic machine, particularly if you don't have a hard drive fitted. Assembler would be OK, although possibly a little too low-level. Something like AMOS would fit the bill perfectly though: Would run find on older systems and very quick to create something that would hold the attention like a game or demo. Although that's not really "systems programming" as such.
I used to do some systems programming with then M2 Amiga Modula-2 compiler.
They had a complete mapping to the systems libraries and I suppose for the general learning experience M2 is more pleasant than C, although that works as well, of course.
There was quite a lot of M2 public domain software at that time on the Amiga so that it should be possible to find good examples.
That said, system programming on the Amiga is for good or bad much closer to the hardware than e.g Linux, so prepare to see a lot of guru meditations along the way when you have slightly mishandled a pointer or a data type, and there are a lot of pointers ;-)
The best way to develop systems software for the Amiga will probably be cross-development from a more modern platform and programming language. LLVM is getting m68k support which ought to make this feasible in the future, including some recent feature updates https://m680x0.github.io/blog/2023/05/may-updates.html . Though some basic pieces are still missing, such as support for the Hunk format in the LLVM linker.
Very interesting article, I've only vaguely heard of the more modern Amiga computers. Looking at https://www.hyperion-entertainment.com/index.php/where-to-bu... the latest versions of the OS run on the 1200+ with an accelerator, I assume then the A500 isn't really supported any more?
I've got an A500 I bought second hand that I need to play with more, it came with some interesting looking software such as AMOS 3D. Just wondering if you have any recommendations to obtain a HDMI output. I just found - https://www.retropassion.co.uk/product/rgb2hdmi_amiga_500/. Also it sounds like I should probably dismantle it to remove the battery?
OS 4.x runs on PowerPC processors, and there are a bunch of dedicated systems like the X1000, X5000 or SAM460EP. You can also run a "classic" OS 4.x version in emulators or on classic Amigas fitted with PowerPC accelerators. You could always snag a used Mac Mini PPC and run MorphOS on it for a similar experience; MorphOS is a sort of "off-shoot" from the Amiga family tree but has very active development including up to date browsers like https://wayfarer.icu.
Hyperion have also released updated and bug-fixed versions of "classic" AmigaOS, and you can purchase the ROM sets and disks for e.g. OS 3.2 to use with an original machine like your A500.
For HDMI output, I use an Indivision card. It's a little fiddly to fit (has to clip in over the top of some other chips) but gives a great stable and crystal-clear DVI or HDMI output. There are also external "flicker fixer" boxes or scandoublers that turn the Amiga 15KHz video output into something useable by modern displays, but in my experience they tend not to give as good quality output or have lag issues when playing games.
To add to the MorphOS option, there's also AROS which aims for more Amiga compatibility, but also runs natively on x86 PCs or hosted under Linux (you get a window with the full AROS desktop) w/out a VM if you want.
(At one point I had a AROS setup that booted straight into FrexxEd with my Linux home directory made available, and Linux-hosted AROS "booted" the entire OS and started FrexxEd faster than my admittedly bloated Emacs setup would start....)
Ok so it's worth noting that the AmigaOS has two completely separate branches in use today: 3.x and 4.x
4.x is targeted to amigas with PPC CPUs or PPC based accelerators (mid to late 90s accelertors and some newer things like the X5000)
3.x is targeted to amigas with m68k CPUS (all the commodore era machines)
Both 3.x and 4.x are under active development today. The latest 3.x is AmigaOS 3.2.2. The latest 4.x is AmigaOS4.1
With regards support, the A500 is still the best supported Amiga. Its install base and current user base dwarves that of all the other models and accelerators. There were just so many more A500s sold than any other type of amiga. I would not be surprised if you told me that there 2 or 3 orders of magnitude more A500s than PPC amigas out there. So if you are developing for the amiga and want your software used by lots of folk then targeting the A500 will get it infront of the most eyeballs.
Today though most people buy some kind of accelerator for their amiga and the Terrible Fire (TF536) or Individual Computers (ACA500plus) accelerator cards seem to be the most favoured modern choices. Neither of these choices are PPC based cards and the amiga community still favours m68k CPUs.
WRT the battery, the standard A500 did not ship with a battery on the motherboard, only the A500+ did. Some RAM upgrade cards do have a VARTA battery and those could still damage the RAM upgrade card and should be removed.
Sidenote: AmigaOS 3.5 and 3.9 are actually a kinda separate abandoned branch but features of these have been backported to the 3.2 branch.
Do I see there an A1200 with a case that doesn't close properly because you put a 3.5" HD in it instead of the more expensive (and less capacity) 2.5" HD? :)
Edit: Ah, no. I just read the article. It's the accelerator, I suppose.
Ha, good eye :) Nah, you see an A1200 that I am constantly fiddling with, and I frequently take the SD and CF cards out to clone! I do have a set of backup scripts that clone content to a CF card in a PCMCIA adapter but I always feel safer with a full "dd" backup or similar. Because I keep opening it up I just leave the screws removed for easier access and make sure it's kept dust free every so often.
Wow! Starred and saved. Thanks for the tip, that will be so useful for testing and incorporating in my Drone pipelines. I'll have a play and post an update, it looks like it should work nicely with my simple utility. Nice find!
I must say, I'm thoroughly impressed that the Amiga community sticks with and improves the standards that were already set in the early 1990's (AmigaGuide, the Lisp-y installer scripts, LHA, and probably also things that are not mentioned in the article, like AREXX and datatypes) instead of reinventing the same wheel over and over.
There is a fantastic article which I've linked to before that goes into a lot of that: https://datagubbe.se/ltmag/
Datatypes in particular are amazing! I really wish some of these features (see also: ASSIGNs) made it over to other platforms. Which makes me think... A really nice hack (after I finally port SetCmd back to 68k and then bring it to more platforms) would be to add an ARexx port. Rexx itself is a pretty decent scripting language and the ubiquity of it on later-day Amiga systems meant that glue-ing components together and automating big chunks of platform behavior was very simple. Off down the rabbit hole again ;)
I detest Rexx, but love having the Arexx port, but more Linux software and the like than people think have Dbus ports. If only dbus just wasn't so overengineered (ubus is an alternative)...
Also have a long list of projects to make my Linux desktop more Amiga-like again...
> "Just use LHA format archives. It’s the standard compression tool on Amigas and even though there are modern (and technically better) alternatives ..."
LZX had supplanted LHA already by 1994.
> "a 7Mhz 68000 16-bit CPU"
It's a "16/32"-bit CPU, since it provides 32-bit operations/immediates and 32 bits worth of data- and address registers. For all practical accounts of programming the CPU it's a 32-bit machine, no matter the bus shoveling data 16 bits at a time behind the scenes.
> "... but all of what follows is in the context of developing a systems tool in C as that's the language of AmigaOS"
Not sure how to interpret this. You're in no way locked to C if you want to program for AmigaOS. You can load and interact with all of the libraries etc. of AmigaOS in Pascal, E and what-have-you, since there are headers available for almost any language you may want. Even assembly, which for the Amiga is/was a far more common choice for OS-friendly applications than people think.
True, but LHA always felt like more of the standard and tools were readily available and present on most systems. Sort of like how Bzip2/XZ and so on are technically far superior, yet a gzipped tarball is still the universal standard on Unix systems. A quick glance through AmiNet shows the majority of packages there are still using LHA as standard. Even stuff targetting a "modern" Amiga tends to use LHA - grepping the Os4Depot full package list shows:
> For all practical accounts of programming the CPU it's a 32-bit machine
True. I'll update the article to include that - I guess I'm really thinking of things like the 68020 processor (and CD32 which proudly proclaimed "32-BIT" in big letters on the case :)
> You're in no way locked to program for AmigaOS in C.
Also true. From what I can see, calling & opening the libraries from Assembly is remarkably similar to e.g. C, but from browsing the leaked OS source (not that I'd ever advocate for that sort of thing ;) ) it was all originally in C. I wanted to dive in and get a better understanding of the code as it was originally written hence my experiments targeting C. Plus, I knew enough C from my old University days to get up to speed in a short enough timespan. With no memory protection, crashing my Amiga because I forgot to free some DOS object or other was a common occurrence - if I was attempting this in Assembly, I'd probably still be working on a basic proof-of-concept! Although I really admire the skills of those developers who did choose that language to write system utilities, not to mention the magic of the demo-scene. It's just a bit beyond my abilities/time constraints at the moment!
It wasn't all originally in C. AmigaDos infamously was originally BCPL, hence the nasty legacy of BPTR and BSTR types all of the places.
EDIT: To those unfamiliar, which I'm guessing is most people here, BPTR's are regular pointers shifted two bits down... BSTR's are BPTR's to a BCPL string, more commonly known as a "Pascal string" (single byte length as the first byte).
The reasoning for this is language simplicity (too much... I hate it, to be clear):
What in C would be array[index] is famously pretty much syntactic sugar for *(array + index). In BCPL it's !(array+index) or array!index. But whereas C is typed enough that C knows that (array + index) requires scaling index to the size of the elements of the array, BCPL is type-less. So if "index" is 1, array + index will add 1 to the address even if "array" holds 32 bit values.
Since every value is typically the size of a pointer (otherwise the typeless goes straight out the window), on M68k the elements are 4 bytes.
So to make (array + index) work, pointers needs to be left-shifted two bits. Then you can right-shift them two bits for any operations explicitly treating them as pointers (like "!")...
And then everyone having to ever interface with your code from any other language will hate you for all time.
AmigaDOS in AmigaOS 1.x was a port/adaption of TRIPOS [0] to 68000 by MetaComCo. This was because the intended disk OS/API, "CAOS", was nowhere near ready for the Amiga's 1985 launch. [1]
It's the conventions of TRIPOS that commands go in "c" / "C:", libraries go in "l" / "L:" and scripts go in "s" / "S:", which is why these directories and standard assigns are on Amiga disks... but AmigaDOS "libraries" are limited to filesystem handlers, real Amiga libraries are found in the "libs" / "LIBS:" directory.
Even the standard filesystem was from TRIPOS. It had 488 bytes of data and 24 bytes of metadata per 512-byte disk block!
There was a lot of wailing and gnashing of teeth trying to use AmigaDOS 1.x. Charlie Heath and others started the AmigaDOS Replacement Project (ARP, retroactively renamed "AmigaDOS Resource Project" to not sound so nasty) which rewrote all the standard C: commands in assembler and C, using a common arp.library, which also added one of the earliest "standard" filesystem requesters. [2]
Commodore took this onboard.
Commodore created FastFileSystem (FFS) to replace the retroactively-named "Old Filesystem" (OFS) in time for AmigaOS 1.3. FFS removed _all_ per-diskblock metadata and let you lay down contiguous runs of 512-byte blocks!
Commodore rewrote AmigaDOS and its commands in C and assembler for AmigaOS 2.0, retaining BCPL only where absolutely needed to keep filesystem handlers working. They also added a new asl.library with a standardized filesystem requester.
In short, ARP was completely successful in getting Commodore to ditch BCPL AmigaDOS for one written in C.
Firstly - no it didn't. Sorry for nitpicking the nitpick, but the first public release of LZX was February 5, 1995.
Secondly, "LZX supplanted LHA" is an opinion with varying levels of support.
LZX did take the Amiga community by storm, with its higher compression ratios, solid archiving and built-in support for unpacking LhA files, faster than LhA could. Many people started recompressing their archives with LZX... but also many people didn't. Some Amiga magazine coverdisks (e.g. AUI) started using DiskSpare and LZX to get as much on a disk as possible... others stuck with normal disks and LHA.
The majority of Amiga software archives are on Aminet, which is still getting uploads today. Aminet standardized on LhA, not LZX.
Just as a random non-Aminet example, the WHDLoad homepage offers you its software in either LHA or LZX format, your choice. Wouldn't it be LZX only by now if LZX supplanted LHA in 1994?
What the OP said rings true; LhA files are ubiquitous on the Amiga, and also it's possible to portably unpack and create them on other systems. LZX is very popular, but I wouldn't personally say it supplanted LHA, even though I have hundreds of LZX archives.
> It's a "16/32"-bit CPU, since it provides 32-bit operations/immediates and 32 bits worth of data- and address registers.
Eh, you're getting into some real crafty wordplay here. If you want to be technical it's a 16-bit processor with compound operations at 32-bit, in the same way a Z80 is an 8-bit processor that does 16-bit compound operations.
Yeah, if you redefine the terms, you can make it mean exactly what you want. This is exactly what Atari did to label the Jaguar a "64-bit" machine, after all. It doesn't change what people meant at the time when they used the nomenclature (the native operating size of the ALU).
How is it "real crafty wordplay"? 16/32-bit is Motorola's own designation, and that's the width of the registers and the ISA's immediates. When programming the 68k you work directly with 32-bit longwords instead of having to manually herd multiple 16-bit words to achieve the same. Register-combining instructions like those in the Z80 do not exist in the 68000, nor are they necessary. Your comparison is invalid. Perhaps you have no experience programming the m68k family.
I literally wrote an m68k emulator core, along with multiple z80 variants. I'm intimately familiar with the internals of both, thanks.
To reiterate my point, with sourcing (to counter your glib dismissals):
> The design implements a 32-bit instruction set, with 32-bit registers and a 16-bit internal data bus.[4] The address bus is 24 bits and does not use memory segmentation, which made it easier to program for. Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two more 16-bit ALUs used mostly for addresses,[4] and has a 16-bit external data bus.[5] For this reason, Motorola termed it a 16/32-bit processor.
When people refer to bit-width around the generation aforementioned (8-bit to early 32-bit), this is what they are referencing. This is because many CPUs operated on different bus sizes throughout the architecture. What people using the term care about is it's native arithmetic capabilities. Unless you want to run around calling ARM11s "16-bit CPUs" because they support THUMB.
As to what Motorola opted to call it, I couldn't care less about marketing speak regarding notoriously fuzzy buzzword CPU-capabilities; I care about technical capabilities and consistency.
> "As to what Motorola opted to call it, I couldn't care less about marketing speak regarding notoriously fuzzy buzzword CPU-capabilities; I care about technical capabilities and consistency."
Speaking of glib dismissals...
I also care for technical capabilities - such as not having to sacrifice multiple registers to operate on 32 bits of data, or having to issue multiple instructions to load and store 32 bits of data. I don't need to treat the 68000 as a completely different platform compared to when I write stuff that run on e.g. the 68020. I mainly need to accept the higher cycle counts.
And yet, it performed 16-bit operations internally. It's awesome that the interface for the 68k was 32-bit oriented, it made it future-proofed for later iterations. The 68000 still only did fused 16-bit operations and is thus (by the most important metric) a 16-bit processor. For the same reason an ARM operating on THUMB instructions is still a 32-bit processor.
Nothing is "clear cut" when you intentionally obfuscate it.
It was not obfuscated to any of us who used them at the time. Apply whatever purity tests you want, but the reality is that a lot of people used these labels different to how you're using them, and when you insist on ignoring that you're the one engaged in obfuscation.
It is very clearly obfuscation to insist on using a term in ways inconsistent with a widely used way in which it was used, yes. Language.is for communication - when you insist on purity over clarity to those you're communicating woth, you're obfuscating.
I got my first Amiga in early 1992 and the Amigas stayed as my main computer systems up until as late as 2000 or 2001. For most of my years with the Amiga I was part of what's called the "demoscene", mainly as a coder but also doing a bit of music now and then, and for a couple of years I also ran a scene focused (non-warez) public BBS. I also spent a few years in the warez scene as a "trader", slinging warez between BBSes.
For me, LZX was the dominant archive format during the latter half of my Amiga days, whether it was scene productions, warez, or stuff sourced from magazine CDs etc. Most things archived with LHA that I came upon were things that originated from the early part of the 90s and before.
I was old enough back then that I remember actually paying for the shareware version of FrexxEd [1]. I just learned from that page that it's open source now, cool!
FrexxEd is beautiful, and scripted with C-like programming language (FPL), or Arexx, and it has fun features such as giving access to the buffers of your running instance via a filesystem, so you can e.g. call the compiler directly on your open buffers (a lot more useful on a limited RAM system with floppies, granted)
CygnusEd was the absolute business back in the day. I still love it, but my muscle memory just isn't there anymore after years of PC/Mac editors! I guess I've also become too spoiled by modern conveniences. LiteXL runs on pretty much anything and writing extensions is also pretty easy. But maybe I should get back into the habit of using CygnusEd some more...
CygnusEd was first released in 1987. I don't think it's fair to compare with a modern editor that was released 30+ years later.
I have not used either [1], but their choice was based on what was available at the time.
Edit: [1] Actually I did use CygnusEd for simple text editing, but I was not into programming at the time. I don't have a basis to compare it to modern editors, other than the knowledge that choices needs to be seen in the proper context.
I've just got an A1200, installed the latest Amiga OS 3.2 (on CF card). It sits nicely next to my upgraded A500. But my resolution and UI in either of them is nothing like the one shown in your screenshots. I'm almost jealous. Are you using the Hyperion latest? I mean, look at those colours - they pop!
The images from my A1200 are on a very customized OS 3.2/CoffinOS (legally "dubious" AmigaOS distribution favoured by Vampire accelerator users) hybrid system with Faenza PNG icons. But if you have a graphics card (or emulate one in e.g. WinUAE), you can run in high resolutions/bit depths like this. The X5000 screenshots are on a QHD 24-bit resolution as the X5000 is a far more modern machine and has a hardware-accelerated compositor and 3D stack running on a Radeon PCIe card.
Sure! Sorry, I was typing on a phone and it turned into a real word salad/jargon mess :)
I was replying to someone asking how I got my "classic" 1990s-era Amiga screenshots to look so fancy. The built in Amiga AGA chipset is pretty limited by today's standards and gets slower/uses more memory the higher you push the resolution and colour depth. Most classic Amigas run on low-res limited colour screens - the default is 640x256 in 4 colours. On an 68030-accelerated Amiga I could just about push it to 800x600 in 256 colours, but it was very sluggish.
I now have a Vampire Accelerator card[1] which adds a much faster CPU core, along with an embedded graphics chipset, HDMI output, networking, SD card interface and other nice things. The Vampire "graphics card" is driven through the AmigaOS's support for "ReTargetable Graphics" (RTG). You can read about the setup and installation on my site[2].
My vintage 1992 A1200 is running a hacked together OS, using a base of "CoffinOS" which is a distribution of AmigaOS favoured by Vampire accelerator users. It consists of a classic AmigaOS 3.x installation along with all the Vampire-specific drivers, utilities, games and other things all ready to go out of the box. Because it ships copyrighted AmigaOS binaries and other things that may not be 100% legal to redistribute (and the Amiga scene in general is a litigious mess), I won't link to it but it's easy enough to find[3].
On top of this, I have installed various components from Hyperion's AmigaOS 3.2, so it's a sort of mash-up of two different distributions of AmigaOS. To get my fancy looking icons, I used the "Faenza" icon set in PNG format.
Hope that clears it up a bit!
[1] There are loads of accelerator options now for classic Amigas that add faster processors, networking, graphics and other cool things. There are some others mentioned in this thread like the TerribleFire series of accelerators, and the PiStorm accelerator based around a Raspberry PI is also proving a very popular and full-featured option.
[3] Side note - Apollo Accelerators (the makers of the Vampire) are working on ApolloOS which is a legally clean distribution of the open-source AmigaOS clone, AROS. This is what you'll get (and is officially supported) if you buy a new Vampire card or stand-alone Vampire V4 system although CoffinOS is still being developed and distributed by a mystery team.
I'm not old enough to actually use Amiga in the past. My 1st PC was... IBM PC something running MS DOS.
But definitely want to learn system programming on retro machines (beside GBA, Nintendo, etc. Just installed FS-UAE and FS-UAE launcher on my Mac. It asked you to provide the ROM of various Amiga machines (A500, A500+, A600, A1000, A1200 etc). I assume pick A500?
A500 has broadest compatibility of those listed. A1200 is the most capable of those listed (A1200 and A4000 had the upgraded "AGA" graphics chipset) but for emulation it doesn't matter so much as the emulators tends to offer expansions (like e.g. emulated "Picasso" graphics cards for something closer to modern resolutions and colours).
How energy-efficient are old Amigas? I get the appeal of "limited computing" because it forces you to be smart about using the resources. But it becomes silly when an Amiga and crt draws more power than a modern server.
My A1200 power supply (Commodore original) is rated for a maximum consumption of 35 watts, which includes headroom for putting both an accelerator board with CPU+FPU+RAM and a 2.5" HDD inside the computer.
Efficient is the wrong word here, because the amount of computing work they can do for a given amount of electrical energy is pretty tiny compared with anything modern. They're pretty light in terms of energy usage though, and because of the elegant simplicity of the system you don't notice how underpowered they are until you ask them to do something CPU intensive. (Think several minutes to draw fractals that even 20-year-old PCs can draw in realtime.)
I have mine connected to a modern flat-panel display as I use an Indivision adapter, and there are other solutions which is fortunate as CRTs are getting very rare (and fragile!) now. Would still love one for the retro appeal, but I just can't justify it! The power draw from the base system is pretty small, I just checked the power meter my A1200 is plugged into, and powering it on jumped the draw from around 1.6A at 240V to around 1.77A.
I bet it'd be rare to see more than 150W. Maybe not efficient compared to a modern laptop, but probably very efficient compared to most modern servers or desktops under load.
Of course, a CRT is much worse, but using an LCD shouldn't be difficult.
