10

A lot of games on the Amiga killed the OS and accessed hardware directly, a practice discouraged by Commodore to the point that AGA hardware was AFAIK undocumented unless one used the proper OS functionality (OpenLibrary on graphics.library and the like).

I’m curious though how much of a performance penalty there really is? I know this is subjective, but assuming a system like a stock Amiga 1200 or CD32, would it have been feasible to make a “Triple A” game (for 1994) just using the official APIs? If not, what would be the biggest blockers? AFAIK stuff like DMA and Copper Lists were supported already, but I’m not sure what else direct hardware access offered? (If the state of “optimizing C compilers” was an issue, I wonder if Assembly programming made it more feasible?)

8
  • 3
    Anywhere between Zero and some. There can't be no answer without a concrete use case as it all depends on game, functions used and power needed. Making a text adventure or Monkey Island run is for sure a different class than porting Xenon 2 from an 8 MHz Atari where it already used every trick there is down to a more than 10% slower Amiga. Not to mention preferences of programmers back then who often simply used direct hardware access because they were used to do so, even if there was no need at all. Commented Dec 29, 2025 at 4:55
  • 5
    There's probably some speed penalties of varying degrees using libs vs hitting the hardware directly but I don't think that's the primary reason devs avoided it. The main issue in those days was limited amounts of RAM, and especially CHIP RAM. Just having the OS loaded at all carries a pretty heavy penalty on how much free RAM you have available to run your game. Commented Dec 29, 2025 at 5:37
  • 1
    @mnem That was, obviously, also a distribution problem: Game developers wanted a "insert disk, switch on, play" flow - With the OS, that would have introduced a licensing problem, a disk space problem, and would likely have collided with copy protection schemes that were common at that time Commented 2 days ago
  • 2
    One thing to also consider speed wise is: Who was best at writing hardware accessing code? The people who wrote the OS, or the people who wrote the game? Commented 2 days ago
  • 2
    @Tommy which makes the 'killing the OS' even more confusing, since you only could totally kill kickstart on a A1000. IIRC, there are some differents ideas of where the border goes between an OS and a BIOS/BDOS etc. Is Kickstart a full OS, or is it only the BIOS/BDOS of the Amiga? But that is another question... Commented 2 days ago

2 Answers 2

Reset to default
9

I think your question is more nuanced than you realize because there are a couple of critical anachronisms at play:

  1. In the 1980s, even sophisticated computer hardware like the Amiga was simple enough for a competent assembly or C programmer to understand most of the hardware features available, how they worked, and how to program them directly for maximum benefit of their program. It was much like what we call "embedded programming" nowadays.
  2. For the Amiga, and its contemporaries like the Mac and Atari ST, there was a necessity to provide highly reusable routines, usually in ROM, that served both as a simple hardware abstraction for the programmer and as a means of assuring compatibility as underlying hardware details were iterated for the platform.

Because of #1, you should not under-estimate the potential that programmer's avoided using standard Amiga toolbox routines, present in the Kickstart ROM, just out of laziness. If they had studied the hardware enough, why bother to also study the "approved" way of accessing it. They could simply disable the Exec and device drivers, run their program single-tasking, and control the hardware directly. The only downside being their program might break in the presence of new or non-standard hardware.

However, some programmers would have embraced the effort that went into the ROM Kernel Routines, and would have learned them so they could confidently reuse them in many programs and avoid the breakage of hardware changes.

They might have still done their own custom booter (but using trackdisk.device), and they might have still disabled Exec (using the approved API for that) and run single-tasking. Then they might take advantage of the graphics.library to setup the display in a way that would safely work with the next Amiga hardware revision. And they might also use dos.library for saved games or for making their software HDD compatible. In that case, they are using the "OS", just not all of it. They are choosing the parts that suit their application.

I think this second approach was way more common than you indicate in the question. The ROM Kernel was actually pretty popular with Amiga programmers and pretty widely used for all programs, including games. It was also flexible enough that you could use only what made sense for your program. You did not have to bypass these sensible parts in order to get adequate performance. If you did, chances are high it was just out of laziness.

Improve this answer
3
  • (a) I don't understand how writing software to directly control the hardware is the lazy option instead of using function calls that took care of everything. The laziness theory doesn't make any sense. It was a ton of work programming Amiga games, they were far from lazy. (b) Living thru that time with friends trying to low-level program the Amiga's graphics, I'd suspect (also guesswork) that programmers wanted to avoid any unknown overheads whatsoever in the graphics operations. Games programmers were trying to squeeze as much from every clock of those systems (same as always, same as today). Commented 20 hours ago
  • @TonyM The argument is that it's lazy because the rationale is "If I need to know all this hardware stuff anyway in order to get best possible performance, and that's enough to implement the thing, why should I waste my time also learning this whole other API?" (Where "learning this whole other API" is at least somewhat necessary to know what benefits you can gain from using it.) Essentially, "lazy" in the "blub paradox" sense. Commented 18 hours ago
  • @ssokolow, yes I know and I'd acknowledged and discredited all that in my first comment, for BrianH. Commented 17 hours ago
-3

Let's take a real world example: Pac-Man that uses nothing but operating system calls for its graphics, sound, and scheduling. Free of AI, just pure '80s tools.

Improve this answer
2
  • 4
    While interesting it would be more relevant if expanded to talk about what performance impacts using the OS calls brings with it. Given the hardware that ran the original Pac-Man an Amiga should have plenty of head room to run a clone on top of OS functions. Commented yesterday
  • 3
    What’s AI got to do with any of this? Commented 23 hours ago

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.