Search options (Page 37 of 40)

Yo Tufty, here's the .tap for the qaop demo track. It was hand-coded in asm so there's no XM for this one

Thanks for the cheers, guys

I've found and (hopefully) fixed a few bugs in the qaop and quattropic XM converters, so please re-download.
Also, I've added a standalone executable converter to the quattropic package, so now you can do things without using Perl. However, I just started to learn C++ yesterday, so it's probably loaded with bugs. But I'd still appreciate if you guys gave it a try and let me know if you run into any problems with it.

New engine for today is coming in a couple of hours, stay tuned

A new day, a new engine.

Day 2: quattropic

- 4 channels of square wave sound
- full duty cycle control
- one of the channels can play noise or fast pitch slides instead of regular tone
- said channel also supports note cut
- 16-bit frequency resolution
- 15.6 KHz mixing

example tune
download
source (includes XM converter)

quattropic is the big brother of ntropic - twice as many channels, and you can even vary the sound of the noise. This comes at a small price, however: There is no per-row speed control in this engine. (It could be easily implemented, but would take another 2 bytes of song data per step.)
quattropic is a little easier to simulate in XM, but still you won't get the full range of sounds out of the template, unfortunately.

Vote page is up!

Voting deadline is Sunday, September 20th.

Hmm, sounds pretty good to my ears I especially like that drums and tones are very well balanced, volume wise.

And yes, the "code" part of the compo will indeed most likely not happen due to lack of entries. So I think I'll just release my own entries one by one over the course of the coming week.

I'm curious about your "realtime saw wave" engine, too, sounds like a very interesting concept.

I'd go for option 2. Unless you preshift note values like in the example above, you never need bit 7, so you can use that to signal detune. Option 1 would be not so practical, because with 16-bit frequencies, you typically need to recalculate the detune value specifically for every note anyway.

Option 2 then again boils down to two choices. Either you interpret this and the following byte as a direct frequency value (ie. skipping the table lookup), which would limit frequency range to 0-$7fff, or you interpret it as note value, followed by a byte-length detune value, which you'd then multiply with e.g. (hi-byte of the frequency/16) or so to get a decent detune range.

Wow, didn't know this existed. Though one has to wonder why they don't make full use of the 6-bit DAC. But I assume it's like on Dragon/CoCo - generating 1-bit music might simply be faster than using full 6-bit DAC. In fact in the contest, we'll have a CoCo 1-bit routine

Not contemporary and not ZX, but there are a few ones from the early days of 1-bit music:

Rekengeluiden van PASCAL - VA (1962)
D21 - In Memoriam - D22  - Göran Sundqvist (1970)

There are a couple more old ones, but I'll have to dig for those later.

Huhu xxl, do you still have Beep'em all 2600 somewhere?

Wow garvalf, that's a lot of spamming Thanks a ton for spreading the word!

You can actually combine those ideas. Let me explain...

Part 9: More Soundloop Tweaks

In this part, I'll discuss two advanced tricks that you can use to open up new possibilities and further speed up your sound loops. I've learned these tricks from code by introspec and Alone Coder, respectively.

Accumulating Pin Pulses

The first trick applies to the PFM/pin pulse method of synthesis. First, let's take a look again at our PFM engine code from Part 5, and modify it to use 16-bit counters.

BC = base frequency channel 1
IX = freq. counter ch1
DE = base freq. ch2
IY = freq. counter ch2
HL = timer

soundLoop:
       add ix,bc                ;update counter ch1
       sbc a,a                  ;A = #FF if carry, else A = 0
       and #10                  ;A = #10 || A = 0
       out (#fe),a              ;output state ch1
       
       add iy,de                ;same as above, but for ch2
       sbc a,a
       and #10
       out (#fe),a
       
       dec hl                   ;decrement timer
       ld a,h
       or l
       jp z,soundLoop           ;and loop until timer == 0

Now, instead of outputting the pin pulses immediately after the counter updates, we can also "collect" them. This will potentially save some time in the sound loop and will give better sound, because the pin pulses will be longer.

In the following example, register A holds the number of pulses to output, and A' will hold #10.

soundLoop:
       add ix,bc                 ;counter.ch1 := counter.ch1 + basefreq.ch1
       adc a,0                   ;IF carry, increment pulseCounter
       
       add iy,de                 ;counter.ch2 := counter.ch2 + basefreq.ch2
       adc a,0                   ;IF carry, increment pulseCounter

       or a
       jp nz,outputOn     
       out (#fe),a              ;OUTPUT state
       nop\nop\nop              ;adjust timing
       
                                ;now we can't use A to check the counter, hence...       
       dec l                    ;decrement timer lo-byte
       jp z,soundLoop           ;and loop if != 0
                                ;this is faster on average anyway, so use it whenever you can.      
       dec h
       jp z,soundLoop           ;and loop until timer == 0
       
outputOn:
       ex af,af'
       out (#fe),a
       ex af,af
       dec a                    ;decrement pulseCounter
       
       dec l                    ;decrement timer lo-byte
       jp z,soundLoop           ;and loop if != 0
                                ;this is faster on average anyway, so use it whenever you can.      
       dec h
       jp z,soundLoop           ;and loop until timer == 0

Even better, you can use this trick to simulate different volume levels, by adding a number >1 to the pulse counter on carry. Just don't overdo it, because eventually the engine will overload, ie. it will take too long until the engine works through the "backlog" of pulses to output. This method is used in OctodeXL, btw.

Skipping Counter Updates

You have a great idea for a sound core, but just can't get it up to speed? Well, here's a trick you can use to make your loop faster.
This trick is mostly relevant to pulse-interleaving engines with more than 2 channels.

The idea here is that you don't have to update all counters on each iteration of the sound loop. It is however important that you output all the states every time,
and that the volume (read: time taken) of each of the channels is equal across loop iterations.

Here's a theoretical, not very optimized example.

DE  = base frequency ch1
IX  = counter ch1
H   = output state ch1
SP  = base frequency ch2
IY  = counter ch2
L   = output state ch2
B   = timer

       ld hl,0                    ;initialize output states
       ld c,#fe                   ;port value, needed so we can use out (c),r command
       
soundLoop:
                         ;---LOOP ITERATION 1---
       out (c),h         ;12      ;OUTPUT state ch1
                         ;^ch2: 40
       add ix,de         ;15      ;counter.ch1 := counter.ch1 + basefreq.ch1
       out (c),l         ;12
                         ;^ch1: 27
       sbc a,a           ;4       ;IF carry, toggle state ch1
       and #10           ;7
       ld h,a            ;4
       ld a,r            ;9       ;adjust timing
       nop               ;4
 
                         ;---LOOP ITERATION 2--- 
       out (c),h         ;12
                         ;^ch2: 40
       add iy,sp         ;15      ;counter.ch2 := counter.ch2 + basefreq.ch2
       out (c),l         ;12
                         ;^ch1: 27
       sbc a,a           ;4
       and #10           ;7       ;IF carry, toggle state ch2               
       ld l,a            ;4
       djnz soundLoop    ;13      ;decrement timer and loop if !0