Search options (Page 3 of 41)

Ah, good. I'm really too tired to dig into this today.

I wonder what causes that high-pitched whine. This and the slow speed makes me think that the engine isn't running at the 2MHz I was assuming. Are there any interrupts still active? Are there any additional delays when writing to the SN, or is it possible that video is causing some blockage?

Optimizing the data read will only get you so far. Since the overall volume is low, row transitions will always be noticable. You might gain more by writing to all 3 tone channels instead of just one, provided you can make the inner sound loop run fast enough.

You might also consider mapping each Tritone channel to it's own SN channel. That would make things less timing critical.

Spotted another one - you're missing the row length counting, ie.

    dex                         ;2  row length low byte
    beq .play_note              ;3 -- 95 ~ 21053Hz (original is 22876Hz)

    dey                         ; row length hi byte
    beq .play_note

where X should be 0 on init, and Y should be whatever Tritone spits out as row length. I don't have Tritone's data format at hand right now but iirc it should be the first byte of a pattern row.

Wow, didn't know Stephane Picq was still active

My French hasn't gotten any better over the years so I'm afraid listening to that much of it in one go will make my head explode, but somebody should pester these guys to play some modern 1-bit stuff.

Alright, so the gist of (equal volume) Tritone is basically this:

    ldx #$0                     ;   reset row length counter lo byte

.play_note
    clc                         ;2  update osc
.ch1_div_lo
    lda #$0                     ;2
.ch1_acc_lo
    adc #$0                     ;2
    sta .ch1_acc_lo+1           ;4
.ch1_div_hi
    lda #$0                     ;2
.ch1_acc_hi
    adc #$0                     ;2
    sta .ch1_acc_hi+1           ;4
.ch1_duty
    cmp #$0                     ;2  compare against duty threshold
    sbc .ch1_acc_hi             ;4  A = 0 on low half-cycle, FF on hi half-cycle
    and #%00001111              ;2
    sta SYSVIA_ORAS             ;4

    clc                         ;2
.ch2_div_lo
    lda #$0                     ;2
.ch2_acc_lo
    adc #$0                     ;2
    sta .ch2_acc_lo+1           ;4
.ch2_div_hi
    lda #$0                     ;2
.ch2_acc_hi
    adc #$0                     ;2
    sta .ch2_acc_hi+1           ;4
.ch2_duty
    cmp #$0                     ;2
    sbc .ch2_acc_hi             ;4
    and #%00001111              ;2
    sta SYSVIA_ORAS             ;4

    clc                         ;2
.ch3_div_lo
    lda #$0                     ;2
.ch3_acc_lo
    adc #$0                     ;2
    sta .ch3_acc_lo+1           ;4
.ch3_div_hi
    lda #$0                     ;2
.ch3_acc_hi
    adc #$0                     ;2
    sta .ch3_acc_hi+1           ;4
.ch3_duty
    cmp #$0                     ;2
    sbc .ch3_acc_hi             ;4
    and #%00001111              ;2
    sta SYSVIA_ORAS             ;2

    dex                         ;2  row length low byte
    beq .play_note              ;3 -- 95 ~ 21053Hz (original is 22876Hz)

    dey                         ; row length hi byte
    beq .play_note

If you want to use unequal volumes (which could definitely come in handy), you need to shift the outputs around a bit somehow. In the original unqual volume, the outputs are distributed at a ratio of 34:49:70 cycles.

As far as data reading goes, I didn't bother since you're probably better off just design your own data scheme.

Noise mode can be tacked onto this design easily by adding

    rol
    adc #0

after adding chx_acc_hi, and using #$2174 as frequency divider value. The duty setting will act more or less as a volume control on that. Or tack on the PWM sample code from SquatM, but beware that this engine is overall much quieter, so PWM samples at full blast may be too loud. Speaking of quiet, I think this will be the main problem with this code - it'll probably be too quiet on the SN, so you might want to write to all 3 tone channels instead of just one. Or even better, output each channel on its own SN tone channel.

As to why the sound is so noisy/muffled, I don't know enough about the beeb to help you there. Are there any waitstates/badlines/whatever it's called to be aware of?

Btw, that comment on youtube suggesting to use the shift register is a good lead, I think. Not necessarily as a hardware mod like the guy is suggesting, but as a means to offload some processing.

Ah, so we're targetting SN76489. I assumed there might be some sort of native device.

Would it be acceptable to leave Port B I/O in WRITE mode and only switch to READing between pattern rows? That would speed up things quite a bit.

Also, am I correct in assuming that I could just keep pumping out DATA bytes (LATCH = 0) to set the volume of a given channel?

Hello there bataais, welcome aboard! I'm liking a lot what I'm seeing on your blog. Our forum is mostly about music as you can see, but I'm very interested to hear more about your video projects as well.

Pah, kids and their hipster gadgets nowadays

There are plenty of z80 instructions which are neither 4 cycles nor a multiple thereof, so that statement is kind of bollocks. Sampling every 4 cycles should still be good enough though, since most beeper engines align output to 8 cycles. To do things properly however one should sample at every clock cylce, and then apply a low-pass at half the sample rate of the emulated output.

The PTC Sol-20 Music System is another (very early) example of this. Coincidentally it's also an 8080-based machine, though the Music System itself is an S100 card.

On ZX81 it's actually a little more complicated since you write to port #ff, but read from port #fe. So if you comment out lines 64-66 and 85-87, and change line 206 to 'ld bc,#01fe', you should be nearly there, save for the drums. Really, don't torture yourself with 1k2b though. that's a horrible piece of code. Funnily enough, these new engines I made (ulasyn and PhaserF) should be fairly straightforward to port.

What would be the challenge for adding it to 1tracker? The data format is quite similar to ulasyn's. In terms of interface, it could be shown as 4 channels, perhaps calling them 1A, 1B, 2A, 2B.

Btw forgot to mention in the readme that row length is 6-bit only, due to using the I register for counting.

Squashed one more bug today. Also tried to implement resonance, but either I'm doing it wrong, or the volume resolution is insufficient to do it. In any case, this should be it, not planning to do more work on this in the near future.

Would be great to have it in 1tracker. I'm not adding it to Bintracker yet, because the engine plugin format still isn't stable.

Aaaand voilà. Volume control implemented. Lower volume means less precision for the filters, of course. Updated source is on github, see above.

Now what I would really like to have is resonance. Not sure if it's actually possible with this setup. In any case I can't wrap my head around the math of it.

Ah, L/C/R panning definable in software, excellent. Like the idea of a RISC V MCU, too. How does it fare in terms of price, though? Mouser claims they're selling a ESP32-C3 for around 1€ over here, but pretty much any other seller is asking around 20€.