Amiga C Tutorial (2022)

An "A500 Mini" is basically the same emulator you could get for basically free, plus a case which is reminiscent of the actual Amiga A500, bundled with some video games.

Probably if you are interested in writing software for an Amiga, rather than nostalgia of old video games you might better begin with just the emulator.

Okay, hear me out .. sure, you could do all this with another system too, if you had them available, but this is a pretty decent implementation, in hardware.

You can boot it into a 'proper' A1200 and use it just like that, as a pretty decent little Amiga system - one doesn't have to only run the built-in OS/provided games, you know.. you can boot it like an Amiga would, albeit with USB.

With the distinctly relevant advantage that a) it is a small and compact, unassuming device .. and therefore can be duct-taped to the back of the LCD monitor[1] that has, inevitably, a 'spare' video input, and b) one doesn't have to install anything on your other .. potentially work-provided .. computer .. which you occasionally switch back to, when the cubicle alarm goes off ..

I mean, I use my raspberry-Pi for productive things. Having an Amiga handy here and there, has been great. Even the conference room monitor has extra inputs and some spots for duct-taping ..

[1] or underneath the desk, in the cabinet, whatever ..

I guess it depends what reading material was available. You could've had Amiga C for beginners published by Data Becker in 1987. Not to say it's a great book, but it's a good start if you're keen. Or perhaps a book like Amiga Graphics Inside and Out that starts with AmigaBASIC but goes on to include programs in C. Some of these books are preserved today so you see what you missed out on [0]

Buying the RKRMs would be expensive, but I borrowed them from my library and read them entirely (... I had a lot more free time then). You could also have written to Motorola and got them to send you the 680x0 Programmers Reference Manual and other books for free!

There are all sorts of "what-ifs". If books like the 1980s Usbourne books [1] weren't available, might so many people have become programmers at all?

[0] https://amigasourcepres.gitlab.io/page/books/ccplusplus/

[1] https://usborne.com/gb/books/computer-and-coding-books

Are you Olaf Barthel? Much respect! Your Amiga software is fantastic. Thanks for all the things you've written over the years.

The overlay system was indeed very unusual, Thomas Richter did a good job describing it in https://aminet.net/package/docs/misc/Overlay (and of course it's also covered in Ralph Babel's Amiga Guru Book). That's really interesting that Aztec supported it natively, I never knew that.

But it also seemed to be that, if you wanted to, newer linkers (e.g. blink, phxlnk/vlink) combined with appropriate pragmas in the C code, and an example overlay manager from one of these sources, would allow you to make your own overlay executable?

I can't say I ever did it myself - the nearest I got to seeing an overlayed executable was seeing Titanics Cruncher or Imploder use the overlay feature to decompress while loading, skipping the whole question of loading/unloading nodes.

Yes, Olaf Barthel here. You're welcome :-)

The Aztec 'C' overlay manager code is something of a clever hack which also needs support from the linker to pull it off.

Unlike the original overlay manager (ovs.asm) provided by MetaComCo, two helper functions (segload() and freeseg()) would let you load and unload those overlay nodes on demand whose function pointer address you passed to them. For example, if a node would contain a function called palette() you invoked segload(palette) and, sufficient memory being available, would load the node into memory which would contain that function.

Both segload() and freeseg() cleverly rewrote the jump tables which led to the respective functions through the miracle of self-modifying code (fine in the age of the 68000-68030 but a nightmare on the 68040). The linker did its part by producing overlay information which "hacked" the dos.library/LoadSeg function behaviour, preventing it from ever unloading any of the overlay nodes because that was now the job of the freeseg() function.

Half of the magic of the overlay support happens within dos.library/LoadSeg, one quarter happens in the linker, 20% happens within the overlay manager code and 5% happen in the AmigaDOS manual's developer documentation on how to tell the linker to use overlays.

The original Electronic Arts creativity software (Deluxe Paint, Deluxe Video, Deluxe Music and, um, Deluxe Print) made use of overlays extensively because the original Amiga then featured only 256 KBytes of RAM. With the next year's release of Deluxe Paint 2, etc. the developers had already switched from Lattice 'C' to Aztec 'C' because it gave much better control over which parts of the program would have to be in memory at a time.

You can write an overlay manager in 'C' but it is bound to be far less elegant that the assembly language version. I am familiar with Ralph Babel's 'C' version which (of course) perfectly matches the behaviour of the original ovs.asm code. But I would be really scared to try it in production code.

Thankfully, the use of overlays fell out of favour as newer Amiga models either shipped with more RAM installed, or could be expanded more easily.