Amiga C Tutorial (2022)
pjhutchison.org
pjhutchison.org
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/
Also had the full series of amiga reference guides, which is actually available online: https://archive.org/details/amiga-intuition-reference-manual...
Rom kernel ref guide is also nice to see again: https://archive.org/details/amiga-rom-kernel-reference-manua...
I wish current OSes had some of the features Amiga had. Hot patching of all syscalls was powerful, if although dangerous by today's standards. Thanks to ARexx every application could easily be made scriptable. DataTypes was the answer to the data interchange problem.
And, beyond the SO itself, Aminet predated the packaging systems that are the fortune of Linux distros. The one tool I contributed can still be downloaded today!
The author uses this code to dereference a pointer to a structure member:
engine = *myvehicle->enginesize;
engine = myvehicle->enginesize;
Now I just wish I had the money to buy an Amiga when I was a kid :-)
It's also assigning string literals to char array struct members in a non-initializing context, which doesn't work.
As someone trying to piece together C knowledge from various b0rk3n tutorials (as a pre-Internet teenager in the early 90s) it's pretty provocative. Luckily I healed and levelled up since.
https://retrogames.biz/products/thea500-mini/
Fact is, with a little LCD and a nice keyboard, one could put the Amiga in the 'loo and have a fair bash at the old school while pushing one out, eh .. ?
/oric_telestrat_forever
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.
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 ..
minimig mist branch is a decent implementation in hardware.
The A500 mini is an open source SOFTWARE emulator (amiberry, designed for the raspberry pi) put in a much cheaper/weaker board relative to the pi, enclosed by a nostalgia-inducing box, and sold at a very profitable price.
There's nothing good I can say about it.
For the same reason that one might learn Lua to write a quick crank app for the play.date machine .. or write a synth plugin for Zynthian.
Alternative platforms are, for a passionate hacker/coder/software person, an extraordinary playground for creative development, both personal and product-wise.
All I'm saying is, sometimes it is great to shed the cruft of modern platform development, and have a look at how things could be done - alternatively - in a way that is nevertheless future-useful.
The constraints of developing an algorithm at great length in the Amiga environment, may then result in a value increase when you port the right bits elsewhere .. many a bit of C has led such a slippery life, you know...
Also, for great justice. We made Amiga, they fucked it up. But we can still pretend what it would've been like had it fared better. The main way one does this is by filling in any gaps in its software collection.
The Clonto gives you AmigaOS 1.0 to 3.1.
If you still want Aztec C, it's available here: http://www.clipshop.ca/Aztec/compilers.htm#amiga
What's absent are the precursors to this release, i.e. Aztec 'C' 3.4a and beyond. I for one would like to complete my own Aztec 'C' 3.6a which I bought back in 1988. I backed up the disks to image files in the 1990'ies, but these original disks had read errors by then.
Aztec 'C' was a "classic" compiler which translated what you wrote into assembly language source code (with a peephole optimizer involved), then this was assembled into object code and linked. One of the rare features which no other vendor offered was a custom overlay manager which allowed Aztec 'C' compiled programs to load/unload sections of the program in and out on demand. The default overlay model required that you preplanned which parts of the program had to be in memory at a time, which lacked the flexibility Aztec 'C' offered.
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.
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.
Once upon a time I used the Aztec cross-compiler in DOS to generate 68k code for some embedded point-of-sale hardware.