Or do most of the game logic in the interrupt handler. Many C64 games would do this, as it allowed precise timing of when updates would happen so as to for example not need double buffering at all - hanging everything off the raster interrupt meant you could trivially ensure you updated the screen when the graphics chip was not processing that part of the screen.
It can be that then the points where the new audio information comes wouldn't be properly spaced to produce pleasant sound. The solution described in the article is really beautiful: you let the interrupts happen, just make sure that the as soon as the interrupt returns the task continues but "covers" all the tracks that the interrupt happened, even if there was no separate stack area at the time the interrupt happened. Really cool.
"Previous versions of the CoCo ROM had been licensed from Microsoft, but by this time Microsoft was not interested in extending the code further.[citation needed] Instead, Microware provided extensions to Extended Color BASIC to support the new display modes. In order to not violate the spirit of the licensing agreement between Microsoft and Tandy, Microsoft's unmodified BASIC software was loaded in the CoCo 3's ROM. Upon startup, the ROM is copied to RAM and then patched by Microware's code."
Or do what the original Macintosh did, have the sound buffer consist of a block of memory at the end of each line in the framebuffer. So each scanline would give the audio hardware new data to process.