100% on test Mod!

At last! 100% of the way through my chosen starting module (Theme tune to Alf by Trash).  Although I am a little sick of hearing it now oddly enough it mostly sounds (to me) as it should do.  Other ears have heard some tuning issues, but only in some places and I suspect this may be due to the rather speedy coding of some of the effects.

As the code to read the actual pattern data was so bodged and crufty and incomplete (anything that used more than 15 samples was never going to work), I decided to completely rip it out and rewrite, but adding in hooks for various bits along the way and knowning now what I didn’t know when I 1st wrote it.

Took me longer than I planned originally, but the final result was certainly worth it!  Adding effects to this new build is super simple.  There are 15 primary effects, with a further 15 sub effects.  For now I am concentrating on the primaries.  I therefor have a list of Addresses of the code to produce the desired effect.  To select the correct effect code the effect number is added as an offset to the address of this list, the program counter is then jumped to the address stored there (not before pushing the desired return address on the stack for the RTS at the end of the effect) and thats it.  When I come to write a new chunk of effect code I simply write it and then update the list of pointers.  Jobs done.

I still have around another 21 effects to code, I am quite pleased with the pitch slide effects I have coded tonight despite me being suspicious that these may be the cause of the out of tune behaviour and also being incredibly simple 😀

To further the work on the player I have a more complex effect rich module to work through now, one of my old favourites back in the day.  It has already identified and helped me resolve a few bugs I wasn’t aware of.  Really enjoying this project 🙂

Moar success!

I cannot believe how well this is going!  not only did my plan for volume adjustment work perfectly, I managed to write the whole thing in RISC on the DSP without any screwups!  Even managing to craft a procedure call with appropriate return 1st time!  Rather pleased with myself.

Some more cracks are starting to show in the less well planned code 🙂 it is like building a wall ontop of a badly done foundation, the more you build the more the foundation crumbles and needs bodging to keep up.  The re-write to RISC will be fresh at least, all though lovely extra registers to play with should make this run even sweeter.

In addition to my volume success I finally twigged on the period values being used within the tracker files, and believe I have actually tuned this to play at the correct pitch now, making it sound even better!  I tried a different tune and this highlighted a load more bugs I need to fix (ignoring the additional effects it uses for now), and yet more crumbling code as well as illustrating a possible need for multiple format detection.

Going to finish up early tonight as I want more sleep and I also need to build a VTES deck for playtime tomorrow 🙂

Patience…

I really do like to test myself :/

My plan (coding wise) for this weekend was to get stuck into some effects in the playback of the tracker.  I added a simple jump and also sample looping quite easily (although they have both proven how code and fix is a terrible development methodology 🙂 a re-write is on the cards.. but still a prototype 🙂 ).  For my next feat I though adding volume adjust in would be easy enough, plus the module I am working with features a gradual volume increase over a looped sample at the start of the tune, so a good test.

The volume setting for modules is a range, 0-64, 0 being off and 64 being full volume, 0-100%.  My initial thoughts were a lookup table, so for any sample value I would have a table of all 64 volumes, (I’d ommit 0% and 100% for obvious reasons), alas this would end up with a table of around 16KB, which whilst not a huge amount of RAM, is more than double the cache RAM of the RISC CPU, which as this is where I want this code ro reside and I don’t want it faffing about on the main bus any more than it needs too, pretty much rules that option out.  I thought on it a bit more, and played with some excel spreadsheets (spent most of my coding time playing with numbers in excel and drawing line graphs etc!).  I could half the table if I only considered samples of 0-127 and then used this for negative values also, I could possibly shrink it further if I only consider 33-63 as the values of interest as I could use a right shift to give me 50%.. these solutions all seemed workable, but that lookup table was still around 1KB at the most reduced size I could think of, more than I was hoping it could be.

So machine off and some PS3 time, films and Dead Space 2 (both relaxing and stimulating 🙂 ).  I then had an idea, which on paper looks like it will work perfectly, and given the range 0-64 makes perfect sense!  I am probably coming at this backwards but figuring this stuff out for myself is the one thing I do this kind of thing for, its where the buzz starts, ending with the implementation of working code.  Quite simply using arithmetic right shifts on the sample, I can generate 6 volume levels easily (7 if you count full volume), 50%, 25%, 12.5%, 6.25%, 3.125% and 1.5625%  now 6 doesn’t sound at all like 64 levels of volume adjust… however, if you combine those 6 in the appropriate combinations you can produce any of the valid volume levels in the range of 0-64!  But how to determine the combination? simple, the binary of the volume level value indicates which of those volumes need to be added together to produce the desired final volume!

So 61 would be 95.3125% in binary 61 is 111101 so we add together 1.5625+12.5+25+50 = 95.3125   HURRAH! 😀

Of course this will require the original sample is processed a maximum of 6 times (with the output of each pass being added together), but this is not a huge amount of processing, even for multiple channels.  I may yet find a neater approach, but this one feels right to me at the moment.  Now I just have to wait until after work tomorrow before I can implement it! curses! 🙂

Success!

I had a day off following the Computer Club at The Lass on Wednesday, my sole plan for the day, to sort out my tracker distortion issues and make some progress.  It was a very successful day!

I attempted a few different approaches to resolve the distortion, having the playback routine count how many samples it had played, and the render code then generating that number of samples.  Which worked to a point, but just simply delayed the occurrence of the distortion by a chunk of time, and also increasing its duration.  It was clearly a slow drift between the two functions.  I tried having the render code monitor the playback position and pause or halt if it caught it up, this generated some weird audio effects or maxed out the 68K to 100% as it effectively spent all its time sat behind the playback trying to generate sufficient samples for the next VBI.

Thankfully Cyrano Jones popped up on IRC and whilst discussing stuff he suggested trying a double buffering technique.  I wasn’t convinced, but it was something I hadn’t tried.  After some battling and issues due to make not assembling all the files when it should of (I now use make clean a lot more 🙂 ) This proved a perfect solution!  As long as the output buffers are suitably sized for the maximum number of samples per VBI at the given refresh rate and playback rate all is good!  I must have spent 10 minutes listening to the same pattern play listening for the distortion, it didn’t come!

With the distortion issue fixed I now needed to get the other 2 channels in the mix.  Due to the way I am heavily using CPU registers for render variables, this was a little more complex and hacky than I would have liked, but this is a prototype so meh, I am looking forward to having the full 64 32bit registers of the DSP to abuse 🙂

The way I am writing the sample data to the DSP buffer is as a single 32bit long, (4x 8bit channels, handy).  This allows the DSP code to pick up all 4 channels from a single load, which also gets around the limitation that the DSP can only make 32bit loads and stores when addressing it’s own cache RAM.

As each pass through the render code generated 2 8bit channels at a time, it seemed logical to simply write these 16bit words to the DSP RAM, (improving efficiency as the DSP and 68K only have 16bit data bus width) skipping over the 16bits for the next 2 channels free for when those channels were computed later.  Or so I thought…. All hail the wacky hardware bug and all it’s glory :/  I soon discovered that DSP RAM should only be written to as 32bit longs from the 68K! otherwise it has a habit of corrupting the other half of the long!  This means the first two channels are written in the high end of a long write, then the last two channels are or’d into the low half of the long :/  so many wasted ticks!

With all 4 channels going, as well as all this 32bit long memory accessing wastage CPU usage is back up to around 40-45%.  At least its less than 50% and I am sure with a lot of optimization I would be able to claw some of that back.

However I now need to start working on the code that reads the actual song data and adding the effects, which is proving another challenge due to the way I have written some of the render code.  A fresh start may be needed based on what I have discovered.  I am completely psyched with the fact this thing actually plays a mod from start to finish and sounds like what it is supposed to! 😀

Of course I have found a few issues in there too which will be fun to fix, but its all progress 😀