Search options (Page 24 of 39)

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?

Alright, we've got a working PhaseSqueek config! It's pretty complete, except that MDAL doesn't support tables that aren't linked from a pattern yet.
For example something like this doesn't work yet:

:SEQUENCE
    pattern1
:pattern1
    A=c1, FX=fx1
    .
:fx1
   A=c1
   A=d1
   A=e1
   FXJUMP=fx2
:fx2
   A=f1
   A=g1
   FXJUMP=fx2

I have to say, MDAL makes things easier, but the engine is still a major p.i.t.a. to use. You have to be very careful especially when constructing tables, because of the data format quirks. For example, if you have A and B set in your pattern, and want to use a table that modifies A, then you should set B again at the start of the table. This is because the player expects a value for B when A is set, but mdalc has no means of knowing what that value should be, and thus will fall back to the default value if you don't tell it to do otherwise. (Setting the value once is enough, mdalc will use the value that was last set from this point on). Likewise, SIDA requires SIDB, ESA, and ESB and vice versa. Also, when in doubt, use PAB/PCD=0 to reset the phase.

I've got some very good news: The core table parser is implemented and working. In other words, MDAL just generated the first complete and (more or less) working music.asm for PhaseSqueek. There's a number of things that still need tweaking, but we're definately getting there.