I can't remember where I found the documentation for it, but I was able to do some pretty bad-ass stuff with a 68K assembler and an Amiga 1000. IIRC, there was a pointer at a well-known memory location that was the head of a linked list of all the OS libraries, so it was really easy to bootstrap to the point where you could set the screen mode and allocate some buffers for video memory, then you just drew on them like a canvas. The location of video memory was based on a not-quite-turing-complete "script" that the copper(?) chip read -- e.g. when a guru meditation error was showing at the top of the screen, the copper chip script was saying "start reading at 0x2222222 and when the raster gets to row 60 start reading at 0x4444444...". You could do freaky stuff with that script, like draw "pixels" of any of the 4096 possible colors, that would end up being about 8 real pixels wide by one high, which begat raster bars and blocky scrolling text. Ah, but nowadays you can't touch the bare metal, and there's nary an API that does anything but crash when you try to use it in an unintended way.

Yes, AbsExecBase, at 0x00000004 was the pointer to the exec library, from which you could get at anything on the Amiga. I still marvel at how everything was a linked list - quite a beautiful OS in some regards (if it wasn't for the lack of memory protection :(

Expanding on this a bit.

Everything was relative on the Amiga. The only thing absolute was AbsExecBase at 0x4. You get a pointer to this library and then, from there, you can locate more libraries by calling FindLibrary() (or something like that).

AbsExecBase is the ultimate proof of the old adage "Any problem in computer science can be solved with an additional layer of indirection".

exec.library is a great design. The way programs know nothing except for AbsExecBase, and it points to a table of function pointers of which you have the offsets of.

In a sense it was a Component Object Model(COM) like the one in Windows. You call exec->OpenLibrary("name of lib", version_of_lib) and it returns a pointer to a table of function pointers of which you know the offsets of. It could even handle multiple versions of a library in principle. In reality makers of libraries just made sure the function table was the same, and added new stuff at the end.

You have to call CloseLibrary(libptr) to release the instance. Pretty similar to Objective-C's and COM's release().

OpenLibrary was allowed to return a different pointer for each call, but the early exec.library did not do this AFAIK.

Great design really. And how signals and message system works is just beautiful as well. I really get why Matt Dillon(of FreeBSD and DragonflyBSD) wanted something similar in the BSD kernel.

I still have the Amiga Kernel Reference Manual for exec in my shelf.

"... except for the problem of too many layers of indirection."

Actually, I learned 68000 assembly by hex-dumping a freeware assembler to find the full set of OpCodes and some reverse engineering. That, combined with some trial and error (and a few magazine articles that actually had a little bit of ASM {} C), and I was able to do some very cool stuff pretty quickly).

Boy, I miss those days :(

You aren't the only one. I always wonder what we could do today to synthesize new environments which capture some of that feeling and will actually be interesting to people who aren't just suffering a fit of nostalgia.

For me, the Raspberry Pi comes close. It's a limited machine, the specs are the same for everyone with your model and there's plenty of scope to make it do impossible things if you apply yourself.

Is the hardware of the Raspberry Pi really fully documented? The GPU too? How about WIFI chips?

I've tried several times to make a tiny kernel for x86, but always feel it's either too old interfaces like the PIC, TIMER, VGA, IDE etc, or chip specific. I can't give my friend a bootable USB because he/she might have a different hardware setup.

Everything that's needed to make an OS is documented, either directly or (like USB) in the Linux kernel's source code. Even the GPU is much easier to support than on a PC because the OpenGL ES driver is running on the GPU itself. You just talk to it through a mailbox interface.

No, there are plenty of closed components with only binary blobs and header files for the programmer. But bare metal coding on it is still very doable and popular.

Well, I couldn't find anything. Zero.

Plus using BBSs implied buying a modem and paying for long distance phone calls. Both completely out of my parents' budget.

In a sense, Amiga demos were actually open source. Coders wrote in assembly, which is a short step from machine code. As most demos were compressed, it required an additional step to get to the actual machine code before you could disassemble. Alternatively using a cartridge like Datel's Action Replay makes it possible to dump the relevant routines to disk. Granted that reading disassembled code is a little more difficult than the original code, it is enough to learn how various demo routines were implemented.

Ever since the term "open source" was coined in 1998, it has had a precise definition[1], and according to that definition, most (all?) Amiga demos are not open source.

1: http://opensource.org/definition

It should have been clear I was referring to the spirit of sharing in the Amiga demo scene itself.

It was no secret people were looking at each other's code. Reviewing the code was a way to learn about how to implement demo routines. But it was also a practical way to learn about programming the machine itself. Things you will not find in any manual.

I was not making a claim about licensing. Perhaps you are not familiar with the notion of a metaphor.

I understand your point but I think that would be stretching the definition of open source, which to me means that the text files used to write the program are available for anyone who want them.

Just shipping a binary that happens to be very close to the language used to write that program wouldn't qualify as open source (and it would still be missing a lot of useful information, such as loop labels, memory location names, etc...).

The fact is there was little distribution of assembly source in the Amiga demo scene. So there is no way this can be called "open source" by the standards we recognize today.

But the demo scene was anti-commercial in nature. The creators gave their demos away in good will. Nobody cared if their work was reused unless it was a blatant rip-off or was used for commercial gain. And disassembly was standard operating procedure to hack on the source code.

So there was some sort of ethos at work, which seemed to arise naturally and spontaneously. And it reminds me of the open source spirit.

> it would still be missing a lot of useful information, such as loop labels, memory location names, etc...

I agree the disassembled code would be missing these things. But they are only conveniences for an assembly programmer.

There is almost 1:1 correspondence between assembly code and machine code, which makes the task a lot easier than disassembling optimized C code for example.

And on a practical level, the lack of labels and names doesn't stop you doing what you want with the code.

For example the IDE used in the Scoopex tutorial above is ASM-One by TFA. But TFA are not the original author. ASM-One was a commercial product. And TFA added some very useful extensions despite not having the source code!

I have used quite a few Amiga music trackers over the years. But they all descended from the disassembled code of Karsten Obarski's abandoned Ultimate Soundtracker [1]. The lack of assembly code was never a practical problem.

[1] https://en.wikipedia.org/wiki/Ultimate_Soundtracker