Amiga music-making

Peter Korsten peter at
Mon Apr 18 00:38:05 CEST 2022

Hey Jay,

> Nice reply, James!


>> 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.

Sure, but those machines didn't have APIs. They just had hardware. The 
Amiga was one of the first systems to come with a comprehensive API, 
that let you control everything on the system. The Mac, Atari ST and 
Unix/X Windows systems had them, too, but they didn't have the 
ridiculously powerful chips that the Amiga had.

These "cowboy programmers" caused a lot of problems. Because even when 
they used the libraries, they still used them the wrong way. So, the 
Exec library's address is stored at address 4. That's the only fixed 
memory address in an Amiga. Take the 32-bit address that is stored in 
bytes 4 to 7, add a certain offset, and you have the address pointing to 
the address of the code to, for example, create a task.

Cowboy programmers would save those all-important 8 clock cycles when 
creating a new task, and jump to the code to create a new task directly. 
So, when AmigaOS 1.3 came around, which introduced support for hard 
discs, all that crappy cowboy code no longer worked, because the code 
for the Exec library was located somewhere else.

The same went for accessing the hardware. 1985 wasn't really the time 
for APIs, and from what I understand they still code that way on 
consoles –directly accessing the hardware– but the fact that so many 
applications, mostly games, accessed the hardware directly, meant that 
any next generation always had to remain backwards compatible. They did 
introduce retargetable graphics at some point, but by that time the 
Amiga had descended into a death spiral.

>> 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?

Not really. If you store other things than just games on your dh0: and 
dh1:, you might want to create assigns for those as well. But if you 
have Lemmings stored somewhere in either dh0:games or dh1:games, you can 
access that directory with games:lemmings.

Maybe it's less relevant these days, with multi-terabyte discs, but I've 
always found it a very neat feature.

- Peter

More information about the music-bar mailing list