Search options (Page 39 of 41)

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

Ah yes, the famous Dancebit A true classic!

Gnnnnrrrrr! There goes my wonderful plan for a new 256b sample engine...

Just to clarify, plugging in earphones isn't harmful. Just don't do it during normal TI-OS operation, ie. plug them in after you've started DoorsCS/Mirage/whatever.

@introspec: hehe thanks It's gonna be a tough battle... TI has nearly the same setup as the Speccy, but it's also nearly twice as fast

Hmm, SilverLink works out-of-the-box for me (Debian+TiLP from the repos). Never had any probs with it.
I think the problem is that the cable is interpreted as serial when it is really USB. On the one hand it's not too surprising because originally GrayLink was a indeed a serial cable. Hmm... maybe you can force TiLP to use it as SilverLink via command line? Otherwise, if problems persist shoot Lionel Debroux (TilP dev) a mail, he's a really nice guy and he might be curious about this cable, too.

Hmm, if there's a memory problem you usually wouldn't be able to transfer it to the machine in the first place. Perhaps you can send me the problematic song file so I can have a look? Maybe I made an error somewhere...

Yes, undoubtedly so, because the rawp engine itself is rather huge. Best to recycle the player and just swap out the song data (have a look at rawp.asm, the pointer to the music data is on line 32)

Yes, 2.5mm jack suxx The unresponsiveness is due to the calculator picking up phantom voltage from the earphones. Plugging them in after you've started the shell should help to avoid the problem.

Yeah, my stupid server is down again.

Thank you for trying it out! Unfortunately this engine uses 8-bit frequency counters, so detuning is to be expected from upper 3rd octave on. I'm working on a version with 16-bit counters though.

Edit re: 83+ vs 84+. Starting with the 83+ SE, the processor can be used in 15 MHz mode, which is awesome. However, I don't own any calcs of this generation (yet), so I'm not supporting this. Also, the size of the Flash RAM varies among models (though it's not necessarily bigger on 84+ models). Other than that, the 83+ and 84+ are practically identical.

garvalf: Thanks, that is quite useful. I'll integrate that into the first part of the tutorial.
Shiru, Hikaru: Since Hikaru deleted his posts, I've moved the rest of the "discussion" to OT for the time being. Will delete it in a while if nobody objects.

I've never actually tested any of my software on TI-82 STATS. Supposedly it's fully compatible with TI-83, but it would be great to get some confirmation of this. Well, whatever you do, just don't get a TI-82 Parcus. Since years I'm trying to figure out why stuff doesn't work on it like it's supposed to, but in the end the answer remains: Because it just doesn't.

Amazing. Congratulations on this outstanding achievement, you've raised the bar to near unreachable levels once again!
Btw just recompiled 1tracker from source, still works fine with krue's patch.