Amiga music-making

[Jay Vaughan]

Nice reply, James!

> 68000 is nice. It's very orthogonal, although you have to weigh the pros and cons of the extra time required to write code that doesn't crash your Amiga. Because the Amiga doesn't have memory protection, and you'll soon get used to the Guru Meditation.

Yeah, I’ve seen this a few too many times today, just hacking around.

> 
> There were some other languages on the Amiga, such as AMOS, and you may want to have a look at ARexx. My perception is that most development took place in (Lattice?) C. The code is performant enough, unless you really want the last bit of performance out of the CPU, and I don't think C++ ever caught on.

Not really looking for performance, just fun. :)

> 
> Getting the last bit of performance out of the Amiga, rather than the CPU, means using the custom chips, though. And this you can do via the APIs, or by accessing the hardware directly. There isn't really much of a performance benefit to using the hardware directly, but some developers would do so anyway as a matter of course. These were people that came from 8-bit environments, and who wouldn't recognise an API if it kicked them in the behind.

Well, I have about twelve 8-bit machines in my collection and I’m honestly finding it kind of refreshing to go back to assembly language programming in an environment where knowledge of ROM addresses is key. This is kind of the point of my exhibit - to give folks the context of where we came from and compare to the cyclomatic complexity of where we are today. 

> One example of using the custom chips is for sound playback. You tell the Paula chip where to find a sample, and at what sample rate to play it. Once it starts playing, you get an interrupt, so you can enqueue the next sample. Playing around with interrupts means that playing sound takes very few CPU cycles.

:)   My colleagues at work (Austrian Audio) seem to think this is still the only proper way to do things.  Of course, they’re doing ANC and other DSP things, so they’re .. probably right. 


> Another example is the Copper co-processor. It has three (!) instructions, but it's synced with the vertical beam, so halfway through drawing the screen you can change the horizontal resolution, bit depth, display mode, colour palette, or anything really. This is how a Screen (the data type) is implemented.

This was something I always wondered at when Matt M showed me how he could drag the Workbench, which was in one resolution, down from the screen and reveal his graphics work - in another resolution - seamlessly.  That always seemed like voodoo to me, so its good to be getting the point about Copper, finally.


> One nice thing about AmigaDOS is the "assign" command. For example, if you have your games in dh0:games and dh1:games, you can put "assign games: dh0:games" and "assign games: dh1:games add" in a startup script, and now you can use "games:" to refer to both directories. You can even refer to volumes that haven't been mounted yet. I'm not aware of any other operating system that does this.


Linux unionfs?


j.
—
Jay Vaughan
ibisum at gmail.com