On the other hand, the likes of Phaser3 is so cycle intensive & specific (and sounding awesome!) that changing or adding anything at all causes sound issues straight away. Took me ages and many attempts to even get it working on the VZ - with my limited knowledge.

Been trying to cut QChan down to 2 channels, no drums, might be what I need. Small player and small music data.

Having been away from speccy and coding for some years, I'm a bit rusty at this. And I've never written sound routines before, just used what's available. Currently going through QChan with debugger to document the code so I know exactly what's going on.

Edit: Just seen utz tutorial on writing a routine, so I'm going to do that instead. Cheers utz, very helpful that...

I.e., the principles I covered in my write-up have nothing to do with the method of mixing. OK, I based Rain on Octode XL because it has low discretization frequency, which made it easier to interleave audio and video codes at high frequency. You can probably make similar claim about the Squeeker engine. I do not think we have any other guidance in this case, do we?

I don't think there is any code for the method Shiru describes, because nobody has implemented it. The idea for continuous sound would be not to call the sound generator through an ISR (because 50 Hz is too slow to make anything but the lowest audible tones), but to interleave it with the multicolour code at regular intervals. The usual restrictions with contention apply there, so it would still be quite tricky.

Actually, I have implemented exactly this idea in my 1K intro "Splash" (2014). The beeper engine there is very simplistic, single voice, but this is purely due to the size limitations I was dealing with.

In fact, I think that it won't be a large overstatement to say that most of my beeper experiments were about trying to push the envelope of how beeper sound can be combined with other things.

Shiru's methods 1 and 2 can be found in quite a few old games with beeper music. I never liked the resulting sound, so I did not do much research on it. Hence, I am not sure if e.g. Manic Miner uses method 1 or method 2 (method 1 seems more likely, given the lack of vsync in the game). My beeper scroller in "Dat Fuzz" (2014) is using, I guess, a variation of the method 2, with one modification: the visuals occupy small fixed time remaining after playing something like 2.5 frames of sound. So, improving the quality of sound is easy - just ensure that the sound does not get interrupted much.

Like I said, method 3 in Shiru's list can be found in "Splash" (2014). At the same time, outside of beeper, I am pretty sure that at least some demos with digital sound use a similar approach (e.g. "Scroller" (2010) or "Atarin" (2018)). In fact, I'd say that the devil is in the implementation detail: visuals usually require v-sync, while beeper (or digi) need +- constant rate of updating, which does not fit well with updating visuals synchronized to vsync or, more generally, doing any non-trivial logic. Specific solutions of this clash of needs can be different and varied; what I did in Splash does not make me happy and I am currently experimenting with another approaches.

A good way to think about all these methods is to think about code responsible for visuals as something that "distorts" sound. Then your strategy to improve the sound quality would always be about something that reduces the distortion. The larger proportion of time you can spend on making the sound, the better sound quality you'd get. This applies to all three of Shiru's methods.

However, there are other methods for reducing the distortion. Instead of trying to reduce the "amplitude" of the distortion ("amplitude" in the PWM sense would be the duration of anything that is not generating sounds), you can change the dominant frequency with which distortion occurs. E.g. the scroller in "Dat Fuzz" operates on the basis of one scroll every 3 frames only partly because this was the only way to significantly change the proportion of time between the work of the beeper engine and the work of the visual code. It is also important that the base frequency of the resulting distortion becomes 18.5Hz (which cannot be heard) instead of the pretty obvious 50Hz produced by engines operating on the basis of single frames logic. If taken to the extreme, some games do all drawing between the rows in the beeper engine, which tends to mask quite well even pretty significant interruptions in sound. Of course, from the point of view of visuals extremely slow updates do not work very well.

My demo "Rain" (2016) was an attempt to see what happens at the other end of the spectrum. What would happen with the sound if the distortion was to operate at very high frequency? In "Rain", the visual code occupies every 4th iteration of the sound loop running at something like 12kHz. It does distort the sound, but the nature of the distortion is such as to create "spacey" sound, which seems a lot more acceptable that what methods 1 or 2 can provide you with. Of course, the type of code you need to write for this mindset is not very vsync-friendly and, in fact, is not very visual-effects friendly. However, you do get surprising amount of time for doing useful work beyond making the sound, so definitely consider this approach too.

Beepfx have give me good results, I've to use it without disabling interrupts, by commenting di and ei instructions.

But the problem is the pitch, as the sound now have to deal with the interruptions and nirvana the playback is slower than is supposed to work on interrupt-less enviroment....

Do you know some way to fix it, besides changing the pitch of the samples?

Do you have any code example for that obscure solution that you mention?

No, if I had something, I sure would publish it already. At the moment, the only game I can think of that kind of used this approach was Sea Dragon port, where I did beeper effects. It used very crude sample-like effects, like every so often during rendering a frame the game just read a bit from an array and outputted it. As it was 50 hz targeted, rendering speed was relatively steady, thus 'sample rate' was steady enough too. I don't have this code around, and can't really recall how many times per frame the routine was called. I think it was the least possible number, to avoid introducing slowdowns. Maybe 8-16 updates per frame.

Since Shiru seems to be busy, I'll try to answer in his place.

I don't think there is any code for the method Shiru describes, because nobody has implemented it. The idea for continuous sound would be not to call the sound generator through an ISR (because 50 Hz is too slow to make anything but the lowest audible tones), but to interleave it with the multicolour code at regular intervals. The usual restrictions with contention apply there, so it would still be quite tricky. Generally, PFM/pin pulse and Zilogat0r's Squeeker method would work best because they both can work with a low sample rate.

For sfx and simple melodies consisting of short blips, doing this on interrupts works fine. Avoid the Basic Beep, as it has a lot of overhead. You can achieve the same result with just three commands:

  add hl,de
  ld a,h
  out (#fe),a

Init DE with the desired frequency divider (for tests, something like #0040 will be fine), and run in a loop for something like 1000 times.

In z88dk, there's also a modified version of the Tritone engine with can be used in combination with game logic. It basically runs all the time and then periodically runs your game code on note changes. If your game logic is simple and doesn't need a lot of CPU time, it might be a good option.

Third, I think is the most obscure one, is applicable to games where frame time is evenly distributed around some nearly constant-time process (rendering usually), so they can call sound routine a number of times per frame with mostly constant pace. That likely would suit well for multicolor engines such as Nirvana. They can have a short sample buffer, prepared outside the raster, then read and output value from the buffer to #FE each N scanlines (very low sample rate, but may work for some cases).

Hi Shiru, first to all, I want to thank you for your mFX player that I'm already using for my games Gandalf and Manic Pietro. Currently I'm working on a Pacman clone and I want to target the 48, with beeper sound fx. Do you have any code example for that obscure solution that you mention?

I've run some test, this are my findings (I'm a newbie on the 48 beeper)

-Sounds can be placed as long they don't mess with interruptions, for example the Basic Beep routine can be used on short intervals and also out254 based sounds seems to be work ok, with no screen flickering or corruption.

-Also I've try to use BeepFx but it disables interrupts.

-Steve Turner player works but it may be interfering with some registers that SDCC needs, as the code jumps to an unexpected place.

-I've placed a call to tiny out254 routine on the Nirvana ISR, to make some noise each time pacman eat a dot and works ok.

What do you think, Any idea or suggestions?

Regards

Engines like Special FX work better with this approach, because of very short pins they're generating.