next gen engine ideas (Page 3 of 6)

Alright, got a new idea - use a "state memory". Now wtf is a state memory? Think about how we implement accumulative pin pulse engines (Octode XL, for example). We basically "remember" the state of the carry flag from add hl,de for a given time (which, in an accumulative pin pulse engine, will control the volume). But in pulse interleaving engines, we evaluate the state only once and then discard it immediately. But it might be useful to actually remember it for some time. For example, we can implement a primitive low-pass filter like this (excuse the sloppy code, it's early in the morning )

   ld hl,0        ;counter, clear it
   ld de,#40      ;freq divider
   ld b,0         ;"state memory"
loop
    add hl,de     ;nothing special going on here, just adding da stuff
    ld a,h        ;HL bit 12 = output state
    out (#fe),a
    
    and #10       ;store the current state in state memory
    or b
    ld b,a
    
    rrca          ;get old state from 8 loop iterations ago
    ;rrca         ;2x rrca = high cutoff, 1x rrca = low cutoff (filter moves slower)
    nop

    nop           ;timing
    
    out (#fe),a
    
    and #ef       ;delete old state from state memory
    ld b,a
    
    ld c,0        ;timing
    
    jr loop

High-pass could be implemented in a similar fashion, because HP_output is basically just (original_output - LP_output). There could be other uses for this "state memory" thing as well.

Been doing some thinking about vibratos. Here's an algo that is reasonably fast, has configurable parameters, and doesn't require a table lookup:

    ld hl,0
    ld de,note_divider
    
    ld c,1                    ;vibrato strength (max 0xf)
    ld b,2                    ;position init (must be ½ of vibrSpeed range - else detune)

loop
    add hl,de        ;11
    ld a,h            ;4
    out (#fe),a        ;11

    ld a,e            ;4
    jr nc,noVibrato        ;12/7

    ret nc            ;5        ;timing
vibrDir                    
    inc b            ;4        ;initial direction (probably needed as configurable parameter)
vibrSpeed equ $+1
    bit 2,b            ;8        ;speed (see above, bit 3 -> ld b,4 | bit 2 -> ld b,2...)
    jp z,vibrDown        ;10
                    
vibrUp
    add a,c            ;4        ;DE += C
    ld e,a            ;4
    adc a,d            ;4
    sub e            ;4
    ld d,a            ;4    
    
    jr loop            ;12
                ;96    

vibrDown
    sub c            ;4        ;DE -= C
    ld e,a            ;4
    sbc a,a            ;4    
    add a,d            ;4            
    ld d,a            ;4    
                    
    jr loop            ;12    
                    
    
noVibrato
    ;... waste some t's
    jr loop            ;12
                ;96

I have a feeling that this thing can be optimized further by using an sbc a,a fallthrough solution, but haven't managed to implement it for the downward slide yet. Let me know if you have any ideas for this.

As far as singing speech synths go, there's of course tavzx: https://www.youtube.com/watch?v=KkZKDJwwb2o
I agree, would be interesting to have something like this in an actual music engine. However, I'd be more interested in implementing actual formant synthesis. I've done a sample-based speech synth a couple of years ago (also with variable pitch btw), it's pretty boring work imo.

Well, trying to imitate the waveforms of the allophones is basically already a sort of proto-formant synthesis

Hybrid Qchan would be doable. Generally, almost any beeper engine can be combined with AY without too much trouble. The main problem is that adding AY would significantly increase row transition noise on most engines, because (re)loading the AY registers takes a lot of time. The other problem is volume balance. For example the classic Qchan is not a good candidate for combining with AY buzzer, because the buzzer is much, much louder. This is why I chose Squeeker-type synthesis for my hybrid experiment, because this type of synthesis produces very loud sound, and it also cloaks row transition clicks pretty well.

Well, as I said earlier, I've retired from writing beeper engines for the time being. So don't put your hopes on me. I do hope though that someone else will pick up these ideas, and I'm of course more than willing to help if somebody is to take up the challenge.

The first example can be done faster with 12-bit counters, at the cost of loosing variable duty:

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

Second example is very powerful. One can create all sorts of waveforms with this, especially if you also play with the distances between the OUT commands. If I understood fourier transformations, I'd have some great fun with this...

My idea was to use a free-running counter. Original idea of an 8-bit counter didn't work, so here is a pretty clumsy version with a 16-bit counter:

    ld de,#80
    xor a
    ld h,a
    ld l,a
    ld b,a
    ld c,a
    
loop
    out (#fe),a    ;11__36
    add hl,de      ;11
    inc bc         ;6
    ld a,h         ;4
    nop            ;4
    out (#fe),a    ;11__36
    add a,b        ;4
    ld r,a         ;9
    jr loop        ;12

Suprisingly it actually works, but wasting a whole 16-bit reg on this seems rather wasteful. Though on the other hand, one free-running counter can serve multiple channels, so maybe not so bad after all.

Edit: On second thought, that register is maybe not wasted at all... because it might be possible to use the frame length counter for this :D
Edit2: Trying out the idea in BeepModular. The effect is less pronounced here because of the volume difference (48 vs 64t), but generally abusing the timer for this seems like a good idea.

Another 1-bit puzzle cracked: How to generate a triangle wave without wavetable lookup. There are some killer modulation effects that you can do with this as well, but I still need to find a few free t-states in order to implement those for 2 channels.

Edit: Ok, got it. Here's a shorter and faster version, 11 t-states free which will be enough to pull of the modulation effects.

sloop
    add hl,de        ;11
    
    ld a,0           ;7    ;timing
    nop              ;4    ;timing
    
    ld a,h           ;4
    rlca             ;4
    sbc a,a          ;4
    xor h            ;4
    
    rrca             ;4
    out (c),a        ;12__64
    rrca             ;4
    out (c),a        ;12__16
    ds 4             ;16
    rrca             ;4
    out (c),a        ;12__32
    
    jp sloop         ;10

Edit2: Example with modulation effect attached.

Hmmf, tried mixing 4 triangle waves. It works, but it sounds rather awful. Not sure why that is. Of course, with the volume level reduced to two bits per channel, the sound will be a bit more distorted. But it shouldn't create all that high frequency fizz. And even when pairing notes (same note on ch1/2 and ch3/4), it's still much more noticable than in pytha, even though the core of this one is faster (200t vs 216t in pytha). Any ideas? Is it maybe because the level changes less often? It'd be great to be able to use the "one counter update per sound loop iteration" trick on this. Because then we could modulate our triangle osc with another triangle osc, which means we'd have primitive FM synthesis running. Well, guess I'm dreaming too much.

Edit: Attached proof-of-concept single channel FM example. It's incredibly simple, 2 ops only, so no change over time. Works but sounds terrible, unfortunately.

Edit2: Did some more tests. One thing I tried was to apply a simple low-pass filter (actual_vol = (last_vol + current_vol) / 2) - no luck. Also tried a very fast routine, mixing 2 triangles in 112t. Even that creates significant parasite tone. So either there's something wrong with my algorithm, or 4 levels is simply not enough to render a passable triangle wave.

Edit3: Sure enough, I can reproduce the effect with a hand-drawn sample in Milkytracker. So the noise is definately caused by the reduced number of volume levels. Damn! I'm afraid that means FM synthesis just isn't going to happen, at least not on 48K.

Recently came across a game with a nice engine I'd not heard before.

Bubble Dizzy (1991) with music by Lyndon Sharp.

Sounds 2 channel plus digi drums

Wow, didn't know about Bubble Dizzy either. Seems the music is mis-attributed to Dave Whittaker on WOS.

I agree, we need more vibrato on the beeper. Hey, I did post a vibrato routine earlier in this thread That one takes 96 cycles though, we definately need to do better. The triangle generator in it's current form wouldn't be usable as the algorithm produces an off-by-one error on the downward movement. But perhaps it's possible to derive something from that. I'll think more about it when I'm back from vacation.

Hmm, Sigma 7 has some brilliant glissandos as well. Wonder if those are hard-coded, or if there's a clever algorithm behind it.

Music in these games is the same indeed, pitched a bit differently, and with different drums.

I didn't look too much into Rally Cross, but by the sound and quick glance at the code it is the same engine as in Zanthrax and other games, i.e. the first version. You can guess some sampling process has been involved into making these drums, but they're not really sound like normal samples (actually pretty cool, unlike anything else).

Bubble Dizzy version of engine has clearly defined traditional samples. The code is very different, not a small tweak, but a complete overhaul. Music data format is the same, though. This and the fact that sound tone is the same, makes me sure it is indeed a second version of the engine.

Damn, seems it's the week of failed experiments for me. In the last days, I tried to implement a very ambitious concept, basically an improved, multi-threaded Squeeker type engine that will calculate optimal wavelength ahead of time, so it's possible to mix two waves with 50% duty with just one output. After trying for 3 days to get it stable, I finally got fed up and put it aside.
So then today I tried to mix 15 square wave channels. Works, but it's... not great. Hear for yourselves.

After seeing this, I was curious if this type of physical modelling could be made to work on beeper.
Well... I guess it can. Voilà, a real-time synthesized string instrument on beeper
This is only a single channel implementation, but there are 79 cycles wasted, so hopefully 2 channels of this will be doable. Another problem is that right now this works only with 8-bit dividers. It would theoretically be possible to go up to 9 or 10 bits, but this would cost a lot of cycles.