Hmmm....

I'm been on and off doing a new c64 music player / editor... and shelved it during the summer (made lots of progress on it when I was off work Ill !!) , and then later got a bit sidetracked with BBC sprites and other real-life (tm) stuff....

I'm thinking of trying to do some cross devs if/when I get my 'music' hat on again...

For instance my C64 Game Aqaurius, as discussed in the C64 > BBC sprite conversion thread has so far had two versions of the music..... The first player/editor I wrote myself and my mate Jason did a tune using it.... He then wrote another player, and re-mixed the tune..... I've been mucking about converting the song/sound data from 'one of his players' to a new c64 player/editor and made quite a bit of progress... but I would need to check the 'new tune' format against the player version I've been playing with/converting....(not a big issue to be honest).

So.... Cut to the chase.... I'd like so see if I can get some 'colin known' c64 note/song data playing on the bbc !!!

Now.... I'm not quite sure where to start......

Currently the music data is in a quite memory inefficient format, so I may look at trying to compile the data to note lengths, amongst other things (say instead of having a Soundtracker mod type format) - This will be done very late on, if I get around to it !!! - I'm not going to worry about this for the moment !!- I use 2 bytes per note... a note and an instrument.... but waste bytes inbetween notes... for blank steps.... (each segment of tune in my old player used 128 bytes for 64 sequence steps - get the idea ?)

Code is obviously in c64 / sid format... Should not prove to be a major problem to convert.... I'd lose some details like different waveforms and effects like ring mod and sync.... but won't loose any sleep !!! - and I'd have to use the Noise Channel to emulate the noise waveform obviously....

Q1) I'm more familair with writing directly to hardware registers of sound chips, rather than doing 'bios' system calls..... Am I going to run into snaggsville here.... IS IT SAFE TO WRITE DIRECTLY TO MEMORY ???? (I'll be going for a BBC B model)

Q2) Do I need to disable the Native Sound software that might cause conflicts - eg... by not calling any interupt services ?

Q3) I presume that I will have to roll my own software ASDR envelopes, as we only have a volume and pitch for each of the voices... 3 Square Waves and Noise on the 4th channel ....thats all you get on the BBC... is this right ?

Q4) Is there a frequency / note / values table kicking around ?? (I've not looked to be honest) - I've obviously got a C64 version, but nothing for the bbc for now... I presume this would be in the advanced manual or whatever... (For the c64 - I use 2 bytes per note table entry - a high and low byte value and I cover a few octaves - 12 notes/24 bytes per octave)

Cheers, Colin

Here is an old C64 Disk of my music editor.... including the Origonal Aquarius Game Tune ( Jase Toon ) - You load this image into a C64 Emulator like VICE.... Pick Jase Toon, run it, then once it boots up.. you press the ` Key (to the left of 1 on the pc keyboard) to start/stop it playing.... Please don't laugh at the other tunes on the disk !! (that I did) - It was all work in progress in 1991 !!!

Wow.. is this really 18 years old !! - Good god !!! (and was hand coded in a m/c monitor line by line ... didn't have an assembler or dev system to hand at the time, lol !!!)

Enjoy... Colin .. PS.... please DO NOT spread this file around.... I don't want it to find its way into the HVSID archives just yet, lol !!! ( I worked with my Graphics Guy Alan Bond this year and we got HIS tunes into the HVSID collection Number 50, that was done in Jasons Editor/Player - but thats all I want to do for now - thanks)

Hey Colin,

Yes, it's perfectly fine to write to the sound hardware directly on the Beeb, and more or less everything you need to know about it is documented in the Advanced User Guide.

A few points you need to know: the keyboard and the sound chip share the same hardware addresses - accordingly, there are some things you need to do in order to select one or the other.

You remember in the keyboard reading code, the set up looks something like this:


The sound chip is also addressed via $FE41 (or $FE4F), but in order to access it, it's necessary to first write the desired value to $FE41, enable the sound chip output for 8us, and then disable it again, like this:



As long as you don't let the OS interrupt handler in at all, you can probably just set up $FE42 to contain $0F right at the start, and leave it there.

I don't know what happens if keyboard is enabled and then (for example) an interrupt occurs and tries to write to the sound chip. My guess is that the sound will be lost, but perhaps TomW knows something about that. So, for safety, you should disable interrupts while checking keys, or ensure that the key reading will never happen during your periodic interrupt (VSync or timer) which updates the sound.

The other thing you need to know is that, when writing the pitch of a tone to a sound channel, the value written ('n') is calculated like this:
where n can range from 1-1023. Using the highest value of n (1023) results in a lowest possible frequency of about 122Hz.

Given that the frequency between one semitone and the next increases exponentially (multiply a frequency by 2 to the power of 1/12th to get the frequency a semitone higher), you'll need a table in order to look up all the semitones or half-semitones for the lowest octave. You can then get the values for higher octaves by dividing these values by 2, 4, 8, etc.

Sorry, it's all a bit of a rushed tutorial, but if you need anything explaining a bit better, give me a shout!

As you can see, it's all a little involved, which is why most games just use the OS sound routines. However, for just that little extra speed and flexibility, it's worth 'doing it yourself'!

Oh, and to answer your questions directly:

See my post above

Yes, if you're going to roll your own sound code, you may as well disable the OS entirely, by simply returning from your IRQ handler with:instead of JMP()ing to the OS handler address. Then you also have the freedom to use the timers at $FE44-45/48-49 as you wish.

Yes. I always hooked sound update to the VSync interrupt, so that it updates pitch and volume of each channel every 1/50th of a second. The OS sound routines update every 1/100th of a second, but I always found this to be more than necessary!

The noise channel is a curiosity - it has two modes: white(ish) noise, and 'periodic' noise, which in fact is a low-pitched tuned note with a totally different timbre to the square wave tone generators. It's the closest you can get to an alternative waveform on the Beeb, and also because it's much lower in pitch than the other tone generators, it's sometimes used to create a bassline. The limitation of the noise channel is that, when used standalone, it can only be set to three predefined frequencies. However, there's also a mode which allows it to take on the pitch of one of the tone channels - so, at the expense of a one of the other channels (which has to have its volume set to silent), you can create 'tuned' noise.

As I mentioned above, you can build a table for an octave's worth of data, based on the fact that the pitch is a 10-bit value, where 1023 is the lowest note, and subsequent semitones are reached by dividing this value by 2^(1/12).

In BeebAsm, you could construct a quarter-semitone pitch table (which should be fine-tuned enough for decent sounding pitch envelopes) like this:(I'm not sure how to build tables in Swift).

To get the pitch value for higher octaves, just shift this 10-bit value right once for each octave higher.

There's a further optimisation to be made, in that the contents of pitchtabhi are only ever 3 (for n=0..19) or 2 (for n=20..47), so you don't actually need to store pitchtabhi at all - instead just some code like this will do the job:

Hope this is a little bit of help to get started


Edit: Just remembered that when writing the frequency to the sound chip registers, it's not split into 8 bits low / 2 bits high like those tables above. So you might want to actually split the tables in a more useful way, i.e. 4 bits low / 6 bits high. But then you have to be careful when shifting the values right to reach higher octaves, to ensure that the carry from the high byte reaches bit 3 of the low byte. Remember you have 8us spare every time you write a sound register, which is ideal for doing these kind of calculations

Or to avoid the shifting, you can just extend the table beyond 48 entries, so there's an entry for every note in every octave. But, for 4 octaves, this is 384 bytes of tables, which sounds like a lot on a memory-challenged Beeb!

Replying to myself again....

I just took a look at how OS 1.20 deals with converting sound pitch values from quarter-semitones to hardware values.

You can see the routine here, from ED16.

The OS uses an even smaller table, in fact, just 24 bytes! This is a lo/hi table of the lowest octave, one entry per semitone. Quarter-semitone fractions are handled by storing a delta value in the otherwise-unused top 4 bits of the high-byte table. This delta value is subtracted for every quarter semitone higher than the base note, which works because, within a semitone, the function is virtually linear.

Higher octaves are also handled by dividing the value repeatedly by 2.

Maybe it's sufficient to just store semitone values, and a delta table per note, so that pitch tremolo can be applied?

My guess is it's what's happening with NeilB's Sparse Invaders - the keyboard and sound chip conflict and you get junk written to the sound chip.