Amiga music-making
Peter Korsten
peter at severity-one.com
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