Search options (Page 39 of 40)

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.

Yes, it works! Thanks a ton, krue!

Yippee! Yes, Phaser2! I'm very, very happy right now.
However, not completely happy because unfortunately I get an "not a valid win32 executable" error when trying to run this (XP SP3).
Ok, I'll see if I can compile it from source for Linux. Though without krue's compile guide I think it'll be tricky...

edit: not getting very far:

angelscript/scriptarray/scriptarray.cpp:15:34: error: ‘asAllocMem’ was not declared in this scope
 static asALLOCFUNC_t userAlloc = asAllocMem;
                                  ^
angelscript/scriptarray/scriptarray.cpp:16:34: error: ‘asFreeMem’ was not declared in this scope
 static asFREEFUNC_t  userFree  = asFreeMem;
                                  ^
angelscript/scriptarray/scriptarray.cpp: In member function ‘void CScriptArray::Precache()’:
angelscript/scriptarray/scriptarray.cpp:1525:11: error: ‘class asIScriptFunction’ has no member named ‘GetParam’
     func->GetParam(0, &paramTypeId, &flags);
           ^
makefile:6: recipe for target 'angelscript/scriptarray/scriptarray.o' failed
make: *** [angelscript/scriptarray/scriptarray.o] Error 1

Thanks Shiru, that's a great explanation.
Now there's one thing that I still don't understand myself - if you or someone else has the time, please do explain: How do engines like e.g. Zilog's Squeeker or the infamous Spectone-1 demo (the one in the "hidden" part that can be reached with key A) work?

Part 7: Variable Pulse Width

Alright, if you've come this far, you should be able to write a pretty decent basic 1-bit sound routine. But the real fun of 1-bit coding has only started. From this point on, coding for 1-bit sounds becomes somewhat of an art form - you've got to use your creativity and imagination in order to build a routine that does something out of the ordinary.

I'm by no means an assembly expert, and don't understand half of what all these crazy beeper engines out there are doing. So I can only share those few tricks and techniques that I have so far discovered/reverse-engineered/been told about.

Ok, let's talk about variable pulse width. Varying the pulse width has a number of useful effects, most importantly the ability to produce more interesting timbres when used in conjunction with the pulse interleaving method. (In conjunction with PFM, it can be used to create volume envelopes, but this is not what this part of the tutorial is about.)

Imagine a classic pulse interleaving routine with 16-bit counters, as explained in part 4. The basic procedure for updating a channel's state and counters is:

  counter := base + counter
  IF carry THEN
    state := state XOR ch_toggle
  ENDIF
  OUTPUT state

This will output a square wave with a 50:50 duty cycle, because half of the time the output is 0, and the other half it's 1.
Well, there is another of way of doing this.

  counter := base + counter                       ld hl,nnnn \ add hl,bc \ ld b,h \ ld c,l

  IF counter < 8000h THEN                         ld a,h \ cp #80
    state := off                                  ld a,0 \ jr nc,skip
  ELSE
    state := on                                   ld a,#10
  ENDIF                                    skip:
 
  OUTPUT state                                    out (#fe),a

So, instead of waiting until the counter wraps from FFFFh to 0h, we now check if it has wrapped from FFFFh to 0h or from 7FFFh to 8000h. So in effect we change the state twice as often, but we will still get a 50:50 square wave. Now what happens if we compare against a value other than 8000h? You probably can guess: Yes, that will change our duty cycle. So, to get a 25:75 square wave for example, we'd compare against 4000h, for 12.5:87:5 we compare against 2000h, and so forth. Simple, right?

If only we wouldn't have to deal with that ugly conditional jump that ruins our timing. Well, in Z80 asm there's a handy trick. It is used in Shiru's Tritone, for example.

  ld hl,nnnn \ add hl,bc \ ld b,h \ ld c,l       ;do the counter math as usual
  ld a,h \ cp nn                                 ;compare against our chosen value
  sbc a,a                                        ;A will become 0 if there was no carry, else it becomes FFh
  and #10                                        ;ANDing 10h will leave A set to either 0 or 10h, depending the on previous result
  out (#fe),a

Part 5: Improving the Sound

You've followed this tutorial series and have come up with a little 1-bit sound routine of your own design. Only problem - it still sounds crap - notes are detuned, there are clicks and crackles all over the place, and worse of all, you hear a constant high-pitched whistle over the music. So, it's time to address some of the most common sources of unwanted noise in 1-bit sound routines, and how to deal with them.

Timing Issues

In order to keep the pitch stable, you need to make sure that the timing of your sound routine is as accurate as possible, ie. that each iteration of the sound loop takes exactly the same time to execute.

Let's take a look again at the first example from part 1. We can see that that code is not well timed at all:

soundLoop:
  
       xor a                    ;4
       dec b                    ;4
       jr nz,skip1              ;12/7
       ld a,#10                 ;7
       ld b,c                   ;4
skip1: 
       out (#fe),a              ;11
  
       xor a                    ;4
       dec d                    ;4
       jr nz,skip2              ;12/7
       ld a,#10                 ;7
       ld d,e                   ;4
skip2:
       out (#fe),a              ;11
  
       dec hl                   ;6
       ld a,h \ or l            ;8
       jr nz,soundLoop          ;12
                                ;78/92t

Due to the two jumps, there are four different paths through the core (no jump taken, jump 1 taken, jump 2 taken, both jumps taking), and the sound loop length thus varies up to 12 t-states - that's more than 15% of the sound loop length, and therefore clearly unacceptable. We need to make sure that the sound loop will always take the same amount of time regardless of the code path taken. One possible solution would be to introduce an additional time-wasting jump:

soundLoop:
  
       xor a                    ;4
       dec b                    ;4
       jr nz,wait1              ;12/7----
       ld a,#10                 ;7
       ld b,c                   ;4
       nop                      ;4-------7+7+4+4=22
skip1: 
       out (#fe),a              ;11
  
       xor a                    ;4
       dec d                    ;4
       jr nz,wait2              ;12/7
       ld a,#10                 ;7
       ld d,e                   ;4
       nop                      ;4
skip2:
       out (#fe),a              ;11
  
       dec hl                   ;6
       ld a,h \ or l            ;8
       jr nz,soundLoop          ;12
                                ;100/100t
                
wait1:
       jp skip1                ;12+10=22
       
wait2:
       jp skip2

There are other possibilities, but I'll leave that for another part of this tutorial.

Row Transition Noise

A common moment for unwanted noise to occur is ironically not during the sound loop, but between notes - the moment when you're reading in new data and updating your counters etc. This is called row transition noise.

Row transition noise is very difficult to avoid. Your focus should therefore be on reducing transition noise rather than trying eliminating it. The key to this is to read in data as fast and efficiently as possible. Not much else can be said about this, except: Make sure you optimize your code. For starters, WikiTI has an excellent article on optimizing Z80 code.

Theoretically, there is a way for eliminating transition noise, though in practise very few existing beeper engines use it (Jan Deak's ZX-16 being a notable example). That way is to do parallel computation, ie. read in data while the sound loop is running. Obviously this is not only rather difficult, but also it is usually only feasible on faster machines - on ZX Spectrum, it will most likely slow down your sound loop too much.

Which brings us to another problem...

Discretion Noise

Discretion noise, also known as parasite tone, commonly takes the form of a high-pitched whistling, whining, or hissing. It inevitably occurs when mixing software channels into a 1-bit output and cannot be avoided. It is usually not a big deal when doing PFM, but can be a major hassle with Pulse Interleaving. The solution is to push the parasite tone's frequency above the audible range. In other words, if you hear discretion noise, your sound loop is too slow. As a rule of thumb, on ZX Spectrum (3,5 MHz) your sound loop should not exceed 250 t-states.

Let's take a look at the asm example from part 4 again. At the end of the sound loop, there is a relative jump back to the start (jr nz,soundLoop). A better solution would be to use an absolute jump (jp nz,soundLoop) instead, because an absolute jump always takes 10 t-states, but a relative jump takes 12 if the jump is actually taken, which we assume to be the case here.

Also, leading up to the jump we have

   dec ix
   ld a,ixh \ or ixl
   jr nz,soundLoop

which takes a whopping 38 t-states. It may be a good idea to replace it with

   dec ixl
   jr nz,soundLoop
   dec ixh
   jp nz,soundLoop

This will take only 20 t-states except when the first jump is not taken. It will introduce a timing shift every 256 sound loop iterations, but this is usually not a major problem, as it happens at a frequency below audible range.

I'll cover some more tricks for speeding up synthesis in one of the following parts.

IO Contention

This section addresses a problem that is specific to the ZX Spectrum. You can most likely skip this section if you're targetting another platform.

IO Contention is an issue that occurs on all older Spectrum models up to and including the +2. The implication is that in certain circumstances, writing values to the ULA will introduce an additional delay in the program execution. You don't need to understand the full details of this, but if you are curious you can read all about IO contention here.

What's important to know is that delay caused by IO contention affects our sound loop timing. Which is bad, as I've explained above. For sound cores with only one OUT command the solution is rather trivial: You just need to make sure that the number of t-states your sound loop takes is a multiple of 8. For ideal sound in cores with multiple OUTs however, the timing distance between each OUT command must be a multiple of 8. Naturally this is pretty tricky to achieve (and chances are your core will sound ok without observing this), but keep it in mind as a general guideline.

Edit 15-12-01: Added/changed info as suggested by introspec.

Part 3: Calculating Note Counters

So you've got your sound loop and your data loader all set up, but now you need to actually fill in some music data. For that, you will need to know how
to calculate the note/frequency counter values.

Basically, all you need to know is the magic formula

fn = int(f0 / (a)^n) 

where...
... f0 is the base note counter value you want to use
... n is the distance to the base counter value in halftones
... fn is the frequency of the note n halftones away from the base note
... a is the twelth root of 2, approx. 1.059463094

Unless you want concert pitch, it doesn't really matter so much which base value (f0) you use, so you might as well use something high, e.g. 254.
Now, to calculate the value for the base note plus one halftone, you do:

f1 = int(254 / 1.059463094^1) = 239

For the base value plus two halftones, it's

f2 = int(254 / 1.059463094^2) = 226

As you can see, the lower the note, the higher the counter value. This makes sense because we decrement these values in the sound loop. A higher value means it takes longer for the counter to reach zero and reset, therefore the output is activated/toggled less frequently - which of course results in a lower frequency.