6

I'm starting to learn how to program in assembly (z80) on the Amstrad CPC computer. As an high level developper i find it pretty fun and i learn a lot of things about computer and CPU architecture.

As of now i mainly want to play with the embedded AY-3-8910 sound chip because my little project is mainly "sound focused". The Amstrad CPC embeds a Firmware in its ROM containing routines to control the sound chip. This set of routines is called "The Sound Manager".

I wonder what were common practices to program the AY-3-8910 on this computer: Did almost every assembly programmers of music / sound software made use of theses firmware routines or did they bypassed them and addressed the chip directly ? Does theses routines perform well compared to addressing the chip directly ?

The aim of my question is to know if it is worth learning and mastering theses routines or is it better to learn how to program the chip directly, using the chip datasheet.

  • 1
    As always both ways where used. Since the CPC featured rather advanced internal mechanics it's always a good idea to use the ROM routines. Then again, as so often, larger projects spend considerable amount of code on project specific sound functions, where adding low level funcionalty wouldn't add much - but maybe offer additional freedom. So, unless you're doing something realy big, I'd say go with the ROM routines - it'll simplify coding now and can be replaced later if there is need for further optimization. Get it going fist - optimize later. – Raffzahn Feb 9 at 13:14
11

Especially for writing the sound registers, it is advisable to use the built-in routines.

According to the Schneider CPC firmware guide, the reason is the following:

  1. The CPC keyboard is directly connected to the AY chip - Thus, the keyboard service routine (which runs as an interrupt service routine) is accessing the AY ports directly.
  2. Accessing the sound chip sometimes needs non-atomic operations like "register select" + "register write" - If the interrupt service routine for the keyboard collides with such non-atomic access, it (or your own code) might become upset.
  3. You can definitely write code that can work around these collisions, but then you'd end up with writing more or less a copy of the BIOS routines. The overhead these BIOS routines add is not significantly more than you'd have to add in your own code.
  • OK, so it seems more annoying than anything else to program it directly, especially because of the keyboard routine. I'm still interested to know what programmers did by the time (or even now, the Amstrad community seems alive and strong) – sgt-hartman Feb 9 at 12:44
  • I'd be curious whether there's a split between bog-standard two-week Spectrum ports and proper Amstrad titles; that might reveal some nuance behind the decision. – Tommy Feb 9 at 16:13
  • 1
    @Tommy Well, the Amstrad routines provide interrupt-driven sound queues and interesting features like Rendez-Vous. You basically just have to plop on your sound files - The Spectrum hasn't got much in comparison. On the other hand, if you don't use the CPC BIOS for sound, you'll also have to code your keyboard scanning from scratch. – tofro Feb 9 at 16:22
  • 1
    I also guess I've stumbled upon a more nuanced topic than I realised: even cross-platform titles with great Amstrad-specific work — like Chase HQ or Robocop — may have gone lowest common denominator in their sound routines. It doesn't need to be a lazy port just to have no use for those advanced features. – Tommy Feb 9 at 19:23
  • @Tommy I would assume the sound data (but maybe not the routines because of different OS support) between Spectrum and Amstrad ports were pretty identical, as the sound chip - and thus sound capabilities - were the same, at least with later Spectrums. Graphically, games ported from the Spectrum were often worse than native Amstrad games, because programmers apparently really were going for the least common denominator (like monochrome sprites, for example). – tofro Feb 12 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.