Search options (Page 25 of 41)

I believe there may be another way of fak... err, I mean generating a saw wave on beeper. For this, we need to look at the frequency spectrum, rather than the waveform. In the frequency domain, a square wave is characterized by having a peak at each odd harmonic. That means, for a 440 Hz, 50% duty square wave, frequency components will be present at 440*3, 440*5, 440*7 Hz, and so forth, but not at 440*2, 440*4, 440*6 Hz etc.
A saw wave, on the other hand, peaks at both even and odd harmonics. Thus it can be approximated by mixing a series of square waves with frequencies of f, f*2, f*4, f*8, etc. With the "fast accumulation" technique (add hl,de \ ld a,h \ out (#fe),a) we can easily achieve this by rotating A to get the required multiples. Doing this with 3-4 frequencies should already give a reasonable approximation of a saw, because the missing components will be high enough to fall out of the range at which humans can reliably detect the difference.

Cheers guys! All that digi stuff aside, my favourite engine from this year is probably Squeeker Plus. I do hope the other engines will get some love, too, though

Aye, sounds intriguing indeed, garvalf! Can we haz teasor nao?

Also yay for 15 minute Space Beeps!

Well, y'all pretty much know what I'm up to - trying to find new 1-bit tricks of course Also been spending a lot of time on that MDAL thing the past weeks. In December, I'll be taking a break from 1-bit as usual, so you won't be seeing me around these parts so often. Will see what I can finish up till then. Perhaps I'm gonna work a bit more on HT2, and maybe make one more Speccy engine.

Discovered something today. It may seem trivial, but nevertheless it was a bit of a revelation to me.
So basically I answered my own question about getting rid of the second counter in a simplified phaser algo. What I came up with is this:

   add hl,de
   ld a,h
   add a,c            ;C holds "second counter" offset
   and h               ;xor|or|and
   out (#fe),a

Now isn't it interesting how, by just swapping two bytes, this can be transformed into a regular "threshold" implementation? And yet this piece of code was derived from a Phaser implementation.

Hmm, in its current form it burns a lot of registers for the buck, I'd say. But generally speaking, anything that does pitch slides is always interesting. Do you think there's any chance to turn this into a vibrato effect somehow?

Meanwhile, I got permission from Rui, so find attached the source for his "WPDM16" player. A few notes:
- main.asm is the latest version. It does not attempt full PDM mixing, but rather a simplified version thereof.
- main_old.asm is an earlier version. Not sure if this one is working at all, so I include it mainly to illustrate how the player developed over time.
- Sample data should contain only signed offsets from -64 to +64. However, as I mentioned mixing is unreliable, so I created some samples that would mix with reliable results, but violate the specs.

Ok, gotcha. Interesting point indeed. Well, it can always be faked via digi method (as can any other waveform at a minor cost), but the real nice thing would be to exploit this via an actual algorithm. So in abstract terms, the question would be how to translate the amplitude levels in H into the time domain. Pity that it doesn't work with pin pulses, that would've been my first try, too. Hmm, what about phase inversion? As you may remember volume can be controlled like this:

add hl,de
ld a,h
cp #80
sbc a,a
out (#fe),a
exx
add hl,de
ld a,h
cp #80
sbc a,a
out (#fe),a

where the offset between HL and HL' will determine the volume (HL=0, HL'=#8000 is most quiet; perceived volume change is logarithmic). Perhaps it's possible to modulate HL' by H somehow (HL' += (256 - H) or something like that)?

@Hikaru: I don't quite understand your sample code. Is the .lvNN part executed every time, and then it will jump to .lv00-.lvXY, from where it'll loop back to .lvNN? Is beeper turned off before executing .lvNN? Wouldn't that give an overall very low volume?

Another thing that I was wondering about. In BetaPhase, phase channels are calculated as

   add hl,bc
   ex de,hl
   add hl,bc
   ld a,h
   xor d            ;or|and|xor
   out (#fe),a

which saves at least one register pair compared to a full Phaser implementation. During testing, I realized that actually 8-bit frequency dividers are enough in conjunction with scalers. So the above could be rewritten as

   ld hl,0
loop:
   ld a,b
   add a,nn
   ld b,a
   sbc a,a
   add a,h
   ld h,a
   ld a,c
   add a,nn
   ld c,a
   sbc a,a
   add a,l
   ld l,a
   xor h
   ds 2             ;2x scaler (rrca/rlca)
   out (#fe),a

freeing up another register pair in the process.
So here's the question: Can't  we get rid of one of the counters somehow (H,L in the above example)? In other words, is it possible to generate similar bitstreams as above (or at least something that offers timbre variation), but with a combined upper counter byte for both of the operators?

Not sure I understand correctly what you mean, could you provide a pseudo-code or asm example?

The only thing I could think of right now would be to implement it via a digi core (like in fluidcore, zbmod, etc). But that would be pretty inefficient, as you'd need 4 shifts to derive a suitable volume value from H. So pointing to a predefined table of wave data would be much faster (but at the cost of using up an extra register, of course).

Speaking of digi core, there is a phenomenon that I haven't quite understood yet. When the overall calculated volume is >50% for longer periods, the actual output volume starts to ramp up, producing a saw-wave like timbre (check octode2k16, it is very noticable in the demo tune, when bass kicks in). My assumption was that this happens because the speaker cone does not have enough time to retract in "off" periods, and thus will start to ramp up volume. However, I made some code to specifically trigger that behaviour (by keeping calculated volume continually above certain thresholds), and it wouldn't produce any conclusive/consistent results.

Hmm, interesting. As far as I understand the schematics (read: not very far), it might only affect RF out, though?