This is the resource page I wished I had growing up. I learned it anyway, but in spite and henceforth poorly. Author should publish this content as a book. I'd buy it.
I was about to comment the same! If teenage me in the 80's and 90's had this information instead of the AmigaBASIC book, I think my career would have been totally different. It would be several more years before I got my head warped by C/C++ in college.
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?
Cheers! I am gearing up for some OS4 coding eventually (need a PPC Amiga first), and am sure one or more of those books will be helpful. A shame the grandaddy Guru Book has yet to fall into "PD" status.
I remember that Amiga C for Beginners book! I learned C on my Amiga 500 (with 3 megs of RAM and a 20 meg hard drive) way back in 1989. I also had a couple of those big blue Commodore ROM Kernel books.
The DICE compiler is not mentioned, but I fell in love with it!
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!
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.
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 .. ?
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 ..
>but this is a pretty decent implementation, in hardware.
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.
It is a complex, non-trivial operating system which has its merits in terms of design and prudent use of resources. All of this is well-documented and understandable. You can learn how everything works, top to bottom and back again, which is a feature modern operating systems tend to have lost over the years. I would also argue that it is a humane design, meant to be understood.
Alternative platforms are a great way to sharpen ones chops, and as well be an early newcomer to a potentially engaging, large-scale platform of new users who are tired of the mainstream, of which there are plenty.
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...
There is a certain magic to the old Amiga - both its software and hardware - and creating something that shares in that magic just seems right. The computer was practically dead when I was born and even I feel compelled by it.
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.
Yes, Manx Software Systems lost out to the competition, with the last release being Aztec 'C' 5.0 (with patches) for the Amiga (they also sold the source code to their ANSI 'C' compliant runtime library). Version 5 is one of the compilers available for download from the web site you mentioned.
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.
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.
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.
