Time for Music

Phil Griffin, West Midlands


Issue 6

Nov/Dec 83

Next Article >>

<< Prev Article



The first long program that I wrote for the ATARI included an opening tune which was written as a separate program to be merged in at the end. Everything went reasonably well with the main program and, at long last the great day came when I slotted in my 'musical masterpiece'. I eagerly ran the completed program and, horror of horrors, found that my original composition had ended up as something of a death march. It was quite easy to speed things up by reducing the length of the FOR ... NEXT delay loop that I had used, but it set me wondering as to why the problem had arisen in the first place.

It appears that the longer a program gets, the longer it takes for a FOR ... NEXT loop to be executed. The problem can be eased by placing the delay loop as a subroutine early on in the program but the resultant benefit is minimal. Programs which contain music normally store the 'notes' to be played in DATA statements and use the READ command to place the required values in the variables included in the SOUND statements. You will find that placing the DATA statements early on within the program will normally prevent any 'jerkiness' from the sound when the notes are changed.

Luckily, you don't have to rely wholly on FOR ... NEXT loops for your timing requirements as the ATARI has an extremely versatile set of internal counters held in the Operating System at locations 18, 19 & 20. These counters are ideal where a precisely timed delay or routine is required. As with any Basic program however, the length of the program will still have an effect, but the timing provided by these locations will be constant and any slowing down will normally be negligible.

The three locations are inter-related and on power-up of the computer, the contents of each location is set to 0. Location 20 then starts to count until it reaches 255. On the next increment, location 20 fails to 0, while location 19 increases by 1. This sequence continues until both locations 20 and 19 contain 255. On the next increment of location 20, location 18 increases by 1 while locations 20 and 19 fall to 0. When all three locations contain 255, the next increment of location 20 causes them all to fall back to 0, so starting the whole cycle again. You can see from this that location 20 is the 'trigger' for location 19 which is in turn the 'trigger' for location 18.

The rate of increase of the value held in location 20 is related to the frequency of the mains electricity system. In America, the system is at 60Hz, while in Britain a frequency of 50Hz is used. This means that, in this country, after an initial reset to 0, a value of 50 would be held in location 20 after one second, a value of 100 after two seconds and so on. In America, the values held after the same intervals would be 60 and 120 respectively.

AtariLister - requires Java

A timing in excess of 5 seconds or so will involve location 19 and possibly location 18. Probably the easiest way to time say, 1 minute, is to convert these locations to 1/50ths of a second (1/60ths in the U.S.A.) and compare the resultant figure with the one required. The Timer program shows how this could be done.

The program contains lots of REM statements which should make it easier to follow what is happening. Line 90 contains three PEEKs which read the contents of the counters. The values contained in locations 18 and 19 have to be converted to 50ths of a second (as in location 20) and this is done in the program by multiplying the values by B and A respectively. The buzzer soundings and the delay are included in case you want to check the timing with a stopwatch. You will find that the routine's timing comes out at just over the minute - but don't forget that the program is written in Basic and there is bound to be an element of 'human error' in operating the stopwatch.

I have included a program containing the tune which started this all off in the first place and it now contains the improved delay routine. The main melody and harmony (voices 0 and 1) consist of a sequence of notes which remain the same throughout. The variation is produced by altering the accompanying 'chords' produced by voices 2 and 3.

AtariLister - requires Java